RAUC v1.11 Released


Download v1.11 release of RAUC

GitHub release page

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

We have collected some noteworthy changes over the last five months since v1.10. The initial version of a new event-logging framework allows you to keep track of your device's update and redundancy boot history in dedicated log files. With extending the capabilities of sending device information upon HTTP requests, RAUC extends its portfolio regarding network-based OTA update support. Automatic creation of symlinks to active slots, options for excluding images from bundle conversion, and fuzzing support are just a few others changes to note.

By the end of the year, it is also time to say goodbye to a companion of many years: Autotools support in RAUC is taking its well-deserved retirement. From now on, Meson, which was introduced in RAUC v1.9, will be the sole build system for RAUC.

Installation History - New Event Logging

One of the most notable additions in v1.11 is probably the new installation history and event logging which has paved its way into mainline since the last release by introducing several smaller new features. The changes introduced mainly focused on clarifying relations and states in the update life-cycle and fix inconsistencies in that context.

With this release, the slot status file was extended: It can now also serve as storage location for global information that is not slot-specific. This first user of this is the new boot detection which works by persisting the system's boot_id and compare it with the current one. Another addition in slot status file handling is that the status field was extended to consistently show the actual slot update status and now has pending and failed state.

The primary purpose of the new framework is to provide configurable log file writing of relevant update- and redundancy boot-related events over the life time of a device. This information is meant to better answer common OTA update-related questions like:

  • Was the update X ever installed on this particular device?
  • After installing update Y a month ago, did the device boot successfully into that?
  • Has there ever been an update failure?

While some of this information could be obtained from the normal RAUC service log already, the messages so far lacked well structuring and consistency, and, with a device lifetime of years in mind, they were hard to filter and archive.

The new dedicated "event" messages make use of Glib's structured logging capabilities, have distinct identifiers, and are used both for the service log as well as for the configurable log files. They consist of a readable text message combined with fields for additional context information.

Soon, the journal messages will be enriched with journald message catalog information, allowing users to obtain more details and possible guidance from the systemd journal output.

Loggers can be defined in the system.conf by creating a [log.<name>] section and specifying a log filename . The log file will be created in the configured data-directory by default. Optional configuration items are the output format and event types to be logged. Loggers also support file rotation to limit the maximum amount of storage space consumed over the device lifetime.

Events currently logged are installation start/end/failure, individual slot writes, good/bad/active marking, boots and service restart.

Available output formats are a human-readable one with details, a short one with only the message line, and a JSON output to support further processing.

Full-featured configuration example:


Refer to the RAUC documentation for more details on the framework and its configuration options.

An example log of the (default) human-readable verbose logger (without event type filtering) looks as follows:

2023-12-20T11:32:15Z: Booted into rootfs.0 (A)
                      boot ID: 55304525-445b-45b2-95e3-71d6646ca437
                      bundle hash: unknown
2023-12-20T11:32:16Z: Marked slot rootfs.0 good
2023-12-20T11:32:33Z: Service restarted
2023-12-20T11:33:56Z: Installation 871dbf94 started
                      transaction ID: 871dbf94-75cf-4a6a-b3de-6b81d2013d9e
2023-12-20T11:33:56Z: Marked slot rootfs.1 bad
2023-12-20T11:33:56Z: Updating slot efi.0
2023-12-20T11:34:17Z: Updating slot rootfs.1
2023-12-20T11:35:05Z: Marked slot rootfs.1 active
                      bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
                      bootname: B
2023-12-20T11:35:06Z: Installation 871dbf94 succeeded
                      bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
                      bundle version: 1.0
                      transaction ID: 871dbf94-75cf-4a6a-b3de-6b81d2013d9e
2023-12-20T11:35:50Z: Booted into rootfs.1 (B)
                      boot ID: 3850cffb-2eca-4960-b682-ec95bd5a222c
                      bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
2023-12-20T11:35:51Z: Marked slot rootfs.1 good


We don’t consider the details of the new log events fixed yet, so please use them as a preview and for testing.

HTTP Header Information

RAUC becomes more and more relevant in the context of (semi-)automatic network-based OTA roll-outs where devices fetch their updates from a server. With its built-in HTTP(S) streaming capabilities, RAUC already made a leap forward towards securely supporting network downloads without the need for intermediate services.

This is sufficient for simple externally triggered bundle downloads from a fixed location, but use cases like automated downloads, update roll-out scheduling, device/fleet monitoring, etc. often require more information about the system and more logic within the client.

When using dedicated deployment servers with control APIs, these tasks clearly belong to an external service (like rauc-hawkbit-updater for hawkBit). However, for many cases, a simple HTTP server with a minimum of backend handling would be sufficient.

As the first step towards supporting the simple update server use-case in RAUC, we identified the ability to send additional information about the device to the server. For this, RAUC v1.11 now comes with configurable and extendable HTTP header information support.

The set of headers to be sent can be set in the system.conf [streaming] section option send-headers:


Additional details can be provided using the system-info handler:


The script example-script.sh can write variables prefixed with RAUC_HTTP_ to stdout that will be forwarded as HTTP headers:


echo "RAUC_HTTP_MAC=$(cat /sys/class/net/eth0/address)"

An example GET request would then look as follows:

GET /test/good-verity-bundle.raucb HTTP/1.1
Host: localhost:8081
Range: bytes=0-3
User-Agent: rauc/v1.11
Accept: */*
RAUC-Boot-ID: 70b30259-817a-4f11-89bb-ae99d22b4b11
RAUC-Transaction-ID: 9c18267e-36ff-4672-ac0d-19f639ca1910
RAUC-Uptime: 19.83
RAUC-MAC: 00:b0:d0:63:c2:26

It is then up to the update server to either just log this information for later or to use them for custom purposes.

Ignore Images During (casync) Conversion

People that wanted to use RAUC's casync support instead of the new built-in streaming, sometimes ran into a problem: rauc convert unconditionally converted all images from the conventional bundle to casync index files. However, some slot/storage types simply (like raw NAND) cannot be written with casync.

With this release we have introduced the new --ignore-image option to exclude certain slots from the conversion. For example, to exclude the bootloader slot class, use

rauc convert --ignore-image=bootloader input-bundle.raucb mixed-casync-bundle.raucb

Further Notable Changes

RAUC now has a simple mechanism for detecting changes to its config file during service runtime. Just like e.g. systemd, it now warns (in the journal/service log) if the config file was changed but you forgot to restart the RAUC service which turned out to be a common pitfall over the years.

For the rauc resign and rauc replace-signature commands, support for encrypted bundles was implemented.

This release also comes with a fuzzing support. Initially contributed by René Fischer, it was extended and adapted to the needs of the OSS-Fuzz project where RAUC is monitored since then.

Parts of the documentation received a little makeover. Both the generated HTML documentation as well as the man pages can now be installed by meson and thus can be made available in distros as offline documentation.

For a comprehensive list of changes in v1.11, see the official changelog.


For those wanting to update applications, data files, containers, etc. that are separate from the root file system, the pull-request #1301 gives a preview of the ongoing work to implement the RAUC Concept Issue #969 for Artifact Updates. Stay tuned for one of the most significant extensions RAUC has received recently.

Thank You!

Contributions to this release came from Angelo Compagnucci, Roland Hieber, Zygmunt Krynicki, David Runge, Emil Velikov, Hans Christian Lonstad, René Fischer, Stephan Wurm, Thomas Kilian, Ulrich Ölmann, and Uwe Kleine-König.

Thanks to you and to all RAUC contributors for effort you put in discussing ideas, reporting and reproducing bugs, and especially for contributing fixes and features over the last year. We wish you Happy Holidays and a successful version bump to 2024!

Weiterführende Links

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.

Saving Download Bandwidth with RAUC Adaptive Updates

Based on RAUC's HTTP(S) streaming capabilities, adaptive updates are a generic concept in RAUC to allow saving download bandwidth and form an alternative to conventional delta updates. This post introduces both the generic concept as well the first implemented method 'block-hash-index'.