Adaptive Updates

RAUC v1.8 introduces adaptive updates which allow saving download bandwidth by requesting only necessary parts of the update. They are RAUC's answer to the common request for delta updates but solve this a bit more flexible than conventional delta updates.

With RAUC v1.8, an initial adaptive update method, called block-hash-index, is implemented. It optimizes download size for block-based image updates for file systems that are aligned to 4k sectors (such as ext4 or erofs).

To enable this mode during bundle creation, configure in your manifest:

[rootfs.image]
adaptive=block-hash-index
filename=rootfs.ext4

and simply run rauc bundle as usual.

A more comprehensive overview of what adaptive updates are and what we can expect from them in the future will be in a separate blog post soon.

Atomic Bootloader Updates For Rockchip RK3568

The Rockchip RK3568 ROM loader searches for a valid image at two (or more) fixed offsets on the boot medium by checking headers, checksums, etc.

The newly-introduced boot-raw-fallback slot type leverages this behavior to implement an atomic bootloader update mechanism similar to the ones already supported by RAUC (e.g. for eMMC boot partitions, GPT, or MBR).

While this was written with a specific ROM loader in mind, the approach can be used for all ROM loaders that behave similarly. Just let the region-start point to the first search offset and set region-size properly so that the second offset starts after the half of the region-size.

[slot.bootloader.0]
device=/dev/mmcblk0
type=boot-raw-fallback
region-start=32k
region-size=4M

The New Data Directory

RAUC v1.8 adds support for specifying a data directory in the RAUC system.conf. The data directory must be located on a shared partition that is not overwritten during updates. It will serve as a general storage location for RAUC-related information and will be of more importance for new features. Currently, it is primarily used for storing the block hash indexes for the adaptive update method of the same name.

[system]
...
data-directory=/data/rauc

For new configurations, setting a data directory is recommended and (unless otherwise configured via statusfile=) is also used to store the central slot status file. See the documentation for details.

Allow passing PEM Passhprase

RAUC now allows setting a passphrase for encrypted PEM files via the environment variable RAUC_KEY_PASSPHRASE.

Some Words About casync and desync Support

Long before the introduction of built-in HTTP(S) streaming and adaptive updates, RAUC's support for the casync content chunking tool has been the only option to satisfy both the need for updating over network without significant intermediate storage and for reducing download bandwidth requirements by fetching only the required chunks of an image.

Although this has been working (except for some known limitations), there was a disclaimer in the RAUC documentation noting it was still 'experimental', mainly because there was hardly any coverage in the test suite. Another reason for keeping the disclaimer was that the original casync tool lacks some features that would make it more efficient and space-saving on embedded targets and that it was not so actively maintained for a while.

On the other hand, with desync, an extended casync reimplementation in Go and casync-nano, a C-based project which focused on the block-based chunking, two alternative implementations came up over the years that solved limitations casync had.

And finally, we also learned that Collabora chose RAUC together with desync as the A/B update solution for the Valve Steam Deck. Something where we do not want to hide that we've been very proud to see RAUC in such a popular product.

We took this opportunity to finally write the missing test cases, merge some open casync-related fixes and to finally get rid of the 'experimental' note in the documentation.

However, this should not be seen as the great announcement and motivation to start with casync in RAUC. It is more the finalization of an open chapter.

The future for optimizing updates with respect to download size we clearly see in adaptive updates. But nevertheless, the casync support and adaptive updates will co-exist for the next years since currently both will be used and still both have their advantages and disadvantages.

For a short summary about casync vs. adaptive updates, I have also added an extra section in the RAUC documentation.

Improvements and Bug Fixes

• RAUC now avoids retrying on HTTP 404 errors during streaming. This allows aborting much faster if for example the bundle URL is invalid.
• The bootloader interaction framework will now print more targeted and less redundant information about what went wrong.
• The handling of errors during loop device block size configuration was improved with the potential to be more stable.
• The boot-mbr-switch atomic bootloader update mode for MBR now also correctly handles MBR tables with empty partitions (such as when only three partitions are configured).
• RAUC does not attempt to take ownership of plain bundles when running as non-root.

There is More to Come

• New meta.<label> manifest sections are intended to provide a forwards-compatible way to add data to the manifest which is not interpreted by RAUC in any way. Currently, they are just ignored when reading a manifest. In future releases, they will be accessible via rauc info, the D-Bus API and in hooks/handlers.

  [meta.pengutronix]
  mac=de:ad:be:ef:01
  location=Hildesheim
  class=edge
  
  [meta.device]
  key=value
  

  Note

  A compatibility preparation for this is already part of this release: RAUC will already ignore meta.<label> sections in the manifest.

• The D-Bus API for bundle inspection will be extended so that it can be used together with HTTP streaming and authentication and with the complete bundle information.

• Installation and Event History that allows to track and trace all installations on the device for inspection and debugging purpose

• We have had requests for application updates or container updates that do not necessarily require an update of the entire system. Since this did not fit well into the current design of RAUC, we thought about if and how this should be made possible (or if that is to be solved outside of RAUC).

  We now have a first proposal for app/container/data updates with RAUC:

  https://github.com/rauc/rauc/issues/969

Contributions

We would like to thanks all contributors how helped realize this new release. Namely (in alphabetical order): Ahmad Fatoum, Enrico Jörns, Jan Lübbe, Jonas Licht, Ludovico de Nittis, Marc Kleine-Budde, Marcus Hoffmann, Matthias Fend, Morgan Bengtsson, Ulrich Ölmann, Uwe Kleine-König

If you want to support the project, a good source for open issues is the [RFE] (request for enhancement) tag on the GitHub issues page. Some issues are additionally flagged with [help wanted] where we would like to encourage contributors to enhance and fix things in RAUC with more low-hanging fruits.