transactional-update, transactional-update.service, transactional-update.timer — Apply updates to the system in an atomic way via transactional updates.
transactional-update [--help] [--version]
transactional-update [--no-selfupdate] [cleanup] [ up | dup | patch | bootloader | initrd ] [kdump] [reboot]
transactional-update [--no-selfupdate] [cleanup] [reboot] pkg install | remove | update <RPM>...<RPM>
transactional-update [--no-selfupdate] migration
transactional-update rollback [number]
transactional-update.service
transactional-update.timer
transactional-update updates the system in a transactional way, which means: it is atomic, so either the patches are fully applied or nothing is changed. The update does not influence your running system and it can be rolled back. To activate the changes, the system needs to be rebooted.
This is archived by creating at first a snapshot of the system. Afterwards, this snapshot is updated with zypper. Only if there were updates and they could be applied without error, the snapshot will be the default with the next reboot.
Changes made to the running root filesystem after transactional-update was started are lost after the next reboot. For this reason, after an successfull update, the system should be rebooted as fast as possible.
For easier maintenance of big clusters, transactional-update is regular run by systemd.timer(5). The time, at which the command is run, can be modified by a configuration file /etc/systemd/system/transactional-update.timer.d/local.conf. See systemd.unit(5) for more informations.
cleanup¶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).
dup¶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.
grub.cfg¶grub2-mkconfig(8) is called to create a new /boot/grub2/grub.cfg configuration file for the bootloader.
bootloader¶A new snapshot is created, the bootloader configuration updated and the boorloader newly written.
initrd¶A new initrd is created in a snapshot.
kdump¶A new initrd for kdump is created in a snapshot.
migration¶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 is done in an interactive mode.
patch¶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.
pkg install <RPM> ... <RPM>¶A PTF or other packages in RPM format can be installed in the system.
pkg remove <RPM> ... <RPM>¶A PTF or other installed packages in RPM format can be removed from the system.
pkg update <RPM> ... <RPM>¶Packages installed as RPMs can be updated.
reboot¶If a new snapshot with updates was created, the system should be rebooted. This option will trigger the necessary reboot. If the rebootmgrd(8) is running, transactional-update will tell the daemon to reboot the system according to the configured policies. Else systemctl reboot is called.
rollback
[number]¶
Sets the default subvolume. On systems with read-write filesystem,
snapper(8)
rollback is called. On a read-only filesystem,
without argument, the current system is made the new default root
filesystem. Else the snapshot with number is made the
new default root filesystem. On a read-only filesystem, no additional
snapshots are created.
shell¶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.
up¶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.
--no-selfupdate¶Skip checking for newer transactional-update versions.
--help¶Display help and exit
--version¶Output version information and exit
Only RPMs, which are fully part of the snapshot of the root filesystem, can be updated. If RPMs contains files outside of the snapshot, the update itself can break or can break the system.
Since all changes to the root filesystem will go lost after creating the snapshot for the update, the system should be rebooted as fast as possible after the update finished.
RPMs, where a license needs accepted for, cannot be updated.
If PTFs get installed or removed, and transactional-update is called again before the next reboot and updates packages, the changes to the PTFs are lost and need to be redone with the next reboot. After installing or removing PTFs, the system should be immeaditly rebooted.
If /etc/default/grub was modified by an administrator, the modified version is copied into the new snapshot.
If during the update process /etc/passwd, /etc/group or /etc/shadow are modified and /usr/etc exists, the modified files are copied into /usr/etc and can be accessed by tools like libnss_usrfiles. This prevents that the new accounts are hidden by local modifications by the system administrator.