transactional-updatetransactional-update, transactional-update.service, transactional-update.timer — Apply updates to the system in an atomic way via transactional updates. |
transactional-update [options...] [general-command...] [package-command
[command-argument...]
]
transactional-update [options...] standalone-command
transactional-update.service
transactional-update.timer
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 contain a nested
/etc subvolume. As configuration files
may be modified after a snapshot was created and before a reboot is performed
(e.g. via configuration management software) on first boot into the new
snapshot the service
transactional-update-sync-etc-state.service will copy
these files into the new snapshot if they weren't also changed there.
/etc has been changed
during the update and is also changed in the running
system after the snapshot has been taken, then only the version of the new
snapshot will be visible after a reboot.
Older transactional-update versions were using multiple
/etc overlays instead of BTRFS
subvolumes; a migration mechanism is in place, the directories will still be
removed if no snapshot is using them 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.
If none of the following commands is given, the value of
UPDATE_METHOD in
transactional-update.conf(5)
will be assumed.
General Commands can be used together in any combination; additionally they can be extended with one Package Command. The order of the General Commands doesn't matter.
|
Mounts Note that - in contrast to regular zypper updates - services will not be restarted automatically. Additionally mounting the three directories is not one atomic operation, so there will be a short timespan where the directories visible to the system will not be in sync. |
|
Identical to calling both |
|
If the current root filesystem is identical to the active root filesystem (means after a reboot, before transactional-update creates a new snapshot with updates), all old snapshots without a cleanup algorithm get a cleanup algorithm set. This is to make sure, that old snapshots will be deleted by snapper. See the section about cleanup algorithms in snapper(8). |
|
Removes all unreferenced (and thus unused)
|
|
grub2-mkconfig(8)
is called to create a new |
|
Same as |
|
A new initrd is created in a snapshot. |
|
A new initrd for kdump is created in a snapshot. This only has an effect when using fadump, on regular kdump system the initrd will be created during boot automatically. |
|
Trigger a reboot after updating the system.
Several different reboot methods are supported, configurable via the
|
|
Execute the command
If a non-zero exit status is expected, then the command may either be
wrapped inside a Bash script (see the program listing below) or it can
be combinded with the
Note that a snapshot will be created for each call, so if the command
only performs read-only operations it may be worth to combine it with
This command consumes all the remaining parameters, so should be placed in the last position. To use features like command lists (e.g. pipes or separators) wrap the script into a Shell command like such as transactional-update run bash -c ' ls && date if [ true ]; then echo -n "Hello " echo '\''world'\'' fi '
|
|
Install the FIPS pattern package and configure the kernel command line parameter to activate FIPS mode.
This command can not be combined with any
Package Command other than
|
|
Sets up kdump on the system; if no
This command can not be combined with any
Package Command other than
|
|
Sets up a SELinux system: Installs the default SELinux "Targeted policy" and enables it.
This command can not be combined with any
Package Command other than
|
|
Opens a shell to execute commands like zypper manually. After all actions are done, before the snapshot with the changes is unmounted and switched to read-only, a shell is started in the new snapshot as chroot environment for testing and debugging. |
Package Commands will invoke zypper(8) to perform actions on the RPM packages. Only one Package Command can be used at the same time. Can be combined with any number of General Commands.
By default commands usually invoked from scripts are called in
non-interactive mode (assuming the default answer in case of questions),
commands typically called by the user are called in interactive mode.
The behaviour can be changed or enforced using the
--interactive respectively the
--non-interactive options.
To facilitate scripting Package Commands will exit early if no packages were updated; if combined with General Commands those will not be executed any more in that case.
|
If new updates are available, a new snapshot is created and zypper dup --no-allow-vendor-change is used to update the snapshot. Afterwards, the snapshot is activated and will be used as the new root filesystem during next boot. |
|
If new updates are available, a new snapshot is created and zypper up is used to update the snapshot. Afterwards, the snapshot is activated and will be used as the new root filesystem during next boot. |
|
If new updates are available, a new snapshot is created and zypper patch is used to update the snapshot. Afterwards, the snapshot is activated and will be used as the new root filesystem during next boot. |
|
Register a (commercial) system. This is a simple wrapper for SUSEConnect, as some commands may require access to the root file system (e.g. to add a new key to the RPM database). Any arguments will just be forwarded to SUSEConnect.
This command implies the SUSEConnect is always a non-interactive command. |
|
On systems which are registered against the SUSE Customer Center (SCC)
or SMT, a migration to a new version of the installed products can be
made with this option. This command calls zypper migration
with the given These arguments can be any zypper-migration(8) argument, with the exception of "--root", as this is handled by transactional-update dynamically. |
||||||
|
Calls zypper with the given
|
||||||
|
Instead of updating the existing system the whole system will be
replaced with the given image, which will be written into the next
snapshot. Exceptions are |
|
Sets the default root file system. On a read-only system the root
file system is set directly using btrfs. On
read-write systems
snapper(8)
If no snapshot number is given, the current root file system is set as
the new default root file system.
Otherwise
This command can be combind with the |
|
Calls zypper in interactive mode, even if the default for this command is non-interactive. |
|
Calls zypper in non-interactive mode, even if the default for this command is interactive. |
|
Use the given snapshot or, if no number is given, the current default snapshot as a base for the next snapshot. |
|
Skip checking for newer transactional-update versions. |
|
If the action does not produce a change in the underlying file system, the snapshot will be dropped. |
|
Do not delete the snapshot in case of errors. This option is mainly meant for debugging or recovery if a tukit plugin failed, the resulting snapshot should be used only after verifying the contents are as expected. The default snapshot will not be changed. |
|
Don't print warnings and informational messages to stdout
when generated by transactional-update itself, i.e. when using the
|
|
Display help and exit |
|
Output version information and exit |
|
All commands were executed successfully. |
|
One of the commands returned with an error. Due to that a potential new snapshot has been deleted again. |
|
The |
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).
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).
transactional-update.conf(5), tukit.conf(5), systemd.timer(5), systemd.time(7), The Transactional Update Guide