Symmetric A/B — two equal root filesystem slots — is the right default for most connected products: install to the inactive slot, reboot into it, and fall back automatically if the new software fails its health check, all while the device keeps running during the write. Limited storage, slow boot, or an application that ships on its own schedule make asymmetric, split, or rescue-augmented layouts the better choice instead. The decision is not whether to use A/B, but which A/B update layout matches your constraint.
Most embedded Linux teams accept early that field updates need redundancy: keep a known-good copy so an interrupted or faulty update cannot leave the device unbootable. The usual answer is an A/B update layout — two slots the device switches between. But “A/B” is not a single design. Each layout is tuned to a different constraint, and choosing the wrong one costs storage, boot time, or availability you did not account for. This post describes the common layouts on their merits and maps each to the scenario where it is the right choice.
The context
An A/B update layout answers the interrupted-update problem, and the mechanism is common to every form — the rollback cycle shown below. What differs is how four factors are balanced, and those factors often conflict. Storage: a second full root filesystem roughly doubles the rootfs space. Availability: some layouts keep the application running during the update, while others must reboot into an update mode. Boot time and bootloader complexity: where the kernel and device tree sit affects both. Release cadence: if the base system and application ship on different schedules, updating them together wastes bandwidth.
That shared rollback cycle:
- Install the bundle into the inactive slot.
- Mark that slot as the next boot target.
- Reboot into it.
- Run early boot and application-level health checks.
- Mark the slot good only after the checks pass.
- Fall back automatically if a boot counter or watchdog detects a failure.
The A/B update layouts
Symmetric root-fs slots
Two root partitions of equal size, A and B. Running from A, an update installs into B, and the reverse when running from B; both slots hold equivalent software, including the main application. To keep the design simple, the kernel and device tree live inside the rootfs (usually in /boot), which requires a bootloader that understands the rootfs type. RAUC describes this as probably the most common setup.
| Slot A rootfs + kernel/DTB (/boot) active | Slot B rootfs + kernel/DTB (/boot) inactive — update target |
Two equal slots; the update writes the inactive slot, then the bootloader switches.
The two slot entries in system.conf look like this, with the mandatory [system] section omitted for brevity:
raghu@techveda.org:~$ cat /etc/rauc/system.conf
[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system-a
[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=system-bAdvantages: an update can start from either slot while the application keeps running; the bootloader fallback logic stays simple; and the process is easy for technicians and users to reason about. The new software takes effect only after a reboot into the updated slot and a passing health check. The reasons to look elsewhere are limited storage, or a need for more redundancy or update flexibility.
Asymmetric slots
When storage is very limited, replace the second full partition with a small “update” (or rescue) partition alongside the full “main” system. To update, the device reboots into the small update system, which writes the new image into the main slot and switches back. Being small, that system usually fits entirely in RAM as a kernel with an internal initramfs (a raw slot). It is a temporary update environment, not a preserved recovery image; that is a separate design, covered below. The costs, as RAUC states them: two reboots per update; a failed update leaves the main application unavailable until a later update succeeds; and any data that must survive in the main slot must be saved elsewhere first and restored afterwards, because the slot is overwritten.
| main full rootfs (active system) | update kernel + initramfs, runs in RAM |
The small update system installs the new image into main, then switches back — two reboots.
Split (multiple) slots
Separate the application from the base root filesystem so each updates on its own schedule — useful when a different team owns the application, or when several applications reuse one base. RAUC models it with an appfs slot whose parent is the rootfs slot. You can also split the boot files (kernel) into their own slot to reduce boot time and bootloader complexity. Split slots layer on top of a symmetric or asymmetric setup. One caution from RAUC: it cannot currently guarantee compatibility between a rootfs and an appfs when a bundle updates only one of them, so always build bundles that contain every required slot, or enforce compatibility in your own release process.
| rootfs A base system | rootfs B base system |
| appfs A application | appfs B application |
Base system and application sit in separate slots, each updatable on its own schedule.
Symmetric A/B plus a rescue slot
A rescue slot is a deliberately preserved recovery environment, distinct from the temporary update system of an asymmetric layout; normal updates never write to it. It guards against failure modes that can disable both A and B at once: a latent software error undetected across releases; corruption from mishandled power failures when slots are mounted read-write; or a configuration error that fails both slots the same way. The bootloader starts the rescue system after repeated boot failures of the normal slots, or on user request.
| rescue never written by normal updates | Slot A rootfs | Slot B rootfs |
Normal updates write only A and B; the bootloader falls back to rescue if both fail.
The decision: matching the layout to the product
Match the A/B update layout to the dominant constraint. The table gives the quick mapping; the notes below cover the cases that need judgement.
| Layout | Best fit | Main benefit | Main cost |
|---|---|---|---|
| Symmetric A/B | Most connected products | Simple rollback; device runs during the write | Two full rootfs slots |
| Asymmetric | Tight flash budgets | Lower storage requirement | Two reboots and update-mode downtime |
| Split slots | Separate app and base release cycles | Independent update cadence | Compatibility management |
| A/B plus rescue | Remote or high-consequence devices | Recovery path if both normal slots fail | More storage and boot logic |
The table maps each layout to its constraint; three points do not fit in a table. Use a proven framework — RAUC, SWUpdate, or Mender — rather than scripting slot selection and rollback yourself; when you can afford the space, symmetric is easier to operate than asymmetric. With split slots, enforce rootfs/appfs compatibility in your bundle policy so a partial update cannot pair mismatched versions. And pair a rescue slot with a read-only, verified rootfs (see our note on how dm-verity keeps a read-only rootfs verified).
Slot layout is only one part of a safety-relevant update strategy: secure boot, signed bundles, watchdog validation, and failure analysis are also required. Payload size is a separate choice too — whichever A/B update layout you pick, frameworks support delta or adaptive payloads to cut download size, decided independently of the layout.
Consequences
Storage follows directly from the A/B update layout: symmetric roughly doubles the rootfs, split avoids duplicating a shared base or heavy assets across slots, and asymmetric trades storage for reboots and downtime. In every layout, keep application state and user data on a separate writable partition, not inside the slots, so it survives updates and is not duplicated — this also removes the asymmetric layout’s need to save and restore that data around the overwrite. Treat that partition as its own design problem: power-fail-safe writes, a schema that still loads after a rollback to older software, and integrity or encryption where the product needs it.
Someone must own the bootloader boot-selection logic and a hardware watchdog so that a boot hang counts as a failure and triggers fallback. Symmetric keeps this simple; splitting boot files or adding a rescue slot adds selection cases to maintain in U-Boot, GRUB, or Barebox. Symmetric A/B on a standard framework is well understood and easy to hand to new engineers; asymmetric and split layouts concentrate more logic and more failure modes, so document them. The build-system layers that realize these layouts — meta-rauc or meta-swupdate — are part of the earlier Yocto versus Buildroot decision, and integrating them is covered in our Embedded Linux on Edge AI course.
Key takeaways
- The question is not whether to use A/B, but which A/B update layout fits your constraint; the comparison table maps each to its scenario.
- In every layout the new software is activated only after a reboot and a health check, with automatic fallback to the previous slot on failure.
- Keep mutable state on a separate writable partition in every layout; slot layout is one part of a strategy that also needs secure boot, signed bundles, and a watchdog.
Frequently asked questions
Which A/B update layout should I start with?
Symmetric root-fs slots, unless storage is too limited to hold two full root filesystems. It is the simplest robust layout and lets updates run while the device keeps working.
Why would I choose asymmetric slots?
When storage cannot hold two full root filesystems. You keep one full main system and a small update or rescue system, at the cost of two reboots per update and the main application being unavailable if an update fails.
What does a rescue slot protect against?
Failures that disable both A and B together: a latent bug that spreads across releases, corruption from power loss on read-write slots, or a configuration error that fails both slots identically. Normal updates never write to it.
Where should the kernel and device tree live?
In the simplest symmetric layout they sit inside the rootfs, under /boot, which needs a bootloader that understands the rootfs type. Splitting them into a separate slot can reduce boot time and bootloader complexity. The exact implications depend on the bootloader, filesystem support, and image format, so treat boot-artifact placement as a per-platform decision.
