Mounts /usr, /etc and /boot of the (new) default snapshot into the currently running system. This is mostly useful for using newly installed packages directly without a reboot. When using apply on a system where existing files will be replaced (e.g. when doing a system update) this behaves similarly to a regular zypper update where files of currently running applications will also be replaced, but with the additional advantage that the update itself was finished successfully as a whole, avoiding inconsistent states on update failures.

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 cleanup-snapshots and cleanup-overlays.

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) /etc overlay directories in /var/lib/overlay.

grub2-mkconfig(8) is called to create a new /boot/grub2/grub.cfg configuration file for the bootloader.

Same as grub.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.

Trigger a reboot after updating the system.

Several different reboot methods are supported, configurable via the REBOOT_METHOD configuration option in transactional-update.conf(5). By default rebootmgrd(8) will be used to reboot the system according to the configured policies if the service is running, otherwise systemctl reboot will be called.

Execute the the command cmd inside a new snapshot. By default this snaphot will remain, but if --drop-if-no-change is set, the new snapshot will be dropped if there is no change in the file system.

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 install.

Sets up kdump on the system; if no --crashkernel option is specified then it will use the values determined by kdumptool calibrate, otherwise the values of low and high (numbers in Megabytes) will be used for the corresponding crashkernel kernel parameters.

This command can not be combined with any Package Command other than install.

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 install.

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.

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) rollback is called.

If no snapshot number is given, the current root file system is set as the new default root file system. Otherwise number can either be a snapshot number (as displayed by snapper list) or the word last. last will try to reset to the latest working snapshot.

This command can be combind with the apply command to make the snapshot effective immediately.

Shows the status of current and older snapshots. The status try to represent how the system diverges from an ideal base image, and the list of patterns and packages added and removed from it.

The status is represented via a hash (currently sha256) of a manifest file that contains the list of expected packages and the build time of those packages. The list of expected packages are calculated using the libsolv library, and resolving it for the list of default patterns associated with the role used during the installation.

Two manifest files are created. One will use the information from the repositories used for the installation. The list of packages (including the full version and architecture) and the build time will be extracted from the repository information. The other one will use the same list of packages, but using the build time from the current system (if the package is present).

Both manifest files will be the same if we have a fresh installed system. But in distributions like MicroOS, that are released based on a rolling model, the subsequent updates will make compromises that will result in a diverged state. In that way, if two systems have the same BASE_MANIFEST_DIGEST (the digest calculated from the repository information), we can assume that are in the same state even if the SYSTEM_MANIFEST_DIGEST is different.

We can require of two system to be in the exact same status, and for that we can compare both digests.

The status also shows the differences in patterns and packages from the expected situation, and will save a copy of both manifest for further audit of the system.

To write the necessary state file EXPERIMENTAL_STATUS=1has to be set in transactional-update.conf.