Artifact Repositories: Flexible Component Updates

So far, RAUC focused primarily on updating the entire system to a well-defined target state, ensuring consistency between the root filesystem and all related slots.

While this approach is effective and suitable for most embedded applications, there are scenarios where specific components need to be updated independently of the base system. Typical examples include:

• Containers
• Virtual machine images
• Large data files
• Add-on binaries
• App-store-like catalogs

Previously, managing updates for these components had to be handled outside of RAUC. However, for systems already using RAUC's cryptographically secured bundles to update the base system, it makes perfect sense to leverage the same infrastructure for updating these components as well. This ensures consistency, security, and a unified update workflow for both the base system and modular components.

This is where the new Artifact Repositories come into play. An Artifact Repository resides in a directory on a shared partition that needs to be mounted in the active system. Each repository is defined by a name, a directory path, and a type. The type specifies how the artifacts are installed and managed, with all types ensuring atomic component updates. Repositories can be updated independently of one another and separately from the base system. The actual artifacts to be installed into a repository are defined solely by the bundle manifest, providing a high degree of flexibility for managing artifacts. For the rest of the system, which should treat artifacts as read-only, the update procedure is transparent.

An example configuration in both the system.conf (left) and the bundle manifest (right) could look as follows:

[artifacts.add-ons]
path=/srv/add-ons
type=trees

[image.add-ons/my-add-on]
filename=add-on-file.tar
conversion=tar-extract

While this provides only an overview of artifact handling, a future blog post will explore artifact updates in greater depth, including a practical example using meta-rauc-community. For more detailed information, refer to the RAUC documentation:

• Artifact Repositories
• Supported repository types
• How to integrate repositories into your platform.

More Flexible Configuration File Handling

RAUC v1.13 introduces the -C/--confopt command-line option, allowing you to set or override system configuration options directly from the command line. This allows customizing behavior for specific scenarios where no configuration file is provided, or for making temporary adjustments that should not be included in the persistent configuration.

Additionally, valid locations for the system configuration have been expanded to include:

• /usr/lib/rauc
• /run/rauc

This extension adheres to the UAPI Group's "Configuration Files Specification" and ensures compatibility with systems using "hermetic /usr" setups.

Testing Infrastructure

The pytest infrastructure introduced in RAUC v1.12 has been significantly enhanced in v1.13, with a focus on flexibility, isolation, and expanded test coverage. Temporary directories (tmp_path fixture) now ensure better test case isolation, while refactored fixtures enable dynamic system context setup and configuration generation, reducing the reliance on static test files.

Some test cases have been extended, and thanks to upstream fixes for QEMU's eMMC boot partition handling by Jan, we have finally been able to add an initial test case for this functionality.

Overall, coverage has now reached nearly 85%, with only the more challenging syscall error handling code remaining untested.

The documentation and functionality of the qemu-test script, which offers both a safe test environment and an interactive debugging system, have been expanded to better assist new developers. For those unfamiliar with it, simply running

$ ./qemu-test system

will boot you directly into a ready-to-use RAUC system. This environment is ideal for debugging, evaluation, and other development tasks. However, note that rebooting within the QEMU environment is out-of-scope.

Further Improvements and Fixes

• Manifest meta-data is is now exposed as environment variables to all handlers and the install-check hook. This uses the same variable names (and implementation) as rauc info --output-format=shell.
• A simple shell-based update service, provided by Angelo Compagnucci, is available as an example in contrib/rauc-client/. Meanwhile, the concepts for a built-in update service support in RAUC also become more concrete and could see some realization soon.
• Thanks to Florian Otte, bundle encryption now ensures that at least one recipient certificate is provided to prevent generating unusable bundles.
• Added logging to track the amount of the bundle data downloaded during streaming. This provides valuable insights into the effectiveness of adaptive updates.
• An issue that prevented reinstalls of previously failed slot installations in combination with install-same=false has been fixed by Samer Kenawy.
• A number of smaller improvements and bugs fixed can be found in the Release Notes.

Upcoming Changes

Several topics are currently under active development, like a native bootloader backend for the Raspberry PI, the ComposeFS artifacts repository type, options for built-in fallback prevention, or actual support for Triple-Redundancy ("A/B/C Updates").

Thanks!

Thanks to all 14 contributors of this release for their work: Ahmad Fatoum, Angelo Compagnucci, Christian Aurich, Emmanuel Ferdman, Enrico Jörns, Florian Otte, Gaël PORTAY, Jan Lübbe, Joachim Wiberg, Richard Alpe, Richard Hozák, Samer Kenawy, Tamara Schmitz, Ulrich Ölmann.

With this release, RAUC has now reached the milestone of 100 contributors! 🎉