*Figure: openSUSE Leap 16 official branding artwork, from the openSUSE wallpapers project — not a live desktop screenshot.*
openSUSE Leap 16.1 entered its Release Candidate phase on 28 September 2026, and the headline item is not a version bump. It is the first time a regular openSUSE Leap release ships with an **Immutable Mode**: a transactionally updated system with a read-only root filesystem. The release goes fully available on **3 November 2026**, deliberately aligned with SUSE Linux Enterprise Server 16.1 so that there is no gap in maintenance updates after launch.
That single feature quietly reorganises the whole openSUSE family. Leap 16.1 in Immutable mode **replaces Leap Micro** outright — there will be no Leap Micro 6.3 or 7.0 — and the familiar MicroOS appliance images move to a corner of the Leap 16.1 download page. If you have been running Leap Micro for container hosts, edge boxes or immutable VMs, your upgrade path now runs through Leap proper.
Official downloads and release candidate images live at **https://get.opensuse.org/leap/16.1/**. The project publishes roughly one build per week during the RC phase, so the image you test today will not be the image you ship on release day.
## What Immutable Mode actually is
The name does a lot of work here, so it is worth being precise about the mechanics.
The root filesystem is mounted read-only and is never modified in place. When you update the system, `transactional-update` does not overwrite files. It builds a **new snapshot** of the whole system on top of the existing base, and the machine boots into that snapshot. Because the previous snapshot is still sitting there intact, rolling back is a single command rather than a recovery exercise.
*Figure: AI-generated illustration of the snapshot stack — not an official openSUSE screenshot.*
This is not a new idea for SUSE — it is what Leap Micro and the SUSE Linux Enterprise ALP lineage have done for years. What is new in Leap 16.1 is that it is exposed as an install-time choice inside the regular Leap installer, with the standard package-managed system still available as the alternative.
The openSUSE project has explicitly asked people to test it. The Immutable mode was only recently added to Agama, which is exactly why the team wants early feedback before the 3 November freeze.
## Picking the mode in the installer
You boot the ordinary Leap 16.1 installation image and choose **Immutable mode** in Agama. No special appliance image is required for a normal workstation install, which is a genuine change from the Leap Micro workflow where you picked a dedicated raw image per deployment type.
*Figure: The Agama mode selection screen for Leap 16.1 RC, with the Immutable option selected. Official screenshot from the openSUSE project.*
The Agama interface itself is worth noting, because it has replaced the old text-mode installer across recent Leap builds. It runs in a browser-style UI with a dark theme, handles localisation and keyboard layout from the top-right corner, and drives the whole install flow — partition, users, networking, packages — through one consistent surface.
## The three-command update loop
Once installed, the day-to-day update cycle is short enough to memorise:
“`bash
sudo transactional-update dup # update the system into a new snapshot
sudo reboot # boot into the new snapshot
sudo transactional-update rollback # go back if something went wrong
“`
`dup` creates a new snapshot, `reboot` moves you onto it, and `rollback` drops you back to the previous one if the new snapshot misbehaves. The rollback is fast because nothing is being recomputed — the old snapshot was never touched.
*Figure: Author-made diagram of the transactional-update workflow, not an official openSUSE screenshot. It is drawn from the Leap 16.1 RC announcement of 28 September 2026.*
Note the deliberate separation: `dup` and `rollback` are run inside a `transactional-update` shell, not directly against the live system. A plain `zypper` invocation on the host will not modify the running root filesystem, because it is read-only.
## Where software comes from
This is the part that trips up people moving from a traditional distro. If the root filesystem is read-only, then a traditional `zypper install` has nowhere to write. openSUSE’s answer is a three-way split:
– **Flatpak** for desktop applications, which is the recommended path on graphical installs.
– **Podman or Distrobox** for containers and containerised apps — this is the natural fit for the immutable crowd.
– **Traditional RPM packages** still work, but they go through `transactional-update pkg install <package>`, which stages them into the next snapshot.
“`bash
sudo transactional-update pkg install
In practice this produces a system where the base layer is genuinely clean and rollback is instant, at the cost of a slightly different mental model than “install it and it is there forever”.
## Leap Micro appliances still exist
Users coming from Leap Micro will find the familiar preconfigured images under **alternative downloads** on the Leap 16.1 page. The list still includes the Immutable Self-install image (recommended for USB installations), plus images for KVM/Xen, Microsoft Hyper-V, VMware, Harvester and Cloud, and a fully encrypted raw disk image.
As with Leap Micro, these appliances are configured on first boot via **Ignition** or **Combustion**, so the declarative first-boot configuration model carries over unchanged.
## Migrating an existing Leap Micro 6.2 install
There is an experimental migration tool, `opensuse-migration-tool`, for moving a Leap Micro 6.2 system onto Leap 16.1 in Immutable mode:
“`bash
sudo transactional-update shell
# Inside the shell:
zypper in opensuse-migration-tool
opensuse-migration-tool –dry-run # check what it would do
opensuse-migration-tool
exit && reboot # boot into the new snapshot
“`
The tool is explicitly still experimental. Back up before you run it, and report your result to the project — the developers are actively looking for migration feedback.
## Desktops: same GNOME, newer Plasma
Some users expected a large GNOME jump in Leap 16.1 and will not get one. Leap 16.1 ships the same **GNOME 48** as Leap 16.0, with bug fixes only (`gnome-shell` moves from 48.4 to 48.8). That is a deliberate pattern inherited from the SUSE Linux Enterprise 15 service-pack model, where major desktop updates are spread across two releases.
KDE Plasma users do get a more substantial upgrade:
| Component | Leap 16.0 | Leap 16.1 |
|—|—|—|
| KDE Plasma | 6.4 | 6.6 |
| Qt | — | 6.11 |
| KDE Frameworks | — | 6.25 |
| LXQt | 2.2 | 2.4 |
| Xfce (Wayland) | 4.20 | 4.20 |
## Checking exact package versions
Leap has a new web tool at **https://opensuse.github.io/osdiff/** that compares source package versions across Leap 16.1, Leap 16.0, Tumbleweed and the latest upstream versions from Repology. You can filter by status — for example, packages that changed relative to Leap 16.0 — and download the comparison data as JSON. It is a quick way to answer “is that package actually newer in 16.1?” without waiting for the full release notes.
For the kernel specifically, remember that Leap’s core comes from SUSE: Leap 16.0 shipped kernel 6.12 inherited from SLE 16.0, and the 16.1 kernel line follows the SLE 16.1 base rather than tracking Tumbleweed. The exact build depends on the final SLES 16.1 freeze, so check `uname -r` on the running system rather than assuming.
## Verdict
openSUSE Leap 16.1 is a smaller release than the marketing suggests and a more consequential one. The desktop story is incremental — the same GNOME, a fresher Plasma — and most of the underlying packages still come from the SLE 16 base. The real change is architectural: Leap now offers transactional updates with one-command rollback as a first-class install option, the Leap Micro line is folded into it, and the whole openSUSE family gets a single immutable story instead of a separate appliance distribution.
If you want that rollback safety on a workstation or server today, the RC is the moment to try it — the project is asking for feedback, and a weekly build cadence means you can exercise the upgrade path more than once before November. If you want the traditional mutable Leap experience, that is still one radio button away in Agama, and nothing about your existing zypper workflow changes.
Official project page: **https://get.opensuse.org/leap/16.1/**
Comments