Transactional updates on SUSE Linux Micro, openSUSE MicroOS and Leap Micro: read-only root and reboot-to-activate

Goal

Apply, activate and, if necessary, roll back a system change on SUSE Linux Micro, openSUSE MicroOS or Leap Micro (and on a SLES 15 SP6 host that opted into a read-only root), where / cannot be written to directly.

Prerequisites

A system already running with a read-only root (the default on SUSE Linux Micro/MicroOS/Leap Micro images); root access; awareness that the running system is never modified in place.

Steps

1. Understand the model first: the transactional-update command "enables you to modify a read-only file system," according to SUSE's SUSE Linux Micro documentation. Every invocation creates a new Btrfs snapshot from the current root, applies the requested change (package install, patch, or an arbitrary shell command) inside that snapshot, and leaves the running system untouched — "no changes are activated until after the system is rebooted," per the SLES 15 SP6 Administration Guide, which documents this mechanism for SLES itself as a technology preview when the root filesystem is read-only.
2. Install or update packages: sudo transactional-update pkg install <package>, sudo transactional-update patch (SUSE Linux Micro, Leap Micro) or sudo transactional-update dup (the update path on rolling openSUSE MicroOS); run without any command, it updates the system. Each creates a new snapshot and exits without touching the booted system.
3. To stack several changes instead of letting each command start again from the booted system, add --continue: the option "is for making multiple changes to the root file system without rebooting"; each run builds on the previous snapshot, and --continue <number> picks a specific base snapshot.
4. Reboot to activate the new snapshot: sudo reboot (or let the platform's reboot manager, rebootmgrd, do it — SUSE Linux Micro runs a daily systemd.timer that applies updates and then informs rebootmgrd that a reboot is due).
5. If the newly activated snapshot is broken, set the previous one back as default: sudo transactional-update rollback last, then reboot. If the system cannot boot at all, select the previous snapshot from the boot loader menu instead, the same way a Btrfs/snapper recovery works on a regular install.

Expected result

transactional-update returns to the prompt having created a new snapshot number (shown in its output); after reboot, snapper list shows that snapshot as the active root, and the change (package, patch, or command) is present.

Limits and test basis

Running transactional-update twice without an intervening reboot, and without --continue, produces two independent snapshots rather than one merged change — only the last one wins for the next boot. /var is not part of the snapshot and cannot be reached from inside it, so a transaction cannot change data there and a rollback does not restore it. A reboot is required to see any effect, and SUSE's documentation calls reboots disruptive; schedule it rather than assuming a change is live immediately.