SUSE offers a graphical and a command line tool to upgrade to a new service pack. These are simple command line tools, an intuitive graphical user interface, support for “rollback” of service packs, and some more. This chapter explains how to do a service pack migration step by step with these tools.
SUSE releases new service packs for the SUSE Linux Enterprise family at regular intervals. To make it easy for customers to migrate to a new service pack and minimize downtime, SUSE supports to migrate online while the system is running.
Starting with SLE 12 SP2, YaST Wagon has been replaced by the YaST migration (GUI) and Zypper migration (command line). The following features are supported:
System always in a defined state until the first RPM is updated
Canceling is possible until the first RPM is updated
Simple recovery, if there is an error
“Rollback” via system tools; no backup/restore needed
Use of all active repositories
The ability to skip a service pack
SUSE supports the following scenarios, be it offline or online:
SUSE Customer Center (SCC), Subscription Management Tool (SMT), SUSE Manager
Boot DVD, flash disk, ISO image, AutoYaST, “plain RPM” and third-party tools
Migration from the following versions are supported:
SUSE Linux Enterprise 12
SUSE Linux Enterprise 11 SP3/SP4, SUSE Linux Enterprise 12
SUSE Linux Enterprise 12
A service pack migration can be executed by either YaST,
zypper, or AutoYaST.
Before you can start a service pack migration, your system must be registered at the SUSE Customer Center. It is not possible to perform a migration with self build repositories derived from DVDs.
Regardless of the method, a service pack migration consists of the following steps:
Find possible migration targets on your registered systems.
Select one migration target.
Request and enable new repositories.
Run the migration.
The list of migration targets depends on the products you have installed and registered. If you have an extension installed for which the new SP is not yet available, it could be that no migration target is offered to you.
The list of migration targets available for your host will always be retrieved from the SUSE Customer Center and depend on products or extensions installed.
A service pack migration can only be cancelled at specific stages during the migration process:
Until the package upgrade starts, there are only minimal changes on the
system, like for services and repositories. Restore
/etc/zypp/repos.d/* to revert to the former state.
After the package upgrade starts, you can revert to the former state by using a Snapper snapshot (see Chapter 6, System Recovery and Snapshot Management with Snapper).
After the migration target was selected, SUSE Customer Center changes the repository
data. To revert this state manually, use SUSEConnect
--rollback.
To perform a service pack migration with YaST, use the tool. By default, YaST does not install any packages from a third-party repository. If a package was installed from a third-party repository, YaST prevents packages from being replaced with the same package coming from SUSE.
When performing the SP migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.
To change this default behavior and allow only required packages, adjust
/etc/zypp/zypp.conf and set the following variable:
solver.onlyRequires = true installRecommends=false # or commented
This changes the behavior of all package operations, such as the installation of patches or new packages.
To start the service pack migration, do the following:
If you are logged into a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).
Run YaST online update to get the latest package updates for your system.
Install the package yast2-migration and its dependencies (in YaST under › ).
Restart YaST, otherwise the newly installed module will not be shown in the control center.
Start in YaST › . YaST will show possible migration targets and a summary. If more than one migration target is available for your system, select one from the list.
Select one migration target from the list and proceed with .
In case the migration tool offers update repositories, it is recommended to proceed with .
If the Online Migration tool finds obsolete repositories coming from DVD or a local server, it is highly recommended to disable them. Obsolete repositories are from a previous SP. Any old repositories from SCC or SMT are removed automatically.
Check the summary and proceed with the migration by clicking . Confirm with .
After the successful migration restart your system.
To perform a service pack migration with Zypper, use the command line tool
zypper migration.
When performing the SP migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.
To change this default behavior and allow only required packages, adjust
/etc/zypp/zypp.conf and set the following variable:
solver.onlyRequires = true installRecommends=false # or commented
This changes the behavior of all package operations, such as the
installation of patches or new packages. To change the behavior of Zypper
for a single invocation, add the parameter --no-recommends
to your command line.
To start the service pack migration, do the following:
If you are logged into a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).
Register your SUSE Linux Enterprise machine if you have not done so:
sudo SUSEConnect --regcode YOUR_REGISTRATION_CODEInstall the latest updates:
sudo zypper patchInstall the packages zypper-migration-plugin and their dependencies:
sudo zypper migration
Run zypper migration:
tux >sudozyppermigration Executing 'zypper patch-check' Refreshing service 'SUSE_Linux_Enterprise_Server_12_x86_64'. Loading repository data... Reading installed packages... 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server 12 SP1 x86_64 2 | SUSE Linux Enterprise Server 12 SP2 x86_64
Some notes about the migration process:
If more than one migration target is available for your system, Zypper allows you to select one SP from the list. This is the same as skipping one or more SPs. Keep in mind, online migration for base products (SLES, SLED) remains available only between the SPs of a major version.
By default, Zypper uses the option
--no-allow-vendor-change which is passed to
zypper dup. If a package was
installed from a third-party repository, this option prevents packages
from being replaced with the same package coming from SUSE.
If Zypper finds obsolete repositories coming from DVD or a local server, it is highly recommended to disable them. Old SCC or SMT repositories are removed automatically.
Review all the changes, especially the packages that are going to be
removed. Proceed by typing y (the exact number of
packages to upgrade can vary on your system):
266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch. Overall download size: 285.1 MiB. Already cached: 0 B After the operation, additional 139.8 MiB will be used. Continue? [y/n/? shows all options] (y):
Use the Shift–Page ↑ or Shift–Page ↓ keys to scroll in your shell.
After successful migration restart your system.
If you cannot use YaST migration or the Zypper migration, you can still migrate with plain Zypper and some manual interactions. To start a service pack migration, do the following:
If you are logged into a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).
Update the package management tools with the old SUSE Linux Enterprise repositories:
sudo zypper patch--updatestack-onlyIf the system is registered, it needs to be deregistered:
sudo SUSEConnect --de-registerRemove the old installation sources and repositories and adjust the third-party repositories.
Add the new installation sources, be it local or remote sources (for the placeholder REPOSITORY, refer to Table 13.2, “Repository Layout for SUSE Linux Enterprise 11 SP3/SP4 and for SUSE Linux Enterprise 12 SP1”):
sudo zypper addrepo REPOSITORYYou can also use SUSE Customer Center or Subscription Management Tool. The command for SUSE Linux Enterprise 12 SP1 on x86-64 is:
sudo SUSEConnect -p SLES/12.2/x86_64 OPTIONSKeep in mind, cross-architecture upgrades are not supported.
Finalize the migration:
sudozypperref -f -s sudozypperdup --no-allow-vendor-change --no-recommends
The first command will update all services and repositories. The second
command performs a distribution upgrade. Here, the last two options are
important: -no-allow-vendor-change ensures that
third-party RPMs will not overwrite RPMs from the base system. The option
--no-recommends ensures that packages deselected during
initial installation will not be added again.
If a service pack does not work for you, SUSE Linux Enterprise supports reverting the system to the state before the service pack migration was started. Prerequisite is a Btrfs root partition with snapshots enabled (this is the default when installing SLES 12). See Chapter 6, System Recovery and Snapshot Management with Snapper for details.
Get a list of all Snapper snapshots:
sudo snapper list
Review the output to locate the snapshot that was created immediately
before the service pack migration was started. The column
contains a corresponding statement and the
snapshot is marked as important in the column
. Memorize the snapshot number from the column
and it's date from the column
.
Reboot the system. From the boot menu, select and then choose the snapshot with the
date and number you memorized in the previous step. A second boot menu
(the one from the snapshot) is loaded. Select the entry starting with
SLES 12 and boot it.
The system boots into the previous state with the system partition mounted
read-only. Log in as root and check whether you have chosen the
correct snapshot. Also make sure everything works as expected. Note that
due to the fact that the root file system is mounted read-only restrictions
in functionality may apply.
In case of problems or if you have booted the wrong snapshot, reboot and choose a different snapshot to boot from—up to this point no permanent changes have been made. If the snapshot is correct and works as expected, make the change permanent by running the following command:
snapper rollback
Reboot afterward. On the boot screen, choose the default boot entry to reboot into the reinstated system.
Check if the repository configuration and has been properly reset. Furthermore, check if all products are properly registered. If either one is not the case, updating the system at a later point in time may no longer work, or the system may be updated using the wrong package repositories.
Make sure the system can access the Internet before starting this procedure.
Refresh services and repositories by running
sudo zypper ref -fs
Get a list of active repositories by running
sudo zypper lr
Carefully check the output of this command. No services and repositories
that were added for the update should be listed. If you, for example,
are rolling back from a service pack migration from SLES 12 SP1 to
SLES 12 SP2, the list must not contain the
repositories SLES12-SP2-Pool and
SLES12-SP2-Updates, but rather the
SP1 versions.
In case wrong repositories are listed make sure to delete them and, if necessary, replace them with the versions matching your product or service pack version. For a list of repositories for the supported migration paths refer to Section 13.4, “Repository Model”.
Last, check the registration status for all products installed by running
SUSEConnect --status
All products should be reported as being
Registered. If this is not the case, repair the
registration by running
SUSEConnect --rollback
Now you have successfully reverted the system to the state that was captured immediately before the service pack migration was started.