RAUC v1.10 Released


Download v1.10 release of RAUC

GitHub release page

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).

So what is in the release? Besides some minor memory leak fixes, smaller improvements, and bugfixes, we have also made progress. And this is meant literally, as you will see below. Other useful features introduced are transaction UUIDs, meta-data printout for rauc info, a new JSON output format, and some more.

A notable bug fixed with this release relates to mount point detection which had a logical issue and thus, in some scenarios could have prevented detecting some external mount points reliably. See #1105 for more information.

As always, the topics in this blog post are cherry-picked from the changes that actually happened. Refer to the full changes listed on the release page for a more comprehensive overview.

Progress Handling Rework

From a user perspective, probably the most notable change with v1.10 is the progress handling, which is now more realistic and fine-grained.

Historically, the progress information in RAUC, emitted by either the D-Bus Progress property or shown by CLI when calling rauc install --progress, was badly distributed. This means that actual image copying started at 80%, while everything before was just some checks and verification.

This has never been a realistic distribution of the actual duration for each task, but has become much worse with the introduction of the 'verity' format which made the initial verification happen quite quickly. As a result (depending on the actual write speeds etc.), the progress bar had reached 80% after completing ~10% of the installation job.

With v1.10, we have now added support for weighting substeps, which allowed us to redistribute the actual progress without having to change much of the current progress update calls. As a result, RAUC will now start coping images at 40% progress.

But, the more notable and often requested feature is of course the support for fine-grained progress, meaning that RAUC will emit evenly distributed progress steps during image installation. Especially when updating a slot takes a long time, this should significantly improve the user experience.

Thanks to the initial work done by Lars Poeschel who submitted this as a PR in November 2021, we have been able to add some missing puzzle pieces and have fine-grained progress working in RAUC in time for a demo for the Pengutronix booth at Embedded World 2023.

Fine-grained progress currently works for non-adaptive installations of block images and archives.

Improvements of rauc info

The 'rauc info' command, meant to show information about a bundle, received some improvements and new features.

When using the default output format for rauc info, all sizes are now also printed in shorter human-readable form with the original per-byte-information, e.g. 14,7 MB (14.659.412 Bytes).

As promised in the blog post for v1.9, the support of custom metadata manifest information is now almost completed by adding it to the InspectBundle() D-Bus method and to all rauc info output formats.

With json-2, we introduced a new output format that uses the same structure as the InspectBundle() method.

$ rauc info --output-format=json-2 test/good-adaptive-meta-bundle.raucb
  "update" : {
    "version" : "2023.03-1",
    "compatible" : "Test Config"
  "images" : [
      "slot-class" : "rootfs",
      "filename" : "rootfs.img",
      "checksum" : "101a4fc5c369a5c89a51a61bcbacedc90[...]",
      "size" : 8192,
      "hooks" : []
  "manifest-hash" : "4f471ebf24aeb566fad623c1084cd448[...]",
  "meta" : {
    "update" : {
      "poll" : "86400"
    "version" : {
      "channel" : "beta",
      "release-notes" : "https://example.com/release-notes"

Introduction of Transaction UUIDs

With v1.10, another element for better tracking of the life-cycle of an installation was added to RAUC: The (installation) transaction UUID.

While the manifest hash, introduced with RAUC v1.9, allowed us to unambiguously tell which exact bundle was installed, one aim of the transaction UUID is to tell which exact installation invocations led to the current state of the system. Further plans are to use this information for tracking the installation procedure beyond just the basic slot writing and allows a user to know if an installation actually resulted in the expected system being booted, etc.

For this, RAUC generates a new UUID when starting an installation. Alternatively, D-Bus callers can provide their own ID here, e.g. for update servers that already have a concept of an ID per installation.

Currently, RAUC prints the transaction UUID in the logs, writes it to the slot status file(s) and shows it in the rauc status --detailed output and in the corresponding D-Bus API.

Sealing the Leak

Triggered by a community contribution fixing a memory leak that was revealed by using the libfuzzer and the address sanitizer capabilities of the compiler, we added a new sanitzier action workflow to the GitHub CI.

Enabling address sanitizer checking for test cases required a number of memory leaks to be fixed in the test cases itself, but in the end also revealed some remaining memory leaks in RAUC itself.

While most unit tests now run with address sanitizer enabled, some still need to be done. However, the new checks already help to detect memory leaks and other regressions in RAUC.

Meson Support

Meson support was introduced with RAUC v1.9 to replace the ancient autotools. They were kept in parallel with autotools for this release to simplify migration.

We have then agreed on keeping both even in the v1.10 release. Not only to have a longer grace period, but also since we still had some smaller issues that were fixed now, like a dependency issue for test builds, a wrong file mode for the rauc-service.sh wrapper, and finally we missed installing our fine man page.

In the next release, autotools support will likely be dropped, thus package maintainers who haven't migrated to Meson yet should consider it.

Luckily, by the time of writing, most have already migrated anyway. Buildroot did it with the v1.9 migration (thanks to Heiko Thiery), same for meta-rauc, and for PTXdist I prepared a patch just yesterday.

Outlook: HTTP Header Customization

As outlined in concept #1114, we have plans to improve support for simple update servers by optionally providing some information about the system state to the server in the first HTTP request's headers. The server can then use this for more detailed logging or even for making simple decisions based on the data.

With v1.10, some other preparations made into RAUC: The so-far quite limited system-info handler was extended to return custom system information as environment-like variables. Specially named variables are then planned to be exposed via HTTP headers, too. The actual header implementation is already available in PR #1152.


Many thanks again to all contributors of the v1.10 release: Christian Hitz, Christian Hohnstaedt, Christian Meusel, Enrico Jörns, Jan Lübbe, Lars Poeschel, René Fischer, Stefan Wahren, Ulrich Ölmann, b4yuan

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.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'.