Leap 15.6 stopped getting updates on April 30, 2026, so a box still on it is running unpatched. You can upgrade openSUSE Leap 15 to 16 in place with opensuse-migration-tool, and since Leap 16.1 went GA the tool offers it as a target next to 16.0. Pick 16.1 and you skip a second upgrade later.
This guide covers both jobs people search for. The main path takes a Leap 15.6 server straight to 16.1 with the migration tool. A shorter section moves an existing Leap 16.0 install to 16.1 with one zypper --releasever 16.1 dup, including the Packman repo that breaks on every minor upgrade. Both paths were run in November 2026 on the official Leap 15.6 and 16.0 VM images, on the day openSUSE Leap 16.1 was released, and every screen below comes from those two machines.
Check the system before you upgrade openSUSE Leap 15 to 16
Four things decide whether the upgrade is clean or painful, and the tool only checks one of them for you. Go through them before you install anything:
- a fully patched Leap 15.6 (not 15.5 or older)
- a CPU with the x86-64-v2 flags
- a rollback point: a Snapper snapshot on Btrfs, a VM snapshot on anything else
- a list of your third-party repos (Packman, NVIDIA, OBS home projects)
Leap 16 raised the CPU baseline to x86-64-v2. The tool checks for it, but only after you pick a target, by which point it has already reinstalled openSUSE-repos and disabled your third-party repos, so check first. /lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v2 should print x86-64-v2 (supported, searched), as it did on our VMs. The rollback point matters more than people think. Agama installs and most Minimal VM images use Btrfs with Snapper, but the Cloud flavour of the Minimal VM image (the one we tested on) puts root on XFS, so it has no Snapper to fall back on and you need a snapshot from the hypervisor. Third-party repos are the usual reason a zypper dup fails, which is why the tool offers to switch them off.
Budget 15 to 60 minutes. Our minimal 15.6 server finished the whole migration in a little over five minutes, but a desktop pulls far more packages. You need root and working access to download.opensuse.org and get.opensuse.org, because the tool reads its list of targets from the get.opensuse.org API. If you would rather start clean, a fresh openSUSE Leap 16 install takes about the same time.
Update Leap 15.6 to the latest patch level
Start the migration from a known-good state. Refresh the repositories and install every pending update first:
sudo zypper ref
sudo zypper upIf the update pulled in a new kernel, as it did on our image, reboot before you go further. Then confirm the release and kernel you’re starting from:
hostnamectl | grep -E "Operating|Kernel"You should see Leap 15.6 on the 6.4 kernel series:
If the kernel line still shows an older build than the one you just installed, you skipped the reboot. Do it now, because the migration replaces the kernel and it’s easier to debug one change at a time.
Install the openSUSE migration tool
The tool ships in the regular Leap 15.6 repositories, so one command pulls it in:
sudo zypper install opensuse-migration-toolIt installs to /usr/sbin, which is not on a regular user’s PATH, so call it through sudo. Run it once in dry-run mode first. That prints every command it would execute, including the repository swap and the final zypper dup, without changing anything:
sudo opensuse-migration-tool --dry-runExpect commands, not a package list, from the dry run. You’ll see the full transaction, with counts and download size, only when zypper computes it during the real run.
Run the migration to Leap 16.1
Start the tool for real:
sudo opensuse-migration-toolIt asks get.opensuse.org which releases are still supported and lists the ones newer than yours. From 15.6 that’s SUSE Linux Enterprise 15 SP6, Tumbleweed, Tumbleweed-Slowroll, Leap 16.1 and Leap 16.0. Press 4 to jump to openSUSE Leap 16.1 and confirm with OK:
Choose 16.1 unless you have a reason to stop at 16.0. Both are marked stable in the API, and going to 16.0 now only means running a second zypper dup later. The entry numbers come from the API, so check the label rather than the number on your screen. If you want the enterprise route instead, the SUSE Linux Enterprise Server guide covers what you would be moving to.
Next the tool scans your enabled repositories and flags any alias it doesn’t recognize. This is the step that matters. Our test box had Packman enabled with its hard-coded openSUSE_Leap_15.6 URL, and leaving it on would mix 15.6 builds into a 16.1 system. Keep the flagged repos ticked so the tool disables them:
After you confirm, the tool installs the Leap 16.1 repository definitions and runs zypper --releasever 16.1 dup with the download done in advance. The summary it prints is your last chance to read what changes:
Read the line with the counts. On this minimal server it was 280 upgrades, 143 new packages, 123 removals and 7 architecture changes, for a 221.3 MiB download. The 123 removals look alarming but they are expected: Leap 16 drops Python 3.11, Ruby 2.5 and a batch of other 15.x-era packages the 15.6 image carried. Let it run without interrupting it, since cancelling during the install phase is what leaves a mixed system.
Choose the post-migration tasks
When the package transaction finishes, the tool shows a short checklist of optional changes. Nothing is ticked by default, so press Space on the ones you want before you hit OK:
The security module is the real decision. Leap 16 uses SELinux in enforcing mode by default, but a migrated 15.x system keeps AppArmor unless you pick 10_keepselinux. Take SELinux unless you have AppArmor profiles you can’t live without, because a fresh Leap 16 install no longer offers AppArmor and that’s the setup the rest of the platform is tested with. 20_ia32 only matters for 32-bit software such as Steam. On a machine that still runs PulseAudio, the package also ships a 20_pulse2pipewire task. It did not show on our minimal server because PulseAudio was not installed.
We ticked SELinux. The tool installed the targeted policy and selinux-autorelabel, dropped the AppArmor boot options and printed Migration process completed. A reboot is recommended. The relabel runs on the next boot, so that first boot takes longer than usual. Reboot now:
sudo rebootExpect one scary-looking message in the scrollback before you get there, covered next.
error: Key 70af9e8139db7c82 (SuSE Package Signing Key) expired
Halfway through the transaction our run started printing this line, 306 times in total, from around package 195 of 491 onwards:
error: Key 70af9e8139db7c82 (SuSE Package Signing Key <[email protected]>) expired on 2024-09-20 08:21:47It looks fatal and it is not. The new rpm from Leap 16 checks the old SLE 15 key still sitting in the keyring and complains that it has expired, but every package still reported done, the run exited 0, and the message did not come back after the reboot. If you want the keyring tidy, list the keys with rpm -q gpg-pubkey --qf "%{NAME}-%{VERSION}-%{RELEASE} %{SUMMARY}\n" and remove the expired one, which was gpg-pubkey-39db7c82-5f68629b on our box, with sudo rpm -e.
Verify the upgrade to Leap 16.1
After the reboot, confirm the release, the kernel and the security module in one go:
hostnamectl | grep -E "Operating|Kernel"
sudo sestatus | grep -E "status|mode"The system now reports Leap 16.1 on the 6.12 kernel, with SELinux enabled and enforcing because we took that task:
For other ways to check the distribution and kernel version, /etc/os-release and uname -r work the same on Leap 16. Next, list the repositories with their URLs to make sure nothing still points at 15.6:
zypper lr -uThe official repos now come from the openSUSE service and carry the 16.1 label. The 15.6 update repos are gone, because Leap 16 has no separate update repo. Packman is still there, switched off and still pointing at the 15.6 tree:
# | Alias | Name | Enabled | GPG Check | Refresh | URI
--+-----------------------------+---------------------------+---------+-----------+---------+-------------------------------------------------------------------------
1 | openSUSE:repo-non-oss | repo-non-oss (16.1) | No | ---- | ---- | http://cdn.opensuse.org/distribution/leap/16.1/repo/non-oss/x86_64
2 | openSUSE:repo-non-oss-debug | repo-non-oss-debug (16.1) | No | ---- | ---- | http://cdn.opensuse.org/debug/distribution/leap/16.1/repo/non-oss/x86_64
3 | openSUSE:repo-openh264 | repo-openh264 (16.1) | Yes | (r ) Yes | Yes | https://codecs.opensuse.org/openh264/openSUSE_Leap_16
4 | openSUSE:repo-oss | repo-oss (16.1) | Yes | (r ) Yes | Yes | http://cdn.opensuse.org/distribution/leap/16.1/repo/oss/x86_64
5 | openSUSE:repo-oss-debug | repo-oss-debug (16.1) | No | ---- | ---- | http://cdn.opensuse.org/debug/distribution/leap/16.1/repo/oss/x86_64
6 | openSUSE:repo-oss-source | repo-oss-source (16.1) | No | ---- | ---- | http://cdn.opensuse.org/source/distribution/leap/16.1/repo/oss
7 | packman | packman | No | ---- | ---- | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.6/Don’t just re-enable that Packman entry, because it would serve 15.6 builds. Remove it and add it back with $releasever in the URL, exactly as shown in the Packman step of the next section; on this box the new entry resolved to openSUSE_Leap_16.1 straight away. Re-adding the repo is not the whole fix if you had Packman packages installed. With Packman disabled, the tool’s --allow-vendor-change dup swaps them for the openSUSE builds: on a 16.0 test box with Packman’s ffmpeg, the tool’s run listed 9 packages are going to change vendor and ffmpeg-7 came out with the SUSE LLC vendor. Switch them back once Packman is enabled again:
sudo zypper dup --from packman --allow-vendor-changeThat installed 15 Packman packages (the nine ffmpeg libraries plus Packman’s builds of libraries such as libx264, libx265, libfdk-aac2 and libgbm1) and put ffmpeg-7 back on the http://packman.links2linux.de vendor; a second run printed Nothing to do. Your services carry across the upgrade with their data, but give anything stateful a quick check. A MariaDB server on openSUSE, for example, keeps its data directory and should start straight back up.
Upgrade Leap 16.0 to 16.1 with zypper dup
Moving from 16.0 to 16.1 is a minor upgrade: same kernel series, same systemd, and the same repository layout. The official repos already use ${releasever} in their URLs, so one zypper --releasever 16.1 dup does the whole job. The only thing that breaks is a third-party repo with the release number typed into its URL, and Packman, which the multimedia codecs guide adds, is the usual one.
Our test machine was the official Leap 16.0 VM image, fully patched with sudo zypper ref && sudo zypper up, with Packman added the old way (openSUSE_Leap_16.0 in the URL) and Packman’s ffmpeg-7 installed. Do the same patch run on yours first. Here is the order that worked:
- Take a rollback point
- Point Packman at
$releasever - Run
zypper --releasever 16.1 dup - Reboot and check
/etc/os-release
On Btrfs, zypper’s Snapper plugin takes the pre and post snapshots for you. Our Minimal VM Cloud image sits on XFS, so we shut it down and took a disk snapshot on the KVM host instead. On Proxmox or another hypervisor, use its snapshot button. On a plain qcow2 disk the command is:
qemu-img snapshot -c pre-16.1 leap01.qcow2Shut the VM down before you snapshot a qcow2 file this way, because the image must not be in use. qemu-img snapshot -l leap01.qcow2 lists it; boot the VM again once pre-16.1 shows up.
Point Packman at $releasever before the dup
With the URL left pinned, zypper --releasever 16.1 ref refreshes the official repos for 16.1 but reports Repository 'packman' is up to date against the 16.0 tree. The dup then keeps resolving Packman packages from 16.0 builds. Packman already publishes an openSUSE_Leap_16.1 tree, so replace the entry with one zypper fills in itself. The commands assume the alias packman; check yours in zypper lr first, since YaST and some guides name it differently. Keep the single quotes so your shell doesn’t expand $releasever:
sudo zypper removerepo packman
sudo zypper addrepo -cfp 90 'https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/' packman
zypper --releasever 16.1 lr -uZypper stores the literal variable in the repo file, and the listing shows it resolving to the 16.1 tree when you pass the new release:
When you first add Packman, zypper asks you to trust its key (fingerprint F887 5B88 0D51 8B6B 8C53 0D13 45A1 D067 1ABD 1AFB on our run). Once the variable is in place you never edit this entry again: the 16.2 upgrade will pick up its tree the same way.
Run zypper –releasever 16.1 dup
Refresh against the new release, then run the distribution upgrade. --download-in-advance is already zypper’s default; spelling it out makes sure every package is fetched before anything is replaced, even if your zypp.conf says otherwise:
sudo zypper --releasever 16.1 ref
sudo zypper --releasever 16.1 dup --allow-vendor-change --download-in-advanceRead the summary before you answer y. Ours showed the product moving from 16.0-1 to 16.1-1, a new kernel that needs a reboot, and a new x86_64_v3 pattern because the CPU supports it:
The 22 downgrades are the line that makes people stop, and here they’re harmless. Thirteen are openSUSE packages where the 16.1 repo carries a lower version-release than the 16.0 update installed on this box (acl, libexpat1, libldap-2, libpng16-16, python313, timezone and a few more). The other nine are Packman’s ffmpeg-7 libraries: its 16.0 tree had ffmpeg 7.1.5 while the 16.1 tree still had 7.1.4. Zypper lets a dup go to the target release’s version even when that version is lower. No vendor-change prompt appeared: a dry run without --allow-vendor-change came back clean, because openSUSE packages stay openSUSE and Packman stays Packman. We keep the flag because the migration tool passes it too, and it saves a stop if one of your repos does change vendor.
On a 2 vCPU VM the run fetched 310.0 MiB and was back at the prompt about six minutes after we started it. Reboot into the new kernel:
sudo rebootSELinux was already enforcing on the 16.0 image, so no relabel was pending and our VM answered on SSH again within a minute.
Check /etc/os-release and the Packman packages
Compare /etc/os-release and the running kernel with what you had before, and confirm the Packman build survived:
cat /etc/os-release
uname -r
rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n" ffmpeg-7 Leap-releaseVERSION_ID moved from 16.0 to 16.1 and the kernel from 6.12.0-160000.40 to 6.12.0-160100.8. ffmpeg kept the Packman vendor, which means it still has the full codec set and was not swapped for the reduced openSUSE build:
From now on you don’t need the flag. After the reboot zypper lr -u shows 16.1 on every repo, Packman included, because zypper reads the release from /etc/products.d/baseproduct, which the new Leap-release package installed. A sudo zypper ref with no options refreshed all three enabled repos cleanly on our box. SELinux stayed enforcing and systemctl --failed listed nothing.
Use the migration tool for 16.0 to 16.1 instead
If you would rather not type the commands, opensuse-migration-tool handles minor upgrades too. On Leap 16.0 its menu lists SUSE Linux Enterprise 16 SP0, both Tumbleweed flavours and openSUSE Leap 16.1:
Packman is where the two routes differ. The tool disables it instead of re-pointing it, and its dup then moves your Packman builds to the openSUSE vendor, so you get the reduced codec set until you add Packman back with $releasever and run the zypper dup --from packman step from the verify section. The manual dup with $releasever in the Packman URL is the shorter path, and it keeps the Packman builds through the upgrade. Once you’re on 16.1, the post-install checklist for Leap is worth a pass for anything a minimal image left out.
Compare the two upgrade runs
Both lab runs used the official openSUSE Minimal VM Cloud images on the same KVM host, which makes the numbers comparable:
| Leap 15.6 to 16.1 | Leap 16.0 to 16.1 | |
|---|---|---|
| Method | opensuse-migration-tool | zypper –releasever 16.1 dup |
| Upgraded / new / removed | 280 / 143 / 123 | 469 / 76 / 3 |
| Downgraded | 1 | 22 (incl. Packman ffmpeg) |
| Download | 221.3 MiB | 310.0 MiB |
| Wall time | about 5 min, incl. SELinux task | about 6 min |
| Kernel after | 6.12.0-160100.8 | 6.12.0-160100.8 |
| Packman after | disabled, still on 15.6 URL | enabled, resolved to 16.1 |
Our 16.0 box downloaded more because it carried ffmpeg-7 and the 117 packages it pulled in. The 15.6 box removed more because the jump to 16 drops a whole generation of libraries. What ends up identical is the kernel and the repo setup, so both machines are on the same footing for the next minor release.
See what the migration tool runs
The tool is a wrapper around plain zypper. This is the sequence its dry run printed for a Leap 16.1 target, with Packman flagged; the Leap branch of the script is the same whether you start on 15.6 or 16.0:
zypper install -y --force-resolution openSUSE-repos
zypper refresh-services
zypper --non-interactive modifyrepo -d packman
zypper addrepo -f https://download.opensuse.org/distribution/leap/16.1/repo/oss tmp-migration-tool-repo
zypper install --repo tmp-migration-tool-repo -y --force-resolution --from tmp-migration-tool-repo openSUSE-repos-Leap
zypper removerepo tmp-migration-tool-repo
zypper refresh-services
zypper --releasever 16.1 dup -y --force-resolution --allow-vendor-change --download-in-advanceInstalling openSUSE-repos-Leap from the target release is the part that matters on a 15.6 system, because it swaps the old static repo files for the service-managed ones that understand $releasever. Running only the last line on 15.6, without that swap, is how people end up with a broken mix of 15.6 and 16 packages. On 16.0 the repos are already service-managed, which is why the manual dup in the previous section is safe there.
Roll back if the upgrade breaks
On the default Btrfs layout, Snapper takes a snapshot before zypper writes anything, so a bad result is recoverable. Reboot, choose Start bootloader from a read-only snapshot in GRUB and pick the earliest pre snapshot of the migration session. The tool runs several zypper transactions (the openSUSE-repos installs, the dup, the post-migration tasks) and each gets its own pre and post pair, so check the timestamps in snapper list rather than taking the pre snapshot of the dup itself. Once you’ve confirmed the old system works, make it permanent. Because you’re already running the snapshot you want to keep, a bare rollback does it:
sudo snapper rollbackIf you’re still booted into the broken system, run sudo snapper list, find the pre-migration number and pass it to sudo snapper rollback. The Snapper automatic rollback guide explains how those snapshots are taken and pruned. On an XFS VM image the hypervisor snapshot is your only way back. We tested ours: with the VM shut down, reverting the qcow2 snapshot brought the box back to Leap 16.0 with kernel 6.12.0-160000.40, Packman ffmpeg 7.1.5 and the old pinned Packman URL:
qemu-img snapshot -a pre-16.1 leap01.qcow2Whichever way you roll back, fix the cause before you try again, and nine times out of ten that’s a third-party repo you left enabled. For a 15.6 server, run the migration tool and pick 16.1 directly. For a 16.0 box, put $releasever in your Packman URL and run the one-line dup. Both end on the current Leap release with repos that follow the next minor upgrade by themselves.
