eselarm

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

I do not know how to fix that key / verify signature issue. It might be there because of earlier diskfull. I only know I needed new keyrings, listed in the armbian list files when I did the in-place upgrade from bookworm to trixie. There is a formal method for that I think, might be here on forum. I however did copy various things from a new Armbian Trixie image. E.g. new file is now: -rw-rw-r-- 1 root root 2297 Aug 31 22:15 /usr/share/keyrings/armbian-archive-keyring.gpg ~# sha256sum /usr/share/keyrings/armbian-archive-keyring.gpg 9d0ab1676008004f1ee0bfc0f99a6043544d8bb6df3d949f9bd30066246f9095 /usr/share/keyrings/armbian-archive-keyring.gpg For Docker problem: I don't use Docker, I have no clue why that file keeps growing.

There is a separate boot partiton, it should be there. MACOS same as Windows might hide/block it as it is tagged as not normal filesystem (0x8300) but boot related (0xea00 or 0xef00) Linux has no issue with it.

You could use the Cubie for it. The trunk.100 works you said, so you have a working Linux computer, can be operated via serial cable console.

For you, 'make an image' means downloading a file from Armbian website and write it to an SD-card. For me, 'make an image' means using the Armbian build environment https://github.com/armbian/build to create an image yourself locally on your computer. This is what 'make an image' is. Already 2 people including myself showed that GPT is corrupted in the image file on the Armbian website. You can assume that the bootloader when run on the board itself also detects that, so it won't boot/proceed. So something goes wrong in the Armbian build infrastructure. However, that is what I assume. So up to you confirm by showing the logs of the bootloader. You need serial console cable for that, so you can copy and paste for sharing that log here on the forum. Other option, a step further ahead, is to make an image yourself. You need a Linux computer/environment for it. It also shows very detailed logs, share that.

I dumped all your text in ChatGPT and got enough answers; maybe do the same

I now actually see after some more reading and checking other SoC's that the CPU's in the A733 must start the kernel at EL2. See also ARM reference doc: 102412_0103_01_en So also 5.x kernel should work if EL2 I think If the A733 has not implemented EL2 and EL3 as could be the case as suggested in ARM reference doc, no KVM. See chapter6: As it is Allwinner, I won't be surprised, but wait and see what Radxa will come up with.

Have you also looked at the clocks? I have several NanoPi-NEO's (since around 2021 I think), H3 SoC, never had any overheating issues. I actually did some measurements recently and surprisingly low power, I had expected more. Clock stays at 480 mostly. I see the Duo2 is H3, Duo I don't see on FriendlyElec's site. But quite different HW/board. Only thing I could think of maybe is that I removed ( apt purge --autoremove) cpufrequtils after in-place upgrade from Bookworm to Trixie. Have not looked at it any further, it just is not in my vanilla Debian Bookworm -> Trixie, so just blind purge I thought. Still all fine, also with 6.18 kernel: # uname -a Linux raspi2 6.18.2-edge-sunxi #1 SMP Thu Dec 18 13:03:43 UTC 2025 armv7l GNU/Linux # cat /sys/class/regulator/regulator.?/microvolts 3000000 3300000 5000000 1100000 # cat /sys/class/thermal/thermal_zone0/temp 27116

May boot from new / known-to-work Armbian on SD-card and use command: sudo lsblk and/or sudo lsblk -f to see what is what. mmcblk numbers have swapped sometime in the past years, so indeed even if you know enough about Linux, mixing numbers might be a disater because you would overwrite the runnig installation. That might also be a reason why tooling might refuse or not list as there is a risk of having it wrong. But you should clean-up the 100% full filesystem. It will take time figuring out what should be deleted, but so does going to the toilet as well. It has to be done, cannot assume there is endless space.

Radxa staff actually does not answer the original question w.r.t. Allwinner A733 HW virtualization, it is just that kernel config has it. But I see from releases 'bullseye', that does not look good at all. In theory, that means 5.10 kernel, and oldoldstable libvirtd/KVM/QEMU etc. As this SoC is bigLITTLE, (Cortex-A76 Cortex-A55), starting a qemu-system-aarch64 process will pick some of those cores randomly, assuming you have more than 1 vCore (smp option > 1) . Kernel older than 6.8 or so does not support moving between an A76 and an A55. That is the same for Rockchips (RK3588). It took me quite a while before I discovered that this is known behavior. So on for example on vendor rk35xx 6.1.115, I pin vCPUs, can be done in virt-manager GUI xml config or cmdline via taskset. As easy test, use -smp 1, then it should work. mainline kernel CPU numbers are such that simplest/lowest CPU's get lowest number. That might be the other way around on 6.1 or older downstream/vendor/BSP kernels. On an RK3588, a 2-core VM with 2x A76 and 512MiB is done by: taskset --cpu-list 6-7 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 512 -smp 2 \ -bios u-boot.bin \ -drive if=none,file=armbian.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic Same should work on A733

log says: No space left on device So you need to look at that, remove unneeded stuff etc. Also check the output of df Maybe something else is wrong

OrangePi in general is bad support, as also is stated on the image download page. For just driving a relay, so a pin change between high and low, you first need to select which pin from the GPIO header you want to use. You can see what are probably generic GPIO by default from picture here: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2W.html In the latest image, I see there is no real support for OrangePi02W, only H5 and A64, not the actual H618 (it seems to use H616, so also that might lead to issues). You can look in file maybe, if you want other then defaults: /boot/dtb/allwinner/overlay/README.sun50i-H5-overlays I have older 32-bit Allwinner things, H3 for example. Analog and SPDIF audio works great there, that is why I bought those mainly. Also GPIO6 I use for driving a switch (via extra resistors and some MOSFET/TRIAC). I did some C-code and got working temp sensor and switch, see lgio code https://abyz.me.uk/lg/download.html But currently for years already in bash script: init: test -f /sys/class/gpio/gpio6/value && echo 6 > /sys/class/gpio/unexport echo 6 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio6/direction chown root:gpio /sys/class/gpio/gpio6/value chmod g+w /sys/class/gpio/gpio6/value on: gpioset gpiochip0 6=1 off: gpioset gpiochip0 6=0 This still works since Armbian Buster, now kernel 6.12. Not tested yet with 6.18

You have to allocate the I/O pins you want to use and how you want to use them yourself, can be done in armbianEnv.txt. A generic image cannot know what you want and what is connected to which I/O pins. GPIO is not like USB or PCIe that is can be automatically let its connected hardware enumerate. Also old Linux behavior w.r.t. GPIO is gone. You fundamentally need to open it, keep it operational with handle, in your code. Like you open a file when you want to read or write. Python might do that for you, but for C-code maybe look at lgio. So maybe tell first what you want to achieve, is it a temperature sensor maybe, or control a MOSFET or relay, etc.

There is at least no primary GPT, all zeros from 0x200-0x20000 Fixed with: # gdisk Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img GPT fdisk (gdisk) version 1.0.10 Caution: invalid main GPT header, but valid backup; regenerating main header from backup! Warning: Invalid CRC on main header data; loaded backup partition table. Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables. Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table! Warning! One or more CRCs don't match. You should repair the disk! Main header: ERROR Backup header: OK Main partition table: ERROR Backup partition table: OK Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.