eselarm

If this is something with languages: I remember Armbian has a preferences option in apt config somewhere 'no languages'. Is old memory, maybe changed nowadays. Maybe a hint where to look and what to try. It would actually be a Cinnamon issue then.

What is booted also depends on boot scripts (and what is in armbianEnv.txt). This might have changed. And also the U-Boot code on the SD-card (sits invisible between partition table and 1st partition, usually sector 34-32767) might be newer and assume other defaults, I don't know. You need serial console cable and loglevel set to 7 so you can see what is happening after power-on. But maybe something else is wrong, at least make sure you post relevant info here on the forum. You can look in /usr/lib/u-boot/platform_install.sh to see where U-Boot is written. Also if you look there you can find some version string, likely in your mtd0/SPI is older than on the SD-card.

But that means you have 2 bootloaders and also 2 bootscripts. That will cause confusion, is it no surprise you end up in initramfs. I do not know which one has priority for the OPI5, maybe it is variable, depending on something in hardware on the board. On my ROCK3A, I can place an optional jumper that disables mtd0/SPI, so only option is U-Boot from SD-card. You can interrupt U-Boot if you connect serial console cable and then manually load the OS from SD-card or NVME, but it is a lot of commands and you need to know or study what those do. If you want to run a new OS from SD-card, you need to change (all) boot.* + armbianEnv.txt files, such that there is only 1 set (from SD-card or from NVME). Also only 1 U-Boot is best, else it will stay confusing. So wipe the U-Boot on SD-card. Then place the correct UUID in armbianEnv.txt (the UUID from rootfs on SD-card). Alternatively, you can use extlinux.conf boot method, you need to create that yourself, I use it on some SBC's so I can test new kernels etc (select at power-on in U-Boot via serial console cable). Or you flash EDK2-UEFI in mtd0/SPI and radically change all to EFI en grub bootmanager. Needs all manual own actions, not an Armbian thing.

This is based on mines, running Armbian Trixie: - NM can work without dhclient, it has it DHCP internally as well. So maybe look at that instead of AI with old info and certainly no clue about a specific SBC - modern kernel it is end0 - systemd-networkd is also an option - you also might use ifupdown still, also not needed, NM can do internally as well

I am not sure if this will lead to problems. The SBC is a Radxa ROCK3A. It might be EVB was used for development and never changed. Maybe won't matter as later on kernel rock-3a dtb is loaded. But could be a reason for issues I saw (year ago) with mainline u-boot, therefor I use Radxa's one / legacy.

Maybe. If it is better you'll have to see. Install package 'linux-u-boot-rockpi-4c-edge' and with dpkg -L linux-u-boot-rockpi-4c-edge you can see where the u-boot binary is located, then: strings <u-boot binary> | grep armbian

I get this on a Debian Trixie VM allocated only 4x Cortex-A76 on ROCK5B 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.5407 s, 236 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.24198 s, 253 MB/s Numbers are lower on RPi4B and ROCK3A. However, since in-place upgrade from Bookworm to Trixie, this slow ssh login is very noticeable and also rather annoying. So this is a Debian issue as far as I can see. I had the same Debian VM running on ROCK3A and was all nice with Bookworm, although only 1GB allocated and of course is 4x Cortex-A55, so slow for crypto and compression (real-time Zstd). Just after upgrade and reboot into Trixie I spent a lot of time trying to figure out why ssh login was so delayed/slow. Also noticeable that it was random, sometimes it was OK, mostly took multiple seconds. I did strace sshd and I saw just delay, waiting time in the process. More I could not figure out, would take me too much time and I had no clue where to look. The plan was anyway to move the VM (and NVME and HDD, the whole NAS setup) to ROCK5B so that is what I did then the next day or so. On the ROCK5B, I do not notice the delay that much, but it seems still to be there. I have no clue why. I use quite a lot ssh unattended, so that I don't care and notice. So I basically still do not know what this is, I have not searched for It, I just see this topic and I recognise it.

OK good that is works now. I did not really read all history. I have a build running now (mainline/edge), but I will again need to dig into overlay/dts, hopefully I understand it now a bit better.

Please post what you used as build command. Or the build log, see instructions at end of build. It needs to be clear what combination of U-Boot build and what kernel build. Else no-one can reproduce. I will maybe run a build, but RK3568 something a bit strange between RK3566 and RK3588(s). I use old U-Boot and 6.1.115 kernel on my ROCK3A as else I cannot get NVME+SATA working at the same time and that is why I bought the ROCK3A. SATA + SPI + ethernet should work, although have not tried. It at least makes NVMe unavailable, that was status a year ago.

There are 2 sentences below that set of download URLs that should say enough: Also see section title: "Bleeding" in normal life means something went wrong, blood dripping from your body might spoil the carpet, blood squirting from your body might mean death is near. So you are expected to do something maybe. You already did by doing that by creating this topic. In case of a device with new SoC (on the market after old 6.1 kernel) it seems wise to put also focus on new mainline kernel which is maybe a bit problematic w.r.t. certain things, but you can be sure it will be the main stable thing sometime. Maybe after years. If people who care about such a device/computer/board would only stick to old/stable Rockchip proprietary downstream kernel and firmware, this thing will be dead after 5 years from now. So in order to survive, it needs development/testing now and continuously actually (also w.r.t. security, that is the case for every computer). You are one of the testers, maybe you forgot to realize. 'images' is very low effort getting an integrated and pre-installed OS tested. If no images, you would point people to a rootfs.tar.gz or instructions to run debootstrap and let people guess how to build a kernel and some bootloader. Or run Debian Testing or a rolling distro like Arch Linux. You would be a better tester if you could more exactly inform where or what the issue is. Maybe it is so simple like a week ago or so that a listed image was only containing U-Boot, so the .xz file was something like 500 kilo not Mega Bytes.

See build log https://paste.armbian.de/lesoquheja The kernel works, but installing the .deb failed because my extlinux script could not copy: /usr/lib/linux-image-6.18.1-edge-sunxi/overlay/sun8i-h3-analog-codec.dtbo The whole overlay folder does not exist. It does exist for 6.12.58-current-sunxi and last time I compiled kernel for the nanopineo was 6.16.8, the overlays were created. I remember it was also once the case with edge kernel for other SBC ( .deb package from the Armbian beta repo). That time own local build did create overlays. I am not sure where to look or what could be wrong.

If you learn yourself a strategy not to wipe existing installation, but dist-upgrade it and also have a flexible backup and restore for yourself, you don't need lists or so as the same set of software keeps being there. I clone installations from 1 computer to the other, so do not use new images. With tasksel you can remove and add Desktop Environments, sudo systemctl set-default <target> to changes from GUI to CLI and vice-versa. Make sure you have a serial console cable working (for CLI and no HDMI/kbd/mouse connected). But you can use 'sudo apt list --installed' on Debian systems. Cloning on x86 is easy, for ARM, you need change bootloader and kernel and some other packages. Until also all ARM computers come with UEFI bootloader/firmware. https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#preparing-apt-sources-files https://digint.ch/btrbk/doc/readme.html https://btrfs.readthedocs.io/en/latest/Send-receive.html

No need to reply in a PM; just run standard Debian tool: sudo tasksel and select what you want and follow the steps.

Easy is what standard Debian (12 and 13) does: NetworkManager and openresolv/resolvconf , even for complex setup of VLANs and bridges, Virtual Machines. Canonical/Ubuntu have invented netplan.io, so they manage NM and systemd-networkd with a yaml script. Easy for them as large organization for business customers. Might not for you as image downloader, as it introduces extra yaml while .nmconnection files are easy to copy between hosts. Also, systemd-resolved might be used, which is actually a sort of local DNS server. It should enable high performance I guess, by default caching enabled, but is that applicable for a simple ARM SBC connected to an ISP router, I don't know. I know is needs extra work for me. So you need to dig into that. Or not use Ubuntu at all. I anyway do not use images, only for testing for others, not to use them myself. It is simply using apt for (dist-)upgrades and so I use standard Debian upgrade method to get from Bookworm to Trixie and keep my KDE as I use that mostly. Also switching kernel, just via apt removals/installs and/or bootmanager. If you get stuck, use sudo nmtui to set an extra network profile connection with fixed IP, known DNS maybe. Done that many times to get things running although not permanent good solution.

It has become your issue. That is the unpleasant reality. It is your setup. It makes no sense to keep guessing what is happening, I gave you already some options.

On an ARM computer: cat Armbian_25.11.1_Odroidn2_noble_current_6.12.58_xfce_desktop.img.xz.sha 1f3816553377dd63a12e46a476f7ff20b8c5118f63f879f8d3d7d27073c97b35 Armbian_25.11.1_Odroidn2_noble_current_6.12.58_xfce_desktop.img.xz unxz Armbian_25.11.1_Odroidn2_noble_current_6.12.58_xfce_desktop.img.xz losetup --show -fP Armbian_25.11.1_Odroidn2_noble_current_6.12.58_xfce_desktop.img mount /dev/loop0p2 2 passwd -d root --root $(pwd)/2/ systemd-nspawn -bD 2 Only as root login. Browsers are installed: Creating a new user account. Press <Ctrl-C> to abort Desktop environment will not be enabled if you abort the new user creation Please provide a username (eg. your first name): ^C Disabling user account creation procedure root@odroidn2:~# apt list --installed | grep -i -e firefox -e chromium WARNING: apt does not have a stable CLI interface. Use with caution in scripts. chromium-browser/noble,now 2:1snap1-0ubuntu2 arm64 [installed] firefox/noble,now 1:1snap1-0ubuntu5 arm64 [installed,upgradable to: 9:133.0+build2-0ubuntu0.24.04.1~mt1armbian1] Running as a container without DE is very minimal, but packages are there and also networking is up. Things might go wrong when starting DE for the first time, the the occasions I had that in the past decade are rare an due to bad storage or so or something failing with graphics HW/stack. You should maybe specifically look at what is managing network and what is managing DNS. Math permutation leads to 4 possibilities already if I look at what is installed. That is excluding all sorts of options you may have with your router or LAN.

Your serial console cable seems to drop several characters or so, but that should not matter for booting. What matters I think is that you have no partition and I see in boot.cmd test -n "${distro_bootpart}" || distro_bootpart=1 echo "Boot script loaded from ${devtype} ${devnum}:${distro_bootpart}" This 1 year old, yours might be different. So if your boot.scr is still compiled from such boot.cmd content (see end of file how), I think it won't work. I have used parttitionless Btrfs, but not for OS rootfs, I also think GRUB will need a hack then. So if possible make it with just as default as possible, a 1st partition btrfs formatted with rootfs and likely also the rootfs subvol set as default. Also that is a tricky thing with GRUB (Debian) I know. I wiped a bootFAT partition actually, so about 16M+256M space before rootfs partition and also sorted the GPT table to default, so 1st entry Btrfs rootfs. I find the boot cmd rather complex, I used a minimum direct one as well for tests. see My (ROCK3A 24/7 up now) has bootFAT again, I did wipe/hide boot.* and armbianEnv.txt and use extlinux, so I can select a specific kernel option via serial console. /extlinux/extlinux.conf menu title Select the kernel variant DEFAULT vendor TIMEOUT 80 LABEL vendor KERNEL 6.1.115-vendor-rk35xx/Image INITRD 6.1.115-vendor-rk35xx/uInitrd FDT 6.1.115-vendor-rk35xx/rk3568-rock-3a.dtb FDTOVERLAYS 6.1.115-vendor-rk35xx/rock-3a-sata.dtbo APPEND root=LABEL=armbidroot rootwait rw earlyprintk console=ttyS2,1500000 cma=256M LABEL edge KERNEL 6.17.0-edge-rockchip64/Image INITRD 6.17.0-edge-rockchip64/uInitrd FDT 6.17.0-edge-rockchip64/rk3568-rock-3a.dtb APPEND root=LABEL=armbidroot rootwait rw earlyprintk console=ttyS2,1500000 cma=256M As this is on extra FAT, I need extra copies for all the files referenced, but when only 1 Btrfs, it should be possible to refer to files in /boot and elsewhere.

There a more important things to do (first). Like even creating a package for the OPI5 as a quick scan reveals there is none. So currently an option is to compile U-Boot yourself with added Btrfs support. And/or also do that on github and make pull request. Over time, more U-Boot will support Btrfs I guess, so how do you think people should spent their time. I did look into armbian-install but it is not according to my wishes/methods. It should work, but more work for me to revert/change than just use manual rsync and btrfs options as I want it. I have some backup/cloning scripting that fits Opensuse methods, not Debian. Your other option is to simply install/copy manually and maintain an extra boot/1st partition, FAT formatted. Several old installs do it like that and it is anyway you have to deal with for 'normal' UEFI computers. So that is why I do that. For simple/cheap/headless SBCs, just U-Boot and single partition is very much preferred I think, as that means less objects to maintain and also it allows seamless systemd-nspawn startup/run. That is very handy method of doing things with images. As with multiple partition you need losetup first and select/mount rootfs partition as well manually. I also use extra 1stFAT so it is easier to experiment and switch bootloader and various boot methods/files. Or build your own image with Armbian build, then 1 linux commandline, 'push-button', if you would select /dev/mmcblk0 as image target and have your buildhost running from NVME. Also note that there is the tool btrfs-convert, it works on various SBC images, if you also change/fix boot settings. For Armbian, I think only change is the rootfstype= line in armbianEnv.txt And what works for several UEFI machines is that you add the boot partitions at the end, so you can just shrink rootfs partition a bit, no complete recreate, that might save time when full 4TB HDD. It must have the correct type then so 0xEF00 (ESP), so Windows oriented users will easily get in trouble. Not sure if that also works for Linux only method, seems 0xEA00, but would expect that. Anyway, this is all fixing afterwards options, it of course won't play nice with Ext4 auto expand filesystem method in every SBC image nowadays (eating your SD-card, you never manage to undo).

Sounds a bit like with My ROCK3A. Bought it last yer and with a SATA breakout board. That breakout board was a newer HW version with a but flatter and simpler (and cheaper of course) SATA connector, such that I could get a SATA cable connected as the MIPI DSI conector was in the way, just slightly too high. So for the 3 euros that it costed I thought, time to warm up the soldering iron and lift it a bit so a SATA cable fits. Radxa apologized and I think the idea was that I would get some new SATA thingy or so for free. Yeah right, trust is gone. That proved a second time as they did not take any further initiative. For example how do they think they can reach me (being at the at the other side of the world). Also now that combination is is just removed from the products page. Indeed they sell now own ASM1166 M.2 M-key modules, of course at a higher price that the generic ones on Aliexpress. No surprise form a Chinese a company, they just throw new boards on the market and hope someone will be their guinea-pig. Also your ROCK4C (non-plus) is not listed anymore. Also note it has no PCIE, so my guess is it uses some USB3 connection. I personally avoid it like a plague. Maybe it can save you in this case, maybe try to get a schematics of the PCB, then the whole thing might work with the HAT off and just GND+5V with own soldering/wiring. Else sell it befor it is too late. That is what also have advised a RPi5 + SATA HAT user who had trouble. As separate components, loss it not too big maybe. My ROCK3A+breakout board was 40 euros, great for replacing old PC for 1 SATA HDD. That those HATs are covering all GPIO, I know, that is why I never will buy a HAT again, also not a Raspberry I think who 'invented' it. I soldered extra wires on top. In your case I would solder the USB console cable on the underside, drop of hotglue and done. Faster than I can write this message. Or else look for a PUKE (Peripheral Under Kernel Environment module that is meant for debugging low-level U-Boot and kernel issues).

U-Boot SPL 2025.10_armbian-2025.10-Se50b-P24f2-Hae98-V38b0-Bbf55-R448a (Nov 19 2025 - 09:08:53 +0000) which is in that image, has no btrfs support I saw for example on my NanoPi-R6C using: U-Boot SPL 2026.01-rc2_armbian-2026.01-rc2-S365a-Pb445-He3cc-V062a-Bbf55-R448a (Dec 03 2025 - 04:31:42 +0000) that it has btrfs support, so can load kernel etc directly from the rootfs partition when it is btrfs formatted. You can first write a newer U-Boot in SPI-Flash, then it should work.

You simply need to read the docs, it takes time and maybe some trial-error. Maybe hours, days, weeks or longer. There is no free ride. https://docs.armbian.com/Developer-Guide_Overview/

Can you post/do something like this: I use Armbian Trixie on ARM64 computer to do builds. I banned Ubuntu (certainly old Jammy) and also do not use docker.

I am afraid you need to dig deeper than those 'convenience installers'. I never used armbian-install but have been running Armbian from Btrfs for several years. It is easy and low failure risk if just simple SBC with only SD-card like NanoPi-NEO, but you get many options where various modern U-Boot builds / bootloaders can go wrong. Do the math permutation and you will realize. I know Armbian can be booted from single Btrfs formatted partition, but it meant full custom own U-Boot and own partition setup. That also involves whether you use subvolumes or not and whether you set 1 as default, other then the root of the filesystem ( ID <= 5 is that). Also features, I use zstd compression, but I am not 100% if the whole chain does also support it. So you need serial console cable to see/log what is going on and also set kernel loglevel to 7 (in armbianEnv.txt). It would also help if you post sha256sum of image you tested/used. That allows others like myself to quickly check/reproduce in virtual machine or so (I don't have OPi5) and not pick a newer build or so next week when time to help you.

What are your steps and/or commands? Arguments of compile.sh have changed regularly, so look at that first I would say.

I find the lack of GRUB via HDMI too problematic, so I put EDK2-UEFI v1.1 in eMMC again. I needed to wipe it completely, just writing the part without partition table normally done for U-Boot kept using the 2025.10 U-boot that was written there. I do not know how that comes. I know EDK2-UEFI v1.1 will divert to SD-card, so I though I use that to test U-Boot again. - blkdiscard SD-card - write U-Boot SPL 2026.01-rc2_armbian-2026.01-rc2-S365a-Pb445-He3cc-V062a-Bbf55-R448a (Dec 03 2025 - 04:31:42 +0000) to it - type reboot After restart and desktop login no HDMI audio. Kernel log showed long series of audio driver related errors - shutdown and pull USB-C powerplug - plug it in again and let it boot - then no audio error and also hear a 'plop' in the monitor that means the audio is enabled/working So it seems something does not reset correctly, so powercycle needed, while HDMI monitor is kept powered and HDMI cable stays connected all the time. What is different now: - kernel 6.18.0-edge-rockchip64 - eMMC contains EDK2-UEFI v1.1 and passes control/boot to SD-card U-Boot But I think it is the powercycle that is the key thing. An interesting new feature of the 2026.01-rc2 U-Boot is that the CPU clock go down to 480 MHz when mainline kernel, was 1GHz. Is not lowering idle power though, is 3 W, is 1.5 W with vendor kernel. Not clear why that is.