Igor

HW (features are determined by kernel used in the image) related issues are shared among all variants, desktop, cli, minimal, Debian or Ubuntu.

Sige5 is community supported and those boards receive automatic generated images only - once per week. Since GitHub introduced additional limitations few months ago, we can't (auto)produce desktop images anymore - only one Debian stable minimal per CSC build target. However, this might change in the future.

Kernel packages comes from the same (main) repository. This won't cause you problems, if you upgrade from bookworm to trixie, but we can't guarantee for packages that comes from Debian. You might try this way: https://docs.armbian.com/User-Guide_Armbian-Config/System/#stable-distro-upgrade Note that you might need to download updated Armbian key: wget -qO - https://apt.armbian.com/armbian.key | gpg --dearmor | \ sudo tee /usr/share/keyrings/armbian.gpg > /dev/null cat << EOF | sudo tee /etc/apt/sources.list.d/armbian-config.sources > /dev/null Types: deb URIs: https://github.armbian.com/configng Suites: stable Components: main Signed-By: /usr/share/keyrings/armbian.gpg EOF

I think official stand from open ZFS project is: "ZFS is not designed for 32-bit kernels" ... it still might work(ed). IMO stay on kernel 6.6.y. I doubt there is anything wrong on Armbian side ... worth experimenting with Ubuntu Noble minimal image to rule out possible headers incompatibility.

OK. I think workaround is to re-download / re-install armbian.key from repository. As key was already changed.

I think the core problem is that headers were compiled with Ubuntu compiler / userspace and you try to use it on Debian. I used this on Ubuntu, which is the reason why it worked. We are aware of this problem - headers should be distro specific. Which adds complexity on our side ...

We already did that. I think the problem is that our keys are not packed (yet) but added at build time. When a person upgrades from Bookworm to Trixie, this will show up, while on new Trixie images this shouldn't manifest. @zital debian Is this the case? https://github.com/armbian/configng/commit/5d866b9b105bfd46cb341c21c70ba76e32e1fea2 We are signing with old and new key (which is aligned with current standards) since then.

Currently yes. A replacement for this package / service needs to be found and implement - in case you want to get involved. Thank you! It's a work of many people, impossible for me to poke into every issue or feature that exists

From desktops I tested Gnome - works.

Recommended. It looks like its not that far away. With rebase you will see the diff and if this is all you need to apply.

Yes, cpufrequtils has been removed upstream. It's not anymore in Debian stable. https://packages.debian.org/search?searchon=names&keywords=cpufrequtils

Yes, exactly.

tl;dr; You need to fix the driver code similar we do it here https://github.com/armbian/build/tree/main/patch/misc I tried this: https://github.com/albertogviana/YT6801 (but tuxedo v1.0.30 might have this already fixed) https://paste.armbian.com/xeraretaxu.diff I fix the most obvious errors, but don't have time to deal with this code. Some intermediate or old kernels might be missing matched headers. They are present at latest kernel (tested). BTW, it works for me: khadas-mind:Downloads:% sudo dpkg -i tuxedo-yt6801_1.0.30tux4_all.deb Selecting previously unselected package tuxedo-yt6801. (Reading database ... 158138 files and directories currently installed.) Preparing to unpack tuxedo-yt6801_1.0.30tux4_all.deb ... Unpacking tuxedo-yt6801 (1.0.30tux4) ... Setting up tuxedo-yt6801 (1.0.30tux4) ... Loading new tuxedo-yt6801-1.0.30tux4 DKMS files... Building for 6.12.44-current-x86 Building initial module for 6.12.44-current-x86 Done. yt6801.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.12.44-current-x86/updates/dkms/ depmod... (Re)load module if possible khadas-mind:Downloads:% modinfo yt6801 filename: /lib/modules/6.12.44-current-x86/updates/dkms/yt6801.ko license: GPL license: GPL author: Motorcomm Electronic Tech. Co., Ltd. version: 1.0.30 description: Motorcomm YT6801 Gigabit Ethernet Driver srcversion: 13DED66BAFB05DCB4D65DE6 alias: pci:v00001F0Ad00006801sv*sd*bc*sc*i* depends: name: yt6801 retpoline: Y vermagic: 6.12.44-current-x86 SMP preempt mod_unload modversions parm: debug:FUXI ethernet debug level (0=none,...,16=all) (int)

https://fi.mirror.armbian.de/apt/pool/noble-utils/b/base-files/ They are in. Perhaps need some time for repo to get in sync.

Etcher used to be / is broken. https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card https://docs.armbian.com/User-Guide_Troubleshooting/

R76S will be supported, but its too early at this stage. We setup download page https://www.armbian.com/nanopi-r76s/ but no images yet.

When things are not actively monitored, features stopped working without knowing. This has to be find out. At least all Armbian distributions have the same kernel, regardless of its upstream origin - Debian X,Y,Z and Ubuntu A,B,C ... have same kernel. But of course kernels versions go up all the time. I am not managing this that deep / specific. Where to search? On this forum. I am sure that this was already brought up.

This is not recommended as its not controlled environment. It might work, but no warranties. HDMI output is broken in general (on this particular SoC) regardless of variant, desktop, cli, minimal. Its known bug, but we currently don't have anyone maintaining Allwinner A20 series so its up to random person to fix this. Code is open, so anyone can. Then it should be o.k. since HDMI output is not needed.

Works well on my side - could not reproduce (with Docker based compilation), but however there is a (common to a20 boards) problem with HDMI output while boards otherwise works.

We have a long wish to implement OTA solution into the build framework. The problem is - like always - time / not enough man power to run another (sub)project. Instead of reinventing the wheel - better is to follow / use (learning from) experts made frameworks: https://rauc.io/ as a base perhaps also this https://github.com/silitics/rugix/issues/82 and https://qbee.io/docs/index.html - all as extensions. If we can join resources, to do it right, its easier. But its still timely and complex due to the nature of what Armbian is dealing with.

We appreciate idea, but we have to look at the health of the whole ecosystem. Our build framework deals with many boards and non-standard low-level components (e.g., U-Boot), and right now it builds reliably only on Ubuntu Jammy. Even Noble isn’t fully compatible yet; adding Debian (unofficially, to some degree, it already works for many years) at this stage would likely cause regressions. As Ubuntu is more present in embedded world, making Debian recommended would costs a lot more from budget we don't have while bringing nothing in return. Exactly. There are many issues in FOSS and there is little we can do. We didn't develop any of those tools - we provide them. Networking stack is an important part, it has its own diversity and this should be in users domain. I think our logic for providing images is a good compromise - we provide Debian and Ubuntu images, we provide them once with systemd-networkd (minimal) and the rest with NetworkManager. Now to keep some consistency and make it simple for non experts, using NetPlan as a central config point also makes sense - for most of use cases and most of users. Those who needs special handling of net stack, its easy to replace them with something else.

When you do first login, you need to choose correct locales combination and language in desktop should follow - you still need to install desktop packages ... If you don't have locales support in the system, you won't be able to use it in desktop. I think this is the problem. In my case, when I select my own locales (sl_SI.UTF-8) and install those desktop related packages, I have Gnome with Slovene support.

This looks normal. Most of those boards have bootloaders at locations prior to boot partition. Boot loop. This can be many things - i would guess kernel crash and watchdog issue restart. Why that happens? Hard to tell. This way? sudo screen /dev/ttyUSB0 115200 It should prompt out something.

Quite possible, actually expected as there is no support for current kernel: https://github.com/armbian/build/blob/main/config/boards/orangepi5pro.csc#L8 and build target is not maintained by core Armbian team https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained

That would be good. Cubox-i has standard microUSB connector for serial console, so its easy. That would give some insights on what is happening.