eselarm

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.

See my 'dry' test: # cat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha 80ffb7486a9d9950c2613f42be520c4086d4a3b894da4fd46a07120ecd9ddb30 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz # sha256sum -c Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz: OK # xzcat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz > Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img # losetup --show -fP Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img /dev/loop0 # sudo fsck -f /dev/loop0p1 fsck from util-linux 2.41 e2fsck 1.47.2 (1-Jan-2025) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks # losetup -d loop0 So can't reproduce. I won't write it to real SD-card and then do the fsck. You can try this first, so via loop device. My computer is Armbian Trixie edge 6.18.0-rc7 NanoPi-R6C, .xz file downloaded on N100, so could also done it there, does not matter Ext4 is Ext4.

AFAIK this can mean the ROCK3C (and software running on it) failed on interpreting HDMI info from your specific HDMI monitor (too old, buggy, not according spec, strange timing, too new, maybe more). See things w.r.t. EDID. One can set a certain video= statement on the kernel cmdline, you need to read docs etc what the options are. Easier might be to use an newer kernel, rockchip64 edge kernel is 6.18.x, that one much better RK35xx support than the 6.12.x one in the image. See armbian-config for selecting edge/beta kernel. Or change sources.list yourself so that you can just do apt install linux-image-edge-rockchip64

I assume you are not blind and need some screen to see what data you enter into computers. I am not saying the N2+ is HDMI connected, but sure you do use some serial console cable and terminal program or ssh or maybe even telnet. But jokes aside, I think you do not get the point that it is you yourself who needs to get your own device working if you want Debian (because Armbian is busted according to you). I mean vanilla Debian, so only Debian packages that can be fetched via apt from Debian repositories. So that means no Armbian kernel+DeviceTree and no Armbian U-Boot. That is what I show you essentially. But read info on debian.org. Up to you to jump into the cold water and swim. You already figured out it is something with I2C busses/numbering, so that is DeviceTree and/or DeviceTree overlays. Vanilla Debian is roughly 1 year older than 25.11.1 Armbian Trixie, so if no-one who owns an N2+ (and is willing to do testing/trials for you) is reacting, you are the only. You can send your N2+ to me, maybe I can make it work, but I won't send it back as I need some sort of salary for the work done of course. Other option is Ubuntu Jammy image (with custom/vendor kernel) from odroid.com or so.

You can remove Xfce from an installation, via apt purge --autoremove options, may just by un-ticking it in tasksel, and systemctl set-default multi-user.target Done that kind of trick to get rid of RPi PiXel DE in the past when they had no -Lite images and/or I wanted to keep my rootfs while upgrading in-place to newer Debian main release. Same Actuallt recently for ROCK3A Armbian Bookworm cloned from NanoPi-R6C to Armbian Trixie just headless/CLI. My last run/config of a Armbian 25.11.1 image was with autologin root and doing 1st run config, the usual I know from Armbian. So the image you use is wrongly generated maybe, but the big question mark is what image? URL+sha256sum enables others to check/confirm without guessing and maybe picking a newer/different 'latest' image or so, else DIY.

Good that this is made default now for various boards. If a board/computer has no factory written bootloader, so only bootROM/maskROM, then this allows way more flexibility and also will get rid of endless topics and support issues that have their root cause in SD-card (failing, or worse fakes, fake brands, etc). As a scrub either done automatically or as support request on-demand/ad-hoc will tell. Also many operations can be done while the board/computer is kept running, no reboot needed. Like transferring rootfs OS from SD-card to NVME and many more great things. Like replacing an SD-card without reboot. Or rollback to know-good older snapshot after faulty update. I see I wrote some things about it here: https://forum.armbian.com/search/?q=CONFIG_CMD_BTRFS&quick=1 For boards/computers with factory written bootloader, so PCs with UEFI or BIOS or the strange Raspberries with their boot(EEP)ROM that need a 1st FAT, it is a different story. I figured out that for my computers that already use Btrfs for rootfs for years, even tiny/old RPi0/1, it is currently better alignment, so that I stick to heaving an extra boot partition still. It can be very small, I had defaulted to 40MiB some years ago for a single Linux OS VM (x86 or ARM), but just for some bootaa64.efi file that is already a lot. For RPi, 3MiB was enough, so you store only a bootcode.bin start* fixup* config.txt uboot.bin bootaa64.efi. But that extra boot partition is also easily very confusing, especially for RPi like methods where kernel+initramfs+DTB are copied. Also, I had Btrfs enabled U-Boot, an Ext4 bootpartition and Btrfs rootpartition while doing experiments (booting from Btrfs raid1 straight from U-Boot) on QEMU and AllwinnerH3. kernel+initramfs+DTB were accidentally read from Ext4 (/) instead of Btrfs (/boot) and more such confusion. So then I recompiled U-Boot without Ext4 (so only FAT,Btrfs), then fine. But generally I would keep Ext4 of course. With just 1 partition, then those issues are is avoided. Then simply 'U-Boot object' and 'rootfs object', where the latter can still be chosen Ext4. Btrfs U-Boot + rootfs also would make raw/flat images viable maybe. xz-compressed will certainly have smaller download file, but for full desktop variant images, there might be an overall advantage. If rootfs is written by Armbian build with let's say compress-force=zstd:9, only first MBR+bootloader sectors, the Btrfs metadata and some filesystem slack is not compressed. I think some statistics are needed first, maybe it is not worth the effort for mass-downloads also via torrents, mirrors, etc, but for own local builds I certainly see benefits. At least I force compress almost all newly written block-devices, so also a restore from backups. It can keep thin-provisioned volumes/images very small, also roughly halves the write-time for (slower/older) SD-cards.

Usually people switch off the HDMI monitor of the computer and and walk away. Or they put a mirror against the monitor and ask the person they see why they bought a computer that does not have Debian installed?. Why am I here? Do I need a CD-ROM drive to install from ISO myself? How do I enter the BIOS? Does it have BIOS? But there is hope. Aarch64 Debian13: root@odroidn2:/boot# apt install linux-image-arm64 root@odroidn2:/boot# ln -sf vmlinuz-6.12.57+deb13-arm64 Image reboot root@odroidn2:/boot# apt install u-boot-amlogic-binaries root@odroidn2:/boot# dpkg -L u-boot-amlogic-binaries | grep odroid-n2 /usr/lib/u-boot/odroid-n2 /usr/lib/u-boot/odroid-n2/u-boot.bin /usr/lib/u-boot/odroid-n2/uboot.elf /usr/share/doc/u-boot-amlogic-binaries/configs/config.odroid-n2.gz

I don't think so, then my Virtual Machine run would fail the same way as you describe, but it doesn't, it works fine. Of course it is the meson64 kernel running on top of KVM/virt machine, the RTC for example is emulated, while for your real N2+ is a specific Amlogic SoC kernel driver I assume, so there something could be wrong. Or what about clocking tree, there are many failures possible. I know for rockchip64 there were 2 RTC modules, at some point in time 1 was chosen over the other, so a change, could also introduce issues. You could browse kernel changes/patches And also what about an unknown bad/corrupted diskblock or so. I normally use Btrfs for rootfs, so easy to check for and detect corruption. So maybe re-image again. I am still not sure if I used the same image as you, but up to you to track that. You can do the same thing as I did to see if it is maybe a specific Amlogic driver issue; Run that image as VM on the same N2+, you need a network bridge with main eth port or else use NAT. Or you make it first efi bootable, then it can run easier in virt-manager GUI. N2+ is fast enough to run VMs, I even do that on ROCK3A (2GB RAM, 4x Cortex-A55). Or use standard Debian Trixie kernel on real N2+, not sure if that works good enough. Or remove/disable RTC kernel module. Or also remove fake-hwclock stuff if you haven't already done that. I did not do it for this VM run, but when real RTC+battery, I would remove or disable it.

I have the NanoPi-R6C and that came out of the box with an OpenWRT variant on eMMC. Indeed many partitions, but I think I managed to get it running somehow with Debian/Armbian rootfs on some higher partition number, I don't remember exactly. As long it can load boot.scr. Indeed eMMC is number 2, I guess they avoid potential confusion that is sometimes there with SBCs and various OSses swapping numbers for SD-card and eMMC. I had that once, no data loss but costed a lot of time. It is a bit similar to that on 6-SATA PC's, Debian might name the OS dev (SSD) /dev/sdb and a large HDD /dev/sda while Opensuse names OS always /dev/sda. So what do we do with 2-MMC SBC's ? I see my HP x86-64 dualrole computer/tablet uses /dev/mmcblk1 (its eMMC) for OS (Linuxes at least, Windows10 I don't remenber). The SD-card slot I have normally empty but uses /dev/mmcblk0 if card is inserted. It has UEFI and SecureBoot and TPM, so no choice actually like there is with opensource U-Boot. For NanoPi-R6C I have written Tianocore EDK2-UEFI to eMMC and appears as /dev/mmcblk1. I do not use the rest of the 32GB storage, but the UEFI binary comes with 1 partition, so easy to use the rest of the 32GB, but currently I need the much larger and faster NVME. And for emergency, if I insert an SD-card with newly generated rolling/edge image or so, it boots from that and is then /dev/mmcblk0. So this is IMO the preferred numbering, but I already had created some shell script code that can identify the boot partition and the root partition, but it is not too generic, only works if certain mounts are there which is what I have as I focus on EFI bootable and Btrfs with subvolumes ('nested' and default). So I would at least use 0 for SD. 1 for eMMC is fine. For the LEDs, on my NanoPi-R6C, I actually don't know, I never look at them. I think it is not correct with my installation (in-place upgraded and also other Linuxes), but I guess correct with current downloadable images. At least they were correct with the FriendlyElec OpenWRT that was pre-installed. I still can't get maskROM mode to work, so I am a bit paranoid on messing too much with data in the Rockchip loader area. I am not sure what happens if I put rubbish data or broken U-Boot there, can I still start from SD-card is the question. I might need to apply a fixed voltage between 9-20V as powersupply, but need to look in PCB schematics again first. For the Zero2, I see removable eMMC, so no risk or fear for 'hard-bricking'. Although I would check if maskROM works. For network, I assume it is the on-SoC port, so fixed off-the-shelf, so end0 is fine. For optional WLAN, I am not sure, likely some PCIe/HWtree named string, I have seen multiple altnames for 'wlo1', at least 'wlp1s0' or 'wlx<MACaddress>'. systemd-networkd should be able to handle those, NM can do all anyway.

I already see what the issue is: I have configured things in such a way that strange/new machines get served differently then known/existing ones. In addition, the known/existing ones need an extra setting in case of systemd-resolved. This makes a quick test with some random VM like this appear doing things wrong, but is actually expected. If I purge --autoremove netplan.io and put a symlink ln -sf /usr/lib/systemd/network/89-ethernet.network.example /etc/systemd/network/89-ethernet.network, there is working network again after reboot or restart service.

Same trick as in but with N2+ image sha256sum: 5627794e883fc3b8b9ccf918efe4e5427621761402e8e2d10b05730495fc19ce Armbian_25.11.1_Odroidn2_trixie_current_6.12.58_minimal.i mg.xz and 1 reboot, then with armbian-config set my timezone to CET and reboot again: root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 19:50:36 CET Universal time: Fri 2025-11-28 18:50:36 UTC RTC time: Fri 2025-11-28 18:59:21 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 20:00:31 CET Universal time: Fri 2025-11-28 19:00:31 UTC RTC time: Fri 2025-11-28 19:00:32 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no It seems it took several seconds for a sync, but nothing strange I think. However, important notice is that networking has picked the wrong DNS server; It seems to assume 'router IP = DNS IP' which is not the case in my case, so several things fail, especially in-house things, not what goes outside. This is not the case when network-manager+openresolv do the network config (and no netplan.io). I run 2 computers with systemd-networkd+systemd-resolved, but that took a lot of time and reading and some config tweaking before those do simply the same as before with network-manager+openresolv. And no benefit, only that they can run slightly easier as container with own MAC-address (real HW must be off then of course) and also a bit easier as container host.

FYI: I got the trunk.22 image booted, running, configured and rebooted in a CLI based QEMU KVM on my NanoPi-R6C running Trixie with edge 6.18.0-rc kernel. xzcat Armbian_community_26.2.0-trunk.22_Rock-3c_trixie_current_6.12.59_minimal.img.xz > armimg.img mkdir -p 1 ; losetup -fP --show armimg.img ; mount /dev/loop0p1 1 cat boot.cmd.qemu-rock3-ext4 load virtio 0:1 ${ramdisk_addr_r} /uInitrd load virtio 0:1 ${kernel_addr_r} /Image fdt addr ${fdt_addr} setenv verbosity "7" setenv rootfstype "ext4" setenv rootdev "LABEL=armbi_root" setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} loglevel=${verbosity}" booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr} mv ./1/boot.scr ./1/boot.scr.rock3c_bak mkimage -C none -A arm -T script -d ./boot.cmd.qemu-rock3-ext4 ./1/boot.scr sync umount 1 ; losetup -d loop0 ln -sf /usr/lib/u-boot/qemu_arm64/u-boot.bin . taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 2048 -smp 4 \ -bios u-boot.bin \ -drive if=none,file=armimg.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic It is a quick and dirty modification from something I did a year ago for ROCK3A to test single partition btrfs formatted rootfs (custom compiled U-Boot), so I am not 100% sure if all is correct, but it works. So the trunk.22 image seems to be fine, except that I needed own boot.cmd. I could not get the one in the image to work. At least it showed something like 'failed to load /armbianEnv.txt'; that might be a U-Boot version/variant issue, it is of course not the blob for the rock3c in the image between MBR and bootFAT but a generic Debian Trixie for qemu (U-Boot 2025.01-3 (Apr 08 2025 - 23:07:41 +0000)).

Note that ROCK3A images are 2 partitions, so 1st is boot and FAT formatted, so you should change verbosity to 7 in armbianEnv.txt, then the log will also contain kernel logs, that might tell what the problem is.

I now realize there is no ROCK3C downloadable image on the Armbian homepage as I was going to suggest you to download a 25.8.x image or so. So '26.2.0-trunk.7' is alpha or beta release and that changes per day, now it is .22 I see. You need enough tools and skills and time to get such a community level support SBC running. The images are just generated, you are the tester/checker. I can't really help you as I don't have a ROCK3C and that is definitely needed for such a case. I like the ROCK3C because with a SATA breakout board added, it is a good and cheap replacement for an old x86 PC to drive a SATA HDD/SSD. But the SATA breakout board can only be bought in China and I am in EU. Checking earlier downloaded schematic: No higher input voltage than 5V. Amount of Watts consumed does not say anything about voltage level and or short dips, so it is certainly no 100% proof that power is not a or the problem, but up to yourself to judge. Also the Rx serial path (so ROCK3C signal reception) might fail. As you mention USB keyboard it reacts. I think standard ethernet will be online, so that is another way to control the board, but needs the image manually pre-configured. You can check in your router for hints. You can build image yourself or use Radxa image, it has KDE Bookworm. You then can merge upgrade that yourself, but as indicated, it is DIY. Also ARM SBC images use 1 kernel only traditionally and you cannot select at boot time. I first changed Armbian boot method to use extlinux instead of boot.scr, so now I can select at least another kernel. If hadn't done that the board would be gathering dust now for a year already. I only used maskROM once just to see if it worked, with CLI tool rkdeveloptool (is default available in Opensuse Tumbleweed, I do not use Windows).

I looked into the image Armbian_25.11.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img It is NOT Trixie, but it is new and prominent one, comments below the download picture are 1 year old so outdated Please state what image you use. Anyway that noble 25.11.1 one is: DTB is explicitly 5b-plus, so that is OK, still name presented I would also think/prefer 5B+ U-Boot SPL 2025.10_armbian-2025.10-Se50b-P0eb7-Hdbe0-Vfd58-Bbf55-R448a (Nov 24 2025 - 08:35:51 +0000) So U-Boot is mainline but kernel is vendor 6.1.115, that does not work I think. On my ROCK5B, I use EDK2-UEFI v1.1 and I need to change a setting in it so it can boot 6.1.115. Standard is mainline (6.10 or later I think). That standard modern/mainline (v1.1 release is from april 2025) with 6.1.115 does not work, it locks up halfway kernel load or so. So this Image can't work I think. It can be changed to mainline kernel, in container or so, could do it right now locally on my computer, but does not make sense for anyone else. If you want Trixie, so debian13, you might take the one with kernel 6.18. I am using that on NanoPi-R6C and saw no issues so far. Of course it lacks various videocodecs etc, but no issue for some webbrowsing and mainly server remote tasks etc. So see want you want to use yours for.

I don't see that from the picture; That tells that kernel is running, and started with initramfs, but what happens after that? just stall?

It gets problematic if it is only Windows that is available. In the past I advised people to download Knoppix and boot the PC with that so you have full control. But nowadays SecureBoot might already be a showstopper, unless you know how to deal with it. So your best Linux is probably the ROCK5 with Armbian Bookworm. You can use that to edit the Trixie SD-card. Or upgrade bookworm in-place to Trixie, I have done it more than 10 times in 2025H2, still 1 or 2 computers to go.

From the log I see: Model: Radxa ROCK 5B 272910 bytes read in 34 ms (7.7 MiB/s) I would expect Radxa ROCK 5B+ Or is it 1 DTB nowadays? The bytes read should represent the DTB file that is loaded, I use extlinux so can see what files are loaded, seems this 2025.10 build does not show this. Also be aware it first tries EFI booting, it fails as one can see, so no issue here, but I got confused on my ROCK5B (not the newer upgraded + board) because I had an NVME connectod with a working bootaa64.efi grub.cfg etc as well, so it booted something else than the image from SD-card. I was my own tuned rootfs, so was rather easy to see, but other occasion I did not notice and wasted a lot of time. For this case, what does the kernel spit out ? set loglevel to 7 in armbianEnv.txt

Try what? Do I need to guess what "the most current stable Armbian" is ? Best post an URL + sha256sum what you are doing/using. In theory, I could fairly easy merge it into booting in a KVM, it has then properly working (virtual) RTC from the host (ROCK5B or NanoPi-R6C or RPi4B), but likely needs generic Debian Trixie kernel+initrd/(DTB). That can hide potential errors with your hardware, like a dangling wire in your cable or RJ45 connector or duplicate DHCPserver in LAN or worse (criminals). Or you have ethernet time protocol working, various ethernet HW supports it, like on RPi. Or what do you use to manage your network? Recently netplan.io got pushed, that was a disaster for me, such that I banned Ubuntu now.

In general it can be done what you want. You just need to understand how Arm SBCs boot/work and Linux in general. Simply stated, it is: ROM -> bootloader -> kernel -> userspace ROM is very specific for the SoC of course, also bootloader is specific as well as the kernel. You can make a kernel that includes all various drivers and methods, like there is for x86 (works with Intel chips and AMD chips). userspace (rootfs) is normally generic, so if you take RPi bootloader+kernel and Libre userspace, it can work. I have done such things several times, but then the other way around: RPi userspace from my 5 years always in-place upgraded rootfs running on Rockchip RK3588 SBCs (Armbian bootloader and kernel). That way no lengthy and boring re-install of all sorts of debian packages and configs tuning etc. Even browser bookmarks are the same then. So very fast up and running with the new SBC. You need to know or start to study the differences in bootloader methods of course. In your case looking into the Libre script/tool would be a good start I think.

From the serial_log.txt I can conclude that your SPI-flash must be empty, as it uses the u-boot version that is on the SD-card. So if you also don't have an eMMC attatched, that is now more simple. It is that older legacy based U-Boot, so should work with kernel 6.1.x. But kernellogging level is default set to 1, so I cannot see from the txt file what kernel it is, it might be older 6.1.x, I had lots of trouble with those. At least the 6.1.115 runs very solid on my ROCK3A now; it does all I/O I want: SPI, NVME, SATA (and SD-card as well but slot normally empty). This U-Boot: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) You can set loglevel to 7 in armbianEnv.txt (or directly on kernel commandline is more generic), then you see much more what is going on, it even might spit out info about crashing itself. A key thing for ROCK3A is to have proper PSU: Mine is never stable with whatever 5V only PSU, so also not the RPI5 PSU for example. Various U-Boot versions don't support USB-C PD, so I just soldered my own USB-C cable/connector that I connect to a 12V old car battery or some random 12V PSU that can do 2A or so. Then the onboard DC-DC converter is used to create a stable 5V etc. I don't remember how the ROCK3C should be powered, also not sure if it has own DC-DC converter onboard, so in that case it is just 5V and you are quite dependent on the quality of your PSU. If only an SD-card, it should be fine, but when PCIe is used fort NVME, I think expect freezes. Also think what you want with the ROCK3C; If you want a generic Arm64 Linux computer, you might be better off with 'edge' (both u-boot and kernel). You can't use quite some specific RK35xx features, but should be stable and easier to maintain. You can always compile/build an image yourself.

And further, what do you need? I know Armbian and Opensuse use chrony instead of older ntp things. Chrony can serve the time to others, do you need that? If not remove it I would say and keep/use a standard client-only method.

2 captains on the same ship is my first note. Then there is fake-hwclock and maybe an RTC onchip/silicon and/or your own or PCB vendor added RTC module like DS3231. And the battery can be almost empty. Early Debian Trixie had a bug with fake hwclock script, I already removed it years ago on SBCs where I added DS3231, but if you haven't there is the sort of 3rd captain. RPi/Raspbian users had that issue.