RAUC v1.4 Released
It's been 3 weeks ago now since the tag for RAUC 1.4 was created. But it is vacation time and so we have a good excuse for communicating things with some delay. Fortunately, the media team is back now and so also those of you who haven't noticed the new release yet will be informed about notable changes.
Beside several minor memory leakage fixes, this release comes with number of stricter checks for parsing the slot selection to help users to identify potential misconfiguration much earlier than before.
The release now also allows and visibly encourages to explicitly decide between a central (single) or per-slot RAUC status files with statusfile=<path>/per-slot. Where possible (e.g. if one has a shared data partition anyway), one should prefer a central status file as this allows RAUC to also store the status of raw partitions and avoids having to write to readonly-mounted ones.
Facing the Future
Or at least the year 2038 when the 32 bit UNIX timestamp overflows. As mkfs.ext4 still defaults to 128 byte inodes with 32 bit time stamps for smaller file systems (<512MiB), this will trigger the kernel warning:
ext4 filesystem being mounted at /foo supports timestamps until 2038
With RAUC you will pretty sure update the filesystem several times before 2038 but to act early and to avoid the warning, RAUC now always enforces 256 byte inodes when creating file systems.
Custom Bootloader (Slot selection)
For very special use cases where the default or currently available bootloader backends do not apply for redundant slot switching, RAUC now also supports implementing a custom logic. This feature was requested again and again in the past and then implemented by Christian Bräuner Sørensen. The documentation added by Andreas Schmidt then finally allowed us to merge it for the 1.4 release.
Below you see a short usage example:
[system] … bootloader=custom [handlers] bootloader-custom-backend=custom-bootloader-script
The interface between RAUC and the custom boot selection script / binary consists of simple commandline arguments, echo to stdout and return values documented here. A manual invocation of this script / binary would look like:
$ ./custom-bootloader-script get-primary A $ ./custom-bootloader-script get-state A bad $ ./custom-bootloader-script set-state A good
Atomic Updates for Bootloaders in a GPT Partition
If your SoC does not support atomic bootloader updates by itself but allows loading the bootloader from a GPT partition, the new RAUC slot type boot-gpt-switch now supports updating the GPT partition atomically.
[slot.bootloader.0] device=/dev/sda type=boot-gpt-switch region-start=1M region-size=32M
This is similar to the already-existing support for MBR partitions and works by defining a disk region with twice the size of the actual partition contents. RAUC then writes a new bootloader image to the inactive region and modifies the GPT entry afterwards to point to this newly written region.
We put some effort in enhancing the tests and the test coverage of RAUC. The new qemu-based testing environment introduced in v1.3 was now extended to also support testing of UBIFS and NAND slot types. We also better test the non-service configuration case (and fixed some convenience issues in this area) that is still of interest for very constrained devices or other special use cases where D-Bus is inappropriate.
Again, thanks to all contributors since v1.3: Andreas Schmidt, Bastian Krause, Christian Bräuner Sørensen, Dan Callaghan, Enrico Jörns, Jan Lübbe, Michael Heimpold, Tobias Junghans, Uwe Kleine-König
In this blog post I would like to address the challenges of performing unattended and verified updates of embedded Linux systems in the field using open source software and workflows. While updating is not a end in itself, a second part of my considerations goes even further and also works out the necessities and possible workflows for keeping the software stack of a project up to date and thus either preventing security issues or at least enabling a short reaction time in case of severe CVE'S discovered.