openSUSE Transactional Updates: An Architecture Note on Atomic System Changes

The Problem: Updates That Either Fully Apply or Fully Don't

Traditional in-place package updates modify the running system file by file. A power cut, a failed dependency, or a broken post-install script can leave the OS in a half-updated state that is painful to diagnose. For kiosks, edge appliances, and unattended servers, that risk is unacceptable.

The takeaway: openSUSE's transactional-update mechanism applies changes inside a new Btrfs snapshot and only activates them at the next boot. The running system is never modified, and rollback is a boot-menu selection away. The trade-off is that updates are invisible until reboot, and only the root filesystem is protected — application data lives outside the snapshot boundary.

Requirements the Design Must Meet

• Updates must be atomic: either the whole change set boots, or the previous state does.
• Rollback must not require reinstallation or rescue media.
• The mechanism should reuse existing RPM packages and zypper repositories, not a custom image pipeline.
• User and application data must survive an OS rollback unchanged.

The Smallest Suitable Design

The transactional-update flow is deliberately simple:

1. Create a new read-write Btrfs snapshot of the root subvolume.
2. Apply RPM changes inside that snapshot using zypper in a chroot-like context.
3. Mark the new snapshot as the default boot target.
4. Reboot to activate it.

Until the reboot, nothing on the live system changes. This is the model used by default on MicroOS and Aeon, and it can be enabled on Tumbleweed by installing the transactional-update package. For an unattended server, pairing it with rebootmgr (which schedules reboots into a maintenance window) is the smallest complete design — no custom image building required.

Trust and Data Boundaries

The critical architectural fact is what the snapshot does not cover:

Rolling back the OS never rolls back your database or logs. That is usually what you want, but it means a rollback after a schema-migrating update can leave new data with old binaries. Plan application-level compatibility accordingly. Also note that defaults differ between MicroOS, Aeon/Kalpa, and Tumbleweed-with-transactional-update — verify the subvolume layout on your chosen variant rather than assuming.

Operational Checks

Run these as root on the target machine. Placeholders: <package> is any package name from the configured repositories.

# Apply a change (no effect on the running system)
transactional-update pkg install <package>

# Confirm a new snapshot exists and which one is the default boot target
snapper list

# Reboot to activate
systemctl reboot

# After reboot: verify the change landed
rpm -q <package>

Expected result: snapper list shows a new entry marked as the default, and after reboot the package is present. On MicroOS, the health-checker service runs post-boot checks and can trigger an automatic rollback into the previous snapshot if critical services fail — check its status with systemctl status health-checker if a boot unexpectedly reverts.

Manual rollback, run as root:

transactional-update rollback
systemctl reboot

Alternatively, pick the previous snapshot directly from the GRUB boot menu. Risk: any configuration written to /etc since the snapshot was taken may not carry over cleanly, so review /etc after a rollback.

Failure Modes

• Surprise invisibility: packages installed via transactional-update do not exist on the running system until reboot. Operators used to in-place zypper updates are commonly bitten by this.
• Disk pressure: interrupted snapshot creation leaves orphaned snapshots, and retention can fill small root partitions. Tune snapper cleanup limits rather than disabling snapshots, and monitor with df -h / and btrfs filesystem usage /.
• /etc divergence: configuration changed on the running system may not match what lands in the next snapshot. Review differences after config changes.
• Kernel and bootloader updates: these only take effect after a real reboot. There is no hot path, so uptime-sensitive services need planned maintenance windows.

Conditions That Would Change the Design

Choose traditional in-place zypper updates on Leap or Tumbleweed instead if the workload requires hot patching without reboots, frequent granular /etc mutation, non-Btrfs storage, or hard uptime guarantees that rule out scheduled reboots. The transactional model trades immediacy for atomicity; if you need immediacy, it is the wrong tool.

Verifying the Behavior Before You Rely on It

On a disposable test VM:

1. Install a package with transactional-update, reboot, and confirm it exists and that snapper list shows a new default snapshot.
2. Deliberately break the new snapshot (for example, remove a non-essential binary), reboot into the previous snapshot from GRUB, and confirm the prior state returns.
3. Run several update cycles and watch disk usage to validate your snapper cleanup configuration.
4. Change a file in /etc, apply an update, and inspect how the change propagates to the new snapshot on your specific variant.

Note that feature names and defaults shift between openSUSE releases; treat version-specific details here as approximate and confirm against your installed release's documentation.