-
Posts
14681 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Igor
-
-
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 ... -
On 1/30/2026 at 1:53 AM, DogancanYr said:
but it didn’t work.
You need to provide more informations. I wasn't able to repreoduce. I works here. -
49 minutes ago, sugatam said:
Is this intentional?
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 -
2 hours ago, norbiv8 said:
desktop images
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.
-
52 minutes ago, DavidFajardo said:
Running VirtualBox on Armbian is generally not a good fit for what you’re trying to do. Armbian is primarily designed for ARM-based single-board computers, and VirtualBox is built with x86 hosts in mind and relies on kernel modules that are not well-supported (or sometimes not available at all) on ARM kernels like the one in your chosen Armbian image.
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.52 minutes ago, DavidFajardo said:especially on boards like the Orange Pi 5 Plus.
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.
52 minutes ago, DavidFajardo said:if you specifically want VirtualBox, you’ll have a much smoother experience running it on a standard x86 Debian/Ubuntu system rather than Armbian.
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)
52 minutes ago, DavidFajardo said:If your goal is to run Home Assistant without containers, a more reliable approach would be to either run Home Assistant OS directly on supported hardware, or use a lightweight hypervisor that works well on ARM (such as KVM/QEMU
Yep, that's the best path for this use case. -
3 hours ago, KAHrel said:
After deleting it, it detects it, but my Android system stops working.
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. -
1 hour ago, kris777 said:
there are no entries for: I2S
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.
-
9 minutes ago, robertoj said:
sway
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
2 hours ago, bedna said:Ignore this if all is ok.
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. -
14 hours ago, XXXBold said:
Which image?
Gnome (wayland) desktop with kernel 6.18.y
14 hours ago, XXXBold said:Would using the CLI version also work
Probably this way?
apt install mpvmpv --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 yuv420pBut something is still missing ... not hw accelerated. Sorry, not an expert here. I am happy when Chromium says it.
-
On 4/7/2026 at 5:13 PM, Joe K said:
and build ubutu desktop Gnome
On vendor kernel you need to enable overlay https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh#L18-L2837 minutes ago, XXXBold said:what is still needed for Kodi
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-configdesktopsPick 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-configknows 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 intools/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 onarmhf, 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 tokenbrowserresolves 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
Optionalrepo:block per DE with full support for: signed-by GPG keyring (noapt-key), per-release suite paths (e.g. SpacemiT's per-snapshot bianbu archive), multi-suite fan-out (one archive, sixdeblines for security/updates/customization channels), wider component lists thanmain, and APT pin preferences in the same place. Removed cleanly on uninstall.Auto-login that doesn't trash your config
Enable / disable autologin forgdm3,sddm, orlightdmvia in-place sed edits — yourWaylandEnable=falseand other customizations stay intact. Branches onID=ubuntufrom/etc/os-release, so it writes to the right file (Debian'sdaemon.confvs Ubuntu'scustom.conf) without guessing from the codename.A weekly AI driven self-audit catches drift
A scheduled workflow scans the YAML matrix againstarmbian/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_desktopsUser documentation:
https://docs.armbian.com/User-Guide_Armbian-Config/System/#desktop
-
9 hours ago, kris777 said:
There are other options, but they probably don't apply to bananapim2pro. :
Worth trying all of them. -
6 hours ago, evilbunny said:
I don't understand is why you have a mirror still listed
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.
6 hours ago, evilbunny said:I've been an apt/Debian user long enough to have a reasonable idea how mirrors work
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.6 hours ago, evilbunny said:Perhaps more to the point, is this a temporary technical glitch or permanent removal of Armbian packages?
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.
-
13 hours ago, evilbunny said:
mirror.aarnet.edu.au is still listed on that page
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 | jqSpoiler{ "AS": [ "http://mirrors.tuna.tsinghua.edu.cn/armbian/", "http://mirror.twds.com.tw/armbian-apt/", "http://mirrors.bfsu.edu.cn/armbian/", "http://mirror.ossplanet.net/armbian/apt/", "http://mirror.albony.in/armbian/" ], "EU": [ "http://mirrors.c0urier.net/linux/armbian/apt/", "http://netcup-03.armbian.com/apt/", "http://armbian.systemonachip.net/apt/", "http://mirror.hostiko.network/armbian/", "http://es.sbcmirror.org/apt/", "http://mirrors.dotsrc.org/armbian-apt/", "http://fi.mirror.armbian.de/apt/", "http://xogium.performanceservers.nl/apt/", "http://netcup-02.armbian.com/apt/", "http://armbian.nardol.ovh/apt/", "http://distrohub.kyiv.ua/armbian/", "http://mirror.vinehost.net/armbian/apt/", "http://k-space.ee.armbian.com/apt/", "http://imola.armbian.com/apt/", "http://stpete-mirror.armbian.com/apt/", "http://armbian.hosthatch.com/apt/" ], "NA": [ "http://armbian.chi.auroradev.org/apt/", "http://armbian.lv.auroradev.org/apt/" ], "default": [ "http://armbian.chi.auroradev.org/apt/", "http://armbian.lv.auroradev.org/apt/", "http://mirrors.c0urier.net/linux/armbian/apt/", "http://netcup-03.armbian.com/apt/", "http://armbian.systemonachip.net/apt/", "http://mirror.hostiko.network/armbian/", "http://es.sbcmirror.org/apt/", "http://mirrors.dotsrc.org/armbian-apt/", "http://fi.mirror.armbian.de/apt/", "http://xogium.performanceservers.nl/apt/", "http://netcup-02.armbian.com/apt/", "http://armbian.nardol.ovh/apt/", "http://distrohub.kyiv.ua/armbian/", "http://mirror.vinehost.net/armbian/apt/", "http://k-space.ee.armbian.com/apt/", "http://imola.armbian.com/apt/", "http://stpete-mirror.armbian.com/apt/", "http://armbian.hosthatch.com/apt/" ] } -
2 hours ago, anuj Chadha said:
cubiboard 1
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. -
13 minutes ago, izzo said:
HC4 kernel and headers version dont match
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.
-
5 hours ago, John Felstead said:
but it cant find a ARMv7 image.
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/#owncloudbut our installer doesn't filter that out yet.
Official Docker way, it won't work. Try something else, perhaps -
8 hours ago, Jeedom Cassivet said:
It seems there is an issue with iptables in the 6.18.10-current-meson64 kernel.
Did you perhaps upgrade kernel and forgot to reboot? -

current kernel from apt repo (6.16.8-edge-sunxi64) still vulnerable to local privilege escalation bug CVE-2026-31431 "copy.fail"
in Software, Applications, Userspace
Posted
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.