Why A/B partitioning?

In embedded systems, failed updates can brick devices. An A/B layout solves this by maintaining two root filesystems:

  • Slot A — active rootfs
  • Slot B — standby rootfs for next update

When an update succeeds, the bootloader switches to the new slot. If boot fails, it rolls back to the last known good version.

This approach presupposes, that slot A and slot B have the same size of the partition, which can be sometimes tricky in embedded systems, when the resources are limited.

swupdate with rescue system

Another approach is, to create partitions for a small rescue system and a bigger partition for the normal running system.

Example Partition Layout

A typical Raspberry Pi Compute Module 5 (CM5) layout might look like this:
PartitionTypePurpose
p1FAT32/boot_A (kernel, cmdline, bootloader)
p2ext4rootfs A
p3FAT32/boot_B (kernel, cmdline, bootloader for rescue system)
p4ext4rootfs_B
p5ext4data / configuration
The bootloader can use a flag (for example, GPIO17=1 in rpi-eeprom) to determine whether to boot from the rescue partition.

Practical Example

This setup is demonstrated in two rpi-image-genexample projects:

The first one creates the rescue system and the second one combines the rescue system with another running system, adjusting partition labels in cmdline.txt and fstab.

Managing update

You can mount the inactive system partition manually to update configurations, applications, or system components.
For production systems, updates are typically managed via SWUpdate, which automates this process safely.

Integration with SWUpdate

SWUpdate natively supports dual-rootfs (A/B) update strategies.
Partitions and update logic are defined directly in the sw-description file.

This approach ensures atomic system updates with built-in rollback safety — an essential feature for headless or remote devices, where manual recovery isn’t feasible.

Articles in this series

Sources