eselarm

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.

Maybe a handful, I have most SBC's equipped with one permanently. And needed for Arduinos etc, you can even power tiny old things like RPI0/1 with it (if you connect red wire to 5V pin as well). In the meantime, you might think about some previous U-Boot and previous kernel. For quite some SBCs, there is trouble when U-Boot is new/mainline/releasecandidate and kernel vendor. I am currently also doing some tests on my NanoPi-R6C (RK3588s) because HDMI is not initialized fast enough (by U-Boot). And with 6.1.115 vendor kernel really choppy mouse updates and green tint, not complete flat green luckily, I can still see icons and mouse.

https://docs.radxa.com/en/rock4/rock4c+/low-level-dev/serial and set loglevel to 7 in armbianEnv.txt

Extract the 7z file in the same folder as Armbian-unofficial_26.02.0-trunk_Luckfox-lyra-ultra-w_trixie_vendor_6.1.115_minimal.img Then do: dd if=uboot.img of=Armbian-unofficial_26.02.0-trunk_Luckfox-lyra-ultra-w_trixie_vendor_6.1.115_minimal.img bs=32k seek=1 conv=notrunc Then you have an old Rockchip 2017.09 u-boot, my guess it that that shall work with 6.1.115 But you are the first one, the tester of it. Also, I did a 32-bit rockchip edge kernel test build and I see no DTB file for Luckfox-lyra-ultra-w That means it is not supported for mainline. At least it seems correct that one cannot build a working image now as legacy u-boot is not available anymore. In theory, the 2025.10-rc4 u-boot might be such that you can get a mainlne edge rockchip kernel running, EFI booted maybe, but expect same strange errors or freezes.

OK so HW seems OK. And you still use vendor kernel as in 1 of your first messages, that was not clear to me. Maybe as a check, tell what CPU's are in that device? I did not know this '6.1.115' also runs as 32-bit, but the problem then is likely vendor kernel and mainline u-boot; That does not correctly work out of the box on any any of my 64-bit Rockchip devices. So use older U-Boot, what should work I think is the U-Boot from the company Ubuntu22 image and the Armbian vendor kernel+DTB. It means what I indicate, you need to compose your own image by patching some own U-boot in it before flashing or change Armbian build such that u-boot and kernel are a compatible set. So naturally, pick mainline kernel, so edge or current.

I would take this as a base: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_NEO2#Set_Audio_Device I have several H3 NanoPi-NEO and use their on-board audio HW. If you want external audio HW, dig deep into Armbian GPIO config, it can be set with some text in armbianEnv.txt, but all depends the board pinout and just reading H5 SoC datasheet for pin and signal codes how to map. Done that for an AllWinnner A20 board and lot of internet searching as well.

So now it runs Linux at least. The question is why difference between LOG1 and LOG2? Is it because you reflashed it as well? Or just powercycle? And what image or what Armbian build command is it? How can people reproduce? You should set loglevel=7 so at least ohers can see what kernel is running. Random behavior mostly is because of HW issues. So powersupply not OK or bad storage or the flashing introduces corrupt datablock on the storage, bad cable, bad Windows computer/software. As it seems to be able to run Armbian Linux, you can also build/prepare a more convenient image, like with NetworkManager, Btrfs rootfs, etc. And completely prepare it first, as container or virtual machine.

While doing various tests, also other bootloader than EDK2-UEFI v1.1 that I had in eMMC, I discovered that with 2026.01-rc2_armbian-2026.01-rc2-S365a-Pa203-He3cc-V062a-Bbf55-R448a kernel 6.18.0-rc7-edge-rockchip64 did not find/enable audio via HDMI. I moved the computer to other room where I rely on the speakers in the monitor, else I would not have discovered it as I also use networked pulseaudio. What works is 2025.01-armbian-2025.01-S6d41-Pdb4b-H2194-V062a-Bb703-R448a, so sort of last-known-good, got that via: sudo apt install linux-u-boot-nanopi-r6c-current=25.8.1 and wrote the binary with dd to eMMC Another issue is that the monitor does get out of sleep too late, so the loglevel=7 effect can only be seen on extra serial console, whereas with the UEFI bootloader, the HDMI gets always initalized properly, so before kernel is loaded. Note that this is with booting via grub. So with EDK2-UEFI v1.1 bootloader, I get a normal Debian graphical kernel selection menu, like on x86-64. With Opensuse Tumbleweed it is slightly different, as that also automatically duplicates on serial console (if 't' is pressed , from 'text'). So this is actually quite ideal. The only disadvantage is that it does not want to store boot entries (but works on ROCK5B in SPI-flash). I probably need an own build on SD-card first to see how 2026.01 (or later) can do the same as EDK2-UEFI v1.1 more or less. I should note that with EDK2-UEFI v1.1 bootloader, I do not load the DTB that comes with the kernel version. I used the setting 'vendor' or 'mainline' in the UEFI settings, that gets stored well actually. Now with the 25.8.1 U-Boot, I manually added a devitree loader line in grub.cfg, but that will be overwritten, so need to see what makes sense.

This means to me that there is a power problem. That can be complex, with a backfeeding situation that exists with the CPU box but not with other computer. Might be electronically something damaged now, not impossible even if it worked for weeks. Might a different U-Boot that does incomplete initialization or does finally something correct but as a consequence that your setup does not work anymore. I see things initiated in the kernel log, but what is what is not clear to me. So maybe have a look at lsusb (with proper options) output. I must also say that USB connected storage is something I avoid. Wasted loads of time on it on RPI4, eventually made own power-supply, also battery fed now, that was main reason for own electronics actually. Else I could also have sold it, I have RK35xx devices now and use SATA from those and 12V based power.

It looks like the training of AI bots is getting to a stall. Anyway, a knowledgeable contributor does not feed the bots. Instead, they judge if the info from the bot can save their life. Will this bot come to my house with food for free and put it into my mouth. Asking the bot to give money first might look a good first thing to do, but it isn't. Even if real coins or paper and not bank transaction.

I now see that in your screenshot, a Windows filepath contains rk3588_sp... This Lyra has a rk3506B, that is a much different and only 32-bit SoC. So that seems not OK to me, so no surprise it does not work I think. But up to you to read documentation. And also I would not use Windows, the docs at luckfox assume Linux, so the commandline tool rkdeveloptool.\ I don't use Windows and also don't have this luckfox model, so cannot guess what is wrong actually.

File (.xz) less than 1M, it extracts to 1444M, only 836k content, rest is sparse. Only U-Boot is written It looks like. So clearly image generation failed.

I think there is something wrong with the whole chain from 'computer-RAM down to SD-card itself'. I state it like this because there can be many points where the root-cause is. An issue like this I have seen several times before, and I think I also have had it myself, but was several years ago. /dev/sdc means you use some USB attached mmc, so even if sequential reads and writes work fine, certain pseudo random scattered small blocks can maybe hit some corner-case in the whole Linux I/O in combination with out-of-spec hardware; can be power issue internally in the SD-card adapter, anything. Also the SD-card itself might do very strange things internally, you don't know, it is some micro-controller firmware. Even if not counterfeit or just fake. Check CID and/or post here maybe. So to avoid at least USB adapter issues, I have used my RPI4 that runs from USB3-SATA SSD as SD-card reader/writer for images for for example a nanopineo. So then in the RPi4 , it is /dev/mmcblk0 you operate on. My NanoPi-R6C runs from eMMC+NVME, so also there /dev/mmcblk0 is free to use for image writing. Advantage is also that those SBC native slots do support trim, so to also internally wipe SD-card I do 'sudo blkdiscard /dev/mmcblk0' sometimes first, than all is fast and freely available. This command actually failed on some details for some SD-card brand when in ROCK3A SD-card slot for some kernel version. Also A2 SD-card and faulty queuing can randomly corrupt things.

See https://wiki.luckfox.com/Luckfox-Lyra/Pinout and connect USB serial console cable You should see then what is going on and post that here.