Support for Armbian

[Kenzu]

Hi

I think support for Armbian would help your project get a lot of traction.
It would give access to a lot of hardware and both Debian a Ubuntu.
So not really a issue, just a suggestion :-)

Thanks

Jesper

[koehlma]

Hello Jesper,

This is a great idea!

I wonder how support for Armbian may look like.

Armbian provides their own build system (Armbian Build Framework). They also provide pre-made images for various boards. Generally, Rugix Ctrl is not bound to any specific distribution, build system, or board — it just requires certain functionality to be provided by the bootloader to facilitate safe and atomic updates. I'm not experienced enough with Armbian to say whether and how an integration with Rugix would be feasible. Ideally, we could hook into some generic mechanism and inject the required bootloader settings/scripts to make it work with all boards supported by Armbian.

Do you have any insights or could elaborate a bit more how you imagine Armbian support to look like/work?

[Kenzu]

Hi No i dont know armbian build framework inside/out. But i know you can build for at specific platform either via menu based setup or cli. But i dont think you can change the way the partition layout is in the finished image it made, so i think it would be a big task to be 1/1 compatible with armbian. Two solutions could be. 1. Make a patch/script that hook into armbian build system like with their user scripts. 2. Do like Dietpi and just use kernel, headers and uboot/uefi from armbian for each platform and build on pure Debian. This would probably be the quick way to get started. Best regards Jesper søn. 31. aug. 2025, 14.55 skrev Maximilian Köhl ***@***.***>:

…

*koehlma* left a comment (silitics/rugix#82) <https://github.com/silitics/rugix/issues/82#issuecomment-3907368764> Hello Jesper, This is a great idea! I wonder how support for Armbian may look like. Armbian provides their own build system (Armbian Build Framework <https://docs.armbian.com/Developer-Guide_Overview/>). They also provide pre-made images for various boards. Generally, Rugix Ctrl is not bound to any specific distribution, build system, or board — it just requires certain functionality to be provided by the bootloader to facilitate safe and atomic updates. I'm not experienced enough with Armbian to say whether and how an integration with Rugix would be feasible. Ideally, we could hook into some generic mechanism and inject the required bootloader settings/scripts to make it work with all boards supported by Armbian. Do you have any insights or could elaborate a bit more how you imagine Armbian support to look like/work? — Reply to this email directly, view it on GitHub <https://github.com/silitics/rugix/issues/82#issuecomment-3907368764>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD3OIQDOWSEDVHZKTR7OJL3QLWCHAVCNFSM6AAAAACFGKK6LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBQGEZDMOBVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[PolyFusionApS]

Maybe you could make a demo recipe that use debian as base but with external u-boot and kernel from armbian repos.
I would like to test it for Radxa CM5 module. Armbian has support for this. It is the same u-boot/kernel for most RK3588(s) boards.
Other boards I have for testing:

Orange Pi 3B (RK3566)
Orange Pi CM4 (RK3566)
Orange Pi Zero 2W (H618)
BigTreeTech CB1 (Allwinner H616)

Thanks
Jesper

[Gitii]

I have played around a bit with rugix and armbian.

Based on this experience, support for armbian seems possible.

• armbian uses debian or ubuntu as base distro
• armbian uses u-boot
• armbian provides individual ready-to-use images for each supported board
• armbian images contain special sections before the actual partitions. These are board specific and I think (haven't dived too deep into this) include the actual u-boot binary and vendor-specific binary blobs.

rugix bakery today:

• already supports u-boot for raspberries with x64, arm and arm64 support.
• expects two-partition layout (boot and system partition)
• no special bootloader support
• no byo-uboot scripts (bakery includes compiled scripts for all supported rpi models)

That said, there is a "unknown" target and custom image layout support. In my proof-of-concept it turned out that this is not sufficient.

How an integration of armbian could look like for bakery:

• add armbian uboot target. This will enable patching of armbianEnv.txt (similar to config.txt and cmdline.txt) and other armbian specific boot flow details.
• add support for single (unified?) image layouts (/boot is part of the system image by default).
• add support for custom bootloaders and uboot scripts (as part of armbian target flow).
• add armbian recipe for building uboot scripts and configuring rugix-ctrl
• as root layer use an official armbian image for a specific board

this sounds complex but actually raspberry u-boot and armbian u-boot are (on a high level) quite similar.
The armbian u-boot target is a variant of raspberry u-boot target with a few minor tweaks.

The real challence is the vast armbian device support. There a sooo many boards with their own little ... habits out there.
But armbian itself being an abstraction layer for all these devices comes in handy here.

As for rugix-ctrl, it's a similar story:

• add support by creating a variant of rpi-uboot boot flow with slight changes - mainly reflect changes done in rugix-bakery.

I have created a fork with a proof of concept-branch for rugix bakery and ctrl.
Gitii/rugix#1

A word of warning: I am not a rust developer, so I needed to heavily rely on claude models to code and took the instructor role. I am not ashamed of the result and I think that the changes fit in nicely.

And finally:
I only have two odroid-c2 devices that both support latest armbian.
I fully expect some slight changes are needed to support varying uboot scripts.
And in fact, the included setup-armbian recipe includes a (very slightly) modified stock uboot script for odroid c2.
Adapting for other boards should be trivial, though.

Rugix bakery is working fine for me.
Rugix ctrl seems to work fine but rebooting into system b doesn't work.
This might be related to the odroid c2, though. I am waiting for a uart-usb-adapter to arrive and watch the bootloader logs at startup.

How to get started:

• build tools and create multi-platform docker image (using the included build scripts). I needed to push the images to a private remote docker registry because by default, docker doesn't support creating multi-platform images and store them directly in the local registry.
• include new recipe setup-armbian
• include a new root layer and use that as parent layer for your own recipes (setup-armbian disables first-boot setup)
• remember to include setup-armbian recipe and also adapt the uboot scripts
• build the image

I hope that it works for you guys and I am interested to hear about the results.

[koehlma]

Oh, wow. That looks really cool!

armbian images contain special sections before the actual partitions. These are board specific and I think (haven't dived too deep into this) include the actual u-boot binary and vendor-specific binary blobs.

Yeah, some boards require some custom blobs or U-Boot itself to be placed at specific offsets within the image. The Armbian build system must have some understanding of where to place those blobs. I wonder whether that could be used to reconstruct them into the final image?

as root layer use an official armbian image for a specific board

I wonder whether there would be a way to use the Armbian build system (or information from it) to directly build a Kernel and U-Boot and use that with a root filesystem generated by Rugix Bakery. Customizing existing images is a powerful capability, but at the same time, it's a bit fragile and not really reproducible.

add support for single (unified?) image layouts (/boot is part of the system image by default).

Unfortunately, this would render static delta updates impossible as the root partition must not be modified for them to work. Do you see any way to avoid this?

add support by creating a variant of rpi-uboot boot flow with slight changes - mainly reflect changes done in rugix-bakery.

We also have a uboot boot flow that works through fw_setenv. Maybe that could be used?

Rugix ctrl seems to work fine but rebooting into system b doesn't work.
This might be related to the odroid c2, though. I am waiting for a uart-usb-adapter to arrive and watch the bootloader logs at startup.

Keep me posted on where this is going.

Again, that looks really cool and I'm very excited about the possibility to significantly broaden board support.

[Gitii]

@koehlma
In my proof of concept, I handle the bootloader-problem in a very simple way: copy the "head" of the original image to the freshly baked one. Essentially transplanting whatever there is to the baked image, excluding the mbr/gpt.
I was really surprised that it worked - but it's a prood of concept , so I guess that's the right approach.

I am not the first person with that idea, so I guess I am not that crazy :)

As for single partition support: I modified rugix to detect single partitions and separate both in the extract step. As a result, the final image will have the default layout of five partitions.

I opted to not use the "generic" uboot boot flow because of the similarities to te raspberry one (after baking the image).

[Gitii]

The UART-debugging proved to be highly effective and I've found the culprits:

• My odroid c2s have to "devices" (u-boot terms). sd card is 0, emmc is 1. I needed to use the devnum variable to dynamically to load from the right device.
• The u-boot of my odroid c2 doesn't support setexpr, so I needed to "rollout" the math operation (as far as I understand with the default A/B-support, a simple if-else-condition would be a minimal alternative anyway).

That fixed my remaining issues.
I did have some struggle to get my 8GB (in reality more like 7.2 GB, depending on which program you ask) emmc chip working. First I needed to reduce the system size (easy change using bootloader.toml) but sfdisk still failed applying the new layout. I played around a bit and I needed to "increase" the reversed space at the beginning and end of the extended partition. Really strange but with a few scripts, I managed to create a "already bootstrapped"-base image that I can flash to my old trusty odroid c2. After that, the "standard" baked images worked fine.

I do not know, how portable the devnum variable is - I have the feeling that this is non-standard...
There is another armbian-supported (old) sbc in the mail and I will adapt the bootloader scripts to also get that board working with rugix bakery. It has 16GB emmc - so I assume that my bootstrapping issues should also be avoided, too.

I am really happy with the result and created a draft PR.
It would be super useful if we could get a few people to try this on their armbian-supported devices and report their findings.
The bigger the sample size, the better my understanding of the u-boot differences between boards should become.

[Gitii]

My Asus Tinker Board S finally arrived, and I got it working.

My concerns were justified—the U-Boot scripts vary quite a bit between boards. I guess they are largely similar, but there are notable differences. Nonetheless, after a few struggles, I managed to get it running.

I've also looked into the Armbian build process to understand how the U-Boot blobs are baked into the images.

There seem to be several layers of abstraction that allow sharing a maximum amount of configuration and logic between boards. I’m not sure if it’s feasible to integrate that with Rugix. Using prebuilt images still seems like the easiest and most reliable approach.

I've noticed that, by default, Rugix tools are only built as artifacts for the armhf architecture (for 32-bit targets), not for both armv7 and armhf. The Asus Tinker Board S uses armv7, and since that architecture is explicitly mentioned as supported, I updated the build process to include all supported architectures. I suppose armhf would have worked as well, but this fix was straightforward.

Right now, the two remaining issues are bootstrapping and GPT support. I’ve experienced some problems with my Odroid C2 and eMMC—and unfortunately, also with the Tinker Board. It seems my initial theory about disk size being the cause was incorrect; perhaps it’s related to the partition offset instead?

Previously I have mostly ignored GPT when patching the image to splice in the bootloader blobs. The reason is simple: I do not have an armbian device that actually uses (or supports) GPT partitioned drives.