Release transitions in openSUSE Leap and SLES replace the operating-system package set. A supported upgrade uses the product's migration workflow, a recovery plan, and post-reboot checks to leave the new release usable.
The openSUSE migration tool manages the Leap repository transition before applying a distribution upgrade. Registered SLES systems use zypper migration to obtain service-pack targets and product channels from SUSE Customer Center or an RMT server. These are separate workflows for regular mutable installations.
Routine zypper update maintenance stays on the installed release and belongs in updating packages in openSUSE and SLES. Tumbleweed, immutable installations, major-version SLES upgrades, and systems managed by SUSE Multi-Linux Manager require their own upgrade procedures. Application database migrations can also require work beyond replacing RPM packages.
Steps to upgrade openSUSE Leap or migrate a SLES service pack:
Prepare the system first, then follow the Leap section on openSUSE Leap or the SLES section on a registered SLES 15 system.
- Back up your application data and system configuration to storage outside this machine.
A release upgrade can remove packages, replace boot components, and interrupt remote access. Filesystem snapshots do not replace an independent backup of application data, including databases and files outside the root snapshot.
On Btrfs systems with Snapper, a pre-upgrade snapshot can also return the root filesystem to its earlier state.
- Check free space on the filesystems the upgrade writes to.
$ df -h / /boot /var
Package downloads, replacement RPMs, and Btrfs snapshots all need room, so clear space first if these filesystems are nearly full.
- Move to a text console or an SSH session for the upgrade.
A graphical session can end during package replacement. On a remote machine, keep console access available in case networking or SSH fails.
Upgrade openSUSE Leap to a new release
Leap 16.0 moves to 16.1 through the openSUSE migration tool, as described in the Leap 16.1 release notes. Leap 15.6 starts differently, so follow the notes' Leap 15.6 migration section there. The migration tool replaces the repository definitions itself, so do not rewrite old repository URLs or add --allow-vendor-change to your own zypper dup.
- Install the pending updates for your current Leap release.
$ sudo zypper update
If the updates ask for a reboot, complete it before starting the migration.
- Install the openSUSE migration tool.
$ sudo zypper install opensuse-migration-tool
The release notes recommend this tool, although its upstream README still marks it experimental.
- Preview the migration and select openSUSE Leap 16.1.
$ sudo opensuse-migration-tool --dry-run
The preview changes nothing and prints the repository changes and the proposed upgrade command, not a full package list. The menu also lists other distributions and may list development releases.
- Start the real migration and select the same openSUSE Leap 16.1 target.
Choosing a target starts the upgrade straight away. The tool uses force resolution, allows package vendor changes, and can run through zypper dup without pausing at a package summary. Cancel in the menu leaves the system unchanged.
$ sudo opensuse-migration-tool
If a third-party repository checklist appears, keep its recommended exclusions, because the upgrade starts when it closes. A checklist of optional tasks appears after package replacement and can stay empty when none apply.
- Confirm that no upgrade work remains.
$ sudo zypper --releasever 16.1 dup --dry-run Warning: Enforced setting: $releasever=16.1 Refreshing service 'openSUSE'. Loading repository data... Reading installed packages... ##### snipped ##### Computing distribution upgrade... Nothing to do.
The tool prints Migration process completed. A reboot is recommended. even when its upgrade failed. Anything other than Nothing to do. means the upgrade is incomplete, so resolve it or restore from your backup before rebooting.
- Reboot into the upgraded system.
$ sudo reboot
- Confirm the system now reports the new release.
$ cat /etc/os-release NAME="openSUSE Leap" VERSION="16.1" ##### snipped ##### PRETTY_NAME="openSUSE Leap 16.1" ##### snipped #####
Re-enable a third-party repository only once it supports the new release.
- List any services that failed to start after the upgrade.
$ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.
Zero units means no service failed. An application can still need its own upgrade step, so try the ones you rely on as you normally would.
Upgrade SLES to a new service pack
Registered SLES 15 systems get their service-pack targets from SUSE Customer Center or an RMT server. The SUSE online-upgrade documentation defines the supported paths and recovery.
- Install the pending patches for your current service pack.
$ sudo zypper patch
If the patches update the update stack or ask for a reboot, complete that before starting the migration.
- Start the service-pack migration and select a target offered for all installed products.
$ sudo zypper migration
The command stops with an error on an unregistered system. A missing target can mean an unsupported product combination, an extension lifecycle limit, or a registration problem. The highest version number does not guarantee that your applications support the move.
- Review the removals and repository changes in the package summary, then confirm the transaction.
SLES migration normally blocks vendor changes, so packages keep their vendors.
- Reboot after zypper migration finishes without errors.
$ sudo reboot
An error or an incomplete package transaction means the migration has not succeeded, so do not restart yet. If you need to roll back, restore the previous root snapshot before changing registration, as the SUSE documentation describes.
- Confirm the system now reports the new service pack.
$ cat /etc/os-release
The VERSION and PRETTY_NAME lines should show the service pack you selected.
- Confirm that all installed products are still registered.
$ sudo SUSEConnect --status
Each product should report as registered. The output can include subscription details, so do not share it publicly.
- List any services that failed to start after the upgrade.
$ systemctl --failed
Zero loaded units means no service failed. An application can still need its own upgrade step, so try the ones you rely on as you normally would.