Armbian 22.11 released with 64-bit RISC-V UEFI, ultra minimal images support

Armbian 22.11 has just been released with three new SBCs, support for 64-bit RISC-V UEFI, a new ultra-minimal image optimized for software development, and various improvements.

Armbian was born as a framework to build better OS images, usually Debian or Ubuntu, for Arm-based single board computers from Orange Pi, Hardkernel (ODROID), FriendlyElec, Banana Pi, and others, but now with the release of Armbian 22.11, support for the RISC-V architecture has started since the system can now generate 64-bit RISC-V UEFI images.

Some other highlights of Armbian 22.11 include:

  • Added support for Banana Pi BPI-M5 (Amlogic S905X3), ODROID-M1 (Rockchip RK3568), and Rock Pi 4C Plus (Rockchip RK3399-T)
  • Enabled community images with a weekly release cycle
  • Added ultra minimal images optimized for software deployment
  • Improved support for the Rock Pi S (Rockchip RK3308)
  • Kernel upgrade is frozen by default to improve stability

I could not find details about the new “Minimal” images, but as can be seen in the screenshot above listing some of the Banana Pi BPI-M5 images, it is about 130MB smaller than the usual “Client” image. There’s no specific RISC-V SBC mentioned in the release, but I’d expect the first RISC-V boards to be supported by Armbian to include the StarFive Vision 2, or the Allwinner D1-based Nezha or Sipeed LicheeRV SBCs. A more detailed changelog can be found on the documentation website.

If you’d like to upgrade simply run those two commands:


For a new or fresh installation, you can browse the list of supported boards, download the Debian or Ubuntu image you’d like to install, and flash it to a MicroSD card with USBImager or other tools. More details may be available in the announcement.

Share this:

Support CNX Software! Donate via cryptocurrencies or become a Patron on Patreon

14 Replies to “Armbian 22.11 released with 64-bit RISC-V UEFI, ultra minimal images support”

  1. It’s nice that they’re focusing on minimizing the amount of useless stuff installed by default on a system. But everyone has a different notion of what a “minimal” image is. For me a full-featured load balancer image for the Breadbee glibc, openssl, openssh, haproxy, wpa-supplicant and the usual debugging tools like tcpdump, strace etc is around 14 MB kernel included (no graphics interface there however, everything is terminal-based). And those working on OpenWRT will laugh, saying that I’m wasting lots of useful flash space storing heavy utilities that could be reimplemented much smaller. So it’s just a matter of referential I guess: if it’s smaller than what you were used to and seems to be as convenient to use, then it’s minimal.

    1. Minimalism is always subjective and yes, you can always go further. For deployment one usually only need some sort of network utils, logger, cron, secure shell … for everything else, there are CLI images, where debugging tools and development tools, perhaps even kernel headers are present by default. (this is environment where I feel good) Kernel wise – maintaining a minimal config. It is possible, but its is very resourcesful. Armbian still carry many different, per family, per generation kernel builds. Perhaps in the future, there will also be a minimal, stripped down kernel, containing just bare support to boot the device up. At least in UEFI supported hardware.

      1. Stripping kernels is indeed extremely hard. I can’t count the number of times I found myself not being able to read an FS because I disabled some apparently unneeded extensions, or missing certain features to properly run a different distro inside a chroot. Not mentionning the first time you boot your kernel on a freshly new machine with a network adapter you had never met before, thus never enabled. Over time your kernels grow again to progressively catch up with all the features that your users need.

    2. Am I mistaken or do these images not come with a package manager which you can use to add what your need?

      1. There’s indeed no package manager, we build full images from sources and flash the images. Typically on my USB stick it’s just a matter of having one kernel and one initrd containing the whole rootfs. It’s a choice, we abandonned packages 15 years ago because we found they were too cumbersome to maintain in field compared to having a single image (think embedded systems, that’s not for every use case). There are pros and cons to this but actually for my home servers/gateways/firewall it’s well suited, just like I like to have it to quickly boot a random PC here or there to turn it into an SSH client, a traffic generator, or just to recover its data. We found parallels in the past with the approach taken by openwrt (except that we didn’t want to compromise on tools, so we’re using full util-linux, coreutils etc), however openwrt managed to nicely integrate a tiny package manager on top of their read-only images and that nicely bridges the gap between a fully read-only image and a fully package-based one. We just haven’t gone that far by lack of need for it.

        1. Sorry, I was asking about the Armbian ultra minimal images. I certainly understand not having a package management system on something like a breadbee. Maybe if it had a uSD strapped to it as well, but with 16MB of SPI, it’s just a LFS ‘in place’ image.

          It sounds like you’re using an Arch or freeBSD kind fo system–just with the source tree missing from the distributed part of the ‘distro’. Sort of an LFS+++

          1. > Sorry, I was asking about the Armbian ultra minimal images
            Ah, misunderstanding then 🙂

            > It sounds like you’re using an Arch or freeBSD kind fo system
            Actually it’s called Formilux. You build it from sources and recipes. The recipes are part of the project and the sources are downloaded. Since it predates git, it relies on FS to store recipes and converting them (and the build system) to switch to git takes a lot of time. To get a better idea of how it works, the simplest solution is to have a look at the build procedure I wrote 6 years ago for our device for students (“Aloha pocket”, running on a GL.iNet 6416A): http://www.haproxy.com/download/aloha/pocket/developers/
            By then the images were even only 12MB kernel included 😉

          2. > Armbian ultra minimal images

            There’s no such thing since Armbian ships with either an Ubuntu or Debian userland (garnished with some Armbian packages and scripts to add stability and security issues) and both distros since relying on systemd can’t be made ‘ultra minimal’. This is the package list of one such reduced (minimal) image and if you check the packages files nearby you get the diff to CLI or desktop variants.

          3. I see “apt-tools” in there, so it’s a package managed version. Thanks, Thomas.

  2. Nobody want UEFI, but people that don’t know what it is. Help vendors to still use closed source driver, slow and clumsy boot. Coreboot/LibreBoot is better for booting than so slow blob BIOS with all it’s closed stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *