matteo

Thank you jbergler for the fix you provided - it got me back up and running again. For reference my ODroid N2 is running Armbian 23.8.1 Jammy from the eMMC with no micro SD card, and Ethernet is working fine with the 6.1.50-current-meson64 kernel.

I think I'm having the same issue with my Odroid N2 (Buster Server, 5.8, EMMC). I updated yesterday, and now it doesn't boot and there's no HDMI output. I haven't been able to identify the problem yet - perhaps I need to look into the USB-UART module. Upgrade: linux-image-current-meson64:arm64 (20.08.9, 20.08.18), linux-libc-dev:arm64 (4.19.146-1, 4.19.152-1), libldap-2.4-2:arm64 (2.4.47+dfsg-3+deb10u2, 2.4.47+dfsg-3+deb10u3), mariadb-common:arm64 (1:10.3.23-0+deb10u1, 1:10.3.25-0+deb10u1), linux-dtb-current-meson64:arm64 (20.08.9, 20.08.18), linux-u-boot-odroidn2-current:arm64 (20.08.1, 20.08.13), armbian-firmware:arm64 (20.08.9, 20.08.17), libldap-common:arm64 (2.4.47+dfsg-3+deb10u2, 2.4.47+dfsg-3+deb10u3), armbian-config:arm64 (20.08.9, 20.08.20), mariadb-client-10.3:arm64 (1:10.3.23-0+deb10u1, 1:10.3.25-0+deb10u1), mariadb-client-core-10.3:arm64 (1:10.3.23-0+deb10u1, 1:10.3.25-0+deb10u1), mariadb-client:arm64 (1:10.3.23-0+deb10u1, 1:10.3.25-0+deb10u1), linux-buster-root-current-odroidn2:arm64 (20.08.9, 20.08.17), tzdata:arm64 (2020a-0+deb10u1, 2020d-0+deb10u1) In the meantime I've installed Focal Server on a microSD card and that's working fine. Worst case I can flash that image to the EMMC.

Very interesting, and thank you for sharing. Do you have any insight into why the Tritium H5 would be so much faster than the ODroid N2 (9 seconds vs 750), despite both including the NEON extension? Not that it matters, I'm happy to use uncompressed indexes.

You're welcome, linuxfan, and thank you for confirming that it works on your setup as well. Big thanks to Igor for mentioning the compressed indexes over on the odroid forum! I did some poking around, and it looks like the decision to compress the indexes was made upstream: https://groups.google.com/forum/#!topic/linux.debian.devel/f_rlg3-cw2Y I ran a test and found that a Tritium H5 running Bionic has no problem searching compressed indexes with apt. Maybe this issue is peculiar to Amlogic SBCs? Or perhaps a Debian vs Ubuntu issue?

I'm not sure either, though I checked and the files are uncompressed on my old cubox i4 pro running Stretch server. Whatever the case, I prefer searching with apt, so the trade off is certainly worth it for me. This is difficult for me to judge, as I went from running Stretch on a cubox via microsd, to Buster on an n2 via emmc. This new system is so much faster that I'm afraid I can't draw any comparisons.

It looks like the files are approximately three times larger now (roughly 35 MB vs 93). I noticed that /etc/apt/apt.conf.d/02-armbian-compress-indexes specifies that files should be gzipped: Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz"; while mine were compressed with lz4. Not sure if this could explain the poor performance, but I thought it was curious. For what it's worth, they're compressed with .gz on my x86_64 desktop. Edit: scratch that - the package files on my desktop are uncompressed, but there are some other files in that directory compressed with gz.

I was able to fix my slow apt searches by removing /etc/apt/apt.conf.d/02-armbian-compress-indexes as described in this thread (forum.odroid.com). This didn't immediately fix the problem, but it started working normally after I removed all of the .lz4 files from /var/lib/apt/lists/ and ran apt update. I confirmed that all files ending with "_Packages.lz4" are now stored in uncompressed form, and my searches are nearly instantaneous. Aside from lost disk space, are there any downsides to this approach?

Normally I'd search with apt, but that's performing poorly on my device ( e.g. 12+ minutes per search): apt search mariadb Searches with aptitude work fine, both with the ncurses interface, and from the command line: aptitude search mariadb I just tried and apt-cache search works fine as well: apt-cache search mariadb

I'm running off of a 64GB emmc, but I just checked and the wa stays at 0.0. I found that searching with aptitude works fine (aptitude search package), so that's a good workaround.

Thank you for the suggestion, xwiggen, and sorry for the delayed response. I just checked in both places, but no trace of ext4lazyinit. I noticed that an apt search causes one of the cores to ramp up to 100% for the duration of the search. There doesn't appear to be any disk activity while searching, and RAM usage only increases by ~25 MB.

I just tried (apt clean, apt update), but no change. Thank you for the suggestion all the same.

I'm having the same problem with a fresh install of Buster server on my ODROID-N2, in case it's related. http://ix.io/2nbL

Hi again Guillaume, I apologize for not responding earlier - I never received a notification that you responded to this thread. It probably ended up in my spam folder, and I lost track of things. My system bricked again, this time using apt-get. I came here to retrace my steps, and saw you were kind enough to respond to my previous questions - please accept my belated thanks. In case it's of any use to Igor or the other developers: I've been running the legacy kernel (3.14.67) without issue for the past 5-6 weeks I logged in via ssh today, and noticed that there were some updates available, so I ran apt-get upgrade I rebooted the system, but it never came online I mounted the SD Card on my Xenial workstation, and noticed that zImage was linked to vmlinuz-4.6.3-cubox I relinked it to vmlinuz-3.14.67-cubox, forgoing the other recovery steps, and it's up and running again /var/log/apt/history.log shows: I'm not sure why apt-get decided to install the vanilla kernel again, though I haven't really investigated much yet. In any case, I agree that Igor and the Armbian team does a fantastic job! I made a donation after the last round of help, because I truly appreciate all of the effort that goes into this project - it has made my investment in this hardware worthwhile. Thanks again everyone! Cheers, Matteo

wildcat_paris, Thanks again for your assistance, I appreciate it. I was able to get the system back up and running after following the rescue procedure. I noticed that I'm now using the legacy kernel (3.14.67), rather than vanilla (4.5.5). Is that expected behavior, or did I choose the wrong set of files? I first tried the cubox_4.5 debs, and then afterward the cubox_5.10 debs. In any case, I might leave things the way they are, as everything seems a tad more responsive with the legacy kernel. Also, I still have the missing file messages at boot, but it doesn't seem to affect anything. Perhaps this was always being displayed, but I never noticed because this is a headless server. I assume it's nothing to worry about? Lastly, I'm fairly certain that I used aptitude for previous upgrades, but I'm not positive. In any case, I'll stick with apt-get for this system from now on. Best, Matteo

Hi Igor and wildcat_paris, Many thanks for pointing this out to me. I read over the documentation last night, but glossed over that section because I didn't think of my unit as bricked. Sorry for the foolish question, but thank you again for the help, and for all the hard work you've put into this project! Best, Matteo