Igor

Try armbian-config way - drop your configs before.

This is not Armbian fault by any means. When you buy hardware, you mainly support hardware designers. Proper software support, that is yet to be developed by projects such as ours (with or without collaboration with hardware makers). This board was added to the Armbian build framework by vendor last week (!), which means its support is basic, bugs are expected and it only have community support status ATM: https://docs.armbian.com/User-Guide_Board-Support-Rules/ Probably this will fix it. https://github.com/armbian/build/pull/7903

Which most likely won't work on Wayland based Gnome desktop ... switching Gnome to X or using XFCE or similar is a way that this will work.

Armbian OS updates: - enable / disable kernel upgrades - switch between stable and rolling repository - enable automatic updating of Docker containers images - automatic packages updating enable + configure (unattended-upgrade)

Explanation and a fix that needs to be integrated https://github.com/armbian/build/issues/7896

Its a Trixie related bug (or some intentional splitting of package dependencies). Fixed: https://github.com/armbian/build/pull/7894

You need a VNC server that supports Wayland. Put that into Google search / ask AI.

We have many of such boards in the system Armbian mission is trying to keep them alive as long as possible. We invest a lot of efforts to keep them build-able, but there is just too many things that can go wrong in the u-boot / kernel area. Boards are constantly collapsing - if we want to keep them aligned with a modern kernel. The task is simply too big for our small team. We encourage people, owners of those (old) boards to step up and integrate those findings to the builds system, so this solution is available for everyone. We are running one mirror on Radxa ITX with success: https://www.armbian.com/newsflash/armbian-v24-11/ Software wise we are covering it well.

Nothing is planned unfortunately. It was a try if I can bring this from the dead in a couple of hours. I spent all the time I could afford to. In order to not go into the self-destruction path, we set a rules to ourselves: https://docs.armbian.com/User-Guide_Board-Support-Rules/ I can't maintain this board. It is one out of (perhaps 500 that are on the market, and one out of 100 that has some user base behind). If someone will help, and step up, to match the board support rules, this board can be lifted to standard support. It was dropped to community support about a year ago https://github.com/armbian/build/pull/6654 as we haven't heard it from its maintainer for a long time. We don't have any other alternative. I hope someone will take a look and integrate those changes into the build framework. Then we will at least a device into automated testing for early problem detections. They will certainly pop up in the future as they always does

Yeah. We have alias for neofetch that is borking this. Needs to find another way.

It depends. It might not work on weird private kernels (vendor v6.1.99), but it works on mainline based ones (<= 6.12) it has to. It works on Bookworm, while on Noble it will work tomorrow: https://github.com/armbian/os/pull/285 Test build succeeded: https://github.com/armbian/os/actions/runs/13486581225/job/37678541738

Could be, yes. Just try without.

You mean this problem is present also on Rockchip vendor kernel? Well, then this is also helpful, while for mainline based kernels, 6.6 and 6.12.y are only target. Besides EDGE, where this will emerge automatically. Thanks.

We will be with stable on 6.12.y for some time. Perhaps add it here: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.12

@prahal Can you look into this?

They have identical firmware. Try most recent 25.2 images https://www.armbian.com/bananapi-m5/ Our test device runs fine - up-time 6 days ATM.

Sure, the rest can be adjusted on PR itself. I still wait / hope we will manage to switch CURRENT to 6.12.y with this release, otherwise this will stick at edge until.

Last week I managed to complete first part of run-time desktop deployment script. It might serve as a starting point of what you want to achieve. https://github.com/armbian/configng/pull/436

# Europe/Moscow - 2000 Mbit/s - server: stpete-mirror.armbian.com/beta/ rules: - field: location.country.iso_code not_in: - UA latitude: 59.9417 longitude: 30.3096 weight: 10 # Europe/Kiev - 1000 Mbit/s - server: fastmirror.pp.ua/armbian/ rules: - field: location.country.iso_code not_in: - RU latitude: 50.458 longitude: 30.5303 weight: 10 After this change, our redirector blocks access to Russian mirrors for users in Ukraine and vice versa. Hopefully, this feature will become obsolete soon.

Test for latest stable image (Armbian_25.2.1_Odroidxu4_bookworm_current_6.6.75_minimal.img.xz) 1. https://dl.armbian.com/odroidxu4/Bookworm_current_minimal 2. Boot logs on HC1 https://paste.next.armbian.com/kupugotasi No issues whatsoever. Check PSU, cables, use different SD card, ...

This is how network is set for some time now: https://docs.armbian.com/User-Guide_Networking/

Desktop installation: (XFCE and Gnome at the moment) https://docs.armbian.com/User-Guide_Armbian-Software/Desktops/ automatic install and uninstall on code changes and daily modular packages assembly https://github.com/armbian/configng/blob/main/tools/modules/system/module_desktop_packages.sh clean and minimal (will be cleaned more, PR is welcome)

If you already upgraded to broken version before, it will break. Then re-installation of those package is needed, like I did.

Manual test on our test device: root@odroidxu4:~# apt update root@odroidxu4:~# apt install --reinstall linux-image-current-odroidxu4 linux-dtb-current-odroidxu4 root@odroidxu4:~# reboot After machine is up: https://paste.next.armbian.com/zapohihawi

We have 3a and 3c. What is the difference anyway? Doesn't work with any of those?