openSUSE Leap Transactional Updates: Architecture Note on Snapper-Based Atomicity

Problem: updates that can leave a server unbootable

On a running openSUSE Leap system, a package update can change libraries, kernel and bootloader configuration while services are active. If the new state fails to boot, recovery requires manual intervention. Transactional Updates aim for atomic switch-over with a known-good rollback target and minimal downtime.

Requirements for atomic updates on Leap

Transactional Updates require a btrfs filesystem for the root filesystem, adequate free space for copy-on-write snapshots, integration with zypper for package operations, and bootloader management that can select a snapshot at boot time. The design must keep user data separate from system state so a rollback does not destroy application data. Only root may create or delete snapshots.

Smallest suitable design

The minimal design uses snapper to manage read-only snapshots of the root subvolume, zypper in transactional mode to apply changes, and GRUB entries that point to a snapshot.

Before changes, snapper creates a pre-update snapshot of the root subvolume. Zypper applies packages against the current writable subvolume. On success, snapper creates a post-update snapshot and the bootloader is updated to point to the new snapshot for the next boot. The previous snapshot is retained for rollback. User data lives in distinct btrfs subvolumes such as /home and /var, which are not replaced by the system snapshot.

Configuration is expressed via snapper config for the root subvolume, typically /etc/snapper/configs/root. The transactional workflow is driven by zypper with the transactional plugin enabled. No overlay filesystem is required for this minimal design.

Trust and data boundaries

Snapshot isolation keeps system state separate from running processes. A snapshot is a point-in-time view of the root subvolume; it does not include changes made to separate subvolumes. Only root can manage snapper, limiting snapshot creation and deletion to privileged users.

User data in /home or /var resides in separate subvolumes and is unaffected by system snapshots. Application-level changes written to those locations during an update are not reverted by a system rollback. This boundary means system rollback restores binaries and configuration, but not necessarily application data consistency.

Operational checks before and after

Pre-update checks should verify btrfs free space and snapshot creation success. Run as root on the host via console or SSH: snapper list. Verify snapshots for the root filesystem appear and that snapper is active.

Pre-update space check can be done with btrfs filesystem usage / run as root. Insufficient space is a risk; snapshot creation will fail and the update should abort.

Post-update validation includes confirming the bootloader entry points to the new snapshot and that essential systemd services start. A practical check is to inspect the GRUB menu after reboot and confirm the system boots into the post-update snapshot. Automatic rollback is triggered if the system fails to boot into the new snapshot, falling back to the previous snapshot via GRUB.

To validate the transactional workflow, run as root: zypper patch --download-in-advance then check snapper status for newly created pre- and post-update snapshots. Do not assume success without verifying snapshot existence.

Failure modes and when to change design

Snapshot creation failure aborts the update. If btrfs space is exhausted, the design falls back to a traditional in-place update or requires manual cleanup.

If the bootloader cannot apply the new snapshot, the system may boot the old snapshot or fail to boot. In that case the design may shift toward an immutable OS image approach such as MicroOS, or an overlayfs-based approach, where the base image is read-only and changes are applied as overlays.

Rollback only restores system subvolumes. User data in /home or /var may still reflect application-level changes from the update, so separate data backups remain essential.

Limitations and how to verify

Transactional Updates require btrfs with adequate free space. They are not available on ext4, xfs, or other filesystems.

Rollback does not revert user data. Verify the current snapshot after boot with snapper list run as root. Verify rollback capability by rebooting and selecting the previous snapshot from the GRUB menu, then confirm the system boots to the prior state and that snapper list shows the rollback snapshot as current. This verification requires current system state and should be performed in a maintenance window.