System-defined slot handlers

[adamheinrich]

Hello, thank you for the great tool!

Currently it is possible to have system-defined pre-install and post-install handlers for the whole installation process and also bundle-defined pre-install and post-install hooks for each slot.

I would like to propose also having the ability to declare system-defined handlers for each slot, possibly pre-install, post-install and install.

Introduction

I have a MBR-partitioned system where partition sizes can change in the future, therefore the rauc updater must be able to update the MBR.

Ideally I would like to have MBR defined as a slot, for example:

# MBR slot:
[slot.mbr.0]
device=/dev/mmcblk0
type=raw

# Other slots:
[slot.rootfs.0]
device=/dev/mmcblk0p1
type=raw

[slot.data.0]
device=/dev/mmcblk0p2
type=raw

When I provide an update bundle with an MBR image of size 512 for the mbr.0 slot, the slot update works. However if partition 1 or 2 sizes have been increased in the MBR, subsequent writes to slots rootfs.0 and data.0 fail due to image/slot size mismatch. This is because the new partition table is not re-read by the system before touching the other slots.

Describe the solution you'd like

An ideal solution would be having a system-defined slot post-install handler where the slot update mechanism could be defined on system level, without the need to provide tweaks in bundled scripts. This would allow calling partprobe /dev/mmcblk0 after updating MBR, which makes further Rauc operations use information from the new partition table.

Moreover, if this was generalized to also having a system-defined slot pre-install and install handlers, this would allow defining new types of slots (such as some microcontroller firmware) while still having the benefits of the slot infrastructure.

Describe alternatives you've considered

There are at least two ways to overcome this, they are just not elegant:

• Always providing bundled post-install slot hook which calls partprobe after MBR update, so that subsequent slot writes already work with the updated partition table -- but then the update behavior is defined in the bundle and not in the hook, it is not possible to provide a MBR image without extra information in the bundle.
• Not having MBR defined as a slot and implementing a custom pre-install handler which is defined in system.conf (dd MBR image from mounted bundle followed by partprobe) -- but then the slot interface is bypassed which adds more work & surface for bugs.

Thank you for considering this.

[jluebbe]

RAUC currently expects that the partition tables don't change during runtime. One way that works with RAUC is to use LVM, where you can resize individual volumes (i.e. in a pre-install hook) without affecting other (potentially active) partitions.

In your example above (with rootfs on /dev/mmcblk0p1), where would you be running from during the update? If that would be some partion on /dev/mmcblk0, I don't see how that could be made robust, as you don't know which A/B copy you're allowed to modify.

Or do you have fully separate devices for A/B? Or a separate recovery system?