Vendor-provided Linux images for single board computers are not always working optimally, so this post is a regular reminder that users may want to check out Armbian and DietPi projects mostly supported by the community but also backed by some of the vendors who offload some (repackaging) software work to them.
Armbian and DietPi are separate projects, but this month, Armbian v25.2 and DietPi v9.11 were almost released simultaneously. I don’t report on each release (should I?), but they release an update every few months. The last time we had a look at both projects was in September 2024 for the releases of DietPi 9.7 and Armbian 24.8. Let’s see what the new releases have to bring.
Armbian v25.2
Main changes:
- New Boards – Rock 2A and 2F, NanoPi R3S, Retroid Pocket RP5, RPMini, Rock 5T, GenBook, MKS-PI, SKIPR, Armsom CM5, NextThing C.H.I.P, Magicsee C400 Plus
- Rockchip 3588 Improvements – Upgrade to the latest vendor kernel v6.1.99 and mainline to 6.12.y, including HDMI driver updates, USB3 fixes, and Bluetooth support updates.
- Wireless Enhancements – RTW88 driver additions and kernel stability fixes, added automatic wireless testing infrastructure.
- Kernel Upgrades – Most kernels were upgraded from 6.6.y to 6.12.y, with extensive refinements in all areas.
- U-Boot Updates – Most boot loaders were updated to their last stable version, 2024.10 or greater
- Easy deployment of tools – AdGuardHome, Pi-Hole, Home Assistant, Utime Kuma, NetData, Grafana, Cockpit with KVM management, NextCloud, … can now easily be deployed via armbian-config
- Expanded build and mirror network – Additional sites in Amsterdam, Vienna, and Nuremberg
- CDN Upgrade – Upgrade of Content Delivery Network (CDN) to support users affected by global conflicts, ensuring better accessibility worldwide (basically to provide easier access in Ukraine and Russia).
- Improve torrent download speed for community download targets by mirroring GitHub downloads at Armbian’s CDN.
A much longer list of changes can be found in the changelog. Armbian also notes (on X) that the Allwinner boards did not get the new 6.12 kernel in this release:
Allwinner family is the only one that hasn’t been upgraded to K6.12.y, as even common bugs couldn’t be fixed by the release date. Older boards likely still work, with kernel 6.6.y, but with so many of them and so few of us, it’s impossible to check them all.
As usual, you’ll find the latest Armbian-build Debian and/or Ubuntu images on the download page. The boards with Platinum support may work better since Armbian gets funding for those from the SBC vendors.
DietPi v9.11
DietPi is an alternative, especially if your board isn’t compatible with Armbian or if you’re looking for a leaner Debian-based image.
DietPi v9.11 changelog:
- Pi-hole – Support for Pi-hole v6 added, and the main reason for a quick release after the v9.10
- Initial boot / Firstboot – Fixes for Quartz64/Star64/VisionFive 2 and WiFi connected hardware
- Fixes for Fail2Ban
Since there’s not too much here, I’ll also list the changelog for DietPi v9.10 that was released earlier this month:
- RISC-V (StarFive VisionFive 2, PINE64 Star64) – Switch to Debian Trixie and support of Bazarr, Raspotify, NZBGet, MicroK8s and AdGuard Home
- Raspberry Pi, NanoPi M6 – New tool DietPi-Display supports the setting of console display modes/rotation
- Raspberry Pi – Migration to the new Raspberry Pi kernel/firmware stack is now possible via dietpi-config
- DietPi-Automation – New option in dietpi.txt for automated APT-based program installs
- myMPD – Available now also for ARMv6 Bookworm systems
- vaultwarden – Display of the package version within the web UI added
- Fixes for Sonarr, Fail2Ban, Raspotify, Navidrome, Home Assistant, Komga, PaperMC, Bazarr, Mono, Gogs, Domoticz and Baïkal
You can check the full changelog for any version of Dieti on the Release page. Visit the download page to see if your board is supported and download a minimal Debian image.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Armbian (or any other project) does not contain code from DietPi, as DietPi does not contribute to commons. Which is the core philosophy that drive open source projects. Especially not to the segment they claim to serve. Their work is largely unrelated to single-board computers, as nearly everything they offer as value originates from other sources, primarily from Armbian project. DietPi does not introduce almost anything new beyond minor, largely irrelevant modifications in the software installer, which itself is poorly implemented and generates constant illusion of progress. In contrast, Armbian relies on Docker containers for most software deployments, ensuring low-maintenance and reliable solutions.
The only real difference between Armbian and DietPi lies in the timing of releases of images developed and stabilized (which is months of work dietpi never did) by Armbian team, thus creating the illusion of added value. It’s unfair to the many open-source projects that genuinely invest in innovation. There is nothing other project can take from them which forcing other projects to scale back their investments into open-source development. This is open source, where fake competitions only makes damages to all of us. Unfortunately, deceptive practices seem to be rewarded rather than questioned.
This was an aspect of DietPi about which I was completely unaware. Do you have sources for this? DietPi and Armbian are often mentioned together but I had no idea there was a parasitic relationship going on…
Just compare the forums of both distro’s and you’ll quickly see which one is a community effort and which not.
All the tricky stuff, hardware support and kernel patches which pretty much defines a SBC board distro based on debian userland is no thanks to DietPi.
Normally I wouldn’t care but begging for donations while maintaining a setup script could be a useful addition to the Armbian team feels a bit leechy.
The easy answer as to why the Armbian forum is different than the dietpi forum is that the Armbian forum is quite hostile to inexperienced users, therefore mostly developers “pass the muster” to hang out there. On the contrary, the dietpi forum is full of inexperienced people who just want to get something working and often ask simple questions, they don’t really understand what to do etc.
Now ask yourself whether this is a situation that exists because “armbian is just better” or whether there are different rules on each forum, and each forum has a different focus.
Also, I have never really seen any dietpi devs “begging for donations” – they just provide a link to their patreon. Contrast this with armbian, where there are repeated dramas about “using the software and not giving back”, “breaking the open source philosophy” and all that. Also, what rule in the “open source philosophy” prevents anyone from remixing what others did? I thought this was the whole point.
There is no developer’s or collaboration category and I’m far beyond the questions you deem relevant.
The open-source philosophy is not about remixing or reuse, but about collaboration to improve software.
Give and take is this underlying motivation of open source, contributing to a common cause, not the resulting rights attached to the software which only serve as a social contract.
The disregard of this social contract and eagerness for a free lunch explains the hostility.
If you want someone else to figure out your stuff and problems in depth you can pay for it to whom it made possible.
For me, I’ve been there and know how the world works as it is. The idea of open-source has eroded to a simple consumption model and I’ll support the people financially as possible who deliver but refrain myself from spending time to contribute to an anonymous community.
Because, the nuisance, hostility and stubborness of an Armbian Igor I can easily respect out of value. Without Armbian or Debian, there is zero value in DietPi.
The first near-mainstream u-boot branch for opizero3 was used in the manjaro arm. After that patches were successfully submitted to the main branch.
Most of the patches for allwinner H616 or A523 in armbian were taken from warpme’s miniarch repository.
Without Manjaro or MiniArch, there is zero value in Armbian.
Manjaro? Initially, much of their ARM section was built on Armbian, which they openly acknowledged. However, over time, they began taking Armbian patches, claiming authorship, and sending them upstream – all in the name of “benefiting users.” It’s another case of taking credits in the name of open-source, but at what cost? Who will ever track the full extent of this? Does anyone care? Unfortunately, probably not. If you’re curious about how they treated the PostmarketOS developers, you can read more here: https://blog.brixit.nl/why-i-left-pine64/.
As for Armbian, it doesn’t officially support some of the newer Orangepi boards, such as the Zero3 and 2W. This creates an opportunity for others to step in and help Aliexpress dealers making money.
Fortunately, many dedicated developers, including Piotr, are actively contributing to these efforts, with Armbian playing a main role in connecting and supporting the ecosystem. In the last Armbian release, there are names from more then 50 contributors …
yep, manjaro. Why I know that? Because those were my builds and patches that I sent upstream. Armbian is appropriating 3rd party labor when it talks about “playing a main role”. I watch the linux-sunxi community and I haven’t seen any armbian activity there at all. Maybe rockchip? No, it’s being handled by collabora. So what does armbian do? Says that everything is done by armbian? That sucks. Because that’s the impression people get over time.
Again, from the point of the user, these squabbles as to who did what are completely irrelevant. Please at least try to get out of your developer bubble and look at this from the perspective of someone who just wants to set up a small server for themselves.
These are complicated projects, you can’t expect normal people to actively participate in developing every single thing they use, this would be a horrible way to live. The option is there, for those who wish.
DietPi is built by end user(s), and unfortunately, many of them may not fully grasp the impact of their actions on the broader ecosystem. End users often lack the insight to see how their involvement can harm or hinder the open-source community. It is disheartening when individuals or organizations take credit for work they haven’t contributed to, especially in the open-source world, where recognition is often one of the few rewards for developers.
Developers deserve acknowledgment, and at the very least, they should receive respect from the media and industry. But can they effectively challenge bad actors or companies exploiting their work? Not without your support.
DietPi focuses primarily on cosmetic changes and selling products that are marginally tweaked versions of others’ work. The only true beneficiaries here are the individuals behind DietPi. In the end, users lose as well. How?
If you visit the DietPi forums, you’ll notice a concerning trend: they tend to avoid addressing real issues. When something requires deep technical investigation, users are often directed to forums like Armbian, where they’re encouraged to apply pressure for solutions. How can developers respond to this? Why does this approach lead to conflict? Is this an effective way to do the job? The answer is no. The real question is, who benefits from this? Users expect flawless software, and when DietPi works well, they claim credit. But when things go wrong, developers are blamed, even though they had no control over the situation.
Tackling tough problems takes time—months of effort, to be precise. Any senior developer knows this. While end users may not understand the depth of these challenges, DietPi, unfortunately, fuels their frustration, often suggesting that developers are simply lazy or incompetent. The pressure they place on developers can push them to their breaking point, sometimes without anyone realizing how much has been lost in the process. For example, contributions made by individual developers, like those on this project https://github.com/Joshua-Riek/ubuntu-rockchip/discussions/1104, often far exceed what DietPi has ever contributed, and these efforts frequently go unnoticed. As a result, the community loses, and so do the users, while DietPi’s reputation remains intact.
Another critical question to ask is: why do companies like OrangePi support projects that don’t contribute to open source and are known bad open source players, https://www.youtube.com/watch?v=omgFoHi6Pt8, while failing to support the open-source developers who are actually creating value for everyone? This situation only further highlights the systemic issues that harm the open-source ecosystem and the developers who tirelessly work to improve it.
[ users starting from ‘https://www.linuxfromscratch.org/index.html’ would be an improvement? ]
People who download Armbian or DietPi images just want something that works out of the box. Linux from Scratch is the opposite of that. Users would basically have to reproduce the work already done by those projects.
> I had no idea there was a parasitic relationship going on…
It’s just that DietPi is not a build system but a bunch of (few) people who grab already existing Debian images somewhere from the Internet, run a ‘diet’ script over it (almost entirely for moronic reasons), add some scripts to ease configuration and software installation and rebrand that as an ‘own distro’ which it isn’t.
For DietPi users it’s a clear advantage when DietPi rebrands Armbian images since Armbian’s build system generates those automagically from scratch unlike many SBC vendor provided images that are full of security flaws. DietPi shipped such latter crap at least in the past also rebranded as DietPi. There is/was no-one over there who understands the problems involved with downloading random crap from the Internet and use this as a base for an ‘own distro’.
Of course Armbian has its own problem(s) which is mostly Igor (a guy thinking it would be OK to add security flaws since he’s soooo exhausted – mostly by personally explaining over and over again to anyone who doesn’t want to know that he’s exhausted – that it’s perfectly OK to not care about security or stability especially ‘since cosmetics matter‘).
The user does not care about petty dramas between developers. The user just wants to use what works. Some users may prefer dockerized applications, some prefer easy bare metal. It’s not for developers to decide what is better, it’s for the users. So, please stop being patronising to anyone who chooses to use dietpi. It’s boring and ineffective. The users does NOT CARE
Perhaps that is the reason why the rk3588s-nanopi-m6.dts is available in Armbian, but not yet upstreamed to lore.kernel.org.
With upstream u-boot and 6.13+-kernel there is little reason to install Armbian or DietPi instead of Debian. Where you could make a mistake with the T6, with the M6 it is hardly possible since the emmc is exchangable. I expect Debian Trixie to fully support both T6 and M6 at the release.
I only saw Armbian had a complete M6-dtb after I managed to get the pcie-wifi working on my M6 with plain Debian.
A big part of the challenges in getting boards to run smoothly comes from dependencies on upstream sources like mainline Linux, Debian, and U-Boot. Comon places are good, but not an ultimate answer. Supporting the vast variety of hardware on the market is a constant effort, and mainline cycles are ridiculously slow. Armbian operates between the embedded and generic Debian worlds, filling a gap that Debian doesn’t address. Users often come from plain Debian, wondering why hardware doesn’t work well in Debian, while Armbian handles it well. They sometimes expect Armbian developers to fix older Debian kernel bugs, like this is job that needs 5 minutes of their time. Although Armbian contributes improvements upstream, the process is slow due to limited resources and high demand on Armbian itself. If you’re a Debian or Ubuntu user, Armbian works the same, usually better.
You are missing a main point. Armbian did great work with armhf. Probably they also contributed to arm64. But the current rockchip rk35xx are pretty much main stream general purpose machines.
Tried the rock5b with armbian: a struggle. Tried the M1 with armbian and switched back to odroid images within a week (system is currently running home assistant now). Tried a R5C, a T6 and a M6 with plain Debian and they where a breeze.
The only advantage from Armbian for me is the M6 DTB. For the T6 and R5C I got them from different parties. Still need to reinstall the Rock5B with Colllabora patches without the “extra’s” from Armbian. But I expect those the current T6 kernel to work for the Rock5B.
My experience is that I don’t appreciate the added value of maintaining a complete distribution from Armbian. Their scripts just generate extra work. Switching to plain Debian removes a great headache for me.
Any one rembering the “fight” of dietpi against dirty pages and flushing/writing them to disk (instead keeping them in memory) for “enhanced” write amplification?