transactional-update, transactional-update.service, transactional-update.timer - Apply updates to the system in an atomic way via transactional updates.transactional-update.service
transactional-updateupdates 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 thistransactional-updateis using Btrfs' snapshot mechanism. Updates will be performed in a new snapshot of the root file system. The snapshot is created withsnapper(8), for the updatezypper(8)is called with the-Roption 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.
Onread-only systemseach snapshot will have a corresponding/etcoverlay 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. changes in older layers will be visible in newer snapshots, but not vice versa. To keep the number of layers at a minimum and the amount of data stored in the overlays low the/etcstate of the oldest still available snapshot is synchronized into the new root file system; unused overlays will be removed at a later time (see thecleanupoption).
If a file was changed both in the new snapshot (e.g. if a package installed anew version of the configuration file or used fillup-templates) and in thecurrently running system after creation of the new snapshot (e.g. if theadministrator or configuration management software changed a file) only theversion of the new snapshot will be visible. When rebooting into the newsnapshot for the first timetransactional-update-etc-cleaner.service will print awarning about such conflicts to the system log file.
Older transactional-update versions were using a single/etcoverlay for all snapshots; a migration mechanism is in place, the directory will also be removed if no snapshot is using it any more.
Onread-write systemsplease 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 an successfull update.
For easier maintenance of big clusters,transactional-updateis run bysystemd.timer(5)in regular intervals. The specific time can be configured in/etc/systemd/system/transactional-update.timer.d/local.conf. Seesystemd.unit(5)for more information.
General Commands can be used together in any combination; additionally they can be extended with onePackage Command.
- If the current root filesystem is identical to the active root filesystem (means after a reboot, beforetransactional-updatecreates 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 insnapper(8).
Also removes all unreferenced (and thus unused)/etcoverlay directories in/var/lib/overlay.
- grub2-mkconfig(8)is called to create a new/boot/grub2/grub.cfgconfiguration file for the bootloader.
- Same asgrub.cfg, but will also rewrite the bootloader itself.
- A new initrd is created in a snapshot.
- A new initrd for kdump is created in a snapshot.
- If a new snapshot with updates was created, the system should be rebooted. This option will trigger the necessary reboot. If therebootmgrd(8)is running,transactional-updatewill tell the daemon to reboot the system according to the configured policies. Elsesystemctl rebootis called.
- 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 invokezypper(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 ofGeneral 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--interactiverespectively the--non-interactiveoptions.
Note that when using Package Commands non-interactively and combining them withGeneral Commandsthe General Commands will only be executed if the Package Command updated any packages.
Non-interactive Package Commands
- If new updates are available, a new snapshot is created andzypper dup --no-allow-vendor-changeis 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 andzypper upis 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 andzypper patchis used to update the snapshot. Afterwards, the snapshot is activated and will be used as the new root filesystem during next boot.
Interactive Package Commands
- 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.
pkg command arguments
- Callszypperwith the givencommandandarguments. The arguments are typically one or more package names, but can be anyzypper(8)parameter for the given command including options. The following commands are supported:
- Installs additional software. See theinstalldescription in the "Package Management Commands" section of zypper's man page for all available arguments.
- Removes installed software. See theremovedescription in the "Package Management Commands" section of zypper's man page for all available arguments.
- Update selected software. See theupdatedescription in the "Update Management Commands" section of zypper's man page for all available arguments.
- Sets the default root file system. On a read-only system the root file system is set directly usingbtrfs. On read-write systemssnapper(8)rollbackis called.
If no snapshot number is given, the current root file system is set as the new default root file system. Otherwisenumbercan either be a snapshot number (as displayed bysnapper list) or the wordlast.lastwill try to reset to the latest working snapshot.
- 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.
- Skip checking for newer transactional-update versions.
- Don't print warnings and informational messages to stdout.
- Display help and exit
- Output version information and exit
Only RPMs which are fully part of the root filesystem and/etccan 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 them[blue]initial configuration and deployment section of the packaging guidelinesm).
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 timetransactional-updatewill create a new snapshot it will be based on thecurrently running system. Callingtransactional-updatemultiple times without rebooting willnotinclude the changes of the previous snapshot, thus effectively discarding all previous changes.
Thorsten Kukuk <kukukAATTsuse.com>
- initial configuration and deployment section of the packaging guidelines
- General Commands
- Package Commands
- Standalone Commands
- SEE ALSO
This document was created byman2html,using the manual pages.