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.