openSUSE Transactional Updates: Read-Only Root with Btrfs Snapshots

Servers and edge devices need updates that either fully succeed or leave the previous system bootable. The practical openSUSE pattern for that is a read-only root filesystem, Btrfs subvolumes managed by snapper, and a transactional update service that stages changes offline and switches the default subvolume on reboot.

Requirements that drive the design

Atomic, recoverable system updates with minimal downtime. Updates must survive power loss during apply and allow fast rollback without manual file restoration. Mutable state such as configuration, logs and user data must persist across image switches. The design assumes Btrfs is available on the root device and snapper is configured. Behavior varies between openSUSE MicroOS, Leap Micro and Tumbleweed; do not assume transactional updates work on ext4 or non-snapshot filesystems.

Smallest suitable design

The minimal working set is three cooperating pieces: an immutable OS image stored as a Btrfs subvolume, snapper snapshots for versioning, and transactional-update for staging.

Btrfs subvolumes and snapper

The root filesystem is mounted read-only. The active OS lives in a subvolume, typically @, and previous versions are kept as read-only snapshots under /.snapshots. Snapper creates pre and post snapshots around changes and enforces retention.

Check the layout on the host as root:

mount | grep ' / '

Expected check: the options for / include ro. Risk: this is read-only inspection.

ls -l /.snapshots

Expected check: snapshot directories exist. Risk: none, read-only.

Transactional update staging

Changes are not applied live. transactional-update creates a writable snapshot, applies package and config changes there, then marks that snapshot as the next boot target. The change becomes visible only after reboot.

Verify the service is present:

systemctl is-active transactional-update.service

Run as root. Expected check: active or inactive depending on variant. Risk: service status check is safe.

List snapshots:

snapper list

Run as root. Expected check: a list of snapshots with types pre/post/single. Risk: none.

Review staging configuration:

cat /etc/transactional-update.conf

Run as root. Expected check: file exists and defines update behavior. Risk: editing this file changes update policy.

Trust and data boundaries

The immutable OS image is trusted only if modified through the privileged update path. The root subvolume is read-only for all users and services, preventing accidental or malicious in-place edits.

Mutable state is separated to writable locations, commonly /etc, /var and /home, often via bind mounts or separate subvolumes. User workloads cannot persist into root; configuration changes must go through the transactional path or be written to the mutable mounts.

Only root can trigger transactional-update. The boundary is enforced by mount options and by the update service, not by application policy.

Operational checks

• Verify root is read-only and subvolume layout is correct. Inspect mount options and /.snapshots.
• Confirm the transactional update service is active and the reboot target is set correctly. Check the default subvolume for the next boot via the bootloader configuration used by the system.
• Monitor disk space for snapshot retention. Snapper cleanup can delete old snapshots automatically; retention policy must be tuned to storage capacity.
• Review mutable path mounts. Inspect /etc/fstab and current mounts for /etc, /var, /home to ensure state is not written into the read-only image.

A practical dry-run check is to stage an update and verify the default subvolume change is staged but not applied until reboot. Do not reboot in production without confirming rollback access.

Failure modes

Power loss during the subvolume switch leaves the previous snapshot bootable because the switch is performed at boot time by the bootloader. If disk fills, snapshot creation fails and the update cannot be staged. Misconfiguration of mutable paths can cause state loss on rollback because changes written into the read-only image are discarded with the subvolume.

Read-only root limits ad-hoc administrative changes. Expect workflow changes for custom services and manual edits; direct edits to files under / will fail.

Conditions that change the design

Consider a different approach when requirements shift to frequent in-place package tweaks, need for non-Btrfs storage, or multi-tenancy requiring per-user atomicity beyond the system image. If the workload needs writable root for development or legacy software that cannot be containerized, the immutable model adds friction.

Limitations: snapshot retention must be managed to avoid storage exhaustion. Automatic cleanup may delete needed rollback points. Assume Btrfs is available and snapper is configured; the pattern does not apply to ext4.