openSUSE MicroOS and Transactional Updates: Atomic System Updates with Btrfs Snapshots

The Problem With Traditional Linux Updates

On a traditional Linux system, apt upgrade or dnf update modifies the running filesystem in place. If power fails halfway through, or a package's post-install script crashes, you have a partially updated system in an unknown state. Rolling back means either a backup restore or manual package downgrade — neither is fast.

SUSE solved this with two complementary mechanisms: Btrfs snapshots (via snapper) for rollback capability, and transactional-update for atomic all-or-nothing updates. openSUSE MicroOS takes it further with a fully immutable root filesystem.

---

Btrfs and Snapper Foundations

SUSE installs Btrfs by default and configures snapper to create snapshot pairs around package operations. This is the foundation everything else builds on.

Btrfs Subvolumes

SUSE's default Btrfs layout uses subvolumes to control what gets snapshotted:

# View Btrfs subvolume layout
sudo btrfs subvolume list /

# You'll see entries like:
# ID 256 gen 100 top level 5 path @        ← root subvolume (snapshotted)
# ID 257 gen 100 top level 5 path @/home   ← home (separate, NOT snapshotted with root)
# ID 258 gen 100 top level 5 path @/var    ← var (NOT snapshotted)
# ID 259 gen 100 top level 5 path @/tmp    ← tmp

# Key point: /var and /home are excluded from snapshots
# This means: user data and runtime data survive rollbacks

Snapper Basics

# List all snapshots
sudo snapper list

# Typical output after updates:
# # | Type   | Pre # | Date         | Description
# 0 | single | none  | ...          | current
# 1 | pre    | none  | 2026-04-01   | zypper(zypper update)
# 2 | post   | 1     | 2026-04-01   | zypper(zypper update)

# See what changed between two snapshots
sudo snapper diff 1..2

# See which files changed
sudo snapper status 1..2

# Undo changes between two snapshots (selective rollback)
sudo snapper undochange 1..2 /etc/nginx/nginx.conf

# Full rollback to a previous snapshot (marks it as default, reboot required)
sudo snapper rollback 1
sudo reboot

After snapper rollback N, the system boots into snapshot N as the new active subvolume. The previous state is preserved as a new snapshot so you can roll forward again if needed.

---

transactional-update: Atomic Updates

transactional-update (available on openSUSE Leap, Tumbleweed, and MicroOS) takes the snapshot approach further:

1. Creates a new Btrfs snapshot of root
2. Applies the update to the snapshot (not the running system)
3. If the update fails, the snapshot is discarded — running system is untouched
4. If the update succeeds, the snapshot becomes the new default on next boot

# Install transactional-update
sudo zypper install transactional-update

# Apply all pending updates atomically
sudo transactional-update

# Update and reboot in one command
sudo transactional-update dup reboot

# Install a package into the next snapshot
sudo transactional-update pkg install nginx

# Run a shell inside the new snapshot (for manual changes)
sudo transactional-update shell

# Rollback: reboot into previous snapshot
sudo transactional-update rollback
sudo reboot

# List available snapshots
sudo transactional-update rollback --list

The key property: if the machine dies during an update, the next boot uses the last successful snapshot. The update is either fully applied or not applied at all.

---

openSUSE MicroOS: Immutable Root

MicroOS extends transactional-update into a full immutable operating system:

• Root filesystem is read-only at runtime
• All updates happen via transactional-update with mandatory reboot to activate
• Designed for container hosts, edge nodes, and automated fleets
• Containers run as usual (container storage is on /var, which is read-write)

Installing MicroOS

MicroOS is a separate image from openSUSE Leap or Tumbleweed — install from microos.opensuse.org. Or use it as a VM/cloud image.

MicroOS Day-to-Day Operations

# Apply system updates (takes effect after reboot)
sudo transactional-update dup

# Install a package (takes effect after reboot)
sudo transactional-update pkg install podman

# Reboot to activate changes
sudo reboot

# The root filesystem is mounted read-only:
mount | grep " / "
# /dev/sda2 on / type btrfs (ro,relatime,...)

# /var and /etc overlays are read-write
# /etc uses an overlay to allow config changes without updating the snapshot

Containers on MicroOS

MicroOS is optimized as a container host:

# Podman is the default container runtime
podman run -it --rm alpine sh

# For Kubernetes, MicroOS + K3s or RKE2
curl -sfL https://get.k3s.io | sudo sh -

# Container data lives in /var/lib/containers (read-write)
# Config lives in /etc/containers/ (overlay — survives updates)

---

Automatic Updates

For unattended servers and edge nodes, configure automatic transactional updates:

# Enable the automatic update timer
sudo systemctl enable --now transactional-update.timer

# Check when it's scheduled
systemctl status transactional-update.timer
systemctl list-timers | grep transactional

# Configure automatic reboot after updates
# Edit /etc/transactional-update.conf:
sudo cat > /etc/transactional-update.conf << 'EOF'
REBOOT_METHOD=rebootmgr
EOF

# Or for immediate reboot after updates:
# REBOOT_METHOD=systemd

# Check rebootmgr policy (maintenance window for reboots)
sudo rebootmgrctl status
sudo rebootmgrctl set-strategy best-effort

---

Comparing Update Approaches

Approach	Atomic?	Rollback	Running State
zypper update	No	Via snapper	Modifies live system
transactional-update	Yes	Automatic	Updates snapshot, reboot to activate
MicroOS	Yes	Automatic	Root is read-only, updates require reboot

---

When to Use Each

openSUSE Leap + zypper + snapper: Standard server where you need flexibility — can install packages and use them immediately. Rollback available but not automatic.

openSUSE Tumbleweed + transactional-update: Rolling release with atomic safety net. Good for developer workstations where you want latest software but with rollback.

MicroOS: Container hosts, Kubernetes nodes, edge devices, or any system where immutability and fully automated update safety are more important than the ability to install packages at runtime.

---

Practical Rollback Workflow

# Scenario: zypper update broke something

# 1. Check available snapshots
sudo snapper list

# 2. Find the pre-update snapshot number (e.g., #4)
# 3. Roll back
sudo snapper rollback 4

# 4. Reboot into the previous state
sudo reboot

# 5. After verifying the rollback works, the broken state is preserved as a snapshot
#    Roll forward by booting it again, or delete it:
sudo snapper delete <broken-snapshot-number>

The combination of Btrfs snapshots, snapper, and transactional-update makes SUSE the most update-safe Linux distribution for production use — updates that fail leave no trace, and rollback is a single command and reboot.