eselarm

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.

Good that you posted serial console output. A bit more and text (starting at power on when U-Boot starts) would be clearer, but I think the 2 top lines with 'Android' mentioned already indicate what is wrong I think; ROCK3C has SPI-flash where also the bootloader (U-Boot usually) can be stored and this has priority over SD-card bootloader. So it seems older/incompatible Android U-Boot variant in the SPI-flash loads Linux and as you use mainline Linux kernel, this won't work correctly as you see. On my ROCK3A, almost similar SoC I get all sorts of strange crashes/hangs in that situation. So use MaskROM mode to wipe SPI-flash or write a correct U-Boot version to it; see https://docs.radxa.com/en/rock3/rock3c/low-level-dev/3c-maskrom?host_os=Linux_MacOS Other option maybe is to boot with an image that has vendor kernel (I use 6.1.115 on my ROCK3A with legacy U-Boot) so then the board can be operated via serial console and from there write the SPI-flash with dd or flashcp (see /dev/mtd*).

I feed my ROCK5B-16GB with SATA brakeout on E-key and Samsung NVMe on M-key with 12V own soldered USB-C pigtail (from an old car battery in addition if mains power 12V brick is not there). It does not work with USB-C PD (the RPi5 27W nor an HP 45W ), then boot loop. I use the 5V and GND from 40-pin header for feeding the 5V of an 3.5 inch HDD (and it gets its 12V from the mentioned setup). Look at the ROCK5 schematics. It is not a RaspberryPi5 or OrangePi5. It has an own DC/DC stepdown convertor which can take 20V-9V on its USB-C power input connector and so creates an own stable 5V that is used for USB or in my case for some DIY 5V i need. You might dig deep into U-Boot and kernel and see if PD handling does work nowadays with latest, I didn't, I just soldered fixed 12V, much easier for me. Automotive can mean very high spikes and negative dips when engine start, so be aware to protect else your board might die sooner or later.

For SBCs without own audio I use networked pulseaudio. I never got it to work in newly installed Jammy and Bookworm, also not in Bookworm upgraded in-place to Trixie. It worked in Buster, BuIlseye and allways worked in Opensuse Tumbleweed. I already had all pipewire user sockets and services disabled and pulseaudio enabled, also de-installed pipewire-pulse as that one is the problem I believe (but is more than a year ago I looked at it). Now it turns out that doing 'pactl load-module module-zeroconf-discover' did add remote audio sinks. GUI based paprefs in Ubuntu/Debian should do it, but that is all grey since years, cannot be selected nor changed. So NanoPi-R6C with Armbian Trixie edge kernel now also plays audio via Armbian Trixie NanoPi-NEO SPDIF enabled with long simple wiring to an amplifier that takes coaxial SPDIF as input. I also had it working analog, but way too much issues with noise etc. 'the long simple wiring' is 1 lead of a low-quality twin analog audio cable, shielding=GND, core=signal.

First tell us how your power supply looks like.

I see on the mint website that there is nothing mentioned about Arm64, so consider mint as 'stay away' if you use Arm64. You have to do it yourself, so I would go for the most integrated solution. Mint is good for x86, because Ubuntu kernel an various proprietary HW, but that is all not the case for an OPi5+. I would take Debian as base and put Cinnamon on it. You can do it yourself by running 'sudo tasksel' or you put EDK2-UEFI v1.1 firmware on the OPi5+ and use https://dl.armbian.com/uefi-arm64/Trixie_current_cinnamon The missing start button might be complicated to fix, it can be due to some tiny error somewhere when you did setup the computer. Maybe a second try it will work, but maybe it is a real bug. I have only ran Cinnamon once for test for 15 minutes or so, it worked, but I use KDE normally, so have no clue where to look to fix it.

Good that it can be updated quite easily, although I am not sure about longer-term. In order to see what it is, I took a quick-and-dirty approach, so not running an install script but taking NextcloudPi_RaspberryPi4_v1.55.3.zip and make that run as/via UEFI. Reason is that Raspberry's must have 2 partitions, 1st must be FAT, so this I know can co-exist with EFI booting. Most other SBC images use 1 ext4 partition, so there is no FAT boot partition where EFI/boot/bootaa64.efi can be placed. I symlink between folders 'firmware' and 'efi' in /boot/, so no change in fstab needed to get it running. It turns out the image is a bit older Armbian Bookworm, not Raspberry Pi OS, so I had to delete some script in /etc/kernel/postinst.d/ and /etc/kernel/postrm.d/ Current Armbian RPI images use a script from RPL (Raspberry Pi OS). For this case I did just direct-boot a Debian13 kernel, copied from other Debian13 Arm64 VM. Once booted, I had to do some DNS fixes (standard fixed 1.0.0.1) and install grub-efi and install it and set boot partition to type 0xEF. As indicated, this also works on a real SD-card taken from an RPI (at least the 4 and 5). The 3 needs a hybrid partition table as the bootROM does not boot from MBR type 0xEF and TianoCore UEFI won't boot from a type 0x0C or other FAT type tag. I see https://www.armbian.com/qemu-uboot-arm64/ list 2 variants, I guess first is UEFI, but have not downloaded it. I use flat/raw images, not QCOW2, so same as SD-card, USB-sticks etc. The second states U-Boot, so I think this needs direct QEMU with -bios option and rather extensive set of options. It is fine for CLI only and fast way to get a single partition image running. Both are Ubuntu and looking at x86-VMs from Nextcloud, I see Ubuntu is needed, so maybe a good starting point. Else use Armbian build.

Make sure you can see and follow kernel messaging when initiating reboot. So another computer that taps serial serial console while you have loglevel=7 for the Potato.

@NOBL You can select text of someones post and then a small popup appears; If you click that, a reply/edit field is provided. It also took me some time before I discovered, maybe it was a browser issue or webblocker before I don't know. Related to it, I also don't know how to create 'hidden' text files so no endless logs or so. Anyway, on the topic: I see indeed VM is only x86-64 focused and also no Linux default build-in virtualizer, only external/commercial stuff like VMware and Windows/Mac. So for nextcloud, it is worse then for HAOS as I see it now. For HAOS, there is some Aarch64 VM image hidden somewhere on github, no documentation, but it works, does update well. It is same principle as for x86-64 VM images, so for me, having used standard Linux virt-manager (libvirtd/QEMU/KVM) for several years after VirtualBox and after VMware, it was easy to get running and as HA has a good backup-restore option, you get perfectly the same In a Aarch64 VM hosted on my ROCK5B for example as something running on old Intel Atom computer (also as VM by the way). So I would consider the easy 'nextcloudpi' and ready made images gone; You have to dig deeper and do more yourself, so looking at all the lower level components like PHP versions etc that fit a certain version. That is independent of which ARM SBC. Nextcloud is high-level software, there is no dependency on HW pins or GPIO or videocodecs etc. If there are Aarch64 images, you have to look at how they are created. I see from other post that there is ncp command, so what does that do? If you stick to 'images', you will indeed have a problem. The only relevant difference between Odroid and Raspberry or other Aarch64 SBC is the bootloader and kernel. Raspberry is the worst as they also do many changes to Debian userspace which for example from bookworm to trixie ruined my networking setup, so I blocked specific things (netplan stuff) and went back to Debian versions. Also RPi5 still cannot run standard Debian. If you want standards, make sure your HW supports UEFI, same as every PC/MAC does. See https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#supported-platforms I have this on ROCK5B and NanoPi-R6C and it is like a PC. You have to install it yourself of course, it is not pre-installed like is the case on a PC. But after installed, it is like a PC. Both those boards I have bought with metal case/heatsink, so no fans. Faster than a RPi5 and M.2 M-key slot on-board, so can use standard Samsung NVME or so. Also, the current/edge Armbian rockchip64 kernel runs in/as a VM, which makes it super flexible for tests but also for 24/7 doing real things. I installed grub-efi and then it boots as VM (assumuing 2 partition scheme). For Odroid (Amlogic SoC) I would expect the same. If not, install linux-image-arm64 in addition and use that kernel.

There are schematics available for this device, so one could get a hint from those, but depends if you have electronics background or not. To me it seems that higher level software in Debian/Linux enables power management handling all the way using info it gets from the power management chip/circuitry. You can guess that for this device, same as smartphone, battery operation is considered primary/essential, so decision is 'low-batt' and shutdown. I have a BananaPi M1 that also has LiPo charging, but that is DIY soldereing, so no OS component bothers with not-connected cell, but if a cell is connected/soldered which I did, is charges and runs on that cell if microUSB PSU (they call it 'AC' in the chip signal names) is disconnected, although its SATA port is unpowered then. Runs Armbian Trixie CLI only (eth + serial console). An old business HP 2-core laptop that I got without battery and HDD runs fine on just the original HP power adaptor (has 3rd wire for some genuine HP charger purposes). For USB-C powered devices, there might be many things to deal with, e.g. my ROCK5B after un-boxing goes in a bootloop with a RPI5 PSU, was/is know, so I feed it with own 12V USB-C pig-tail. For the Pinebook, it might be that the 5V is perfectly 5.000V but drops to 4.900V or so in spikes under load, so the typical 5V SBC powering issue well-known from RPi and other cheap SBCs that cannot handle >5V USB PD voltages. The Pinebook might do well if you fake the battery, so look at colored wire/connector. I have used that several times in the past decades. The yellow wire might be for temperature so besides a proper voltage on black and red, you also need to do something with the yellow wire I guess. It also might be that is you skip/disable the parts of software that do power management handling, that it runs fine. So I would boot/run the 'image' of the pinebook in a systemd-nspawn container or libvirt VM (at least the user space) and see what is what. Maybe it is something like purge 'laptop-tools' package or so, or blacklist the kernel module for power management.

What is easiest depends on the situation. If you feel comfortable enough to use dd to write bootloader, I just downloaded the -edge package from the beta apt package pool, extracted the .bin file and wrote it to correct location on SD-card, after saving the first 32k sectors also with dd to a backupfile. Then reboot and you know it. The qemu experiment was to boot directly from U-Boot to Btrfs raid1 filesystem, it took a lot of time browing through U-Boot config/compile options. Better/formal method is to install -edge package, it will remove -current package, then use armbian-config to write the bootloader explicitly.

OK, it seems your SPI-flash is empty, so not used and skipped. I start to remember I think; ROCK5B -current is quite old and not from denx.de (or 'mainline') so I picked -edge, but I think I never wrote it to SPI, instead I have this in SPI: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file You need grub-efi or other efi capable and configured bootloader (hide boot.scr, add ESP partition) root@rock5b:~# strings /usr/lib/linux-u-boot-edge-rock-5b/u-boot-rockchip-spi.bin | grep "U-Boot SPL" U-Boot SPL 2024.04-armbian-2024.04-S830c-P0000-H1056-Vdfa5-Bb703-R448a (Jun 08 2025 - 03:38:17 +0000) My ROCK5B is 24/7 server, I won't reboot and do checks now, up to yourself to dig deeper and see how various versions are build. I remember there is a config option w.r.t. this 1 sec timeout, that I saw when building qemu arm64 u-boot a year ago. I currently have blocked u-boot and armbian packages, but will maybe configure/build for ROCK3A 2025.10, but that is completely other topic/issue.