Igor

Neither we do full hardware validation. That is only done in military grade software support and this is community open source development Thank you for your input. We don't have much time so in case we don't find a fix in <1h, broken images will be removed. Which is already a good added value. It is interesting that Gnome works and KDE don't. I did several tests on x86 platform and KDE always worked ... But I think we need to be realistic and happy if one desktop works solid.

1. At this stage you should be extremly happy if it generally works trouble free. 2. Yes.

Armbian 26.05 Test images: https://fi.mirror.armbian.de/incoming/igorpecovnik/ Tested by me: - x86 and arm64 UEFI images - Odroid M1 - Radxa 5T https://paste.armbian.com/jizuhuweru - Inovato Quadra - RPi 400 - Musepipro - Orangepi 5 Plus (vendor BROKEN, wrong DT) - Odroid N2 https://paste.armbian.com/ipoyatajuj - Nanopi M4V2 https://paste.armbian.com/rewiqijizi - Nanopi R4S https://paste.armbian.com/sesemehohi - NanoPC T6 LTS / plus https://paste.armbian.com/cupifefofe - Nanopi R6S/C https://paste.armbian.com/igesulided ..

Ask AI to fix problems at repo level: https://github.com/armbian/supervised-installer so we can all benefit. I don't have capacity to maintain this alone.

Me neither. This is my primary intention, just currently overwhelmed with things. I did some changes on top on official: https://github.com/armbian/supervised-installer

I am running mine on Trixie, installed about a year ago. Then it worked ... Core is running inside Docker container so functionality should be O.K., but we might currently have some problem ... I will look into this when I am about to reinstall my setup, but I plan to add Docker install only, which should work well, but it has certain limitations.

There has been several improvements that hasn't landed to stable images yet - try rolling releases for this board.

On it. Coming soon.

We understand the concern, and we appreciate the effort put into testing and documenting the issue. At the same time, it is important to understand the realities of the embedded Linux ecosystem. Armbian supports a very large combination of SoCs, vendor kernels, boot chains, and downstream modifications across several hundred boards. Security response and validation in this environment is significantly more complex than in standardized desktop/server distributions. Explained here: https://github.com/armbian/build/issues/6937#issuecomment-4366571379 This is not a matter of ignoring the issue, but of limited engineering resources, kernel fragmentation, and the high cost of validating fixes safely across multiple platforms. Project can only finance security from your contributions https://github.com/sponsors/armbian volonteers or sponsors. Until none is taking this seriously, there is little what existing team members can do. We already attempted mitigation work on one of the most widely used kernel branches: https://github.com/armbian/linux-rockchip/pull/475 but even targeted fixes require substantial testing effort and may (i am sure it will) introduce regressions on affected hardware families. Current resources barely sustain even our regular release and maintenance process: https://docs.armbian.com/Process_Release-Model/ For users who need receiving upstream fixes faster and are willing to accept a higher risk of regressions on hardware feature breakage, there is always an option to switch to rolling/daily builds, where fix may already be available: https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling Tradeoff between stability, validation cost, hardware compatibility, and update speed is unfortunately a sad reality of embedded Linux maintenance.

Just a small note here - I recently added Bianbu desktop (can be installed from armbian-config), where acceleration works on K1 based Musebook (legacy kernel). This should be possible to adopt to any other K1 board. Youtube video works fine in Chromium ...

For Ubuntu Resolute desktops you need to build from this branch: https://github.com/armbian/build/pull/9683 It is a matter of days when this will be merged. You can speed this process by reviewing the code. P.S. We lack 1-2 beefy arm64 servers or 30-40k $ and unknown $ for storage space as we would need to upgrade from free storage which is limited to 1000 artifacts in order to provide more build combinations. We are far away ...

You need to provide more informations. I wasn't able to repreoduce. I works here.

What you’re seeing is open-source maintenance in practice. It’s not centrally orchestrated. We only manage to do this for some key features while DVB support is present in some kernels, but it’s not guaranteed to be consistently enabled across all targets unless someone explicitly maintains this functionality. -> https://github.com/armbian/build/pulls

https://docs.armbian.com/User-Guide_Armbian-Config/System/#desktop Should be straighforward to enable desktop on top of CLI.

We have information on which mirrors are good and which bad. We just don't display it. Good are passed to the redirector.