RAUC v1.4 Released

It's been 3 weeks ago now since the tag for RAUC 1.4 was created. But it is vacation time and so we have a good excuse for communicating things with some delay. Fortunately, the media team is back now and so also those of you who haven't noticed the new release yet will be informed about notable changes.


Download v1.4 release of RAUC

Beside several minor memory leakage fixes, this release comes with number of stricter checks for parsing the slot selection to help users to identify potential misconfiguration much earlier than before.

The release now also allows and visibly encourages to explicitly decide between a central (single) or per-slot RAUC status files with statusfile=<path>/per-slot. Where possible (e.g. if one has a shared data partition anyway), one should prefer a central status file as this allows RAUC to also store the status of raw partitions and avoids having to write to readonly-mounted ones.

Facing the Future

Or at least the year 2038 when the 32 bit UNIX timestamp overflows. As mkfs.ext4 still defaults to 128 byte inodes with 32 bit time stamps for smaller file systems (<512MiB), this will trigger the kernel warning:

ext4 filesystem being mounted at /foo supports timestamps until 2038

With RAUC you will pretty sure update the filesystem several times before 2038 but to act early and to avoid the warning, RAUC now always enforces 256 byte inodes when creating file systems.

Custom Bootloader (Slot selection)

For very special use cases where the default or currently available bootloader backends do not apply for redundant slot switching, RAUC now also supports implementing a custom logic. This feature was requested again and again in the past and then implemented by Christian Bräuner Sørensen. The documentation added by Andreas Schmidt then finally allowed us to merge it for the 1.4 release.

Below you see a short usage example:




The interface between RAUC and the custom boot selection script / binary consists of simple commandline arguments, echo to stdout and return values documented here. A manual invocation of this script / binary would look like:

$ ./custom-bootloader-script get-primary
$ ./custom-bootloader-script get-state A
$ ./custom-bootloader-script set-state A good

Atomic Updates for Bootloaders in a GPT Partition

If your SoC does not support atomic bootloader updates by itself but allows loading the bootloader from a GPT partition, the new RAUC slot type boot-gpt-switch now supports updating the GPT partition atomically.


This is similar to the already-existing support for MBR partitions and works by defining a disk region with twice the size of the actual partition contents. RAUC then writes a new bootloader image to the inactive region and modifies the GPT entry afterwards to point to this newly written region.



We put some effort in enhancing the tests and the test coverage of RAUC. The new qemu-based testing environment introduced in v1.3 was now extended to also support testing of UBIFS and NAND slot types. We also better test the non-service configuration case (and fixed some convenience issues in this area) that is still of interest for very constrained devices or other special use cases where D-Bus is inappropriate.

Again, thanks to all contributors since v1.3: Andreas Schmidt, Bastian Krause, Christian Bräuner Sørensen, Dan Callaghan, Enrico Jörns, Jan Lübbe, Michael Heimpold, Tobias Junghans, Uwe Kleine-König

Weiterführende Links

RAUC v1.11 Released

Ho Ho ho! As the year's progress bar approaches 99%, another update is already completed: RAUC v1.11 is here!

RAUC v1.10 Released

Just in time for the EOSS 2023 in Prague, we have released v1.10 of RAUC. Just-in-time means the release was actually finalized by Jan Lübbe in the train to Prague (like I finally wrote the majority of this blog post on the train back).

RAUC v1.9 Released

"Getting things off the ground" could be the motto for the v1.9 release of RAUC. The support for custom metadata in the manifest got a step further, a new, more flexible, D-Bus API for bundle inspection paved the way for obtaining more detailed information, and a new manifest hash marks the first of several planned changes for configurable event logging. However, one of the most invasive changes happened under the hood: We have started the transition from autotools to meson as a build system.