📁 ComposeFS Artifacts

While the previous v1.13 RAUC release introduced Artifact Updates, these gain a first extension with a new composefs repository type, named after the file system with the same name.

ComposeFS leverages the existing Linux features OverlayFS and EROFS to provide a content-addressed model for file data: it stores metadata and file contents separately, enabling deduplication of identical files across artifacts. This means each unique file is stored in the repository only once — and is also installed only once — which significantly improves storage efficiency.

The use-cases of the composefs artifact repository are very similar to those of the existing tree type. However, it offers important advantages such as reduced storage usage on the target and smaller streamed download sizes, particularly in systems where components are overlapping or frequently reused.

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

/srv/add-ons
├── .artifact-my-app-790b5df9...
│   └── image.cfs          ← ComposeFS metadata image
├── .rauc-cfs-store/       ← content-addressed object store
│   ├── 1a/1a2b3c4d5e...
│   ├── 67/a2e51e88fe...
│   └── ...
└── my-app -> .artifact-my-app-790b5df9...

To manually mount an installed ComposeFS artifact called my-app from the repository add-ons, the following command can be used:

REPO=/srv/add-ons
mount -t composefs $REPO/my-app/image.cfs -o basedir=$REPO/.rauc-cfs-store /run/mnt/my-app

[image.add-ons/my-app]
filename=my-app-file.tar
convert=composefs

🔄 Preparations for Polling Support

A couple of smaller changes in this release belong to a longer-planned higher level feature which will presumably make it into the next release: built-in update polling support.

While packaging and installing updates is already well-supported by RAUC (and other updaters), the available open source options on the server or rollout side are relatively limited.

On the other hand, the actual set of server features required in most scenarios is quite small — and often a simple, well-known URL where the client can poll for updates is already sufficient.

RAUC already provided a fundamental building block for implementing polling with its unprivileged download helper for bundle streaming. Support for sending custom HTTP headers, added in v1.11, extended this to allow the server side to process or log some basic information sent by the target.

This release now adds:

• A system version to the system-info handler, that can be set using the RAUC_SYSTEM_VERSION output variable. While this information is only stored internally for now, it will later be used to inform the server of the currently running system version.

• An optional min-rauc-version field in the bundle manifest. This adds an explicit way to specify the minimum RAUC version the bundle is compatible with and reject those that are incompatible. This will help in the long run, once v1.14 is rolled out in the field.

• Support for requiring a specific manifest hash during installation. This is useful not only with polling, but also for scenarios where the bundle must be confirmed or validated manually before installation — ensuring that only that exact bundle will be installed.

  Example:

  # Extract the manifest hash
  rauc info --output-format=json-2 bundle.raucb | jq '.["manifest-hash"]'
  
  # Use it during installation
  rauc install --require-manifest-hash=<hash> bundle.raucb
  

The actual polling implementation is already available as a pull request , along with an example server implementation.

🛡️ Fallback Prevention

While the ability to fall back to the previously installed slot group is an interesting option if the focus is on system availability, it has its downsides when it comes to security. Without special measures, a fallback mechanism opens the door for externally triggered system downgrades.

While there are several potential solutions to this, a quite obvious one is to disable fallbacks once the newly installed system has booted successfully.

With the newly added prevent-late-fallback system config option, this behavior can be automated. A call to rauc status mark-good will automatically mark the other slot group(s) as 'bad', which will prevent the bootloader from booting it.

⏳ Detailed Progress for Adaptive Updates

In earlier releases, RAUC gained support for emitting progress during a slot update. However, this did not work for the adaptive update method block-hash-index.

Thanks to RAUC contributor Marcus Hoffmann, the necessary bits for calculating progress during chunk copying were added so that RAUC now emits progress updates for chunk copying.

What's still missing, but under active development, is progress information for the on-demand hash index calculation, which may — depending on slot size and hardware used — take some seconds or even minutes.

🔐 Encryption for Many Recipients

RAUC supports encrypting a bundle for scenarios with shared keys as well as for unique per-device keys.

However, when encrypting for a large number of individual recipients, the encrypted manifests (internally stored in a CMS structure) may exceed RAUC's default maximum signature size of 64 KiB, causing the bundle to be rejected.

With the newly added max-bundle-signature-size option in system.conf, the size limit can now be configured to allow reasonably large signature sizes.:

[system]
...
max-bundle-signature-size=131072

Additionally, to avoid hitting this limitation first during installation, the rauc bundle command now emits a helpful message:

Resulting signature size of 73KiB exceeds default of 64KiB. Make sure to set 'max-bundle-signature-size' in your target's system.conf to a sufficiently high value.

🔧 Other Notable Changes

• Over the years, the number of supported bootloader backends has grown — and so has the codebase. The previously monolithic bootchooser.c file has now been split into several bootloader/*.c files, paving the way for adding new backends, such as support for the Raspberry Pi
• The D-Bus API documentation was significantly restructured to reduce redundancy and improve readability.
• Installation of plain bundles on kernels configured without the CONFIG_BLK_DEV_WRITE_MOUNTED option (introduced in Linux v6.8) previously failed. This has been fixed by Sascha Hauer, who modified RAUC to correctly open the loop device in read-only mode.
• Thanks to Peter Korsgaard, the RAUC_TRANSACTION_ID is now exposed to the full custom and system pre/post-install handlers.

For a full list of changes, see the v1.14 changelog.

🧭 Outlook

Besides the already mentioned polling support, there is still active community effort in pushing the Raspberry Pi bootloader support forward, mainly driven by RAUC contributor Gaël PORTAY. The signing capabilities will presumable gain some extensions and there is still a number of in-flight pull requests for many different topics. Stay tuned!

🙏 Thanks!

We’d like to thank all contributors, testers, and users for making this release possible.

Not directly release-related, but I’d also like to thank everyone who joined the RAUC meetup at Embedded World for sharing their ideas and feedback.

A special thanks to Leon Anavi, who maintains the meta-rauc-community layer and recently upgraded and tested all supported hardware platforms on the upcoming walnascar OpenEmbedded release.