Igor

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.

Community images are tied to daily beta repo where it should always be a match kernel - headers. Just make sure you have a clean updated system then proceeding to header installation via armbian-config. And only if this doesn't work, report so we can look into.

Generic aarch64 or x86 image has all needed support for most comon virtual environments. On a side we provide cloud images, optimized to run inside KVM / QEMU virtualized environment - super lean kernel. https://armbian.com/boards/uefi-arm64 https://armbian.com/boards/uefi-x86 Look for cloud kernel images. Here it can only be a problem if host (Orangepi) supports qemu or not. I don't run it here but I think it must just work. There won't be any difference compared to standard Debian / Ubuntu. Armbian is more polished in general, comes with several important improvements. Securing support for virtual targets is relatively easy compared to any custom hardware. And this was done long time ago. We use Armbian UEFI and QCOW2 virtual images to drive our infrastructur and also automated testing, but of course we target KVM / Quemu not Virtualbox. Which anyway can run normal image. Our runners and cloud services mainly run Armbian Noble cloud. Our website (dual core x86 vps): www:/boot:% du -h vmlinuz-6.18.10-cloud-x86 15M vmlinuz-6.18.10-cloud-x86 + 17M for modules (normal image has 150-200M for modules, for things you never need in virtualized environment) Yep, that's the best path for this use case.

When SPI is erased, the board falls back to the bootloader on the SD card. If you want to run Armbian, or Linux in general, the bootloader often needs to be updated - in this case on SPI. This can be done with armbian-install. Android support is not verified and is outside the scope of Linux maintainers. It may continue to work, or it may break.

This likely means the I2S overlay doesn’t exist yet. Someone would need to implement it and add it upstream (or just here to Armbian build framework). You can try enabling it manually via the Device Tree editor: https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-editor No guarantees it will work — hardware descriptions are often incomplete or inaccurate, and that’s outside our control.

If someone is eager to add sway - we have a new cleaner way to add and maintain (unit tests, AI auto maintain) new desktop: https://docs.armbian.com/Developer-Guide_Desktops/

https://actions.armbian.com/?repo=armbian.github.io Here anyone can monitor ... but the real problem is capacity to fix problems. Not knowning them. We have too many problems on the to do list It is not O.K., but also not a critical problem. This script is making a cache for this package which is needed in critical operations. Where it can't fail. This is why this was made in 1st place. We can't rely on upstream infrastructure.

Gnome (wayland) desktop with kernel 6.18.y Probably this way? apt install mpv mpv --hwdec=auto test.mkv (+) Video --vid=1 (*) (hevc 1920x816 25.000fps) (+) Audio --aid=1 --alang=mul (*) (aac 2ch 48000Hz) AO: [alsa] 48000Hz stereo 2ch float VO: [gpu] 1920x816 yuv420p But something is still missing ... not hw accelerated. Sorry, not an expert here. I am happy when Chromium says it.

On vendor kernel you need to enable overlay https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh#L18-L28 mainline based gnome desktop + apt install kodi (just tested 4k/H264 video works without any problems)

Support for rotation is better in modern 6.18.y Linux. Fastest is to download image and try https://www.armbian.com/boards/roc-rk3399-pc But VPU acceleration in rotated screen might be a problem ... and you will need to generate Gnome desktop image to facilitate Wayland or no fun.

What's new in armbian-config desktops Pick how much desktop you want — at install time and after Three tiers (minimal / mid / full) instead of one monolithic install. Minimal = DE + display manager + a terminal (~500 MB). Mid adds a browser and everyday apps (~1 GB). Full adds office + creative tools (~2.5 GB). And you can move between tiers later — armbian-config knows the delta and only adds or removes what changed, no reinstall. Clean uninstall, every time Every install records a manifest of exactly which packages it added. Removal undoes only those — packages that were already on the system before you installed the desktop stay put. No more "I uninstalled XFCE and lost half my system." One YAML per desktop, no per-distro hacks Each DE is a single declarative file in tools/modules/desktops/yaml/. Adding or maintaining a desktop no longer means editing scripts; you describe what you want and the engine figures out releases, arches, browsers, and overrides. Adding a new desktop is a YAML edit and a parser smoke test, not a hunt through bash. Same desktop, every supported distro and arch Per-release and per-arch overrides handle the awkward edges: missing packages on armhf, the riscv64 ports that lag behind, the package that got renamed in Ubuntu noble. Same YAML works on Debian bookworm/trixie and Ubuntu noble across amd64 / arm64 / armhf / riscv64. Smart browser selection The literal token browser resolves to the right package per platform automatically — Chromium where it exists, Epiphany on platforms where Chromium is broken, Firefox-ESR on Debian riscv64. No more bug reports about "Chromium won't install on RISC-V." Custom vendor archives, done right Optional repo: block per DE with full support for: signed-by GPG keyring (no apt-key), per-release suite paths (e.g. SpacemiT's per-snapshot bianbu archive), multi-suite fan-out (one archive, six deb lines for security/updates/customization channels), wider component lists than main, and APT pin preferences in the same place. Removed cleanly on uninstall. Auto-login that doesn't trash your config Enable / disable autologin for gdm3, sddm, or lightdm via in-place sed edits — your WaylandEnable=false and other customizations stay intact. Branches on ID=ubuntu from /etc/os-release, so it writes to the right file (Debian's daemon.conf vs Ubuntu's custom.conf) without guessing from the codename. A weekly AI driven self-audit catches drift A scheduled workflow scans the YAML matrix against armbian/build's supported releases and the live Debian/Ubuntu archives — flags releases not yet covered, flags packages that no longer exist upstream — then opens a draft PR with proposed YAML fixes. Dead packages and missing releases stop accumulating silently. armbian-config --api module_desktops User documentation: https://docs.armbian.com/User-Guide_Armbian-Config/System/#desktop

Worth trying all of them.

Open source projects like ours operate with very limited resources, and infrastructure such as mirrors is maintained on a best-effort basis. We’re aware that things are not always perfect, but addressing this properly requires dedicated maintainers - something we never had. If you’d like to help improve the situation, we’d genuinely welcome someone stepping in to take ownership of this part of the infrastructure. Improving scripts to make this information correct and other things that are missing ... Perhaps contanting mirror owner would already be a solution. I understand - but our mirror system isn’t a standard Debian-style setup. The “empty mirrors” you’re seeing are a cosmetic problem. Only status isn’t automatically pruned yet, so entries can remain listed after they’re no longer active. This does not affect users: traffic is routed through apt.armbian.com and dl.armbian.com, which only serve from working mirrors. What’s missing is automation to keep the public listing in sync - not mirror functionality itself. One of those https://actions.armbian.com/?repo=armbian.github.io needs further development. Our rsync server works: rsync -av rsync://rsync.armbian.com/dl/ I have no clue as this mirror is not under our direct control. Edit: I sent email to administrator of AARNet.

At the begginging of the page https://docs.armbian.com/Mirrors/#introduction it is written how the system works. What we don't provide on that list is current status of which are live in in sync. However you can check this at any moment: curl http://apt.armbian.com/mirrors | jq

Kernel 3.4 was the last known version supporting NAND boot. Since its deprecation nearly a decade ago, equivalent NAND support has not been integrated into mainline kernels.

Did you ran apt update + upgrade + reboot before ? Edit: we might add warning if installed and running kernel version differs. I ran into this problem myself.

They don't provide images for armhf anymore. Last build was 3 years ago: https://hub.docker.com/r/owncloud/server/tags?page=1&ordering=last_updated&name=v7 We made a notice that its compatible for amd64 and arm64: https://docs.armbian.com/User-Guide_Armbian-Software/Media/#owncloud but our installer doesn't filter that out yet. Official Docker way, it won't work. Try something else, perhaps

Did you perhaps upgrade kernel and forgot to reboot?

https://docs.armbian.com/Process_Contribute/#adding-a-new-board