How openSUSE MicroOS Uses Btrfs Snapshots for Atomic Updates With Automatic Rollback

The problem: updates that break production

You apply a routine package update on a Friday afternoon. The system reboots, but a critical service fails to start because a library version changed. Now you're debugging in production while users see errors. Traditional package managers don't offer a built-in "undo" that restores the entire OS state.

openSUSE MicroOS (server/container host) and Aeon (KDE desktop) solve this with transactional updates: each update is staged into a new Btrfs snapshot, activated by switching the bootloader entry, and applied on the next reboot. If a health check fails after the reboot, the bootloader automatically falls back to the previous snapshot on the subsequent reboot.

How the update transaction works

The root filesystem is mounted read-only. /etc and /var are separate Btrfs subvolumes that persist across rollbacks. When you run an update, transactional-update (a wrapper around zypper) creates a new snapshot, applies the RPM changes inside it, and registers a new GRUB2 boot entry pointing to that snapshot's kernel and initrd.

On reboot, the new entry becomes the default. Systemd then starts services and runs any configured health scripts. If a service fails or a health script returns non-zero, the transactional-update-rollback service marks the previous snapshot as the next boot target. The following reboot restores the known-good state.

Worked example: staging an update and triggering rollback

Run these commands on a MicroOS/Aeon machine with a Btrfs root (requires root).

# Check current deployment
transactional-update status

# Stage a full system upgrade (dup = distribution upgrade)
transactional-update dup

# Reboot to activate the new snapshot
systemctl reboot

After reboot, verify the new deployment:

transactional-update status
snapper list

To simulate a failure and watch automatic rollback, mask a critical service before reboot:

systemctl mask sshd
systemctl reboot

The system boots the new snapshot, systemd reports sshd as masked (failed), the health check triggers rollback, and the next reboot loads the previous snapshot. Check the journal to confirm:

journalctl -u transactional-update-rollback

Trade-offs and limitations

• Btrfs required: The root filesystem must be Btrfs; ext4, XFS, or ZFS are not supported for transactional updates on the root volume.
• Read-only /usr: Traditional zypper in package does not persist. Use transactional-update pkg install vim (requires reboot) or Flatpaks/containers for user-space apps.
• Health-check scope: Automatic rollback only covers failures detected by systemd service status or explicit health scripts. Silent data corruption or logical application errors may not trigger rollback.
• Snapshot accumulation: If reboots are infrequent, staged snapshots accumulate until a reboot activates them, temporarily increasing disk usage. Cleanup runs daily via snapper.
• Third-party kernel modules: Proprietary GPU drivers or out-of-tree modules must be rebuilt against the new kernel after each update; the kernel-module-* packaging helps but may lag.

What to do next

1. Test in a VM: install MicroOS or Aeon with Btrfs root, run transactional-update dup, reboot, then verify with transactional-update status and snapper list.
2. Add a custom health script in /etc/transactional-update/health-check.d/ that validates your application's readiness (exit 0 = success, non-zero = trigger rollback).
3. Monitor snapshot space with btrfs filesystem usage / and snapper list --type pre-post over several update cycles.
4. For configuration audit trails, pair transactional updates with etckeeper or an IaC tool; /etc changes persist but aren't version-controlled by default.

Transactional updates give you a safety net that traditional package managers lack. The key is treating the OS as an immutable image and letting Btrfs snapshots handle the rollback mechanics—while you focus on defining what "healthy" means for your workload.