Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Desktop 15 SP1

9 Transactional Updates Edit source

Transactional updates are available in SUSE Linux Enterprise Desktop as a technology preview, for updating SLES when the root filesystem is read-only. Transactional updates are atomic (all updates are applied only if all updates succeed) and support rollbacks. It does not affect a running system as no changes are activated until after the system is rebooted. As reboots are disruptive, the admin must decide if a reboot is more expensive than disturbing running services. If reboots are too expensive then do not use transactional updates.

Transactional updates are run daily by the transactional-update script. The script checks for available updates. If there are any updates, it creates a new snapshot of the root file system in the background, and then fetches updates from the release channels. After the new snapshot is completely updated, it is marked as active and will be the new default root file system after the next reboot of the system. When transactional-update is set to run automatically (which is the default behavior) it also reboots the system. Both the time that the update runs and the reboot maintenance window are configurable.

Only packages that are part of the snapshot of the root file system can be updated. If packages contain files that are not part of the snapshot, the update could fail or break the system.

RPMs that require a license to be accepted cannot be updated.

9.1 Limitations of Technical Preview Edit source

As a technical preview, there are certain limitations in functionality. The following packages will not work with transactional-update:

  • The nginx default index.html page may not be available

  • tomcat-webapps and tomcat-admin-webapps

  • phpMyAdmin

  • sca-appliance-*

  • mpi-selector

  • emacs works except for Emacs games

  • bind and bind-chrootenv

  • docbook*

  • sblim-sfcb*

  • texlive*

  • iso_ent

  • openjade

  • opensp

  • pcp

  • plymouth

  • postgresql-server-10

  • pulseaudio-gdm-hooks

  • smartmontools

The updater component of the system installer does not work with a read-only filesystem as it has no support for transactional updates.

Further considerations:

  • In general it is a good idea to minimize the time between updating the system and rebooting the machine.

  • Only one update can be applied at a time. Be sure to reboot after an update, and before the next update is applied.

  • update-alternatives should not be run after a transactional update until the machine has been rebooted.

  • Do not create new system users or system groups after a transactional update until after reboot. It is acceptable to create normal users and groups (UID > 1000, GID > 1000).

  • YaST is not yet aware of transactional updates. If a YaST module needs to install additional packages, this will not work. Normal system operations only modifying configuration files in /etc will work.

  • For php7-fastcgi, you must manually create a symlink, /srv/www/cgi-bin/php, that points to /usr/bin/php-cgi.

  • ntpis part of the Legacy Module for migration from older SLES versions. It is not supported on a new SUSE Linux Enterprise Desktop installation, and has been replaced by chrony. If you continue to use ntp, a fresh installation is required to work correctly with transactional updates.

  • sblim-sfcb: The whole sblim ecosystem is incompatible with transactional update.

  • btrfs-defrag from the btrfsmaintenance package does not work with a read-only root filesystem.

  • For btrfs-balance, the variable BTRFS_BALANCE_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance must be changed from / to /.snapshots.

  • For btrfs-scrub, the variable BTRFS_SCRUB_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance must be changed from / to /.snapshots.

9.2 Enabling transactional-update Edit source

You must enable the Transactional Server Module during system installation, and then select the Transactional Server System Role. Installing any package from the Transactional Server Module later in a running system is NOT supported and may break the system.

Note that changing the subvolume layout of the root partition, or putting sub-directories or subvolumes of the root partition on their own partitions (except /home, /var, /srv, and /opt) is not supported, and will most likely break the system.

9.3 Managing Automatic Updates Edit source

Automatic updates are controlled by a systemd.timer that runs once per day. This applies all updates, and informs rebootmgrd that the machine should be rebooted. You may adjust the time when the update runs, see systemd.timer(5). To adjust the maintenance window, which is when rebootmgrd reboots the system, see rebootmgrd(8).

You can disable automatic transactional updates with this command:

root # systemctl --now disable transactional-update.timer

9.4 The transactional-update Command Edit source

The transactional-update command enables you to install or remove updates of your system in an atomic way. Updates are applied only if all of them can be successfully installed. transactional-update creates a snapshot of your system before the update is applied, and you can restore this snapshot.

All changes become active only after reboot.

cleanup

If the current root filesystem is identical to the active root filesystem (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 ensures that old snapshots will be deleted by Snapper. (See the section about cleanup algorithms in snapper(8).) This also removes all unreferenced (and thus unused) /etc overlay directories in /var/lib/overlay:

root # transactional-update cleanup
pkg in/install

Installs individual packages from the available channels using the zypper install command. This command can also be used to install Program Temporary Fix (PTF) RPM files.

root # transactional-update pkg install package_name

or

root # transactional-update pkg install rpm1 rpm2
pkg rm/remove

Removes individual packages from the active snapshot using the zypper remove command. This command can also be used to remove PTF RPM files.

root # transactional-update pkg remove package_name
pkg up/update

Updates individual packages from the active snapshot using the zypper update command. Only packages that are part of the snapshot of the base file system can be updated.

root # transactional-update pkg remove package_name
up/update

If there are new updates available, a new snapshot is created and zypper up/update updates the snapshot.

root # transactional-update up
dup

If there are new updates available, a new snapshot is created and zypper dup –no-allow-vendor-change updates the snapshot. The snapshot is activated afterwards and becomes the new root file system after reboot.

root # transactional-update dup
patch

If there are new updates available, a new snapshot is created and zypper patch updates the snapshot.

root # transactional-update patch
rollback

This sets the default subvolume. On systems with a read-write file system snapper rollback is called. On a read-only file system and without any argument, the current system is set to a new default root file system. If you specify a number, that snapshot is used as the default root file system. On a read-only file system, it does not create any additional snapshots.

root # transactional-update rollback snapshot_number
grub.cfg

This creates a new GRUB2 configuration. Sometimes it is necessary to adjust the boot configuration, for example adding additional kernel parameters. Edit /etc/default/grub, run transactional-update grub.cfg, and then reboot to activate the change. You must immediately reboot, or the new GRUB2 configuration will be overwritten with the default by the next transactional-update.

root # transactional-update grub.cfg
reboot

This parameter triggers a reboot after the action is completed.

root # transactional-update dup reboot
--help

This prints a help screen with options and subcommands.

root # transactional-update --help

9.5 Troubleshooting Edit source

If the upgrade fails, run supportconfig to collect log data. Provide the resulting files, including /var/log/transactional-update.log to SUSE Support.

Print this page