SUSE Linux Enterprise Server 16.1

Using `zypper` on the immutable SUSE Linux Enterprise Server

Publication Date: 28 Aug 2026

On the immutable SLES the root file system is mounted read-only to ensure stability and reliability. While file system modifications are handled in the background by the transactional-update command, a built-in wrapper enables administrators to execute standard zypper commands directly. This article provides an overview of how zypper interacts with an immutable system, covering both native read-only operations and seamless system modifications..

Prerequisites:

Basic knowledge of zypper
Knowledge of the transactional-update command

Revision History: Using zypper on the immutable SUSE Linux Enterprise Server

1 `zypper` commands not modifying the file system #

Operations that query external repositories or the local database do not require write access to the root file system. Because these commands do not alter the system state, they bypass the transactional wrapper and do not create a Btrfs snapshot.

The following zypper commands function exactly as they do on a standard system:

zypper search PACKAGE_NAME
zypper info PACKAGE_NAME
Repository modification commands

For more details about the above mentioned commands, refer to the zypper article.

2 Modifying the immutable system #

Without the transactional wrapper, the system modification commands like zypper install, zypper patch, or zypper update fail and the user is instructed to use the transactional-update command instead.

When the transactional wrapper is enabled, zypper detects the immutable mode and spawns the transactional wrapper as a child process to execute the requested write operations. The transactional wrapper retrieves the exact command-line arguments of its parent process directly from the /proc file system. This ensures the command is replicated perfectly without requiring any syntax changes from the user.

Warning: Reboot between consecutive transactions

When executing multiple zypper update commands, you must activate the snapshot created by the previous transaction by rebooting before running the next command. If you run subsequent zypper commands without activating the intermediate snapshots, earlier modifications are discarded. For example, executing zypper in foo followed by zypper in bar, and then rebooting, results in a system where only the bar package is installed.

The transactional wrapper is usually installed and enabled by default. If it is not present on your system, see the following section for installation instructions.

2.1 Installing the transactional wrapper #

To install the package, perform the following steps:

Install the package:

> sudo transactional-update pkg in transactional-wrapper

Reboot the system to switch to the new snapshot.

3 Configuring the transactional wrapper #

The transactional wrapper has a configuration file, transactional-wrapper.conf, that enables you to switch the functionality off or modify its behavior after performing modifications to the file system.

To change the default configuration, copy transactional-wrapper.conf to /etc/.

> sudo cp /usr/etc/transactional-wrapper.conf /etc/transactional-wrapper.conf

Modify the file as described in the following sections.

3.1 Disabling the transactional wrapper #

In the file, you can switch off the transactional wrapper by setting the attribute ENABLE_TRANSACTIONAL_WRAPPER to 0:

ENABLE_TRANSACTIONAL_WRAPPER=0

Keep in mind that this disables calling zypper directly on the immutable system. To perform modifications to the file system, you must use the transactional-update command.

3.2 Configuring post-transaction behavior #

You can configure what the system does after an operation finishes by changing the value of ACTION. The following values are supported:

apply: This option calls transactional-update apply, and the system switches to the new snapshot with no need to reboot.
reboot: The system is rebooted immediately after an operation successfully completes.
soft-reboot: A soft reboot is performed immediately after an operation successfully completes.
kexec: The system is rebooted immediately using kexec.
info: This is the default value. The system informs you that a reboot is needed to apply the changes.

4 Legal Notice #

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.