Skip to main content

A/B Update

An A/B update is a servicing type that provisions a new OS onto the inactive A/B volume while the current OS continues running on the active volume. Like an install, it is driven by a Host Configuration file that declares the desired state. Trident compares the new Host Configuration against the currently provisioned one and applies the necessary changes to bring the inactive volume to the desired state.

An A/B update is triggered automatically when Trident detects that the Host Configuration changes go beyond runtime-updateable components. For an overview of how Trident selects the update type, see How Trident Knows What to Do.

Operations​

An A/B update is split into two operations:

  1. Stage — streams new OS images to the inactive volume and configures the target OS. Because the active volume is untouched, the current workload continues running undisturbed during this phase.
  2. Finalize — configures the UEFI BootNext variable to boot the updated volume on the next reboot, then triggers the reboot.

These can be run together or separately. See Two-Step Installation and Update for details on running them independently. Separating stage from finalize is particularly useful for A/B updates because the time-consuming image download can happen in the background while the workload runs, and finalize (the disruptive reboot) can be scheduled for a maintenance window.

What Happens During an A/B Update​

Storage​

The storage subsystem streams new OS images to the inactive volume:

  • Image streaming — new COSI images are streamed from remote sources (HTTP or OCI) to the inactive partitions using the image streaming pipeline.
  • Encryption — if the system uses LUKS encryption, the inactive volume is re-encrypted with updated keys as needed.
  • Verity — dm-verity hashes are updated for root or usr integrity verification.

Unlike an install, an A/B update does not create new partitions, partition tables, RAID arrays, or A/B volume pairs. The disk layout established during install is preserved. Features such as software RAID, ESP redundancy, and partition adoption are not activated during an update — they carry forward from the original install.

Bootloader​

Trident updates the bootloader configuration on the inactive volume:

  • The bootloader configuration is updated to reflect the new OS image.
  • GRUB2 or systemd-boot are supported. See Bootloader Configuration.
  • Unified Kernel Images (UKI) are supported for combined kernel, initrd, and command line images signed for Secure Boot.
  • The UEFI BootNext variable is set so the firmware boots the updated volume on the next reboot only. This is in contrast to an install, which sets BootOrder for all subsequent reboots. The BootOrder is only updated after a successful commit.

OS Configuration​

Trident enters a deployment chroot on the inactive volume to configure the new OS. The full list of supported options is defined in the Os object. Key capabilities include:

Customization​

  • Script hooks — user-provided scripts can be executed at defined points during the update. See Script Hooks.

Management​

Trident records the new Host Configuration and servicing state in its datastore, enabling the subsequent commit, rollback, and future update operations.

After the Update​

After finalize triggers a reboot, the machine boots into the updated volume. On the next boot:

  1. Commit — trident commit validates that the system booted from the expected volume. On success, it promotes the updated volume to active by updating the UEFI BootOrder variable for all subsequent reboots.
  2. Health checks — if health checks are configured, Trident runs them before committing to verify the update was successful.
  3. Rollback — if the commit fails or health checks do not pass, Trident can roll back to the previous volume. The previous volume remains intact and bootable because the A/B scheme guarantees that the old OS is never modified during the update.

This commit-or-rollback mechanism ensures that a failed update never leaves the system in an unbootable state.