Igor

Software complexity is extreme ... And only x86 I would assume, so there is very little of interests for us. It is enough that packages are assembled at different time, so they will have different (bugs &) fixes. Either Ubuntu will get this bug or xtradebs will be fixed. Soon both wil be fixed or both broken .... unless bug is down to the OS level. Where snap will win with its, presumbly, stabilized OS container.

On prebuild images we test video acceeleration within Chromium and it works. Both kernels, Ubuntu Noble / Resolute Gnome, same good or bad on all boards. Others userspace combo might not work and other/all video players we don't even try to cover. Our job is done, when at least one method works OOB. It was integrated. This is not needed anymore. For overlay, I don't know. I think its still needed and it that case, its certanly present. On kernel, where this is needed.

Perhaps here: https://issues.chromium.org/issues?q=status:open as xtradeb ppa is packaking service only. I don't think they do anything else that that.

Tested: - Odroid C4 / HC4 - Tinkerboard - Odroid XU4 - Rockpi E

All moved.

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 ...