Table of Contents
This chapter describes the handling of the root file system. In general
transactional-update will not modify any
other subvolumes or file systems: Information stored on these mounts
(such as /var or
/home) is usually not supposed
to be rolled back. See Chapter 4, System setup for a real world
setup.
There are exceptions for a few dedicated subvolumes such as
/boot/grub2/x86_64-efi which
also have to be available to be able to update the bootloader; these
directories will be bind mounted into the update environment.
transactional-update is based around several concepts of the Btrfs file system, a general purpose Copy-on-Write (Cow) filesystem with snapshot and subvolume support, though support for other file systems is possible (see Chapter 6, Porting to other systems for requirements and porting information).
transactional-update is wrapping all binaries which will modify the file system with tukit, which will in turn use chroot to execute the command in the new snapshot. That way e.g. zypper will install packages into the new snapshot only.
In the beginning there is a list of old snapshots, each one based on the previous one, and the newest one is the current root file system.
In the first step, a new snapshot of the current root file system will be created. This snapshot is set read write.
In the second step the snapshot will be updated. This can be zypper up or zypper dup, the installation or removal of a package or any other modification to the root file system.
In the third step the snapshot will be changed back to read-only, so that the data cannot be modified anymore.
The last step is to mark the updated snapshot as new root file system. This is the atomic step: If the power would have been pulled before, the unchanged old system would have been booted. Now the new, updated system will boot.
After reboot, the newly prepared snapshot is the new root file system. In case anything goes wrong a rollback to any of the older snapshots can be performed.
If the system is not rebooted and
transactional-update is called again a new
snapshot will be created and updated. This new snapshot is based
on the current running root filesystem again,
not on the new default snapshot!
For stacking changes (i.e. if several commands are supposed to be
combined in one single snapshot) the shell command
can be used to perform any number of operations, or the
--continue can be used to continue the latest
snapshot while preserving a separate snapshot for each step.
In essence the logic of transactional-update can be summarized as follows:
SNAPSHOT_ID=`snapper create --read-write -p -d "Snapshot Update"`
zypper -R ${SNAPSHOT_DIR} up|patch|dup|...btrfs property set ${SNAPSHOT_DIR} ro truebtrfs subvol set-default ${SNAPSHOT_DIR}systemctl reboot