openSUSE MicroOS/Aeon Transactional Updates and Rollback

openSUSE MicroOS/Aeon uses transactional updates with Btrfs Snapper for atomic rollbackable OS changes. This guide covers the stack, a worked example, and key limitations.

The problem: an update that won't boot

Traditional package managers apply changes in place. If a transaction is interrupted or a post-install script fails, a server can become unbootable. openSUSE MicroOS (server) and Aeon (desktop) avoid this by keeping the root filesystem read-only and staging every update atomically.

How the transactional stack fits together

MicroOS and Aeon share the same foundation:

Btrfs provides copy-on-write subvolumes for /, /var, and /etc.
rpm-ostree stages a complete new OS deployment (kernel, initrd, userspace) as a single commit.
Snapper creates pre/post snapshots for every rpm-ostree transaction and for manual zypper runs; these snapshots become bootable GRUB/BLS entries.
systemd-boot (UEFI) or GRUB with BLS makes prior deployments selectable at boot.

Worked example: stage, activate, and roll back

# Check the current deployed state and any staged update transactional-update status

Output shows the booted deployment hash, a staged hash (if pending), and whether a reboot is required.

# Download and stage the latest update from the Tumbleweed/MicroOS repository transactional-update up

This runs rpm-ostree upgrade under the hood, creates a new deployment, and registers a Snapper pre-snapshot. A message indicates that a reboot is needed.

# List snapshots to confirm the pre/post pair snapper list

You should see two new entries: a pre-snapshot and a post-snapshot. Both are bootable entries in the bootloader.

# Reboot to activate the staged deployment systemctl reboot

After reboot, verify:

rpm-ostree status

The Booted deployment hash should match the staged hash from before.

If a service fails or the system is unstable, roll back in seconds:

# Replace N with the pre-snapshot number from snapper list snapper rollback N

systemctl reboot

The rollback sets the default boot entry to the selected snapshot and creates a new read-write snapshot for /etc. After reboot, rpm-ostree status shows the previous version.

Trade-offs and limitations

RPM layering increases update size

You can install extra RPMs with rpm-ostree install. This creates a local layer on top of the base. Every subsequent update must recompute that layer, increasing update size and reboot time. The project guidance: use Flatpak for GUI apps, Podman for services, and toolbox/distrobox for CLI tooling.

Third-party kernel modules

NVIDIA drivers, ZFS, or VirtualBox guests must be rebuilt for each new kernel deployment. The supported path is the NVIDIA Container Toolkit or DKMS inside a container, which adds operational complexity.

/etc management across deployments

/etc is merged via etc.d on boot; manual edits to files outside /etc/*.d directories persist but can conflict with vendor updates. Use drop-in files under /etc/*.d for safe customization.