NAME¶

transactional-update, transactional-update.service, transactional-update.timer - Apply updates to the system in an atomic way via transactional updates.

SYNOPSIS¶

transactional-update [options...] [general-command...] [package-command [command-argument...]]

transactional-update [options...] standalone-command

transactional-update.service

transactional-update.timer

DESCRIPTION¶

transactional-update updates the system in a transactional way; this means updates are atomic, so either the patches are fully applied or nothing is changed. The update does not influence the running system and it can be rolled back. To activate the changes, the system needs to be rebooted.

To achieve this transactional-update is using Btrfs' snapshot mechanism, combined with the default distribution tools. Whenever an update of the root file system is going to be performed, snapper(8) will create a new snapshot of the root file system first. This new snapshot is then used to perform the update, e.g. by calling zypper(8) with the -R option pointing to the new snapshot. If no errors occured the snapshot will be set as the new default snapshot and set as read-only. In case of errors the snapshot will be deleted again.

By default the snapshot is always branched off from the current root file system, i.e. calling transactional-update multiple times without rebooting will create separate, independent snapshots, not containing the changes of the previous run. If multiple consecutive actions are to be executed, the --continue option can be used. This will still create a separate snapshot for each call, so it is possible to roll back to previous intermediate steps in case of errors.

On read-only systems each snapshot will have a corresponding /etc overlay located in /var/lib/overlay. As configuration files may be modified after a snapshot was created and before a reboot is performed (e.g. via configuration management software) the overlay file system will use multiple lower layers, i.e. configuration file changes applied to the currently running system will be visible in the new system, but not vice versa. To keep the number of layers at a minimum the /etc state of the previous snapshot is synchronized into the new root file system; unused overlays will be removed at a later time (see the cleanup-overlays option).

Older transactional-update versions were using a single /etc overlay for all snapshots; a migration mechanism is in place, the directory will also be removed if no snapshot is using it any more.

On read-write systems please be aware that all changes done to the running root filesystem after snapshot creation are lost after the next reboot. For this reason the system should be rebooted as fast as possible after a successful update.

For easier maintenance of big clusters, transactional-update is run by systemd.timer(5) in regular intervals. The specific time can be configured in /etc/systemd/system/transactional-update.timer.d/local.conf. See systemd.unit(5) for more information.

COMMANDS¶

If none of the following commands is given, the value of UPDATE_METHOD in transactional-update.conf(5) will be assumed.

	  transactional-update run bash -c '
	    ls && date
	    if [ true ]; then
	      echo -n "Hello "
	      echo '\''world'\''
	    fi
	  '
	

OPTIONS¶

--interactive, -i

--non-interactive, -n

--continue [number], -c [number]

--no-selfupdate

--drop-if-no-change, -d

--quiet

--help, -h

--version

EXIT STATUS¶

0

1

2

IMPORTANT¶

Only RPMs which are fully part of the root filesystem and /etc can be updated. There is also limited handling for adding files and directories to /var, however modifications of existing files (e.g. migrating databases) are supposed to be handled by systemd jobs at startup (see the initial configuration and deployment section of the packaging guidelines[1]).

Since all changes to the root filesystem will get lost after creating the snapshot for the update, the system should be rebooted as fast as possible after the update finished.

Every time transactional-update will create a new snapshot it will be based on the currently running system. Calling transactional-update multiple times without rebooting will not include the changes of the previous snapshot, thus effectively discarding all previous changes (except when using --continue to explicitly continue a previous snapshot or when apply was called previously).

SEE ALSO¶

transactional-update.conf(5), tukit.conf(5), systemd.timer(5), systemd.time(7), The Transactional Update Guide[2]

AUTHOR¶

Thorsten Kukuk <kukuk@suse.com>

NOTES¶

1.

initial configuration and deployment section of the packaging guidelines

2.

The Transactional Update Guide