eselarm

Armbian_26.2.1_Rock-3a_trixie_current_6.18.8_minimal.img.xz (ROCK3A) - system has NVME inserted and SATA M.2 E-key adaptor where HDD is connected to - SPI has Armbian legacy U-Boot, but that is skipped as SD-card with new image is inserted - further only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - NVME is available (but OS is running from SD-card for the test) - SATA is not available as not supported mainline based kernel (and needs adding overlay manually when vendor kernel) - reboot does not reboot (but 'echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger' works) - also poweroff is only shutdown, no powerdown (and HDD keeps also spinning)

Armbian_26.2.1_Bananapi_trixie_current_6.12.68_minimal.img.xz (Bananapi M1) - only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - then connecting a SATA SSD ('hotplug'), pops up in dmesg, so recognized OK

I would first check the link, what is on the other side, etc. Also do a flood ping with large enough packages. Or UDP flood, not sure how to do that. Iperf3 might be easier. I have no clue about Radxa OS, never really used it. Maybe also do test boot with mainline based kernel, 6.19 edge I think. And what U-Boot version is used. I use Tianocore EDK2 UEFI v1.1, that might also have effect.

already in the first dmesg part I see: [54475.779558] r8169 0004:41:00.0 eth0: Link is Down [54479.115749] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [54479.115748] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off [55390.928391] br-ce724241dce3: port 1(veth1664549) entered disabled state [55390.928949] veth6932af4: renamed from eth0 [55391.020157] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.021811] device veth1664549 left promiscuous mode [55391.021831] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.493933] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.493954] br-ce724241dce3: port 1(veth1a65439) entered disabled state [55391.494085] device veth1a65439 entered promiscuous mode [55391.500502] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.500519] br-ce724241dce3: port 1(veth1a65439) entered forwarding state [55391.539757] eth0: renamed from vethb9b9ca0 [55391.561925] IPv6: ADDRCONF(NETDEV_CHANGE): veth1a65439: link becomes ready Which means to me that you use containers/docker or so and something on that networking level goes wrong. I think it had nothing specifically to do with Armbian nor ROCK5B. You should figure out what is running on your computer and what is done to networking in general. I do not use containers like seems to be done here, so cannot really help here. I have no clue about your networking setup and plans. I use various bridges and VLANs on my ROCK5B (Armbian Trixie), but all strict manually done by myself, only own files in /etc/NetworkManager/system-connections/

A month ago when doing test boots and power measurements, see I discovered that when using the RPL 27W 'Pi5' PSU, the NanoPi-R6C with the indicated bootloader(s) and kernel(s) sticks to 5V. But when using a 45W USB-C PD PSU from a HP laptop or 60W USB-C PD PSU white-label, switch is made I saw on a USB-C PD power measurement device that was also in the chain. More detailed USB-C PD protocol analysis seems to be needed in order to figure out what happens. One could guess 3A is requested at highest possible voltage as with the 45W PSU, I saw 15V. 9V or 12V would also be OK, but the PD handler cannot be 100% sure I think, depends also what is inserted in USB type-A ports on device etc.

That is the correct one. Then I do not know anymore why yours does not work with recent Armbian images/installation.

Which microUSB connector of the bananapi do you use for powering the bananapi itsef?

How do you power the bananapi m1? It has 2 microUSB connectors.

You can check the .DTB files on the bootfs (FAT32) 1st partition. AFAIK the Pi500 uses a D0 variant of the SoC and that needs a separate/dedicated .dts (when downstream kernel what Armbian also uses). When upstream kernel, make sure you have the very latest, as even in 6.18.0-rc? (or 6.19.0-rc? dont remember) I saw some fix w.r.t. naming w.r.t. that D0 variant. And also should pair with proper and/or new enough bootloader (the code in EEPROM). Still upstream kernel might lack a lot of functionality, but at least RP1 should work so RJ45 should work.

Mine is M1, no plus, so no WiFi. I used the following 2 years ago when I got the SBC: https://fi.mirror.armbian.de/oldarchive/bananapi/archive/Armbian_23.11.1_Bananapi_bookworm_current_6.1.63.img.txt

What is this topic about? M3 - it has Allwinner A83T and no SATA on the SoC but added via USB2 see https://banana-pi.org/en/banana-pi-sbcs/51.html M1(+) - it has Allwinner A20 and SATA on the SoC see https://banana-pi.org/en/banana-pi-sbcs/10.html Mine is the latter.

Just to note some more: I use none of those images, instead is it in-place upgraded Armbian, originally: root@banlipi:/tmp# grep VERSION /etc/armbian-image-release VERSION=23.11.1 Now Trixie: root@banlipi:/tmp# cat /etc/os-release PRETTY_NAME="Armbian 25.8.1 trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.0 ID=debian HOME_URL="https://www.armbian.com/" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 25.8.1 trixie" I log some stuff to terminal in my backup script; I see: U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Hb9d3-Vf23c-Bb703-R448a (Jun 21 2025 - 02:53:13 +0000) Maybe also good to know, I use extlinux on real HW, grub on KVM root@banlipi:/boot/efi/extlinux# cat extlinux.conf menu title Select the kernel variant DEFAULT default TIMEOUT 80 LABEL default KERNEL zImage INITRD uInitrd FDT sun7i-a20-bananapi.dtb FDTOVERLAYS sun7i-a20-analog-codec.dtbo APPEND root=LABEL=armbianrfs rootwait rw earlyprintk console=ttyS0,115200 But I am not sure how valid the release info is, will need to look at lists files etc and also run update to it is latest Debian 13.3 I think. I just ran apt update && apt full-upgrade and now it is 'latest debian trixie' but I use apt pinning and I see it is too strict and also an error, so os-release not changed It is essentially Debian Trixie armhf up to date with manually written U-Boot and manually copied sunxi kernel.

I have this SBC and it is still nice one as it includes LiPo charging/operation and SATA. I changed Armbian OS drastically, such that the raw SD-card as blockdevice/image also runs as KVM on my ROCK3A or RPi4 for example as standard UEFI machine. I have not tested that yet, but done several similar for NanoPi-NEO and some RPi3. Last thing done was use kernel 6.18 as default. Had not tested/connected a SATA recently, so good time to do it now; It works, see below: root@banlipi:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 512M 0 part └─sda2 8:2 0 118.7G 0 part mmcblk0 179:0 0 59.6G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot/efi ├─mmcblk0p2 179:2 0 6G 0 part /.snapshots │ /local/fsroot │ / ├─mmcblk0p3 179:3 0 1G 0 part [SWAP] └─mmcblk0p4 179:4 0 52.4G 0 part /local/sdata root@banlipi:~# dmesg | grep ata [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes [ 0.045731] Memory: 859656K/1015868K available (11264K kernel code, 1761K rwdata, 9604K rodata, 1024K init, 377K bss, 53644K reserved, 98304K cma-r eserved, 229436K highmem) [ 0.742930] libata version 3.00 loaded. [ 1.268996] ahci-sunxi 1c18000.sata: supply ahci not found, using dummy regulator [ 1.269351] ahci-sunxi 1c18000.sata: supply phy not found, using dummy regulator [ 1.269470] ahci-sunxi 1c18000.sata: supply target not found, using dummy regulator [ 1.311601] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 1.311632] ahci-sunxi 1c18000.sata: forcing PORTS_IMPL to 0x1 [ 1.311727] ahci-sunxi 1c18000.sata: AHCI vers 0001.0100, 32 command slots, 3 Gbps, platform mode [ 1.311748] ahci-sunxi 1c18000.sata: 1/1 ports implemented (port mask 0x1) [ 1.311762] ahci-sunxi 1c18000.sata: flags: ncq sntf pm led clo only pio slum part ccc [ 1.316206] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 34 lpm-pol 0 [ 1.630949] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.632905] ata1.00: ATA-9: SanDisk SDSSDP128G, 1.0.0, max UDMA/133 [ 1.632934] ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 32) [ 1.633567] ata1.00: configured for UDMA/133 [ 11.515496] systemd[1]: Expecting device dev-disk-by\x2dlabel-sdata.device - /dev/disk/by-label/sdata... [ 22.764093] BTRFS: device label sdata devid 1 transid 36 /dev/mmcblk0p4 (179:4) scanned by mount (378) [ 23.002238] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. root@banlipi:~# uname -a Linux banlipi 6.18.2-edge-sunxi #1 SMP Thu Dec 18 13:03:43 UTC 2025 armv7l GNU/Linux root@banlipi:~# cd /tmp root@banlipi:/tmp# mkdir 1 2 root@banlipi:/tmp# mount /dev/sda1 1 root@banlipi:/tmp# mount /dev/sda2 2 -osubvolid=0 root@banlipi:/tmp# ddrescue -f /dev/sda /dev/null GNU ddrescue 1.29 Press Ctrl-C to interrupt ipos: 1731 MB, non-trimmed: 0 B, current rate: 75366 kB/s opos: 1731 MB, non-scraped: 0 B, average rate: 133 MB/s non-tried: 126304 MB, bad-sector: 0 B, error rate: 0 B/s rescued: 1731 MB, bad areas: 0, run time: 12s pct rescued: 1.35%, read errors: 0, remaining time: 15m time since last successful read: n/a Copying non-tried blocks... Pass 1 (forwards)^C Interrupted by user So I can browse the filesystems on the SSD, seems I had used it for conversion of RPi Trixie Ext4 to Btrfs. Raw speed is fine I see. So I still can use it also with large 3.5inch HDDs, that is what I prepared the surrounding 12V powersupply for.

I stopped using netplan and its extra yaml layer on top of NetworkManager or systemd-networkd. I have a handful of VLANs (and several managed switches and cables in- and outside the house and also bridges 'on top' of those VLANs and USB/4G/WiFi as well. Several ISP's also use VLANs, so a must to have that working properly. It all works fine based on only NetworkManager essentially, but if needed I would do direct setup with ip tool. I have also Opensuse, that does not use netplan, but works simply by exchanging .nmconnection files with Debian. No new study or testing for days/weeks/months. Not Ubuntu because of that netplan and it generates .nmconnection files, so overwriting your own. The problem is, NetworkManager package in Ubuntu has a dependency on netplan.io package. So if you purge netplan.io , also NetworkManager is removed. This is not the case in Debian, hence Ubuntu again after 5 years when they also introduced could-init, turns out to be a PITA and simply waste of time for me. So for example for my ROCK3A (similar to your BPI-M5), I just threw away the Armbian Noble install and cloned Armbian Bookworm from NanoPi-R6C and later upgraded in-place to Trixie. Same networking, very little effort, almost unattended. As a sort of sick joke (for experienced home Linux users at least), also RPL put netplan and cloud-init as default in their images. There are several hacks/tweaks/workarounds on that forum. Even more because also many RPi users still use ifupdown and interfaces file (and dhcpcd based although not needed for static). Maybe have a look to see what could be best for you. I basically removed/blocked additional package sources lists, so I get the same on ARM as on x86-64. But note that that is for servers based, pure client computing should work out of the box if you have standard/average/common router, like ISP's 'give you'. If not, lot's own work to do as you see, but not Armbian specific, just home networking and router maintenance. So maybe think about hostnames and IP addressing in your home. I have own router (own software, Linux based) for more than 2 decades basically, so easy to keep a list of MACaddresses/computers, although I still have a simple spreadsheet as a sort of design philosophy/overview. You can reserve/fix MACaddress+IPaddress in dd-wrt, so then all client computer DHCP based tools should be no issues. Else you get a mess as you see. I have setup some dev/test environment based on a physical PCIe with RTL chipset ethernet port for systemd-networkd in combination with managed ethernet switches, but first trial locked up a certain VLAN (something in the switch I think). That was 3 monhts ago and not sure if I continue with it. It means more reading the long systemd-networkd docs, it seems not worth the effort when I compare with NM and its nmtui tool. You might also have silently installed a firewall package. firewalld defaults to public zone, that blocks incoming ssh. I experienced that some time ago on 1 computer with rolling release Linux distro, so that overwrites things every now and then when a fundamental upgrade of a certain part, but noted/warned in changelogs.

Network is down: 2: end0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 All instances I could find. I think your own networking methods conflict with what is common nowadays and also might be reason ssh server is not even running or depending on a pseudo random situation. Same as for other topic where you could not reach armbian repo server.

If you need an own build for some reason, you should be able to debug it as well. Why does it fail, others cannot know that from that screenshot. Also you yourself cannot. You need serial console etc, look into bootprocess of RPi, examine files and logs. In general it is rather simple compared to other SBC's, but still you need to do that yourself. It also might be an (additional) problem with you Pi or some SD-card adaptor etc/ Why can't you not use the standard available image? You can remove/tweak/add from there as well.

Ubuntu I see. That I do not have running, so cannot speak from experience.

If it is so critical, you should have a backup, not only of the files on the RAID array, but also of the root filesystem. Then you can again make a copy of that backed-up rootfs and do a test upgrade with that. You should also mention what OS/distro it is based (Debian or Ubuntu) , see /etc/os-release I guess it is Bookworm. This usr-merge should work OK if you did normal upgrades and even dist-upgrades. I have seen many warnings when doing Bookworm-> Trixie, but all still works well (not on Odroid-HC4, but various other Armbian installations). I do not use DKMS but that can cause some issues as it is not a standard distro kernel but Armbian's instead. So for me it is easy, I purge it. You should know where you need it for, I guess you don't need it as you do at least not run ZFS on the array AFAIK.

What happens after this is needed. make sure loglevel is 7 in armbianEnv.txt Hopefully yo have a serial console cable so you can copy and paste the text here on the forum, is better than pictures on imgur (site is blocked in UK by the way)

You use a Desktop/Xfce installation, and it is for a low-power ARM64 computer. So I would not be surprised if in modern Xfce, the Power Management default to suspends after 30 minutes or so. Last time I used Xfce was when Debian Buster, also then in then I remember in the GUI there should be some system setting where you can configure power settings. So there you can make sure that it never enters suspend state. I do not know how to configure that from command line, but that should also be possible, maybe search internet. You can also look into the journal and see what happened, maybe something is wrong. 7 Watts is way too high for suspend state at least, but maybe things connected on USB still draw power and is it only the CPU that is halted. Other option is not to use a Desktop image/installation, but a CLI for server/IoT variant. Those images should have suspend disabled.

I downloaded and extracted that image and now run it as container on my ROCK5B. Just wiping the root password first and then only configure root and then: root@bananapim5:~# apt update Get:1 https://github.armbian.com/configng stable InRelease [5,467 B] Hit:2 http://ports.ubuntu.com noble InRelease Get:3 http://ports.ubuntu.com noble-security InRelease [126 kB] Get:4 https://github.armbian.com/configng stable/main arm64 Packages [434 B] Get:6 http://ports.ubuntu.com noble-updates InRelease [126 kB] Get:7 http://ports.ubuntu.com noble-backports InRelease [126 kB] Get:5 https://fi.mirror.armbian.de/apt noble InRelease [39.2 kB] Get:8 http://ports.ubuntu.com noble-security/main arm64 Packages [1,882 kB] Get:9 https://fi.mirror.armbian.de/apt noble/main all Packages [9,047 B] Get:10 https://fi.mirror.armbian.de/apt noble/main arm64 Packages [769 kB] Get:11 http://ports.ubuntu.com noble-security arm64 Contents (deb) [167 MB] Get:12 https://fi.mirror.armbian.de/apt noble/noble-utils arm64 Packages [26.3 kB] Get:13 https://fi.mirror.armbian.de/apt noble/noble-utils all Packages [5,408 B] Get:14 https://fi.mirror.armbian.de/apt noble/noble-desktop arm64 Packages [16.7 kB] Get:15 https://fi.mirror.armbian.de/apt noble/noble-desktop all Packages [4,984 B] Get:16 http://ports.ubuntu.com noble-security/restricted arm64 Packages [4,059 kB] Get:17 http://ports.ubuntu.com noble-security/universe arm64 Packages [1,193 kB] Get:18 http://ports.ubuntu.com noble-security/multiverse arm64 Packages [38.3 kB] Get:19 http://ports.ubuntu.com noble-updates/main arm64 Packages [2,235 kB] Get:20 http://ports.ubuntu.com noble-updates arm64 Contents (deb) [175 MB] Get:21 http://ports.ubuntu.com noble-updates/restricted arm64 Packages [4,224 kB] Get:22 http://ports.ubuntu.com noble-updates/universe arm64 Packages [1,899 kB] Get:23 http://ports.ubuntu.com noble-updates/multiverse arm64 Packages [38.0 kB] Get:24 http://ports.ubuntu.com noble-backports/main arm64 Packages [49.4 kB] Get:25 http://ports.ubuntu.com noble-backports arm64 Contents (deb) [782 kB] Get:26 http://ports.ubuntu.com noble-backports/universe arm64 Packages [34.7 kB] Fetched 360 MB in 42s (8,497 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 304 packages can be upgraded. Run 'apt list --upgradable' to see them. So that seems OK. Now running apt full-upgrade -y and that works fine so far. Note that this does use the networking and kernel of the host, but a fast way to test userspace. no release file might have to do with something wrong in armbian repo mirrors. I am in the EU, might be different internet paths/routes/mirrors for you. I am actually unsure how this all works, so might also be something in the network setup in the noble image itself. Ubuntu uses netplan.io, that I could not get working with comples bridges and VLANs I use on ARM64 computers, so I avoid Ubunto for that and also in Armbian Debian images, I purged netplan.io and made sure I got NetworkManager working. And openresolve as DNS. You say you set up networking, I am not sure what that means. I mostly set a fixed IP address for a MAC address of the computer, then leave rest automatic as possible. You can setup more dedicated named/permanent profile with nmtui of course as well.

If I look at https://www.armbian.com/bananapi-m5/ the SBC is still supported. There were infrastructure problems, but that was before last weekend. I upgraded several Armbians (rockchip64 and sunxi) but are Debian Trixie based. I do not know about Ubuntu based and Amlogic/meson, but kernel is anyway Armbian and Ubuntu servers should be online. If you still have the old Ubuntu, it should be possible to upgrade in-place, so not new image, but edit sources.list files and then run normal upgrade.

So if this works for you and you apparently know how to change bootloader, I can not really say or conclude more in addition to what is already said. I do not use images nor Imager and also do not own the ITX, I only tried to see if this issues is maybe something RK3588 generic.

On https://www.armbian.com/radxa-rock-5-itx/ there are several things wrong. 1 is a desktop image has stated size of 260.1 MB, that is certainly wrong. Then below there are several filenames Armbian_24.11.1_Rock-5-itx* in a sort of test report list. Note sure if that makes sense, more than 1 year old images. Also 6.1.75 vendor kernel had a few issues for me, although other RK3588 SBC. 1 year old versions of images might rely on older non-KMS HDMI init of a HDMI-monitor (done by older U-Boot), while newer U-Boot fails to init HDMI-monitor and also newer kernel and the current KMS might do things in a different way. I have that for my NanoPi-R6C and a certain older Medion HDMI monitor. Sometimes the KDE login screen just pops-up in 640x480. When login, the normal desktop goes correctly to 1080p60 (fullHD). A soft reboot also keeps it then in 1080p60, but the 2026.x versioned U-Boot does not manage to init the HDMI (maybe on-purpose, I have not looked in build config etc). I have not tried restarting displaymanager via ssh as the 640x480 came eventually, but did it several times in the past (from 2019 till 2024 or so until not using it with HDMI anymore) for 2 RPI4, also different monitor and also with or without a HDMI switch in between. A method is to put a video= statement on the kernel commandline with the desired mode. Earlier via RPi firmware in config.txt. I also looked into journal for the NanoPi-R6C issues of course and various failures w.r.t. HDMI after kernel 6.16.x or so, but all not fatal. So in the end it works and now properly working with kernel 6.18.2 edge kernel (Armbian Trixie KDE6). I went back to other bootloader (EDK2-UEFI v1.1) as that manages to init the HDMI monitor before kernel load and that is what I need, else always other computer needed (serial console) to select a different kernel or kernel config. I have never used video= statement with Armbian (yet), maybe I'll try just to know if and how it could work. So @Bobbox, can you post what image it is (exact filename and sha256sum) ? Even better is also kernel version and U-Boot version (exact UUID build strings), but a better human readable version will also give some hints already. And maybe upload armbianmonitor log, but that is maybe for later.

Standard Debian; select what you want when you run: sudo tasksel