The openSUSE Project has officially released openSUSE Leap 16.1, introducing a major change to how the distribution can be installed, maintained, and deployed. Released on November 3, 2026, the update brings an integrated Immutable Mode that allows users to install a transactionally updated operating system with a read-only root filesystem, while continuing to offer the traditional Linux installation model.

The new approach also marks the beginning of the end for openSUSE Leap Micro as a separate distribution. Its functionality is now incorporated into Leap 16.1, giving administrators a unified platform for desktops, conventional servers, container hosts, virtual machines, and edge computing environments. Users can select the installation model that best fits their workloads without switching to an entirely different openSUSE product.

Beyond the new installation architecture, Leap 16.1 updates KDE Plasma to version 6.6, retains GNOME 48 with additional maintenance fixes, introduces LXQt 2.4, and continues using the Linux 6.12 long-term support kernel series. The release also expands container tooling, improves system monitoring, updates security components, and introduces changes designed to make enterprise-oriented Linux deployments more predictable.

Immutable Mode Becomes the Defining Feature of Leap 16.1

The most important addition to openSUSE Leap 16.1 is its new Immutable Mode, which allows the operating system to use a read-only root filesystem and transactional updates. Instead of modifying the active operating system directly whenever packages are installed or updated, the immutable configuration prepares changes in a separate filesystem snapshot.

This approach differs from a conventional Linux installation, where package managers typically modify files in the active root filesystem. On a traditional system, an update can replace libraries, executables, and configuration components while applications continue running. Although Linux package managers handle these operations carefully, interrupted updates or incompatible package combinations can sometimes leave a system in an inconsistent state.

Immutable Mode reduces this risk by preparing operating-system changes separately from the currently running environment. Updates become active after a reboot, allowing the system to start using a consistent set of packages and configuration changes. If an update introduces problems, administrators can return to an earlier snapshot rather than manually reversing individual package modifications.

The underlying technology is not entirely new to openSUSE. Similar functionality has been available through Leap Micro, which was designed for lightweight, transactionally updated server and infrastructure deployments. What changes in Leap 16.1 is that this operating model becomes an installation choice within the main Leap distribution.

Traditional and Immutable Installations Now Share One Platform

Historically, openSUSE users selected different products depending on whether they wanted a conventional operating system or a more specialized immutable environment. Leap provided a familiar general-purpose Linux installation, while Leap Micro focused on container hosts, virtual machines, and other infrastructure workloads where controlled updates and minimal maintenance were priorities.

Leap 16.1 combines these approaches under a single release. Users who prefer the conventional model can continue installing a standard system with a writable root filesystem and familiar package-management workflows. Those who want a more controlled operating environment can select Immutable Mode and manage system changes transactionally.

This unification also simplifies maintenance planning. Instead of following separate release schedules and support policies for Leap and Leap Micro, administrators can use the same Leap release family for both installation models. The openSUSE Project has confirmed that Leap 16.1 in Immutable Mode succeeds Leap Micro 6.2, with no separate Leap Micro 6.3 release planned.

The distinction remains important because the two modes serve different operational needs. A traditional installation offers flexibility for frequent package changes and direct system customization, while an immutable installation prioritizes predictable updates, rollback capabilities, and a more tightly controlled base operating system.

Neither approach is universally better. The appropriate choice depends on whether the system is being used as an interactive workstation, a general-purpose server, a container host, or a specialized appliance.

Agama Makes Immutable Installation Available During Setup

The new installation mode is integrated into Agama, the installer introduced with the Leap 16 generation. Rather than requiring a separate installation image or a complicated post-installation conversion process, users can select their preferred operating-system model during setup.

Agama provides a modern installation workflow designed to support both interactive and automated deployments. In Leap 16.1, the installer offers a choice between a standard installation and Immutable Mode. The standard option creates a conventional Linux environment with a writable root filesystem, while the immutable option configures a read-only root and enables transactional system management.

An important limitation is that the installation mode cannot be changed after installation. Users who install a traditional system cannot simply enable Immutable Mode later through a configuration switch, and immutable installations cannot be converted directly into traditional installations through the installer.

This makes the initial selection particularly important for administrators planning long-term deployments. A development workstation that frequently requires direct modifications to system packages may be better suited to the traditional model, while an appliance or container host that benefits from controlled updates may be a stronger candidate for Immutable Mode.

Agama also supports automated installation profiles written in JSON or Jsonnet, allowing organizations to define repeatable system configurations. This is useful for deploying multiple machines with consistent storage layouts, user accounts, and operating-system settings.

Transactional Updates Change How Packages Are Installed

On a conventional openSUSE installation, administrators typically use zypper to install packages and apply updates directly to the active operating system. Immutable Mode introduces a different workflow based on the transactional-update utility.

The tool prepares system changes in a new snapshot instead of modifying the currently running root filesystem. Once the operation completes, a reboot activates the updated snapshot.

To perform a distribution update on an immutable Leap installation, administrators can use:

sudo transactional-update dup
sudo reboot

The first command prepares the updated system in a new snapshot, while the second restarts the machine into that environment. The currently running system remains separate from the prepared update until the reboot occurs.

Additional RPM packages can also be installed transactionally. For example, an administrator who needs the htop system-monitoring utility can run:

sudo transactional-update pkg install htop
sudo reboot

This allows the package to become part of the updated operating-system snapshot without directly modifying the active root filesystem.

The approach introduces a different maintenance rhythm. Instead of treating every package installation as an immediate modification to the running system, administrators prepare changes, activate them through a reboot, and verify the resulting environment.

Snapshot Rollbacks Provide a Recovery Mechanism

One of the main advantages of transactional updates is the ability to recover from an unsuccessful system change. Because updates are associated with filesystem snapshots, administrators can return to a previous state when a new package version or configuration introduces a problem.

On an immutable Leap installation, the rollback process can be initiated with:

sudo transactional-update rollback
sudo reboot

The rollback command selects a previous system snapshot, while the reboot activates it. This provides a practical recovery mechanism for problems introduced by operating-system updates.

For example, a server might receive an update that changes a critical library or introduces a compatibility problem with a deployed application. Rather than manually downgrading several packages, the administrator can restore the earlier system snapshot and investigate the update separately.

Rollback capabilities do have limits. They are not substitutes for backups, and they do not necessarily restore application data stored in writable locations such as /var or user files stored under /home. Database contents, container volumes, and other persistent data still require appropriate backup and recovery procedures.

Nevertheless, transactional updates can significantly simplify operating-system recovery, particularly when administrators need to manage large numbers of machines with consistent configurations.

Leap Micro Users Gain a New Migration Path

With Leap Micro functionality now integrated into Leap 16.1, existing Leap Micro 6.2 users have a path toward the new unified distribution. The openSUSE Project provides migration support through the opensuse-migration-tool, allowing administrators to move compatible installations toward Leap 16.1 in Immutable Mode.

The migration process remains experimental, making preparation especially important. Administrators should create reliable backups and review the proposed changes before proceeding, particularly when the system hosts containers, virtual machines, or production services.

For users who prefer a fresh deployment, openSUSE also provides dedicated immutable installation images. These include self-installing images intended for USB-based installations, along with preconfigured images for virtual machines and other infrastructure environments.

The available formats cover platforms such as KVM, Xen, Microsoft Hyper-V, VMware, Harvester, and cloud deployments. Fully encrypted raw disk images are also available for users with specific storage-security requirements.

First-boot configuration remains available through Ignition and Combustion, two technologies familiar to Leap Micro administrators. These tools allow systems to apply predefined settings during their initial startup, making them useful for automated infrastructure deployments.

Containers Become the Preferred Application Environment

Immutable operating systems encourage a separation between the base system and the applications running on top of it. Instead of installing every development tool or application directly into the root filesystem, users can place additional software inside containers.

openSUSE Leap 16.1 supports this model through tools such as Podman, Distrobox, and Flatpak. Podman provides container management capabilities suitable for development and infrastructure workloads, while Distrobox makes it easier to create interactive Linux environments based on other distributions.

For example, users can create a Debian-based development environment through Distrobox:

distrobox create --name debian-dev --image debian:stable

After creating the environment, they can enter it with:

distrobox enter debian-dev

Inside the container, developers can install packages and experiment with software without modifying the immutable host operating system. This is particularly useful when a project requires tools or library versions that differ from those provided by Leap.

Distrobox is now preinstalled by default in Leap 16.1, replacing the older Toolbox utility. It supports integration with the host's home directory, graphical applications, audio devices, and other desktop resources, making containerized development environments more convenient.

Containers are not complete security boundaries by default, and their isolation depends on configuration and permissions. Their main advantage in this context is operational flexibility: applications can change independently while the underlying operating system remains comparatively stable.

KDE Plasma 6.6 Brings a Newer Desktop Experience

Desktop users also receive meaningful software updates in Leap 16.1. The distribution upgrades KDE Plasma from the 6.4 series used in Leap 16.0 to KDE Plasma 6.6, bringing a newer generation of KDE's customizable Linux desktop environment.

The update is accompanied by Qt 6.11 and KDE Frameworks 6.25, providing a more recent application framework and supporting libraries. These components are important because Plasma relies on Qt and KDE Frameworks for interface rendering, application integration, and many of its underlying desktop services.

Although openSUSE Leap does not follow KDE's newest releases as aggressively as a rolling distribution such as Tumbleweed, moving to Plasma 6.6 provides a substantial update within Leap's more conservative software-maintenance model.

For users who want a KDE desktop with a longer support lifecycle, Leap 16.1 offers a balance between modern features and a relatively stable software foundation. The distribution continues to emphasize predictable updates rather than replacing major desktop components as soon as upstream releases become available.

Users can inspect their installed Plasma version with:

plasmashell --version

This command is useful after upgrading because it confirms which Plasma Shell version is installed on the system.

GNOME 48 Remains Available With Maintenance Fixes

While KDE receives a major version update, GNOME remains on the GNOME 48 series in Leap 16.1. The distribution includes maintenance improvements within that branch, including a newer GNOME Shell version than the one provided by Leap 16.0.

This decision reflects openSUSE Leap's approach to desktop stability. Rather than introducing a new GNOME generation in every annual minor release, the project maintains a desktop version across multiple releases while incorporating appropriate fixes.

For users who prioritize a consistent GNOME environment, this can reduce the disruption associated with major desktop upgrades. Extensions, workflows, and application behavior are less likely to change dramatically when the underlying desktop remains within the same major version.

Leap 16.1 also updates LXQt to version 2.4, while the LXQt Wayland session advances to version 0.4. The installer does not yet offer LXQt as a standard desktop selection, but users can install it after setting up the operating system.

An experimental Xfce Wayland session is also available, based on Xfce 4.20. This reflects the broader transition toward Wayland across Linux desktop environments, although experimental sessions may still have limitations compared with established configurations.

Linux 6.12 LTS Continues as the Kernel Foundation

openSUSE Leap 16.1 continues using the Linux 6.12 long-term support kernel series rather than adopting the newest mainline kernel generation. This is consistent with the distribution's focus on enterprise compatibility, predictable maintenance, and long-term stability.

Long-term support kernels receive ongoing fixes without requiring distributions to adopt every architectural change introduced in newer kernel releases. For enterprise-oriented systems, this can reduce compatibility risks involving hardware drivers, third-party kernel modules, and applications that depend on stable operating-system behavior.

However, remaining on an LTS kernel does not mean that Leap receives no newer kernel functionality. SUSE can incorporate selected improvements and backports into its maintained kernel packages while preserving the broader compatibility expectations associated with the enterprise platform.

Users can inspect their currently running kernel with:

uname -r

The result identifies the active kernel version, including any distribution-specific release information. As with other Linux distributions, installing a kernel update normally requires a reboot before the new kernel becomes active.

Leap 16.1 also introduces improvements to scheduling behavior, including a transition toward the PREEMPT_LAZY preemption model. This approach allows the kernel to balance responsiveness and scheduling overhead in a way suited to modern workloads.

Pressure Stall Information Is Enabled by Default

A notable system-monitoring change in Leap 16.1 is the decision to enable Pressure Stall Information (PSI) by default. PSI provides metrics that describe how much time tasks spend waiting for CPU, memory, or I/O resources.

Traditional monitoring tools often report utilization percentages, memory consumption, and disk activity. While these metrics are useful, they do not always reveal how much resource contention is delaying applications.

PSI addresses this problem by measuring resource pressure directly. For example, a system might show high CPU utilization without experiencing severe contention, while another system could suffer noticeable delays because tasks frequently wait for memory reclamation or storage operations.

Linux exposes PSI information through files under /proc/pressure/. Administrators can inspect CPU pressure using:

cat /proc/pressure/cpu

Memory and I/O pressure can be examined with:

cat /proc/pressure/memory
cat /proc/pressure/io

These interfaces provide metrics that monitoring systems can use to identify resource contention and understand performance problems more accurately.

Leap 16.1 enables PSI collection by default, allowing tools such as sysstat to consume the information without requiring administrators to activate the feature manually. The project reports negligible overhead for most workloads, although certain scheduling-intensive microbenchmarks may experience a measurable performance cost.

For specialized workloads where PSI overhead becomes problematic, administrators can disable the feature through the psi=0 kernel boot parameter.

Security Defaults Continue Emphasizing SELinux

openSUSE Leap 16.1 retains SELinux as its default Linux Security Module for new installations. SELinux provides mandatory access controls that restrict what processes can access, even when ordinary Unix file permissions would otherwise allow an operation.

This approach can limit the damage caused by compromised applications or services. For example, a web server process may be restricted from accessing unrelated files or system resources, even if an attacker gains control over that process.

Leap also includes AppArmor 4.1, although AppArmor is not the default security module for new installations. Users who require AppArmor can enable it after installation, while certain migration paths preserve existing AppArmor configurations.

Administrators can inspect the active SELinux enforcement state with:

getenforce

A result of Enforcing indicates that SELinux policies are actively enforced. Permissive means policy violations are logged without being blocked, while Disabled indicates that SELinux enforcement is not active.

The distribution also updates security-related utilities and package defaults. For example, firewalld is enabled by default across traditional and immutable installation modes, providing a more consistent network-security configuration.

Unified systemd Presets Simplify Administration

Leap 16.1 brings traditional and immutable installations closer together by unifying their systemd service presets. These presets determine which services should be enabled by default when the operating system is installed.

Previously, the two installation models could have different default service configurations, reflecting their separate development histories. With Leap Micro now integrated into Leap, maintaining inconsistent service defaults would create unnecessary differences between systems that otherwise share the same distribution.

The updated presets align services such as firewalld, chronyd, display management components, virtualization helpers, and cloud-related infrastructure where appropriate. Services directly associated with transactional updates remain specific to immutable installations.

This makes administrative behavior more predictable across different deployment types. An organization running both traditional Leap servers and immutable container hosts can expect more consistent defaults, reducing the need for separate configuration policies.

Administrators can inspect the state of a service using:

systemctl status firewalld

They can also determine whether a service is enabled to start automatically:

systemctl is-enabled firewalld

These commands help verify the actual configuration of an installed system, which remains important because package selection and administrative changes can affect service state.

AppArmor, SELinux, and Other Security Changes

Beyond the default security module, Leap 16.1 incorporates additional security improvements across its software stack. AppArmor advances to version 4.1, introducing policy capabilities such as priority-based rule handling.

The distribution also updates util-linux to address several security vulnerabilities involving mount operations. These corrections tighten the handling of filesystem paths and restrict certain mount behaviors available to unprivileged processes.

The changes are intended to prevent privilege escalation and time-of-check-to-time-of-use race conditions. Such vulnerabilities can occur when a program validates a filesystem path and then operates on it after another process has changed the underlying filesystem state.

For administrators, the practical consequence is that some previously accepted mount operations may now be rejected. Systems relying on unusual unprivileged mount workflows should be tested carefully before upgrading.

Leap 16.1 also improves certificate trust integration by preferring p11-kit-nss-trust for new installations of Mozilla NSS components. This allows applications using NSS to inherit centrally managed certificate authorities more consistently, which can simplify enterprise certificate management.

New Container and Virtualization Capabilities

The integration of Immutable Mode makes Leap 16.1 particularly relevant to container and virtualization deployments. Systems designed primarily to run containers benefit from a stable host operating system that can be updated predictably while applications remain isolated in separate environments.

Podman provides the container runtime, while Distrobox supports interactive development environments. Leap 16.1 also includes improvements to kernel behavior involving CPU-restricted containers and shared kernel locks.

Under certain conditions, a container constrained by CPU limits could previously hold a critical kernel lock while being throttled. Other containers waiting for that lock could experience delays even when they had sufficient CPU resources available.

The updated kernel behavior avoids throttling tasks while they hold certain critical locks, reducing the possibility that CPU restrictions on one workload will interfere unnecessarily with unrelated containers.

This change is particularly valuable for environments running multiple services with different resource limits. It improves workload isolation at the scheduler level without requiring administrators to redesign their container configurations.

Leap 16.1 also expands virtualization support, including improvements to virtual machine provisioning and support for virtual persistent memory in compatible guest environments.

A Real-Time Kernel Option Expands Specialized Workloads

Another addition in Leap 16.1 is support for a real-time kernel intended for workloads requiring more predictable scheduling latency. Real-time Linux configurations are useful in environments such as industrial automation, specialized data acquisition, audio processing, and other systems where timely responses can be more important than maximum overall throughput.

The real-time kernel maintains a separate kernel application binary interface from the standard Leap kernel. This distinction matters for third-party kernel modules, which may need to be built specifically for the real-time configuration.

NVIDIA drivers are not currently available for Leap 16.1's real-time kernel because the supported packages target the default kernel. Users requiring NVIDIA graphics acceleration should therefore verify their hardware and driver requirements before choosing the real-time kernel.

The presence of a real-time option expands Leap's suitability for specialized systems, but it does not mean ordinary desktop users should switch to it. Real-time kernels involve different scheduling tradeoffs and are best selected when an application has a specific need for predictable latency.

The x86-64-v2 Requirement Remains in Place

openSUSE Leap 16.1 continues using the x86-64-v2 CPU architecture baseline introduced with Leap 16.0. This requirement means the distribution expects processors to support a defined collection of instruction-set extensions beyond the original x86_64 specification.

The newer baseline allows software maintainers to target a more capable minimum processor architecture, potentially simplifying optimization and compatibility decisions. However, it also means some older 64-bit processors cannot run Leap 16.1.

Users considering an upgrade should verify that their hardware meets the requirement, particularly when working with older desktops, servers, or virtual machines configured to expose a limited CPU feature set.

On Linux, available processor features can be inspected with:

lscpu

For more detailed information, administrators can examine the CPU flags reported by the kernel:

grep -m1 '^flags' /proc/cpuinfo

These commands provide information about the processor features visible to the operating system. However, users should consult the distribution's compatibility requirements rather than relying on the presence of a single instruction flag.

For hardware that does not meet Leap's newer baseline, openSUSE Tumbleweed or Slowroll may provide alternative options, depending on the specific processor and current distribution requirements.

32-Bit Compatibility Remains Disabled by Default

Leap 16.1 continues the policy introduced with the Leap 16 generation of disabling conventional 32-bit application compatibility by default. This reflects the distribution's emphasis on modern 64-bit software and a reduced compatibility footprint.

However, 32-bit support has not been removed entirely. Users who require legacy applications or gaming software can enable the necessary compatibility components.

This is particularly relevant to Steam, which has historically depended on selected 32-bit libraries. The Steam package is no longer provided through Leap's Non-OSS repository, and users are instead encouraged to install it through Flatpak.

On systems that require 32-bit execution support, the grub2-compat-ia32 package can be installed, followed by a reboot. Depending on the system's SELinux configuration, gaming-related policy packages may also be necessary.

Users should review these requirements before installing Steam or other software that depends on 32-bit components. The change does not mean Linux gaming is unsupported, but it does introduce additional configuration considerations compared with distributions that enable 32-bit compatibility by default.

How to Upgrade From openSUSE Leap 16.0

Existing Leap 16.0 users can upgrade to Leap 16.1 using the official openSUSE Migration Tool. The project recommends previewing the planned changes before performing the migration.

First, install the migration utility:

sudo zypper install opensuse-migration-tool

Next, perform a dry run to inspect the proposed upgrade:

sudo opensuse-migration-tool --dry-run

The dry run allows administrators to identify potential repository, dependency, or package changes before modifying the system.

If the proposed migration is appropriate, the upgrade can be started with:

sudo opensuse-migration-tool

After the migration completes, reboot the system:

sudo reboot

Before beginning, users should back up important data and review any third-party repositories or manually installed packages. Systems running production services should also be tested in a nonproduction environment when practical.

The migration tool handles the distribution upgrade, but it does not convert a traditional installation into Immutable Mode. Users who want to change installation models should plan a fresh installation using the desired mode.

Leap 16.1 Continues the Distribution's Longer Support Strategy

The Leap 16 generation introduced a longer maintenance model intended to make the distribution more attractive for users who value predictable upgrade schedules. Each minor release is expected to receive approximately 24 months of community maintenance, with new minor versions arriving annually.

This creates an overlapping support structure in which users have time to evaluate a new release before upgrading. Rather than being forced to migrate immediately when a successor becomes available, administrators can schedule testing and deployment around their operational requirements.

The current roadmap anticipates annual Leap 16 releases through version 16.6 in 2031. Longer-term plans may change, but the strategy establishes a clearer direction for users planning desktop and server deployments over multiple years.

Leap continues sharing a closely aligned software foundation with SUSE Linux Enterprise, allowing organizations to develop and test workloads on the community distribution before considering enterprise deployments.

Although Leap 16.1 was released on November 3, 2026, the corresponding SUSE Linux Enterprise Server 16.1 release is expected later in November rather than having shipped on the same day.

What the Release Means for Linux Users

For desktop users, Leap 16.1 provides a refreshed software environment without abandoning the distribution's emphasis on stability. KDE Plasma 6.6 offers a newer desktop stack, GNOME 48 continues receiving maintenance fixes, and LXQt 2.4 expands the available lightweight desktop options.

For developers, the addition of Distrobox by default makes it easier to work with different Linux environments without changing the host operating system. This is particularly valuable on immutable installations, where containers provide a convenient way to install development tools and experiment with software independently of the base system.

For system administrators, the most important development is the consolidation of traditional and immutable deployments. A single release family can now support conventional servers, container hosts, virtual machines, and specialized infrastructure while offering different update models suited to each environment.

The combination of transactional updates, filesystem snapshots, automated installation, and standardized service presets makes Leap 16.1 especially interesting for organizations seeking more predictable Linux infrastructure management.

Conclusion

openSUSE Leap 16.1 represents a significant evolution of the distribution's installation and maintenance model, combining traditional Linux deployments with an integrated immutable operating system option. Released on November 3, 2026, the update brings Leap Micro's transactional approach into the main Leap distribution, allowing users to choose between a writable root filesystem and a read-only system managed through snapshots.

The new Immutable Mode is the release's defining feature. Through Agama, users can select the appropriate installation model, while transactional-update provides controlled package changes and rollback capabilities. Podman, Distrobox, and Flatpak complement this approach by allowing applications and development environments to evolve independently of the underlying operating system.

The release also delivers meaningful software improvements, including KDE Plasma 6.6, LXQt 2.4, continued GNOME 48 maintenance, and the Linux 6.12 LTS kernel. Security and infrastructure updates strengthen SELinux integration, system monitoring, container scheduling, service management, and automated deployment capabilities.

For existing Leap Micro users, the transition establishes a unified future within the Leap release family. Traditional Leap users, meanwhile, retain the familiar installation and package-management model while gaining access to a more flexible platform.

By bringing both operating models together, openSUSE Leap 16.1 positions itself as a distribution capable of supporting conventional Linux desktops and servers alongside modern container-focused infrastructure. Its most important achievement is not simply offering another installation option, but making immutable system management part of a broader, long-term Linux platform.