Applies to SUSE Linux Enterprise Server 15

5 Upgrading Online

  • Filename: sle_update_online.xml
  • ID: cha.upgrade-online
Abstract

SUSE offers an intuitive graphical and a simple command line tool to upgrade a running system to a new service pack. They provide support for rollback of service packs and more. This chapter explains how to do a service pack upgrade step by step with these tools.

5.1 Conceptual Overview

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 migrating online while the system is running.

Starting with SLE 12, YaST Wagon has been replaced by 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

Warning
Warning: Online Migration Not Supported for Major Releases

The online migration is only supported for migrating between service packs. Online migration is not supported for upgrading to new major releases. For details, see Chapter 1, Upgrade Paths and Methods.

Use the offline migration to upgrade to a new major release. For details, see Chapter 4, Upgrading Offline.

5.2 Service Pack Migration Workflow

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 or a local RMT server. SUSE Manager can also be used.

Regardless of the method, a service pack migration consists of the following steps:

  1. Find possible migration targets on your registered systems.

  2. Select one migration target.

  3. Request and enable new repositories.

  4. 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.

5.3 Canceling Service Pack Migration

A service pack migration can only be cancelled at specific stages during the migration process:

  1. 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.

  2. After the package upgrade starts, you can revert to the former state by using a Snapper snapshot (see Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper”).

  3. After the migration target was selected, SUSE Customer Center changes the repository data. To revert this state manually, use SUSEConnect --rollback.

5.4 Upgrading with the Online Migration Tool (YaST)

To perform a service pack migration with YaST, use the Online Migration 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.

Note
Note: Reduce Installation Size

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:

  1. Deactivate all unused extensions on your registration server to avoid future dependency conflicts. In case you forget an extension, YaST will later detect unused extension repositories and deactivate them.

  2. If you are logged in to 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).

  3. If you are an LTSS subscriber, make sure that the LTSS extension repository is active.

  4. Run YaST online update to get the latest package updates for your system.

  5. Install the package yast2-migration and its dependencies (in YaST under Software › Software Management).

  6. Restart YaST, otherwise the newly installed module will not be shown in the control center.

  7. In YaST, choose Online Migration (depending on the version of SUSE Linux Enterprise Server that you are upgrading from, this module is categorized under either System or Software). 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.

  8. Select one migration target from the list and proceed with Next.

  9. In case the migration tool offers update repositories, it is recommended to proceed with Yes.

  10. 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 SUSE Customer Center or RMT are removed automatically.

  11. Check the summary and proceed with the migration by clicking Next. Confirm with Start Update.

  12. After the successful migration restart your system.

5.5 Upgrading with Zypper

To perform a service pack migration with Zypper, use the command line tool zypper migration from the package zypper-migration-plugin.

Note
Note: Reduce Installation Size

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:

  1. If you are logged in to 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).

  2. Register your SUSE Linux Enterprise machine if you have not done so:

    tux > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. If you are an LTSS subscriber, make sure that the LTSS extension repository is active.

  4. Run zypper migration:

    tux > sudo zypper migration
    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 SUSE Customer Center or RMT repositories are removed automatically.

  5. 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 ShiftPage ↑ or ShiftPage ↓ keys to scroll in your shell.

  6. After successful migration restart your system.

5.6 Upgrading with Plain Zypper

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:

  1. If you are logged in to 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).

  2. Update the package management tools with the old SUSE Linux Enterprise repositories:

    tux > sudo zypper patch --updatestack-only
  3. If the system is registered, it needs to be deregistered:

    tux > sudo SUSEConnect --de-register
  4. Remove the old installation sources and repositories and adjust the third-party repositories.

  5. Add the new installation sources, be it local or remote sources (for the placeholder REPOSITORY, refer to Section 2.3, “Module Dependencies and Life Cycles”):

    sudo zypper addrepo REPOSITORY

    You can also use SUSE Customer Center or Repository Mirroring Tool. The command for SUSE Linux Enterprise 12 SP1 on AMD64/Intel 64 is:

    tux > sudo SUSEConnect -p SLES/12.2/x86_64 OPTIONS

    Keep in mind, cross-architecture upgrades are not supported.

    Zypper will display a conflict between the old and new kernel. Choose Solution 1 to continue.

    Problem: product:SLES-12.2-0.x86_64 conflicts with kernel < 4.4 provided by kernel-default-VERSION
     Solution 1: Following actions will be done:
      replacement of kernel-default-VERSION with kernel-default-VERSION
      deinstallation of kernel-default-VERSION
     Solution 2: do not install product:SLES-12.2-0.x86_64
  6. Finalize the migration:

    tux > sudo zypper ref -f -s
    tux > sudo zypper dup --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.

5.7 Rolling Back a Service Pack

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 Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper” for details.

  1. Get a list of all Snapper snapshots:

    tux > sudo snapper list

    Review the output to locate the snapshot that was created immediately before the service pack migration was started. The column Description contains a corresponding statement and the snapshot is marked as important in the column Userdata. Memorize the snapshot number from the column # and its date from the column Date.

  2. Reboot the system. From the boot menu, select Start boot loader from a read-only snapshot 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.

  3. 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 since 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:

    tux > sudo snapper rollback

    Reboot afterward. On the boot screen, choose the default boot entry to reboot into the reinstated system.

  4. Check if the repository configuration 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.

    1. Refresh services and repositories by running

      tux > sudo zypper ref -fs
    2. Get a list of active repositories by running

      tux > sudo zypper lr

      Carefully check the output of this command. No services and repositories that were added for the update should be listed. For example, if you are rolling back from SLES 12 SP1 to SLES 12 SP2, the list must contain the SP1 repositories, and not the repositories SLES12-SP2-Pool and SLES12-SP2-Updates.

      If wrong repositories are listed, 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 2.3, “Module Dependencies and Life Cycles”.

    3. Last, check the registration status for all products installed by running

      tux > sudo SUSEConnect --status

      All products should be reported as being Registered. If this is not the case, repair the registration by running

      tux > sudo SUSEConnect --rollback

Now you have successfully reverted the system to the state that was captured immediately before the service pack migration was started.

5.8 Migrate from openSUSE Leap to SUSE Linux Enterprise Server

You can migrate an openSUSE installation online to SUSE Linux Enterprise Server. The procedure is analogous to Section 5.5, “Upgrading with Zypper”, but some additional steps are required. We recommend to run this procedure on a test system that replicates your production setup before executing it on the production system.

To see for which openSUSE Leap versions a migration is supported, read Section 1.1, “Supported Upgrade Paths to SLE 15.

Warning
Warning: Not All openSUSE Packages Can Be Migrated

The openSUSE repositories provide more packages than are available in the SUSE Linux Enterprise Server repositories. If you have any of these packages installed, they will no longer receive updates after the migration. These packages will be removed when following the procedure below.

Make sure that all packages you need for operating your system are available in the SUSE Linux Enterprise Server repository. You can also check if the packages are available in the SUSE Package Hub repository. For details, see Book “Deployment Guide”, Chapter 18 “Installing Modules, Extensions, and Third Party Add-On Products”, Section 18.3 “SUSE Package Hub”.

To migrate from openSUSE Leap, execute the following procedure:

  1. Switch to a TTY, for example by pressing CtrlAltF1. Then log in as root.

  2. Install SUSEConnect.

    root # zypper in SUSEConnect
  3. Remove packages that produce file conflicts during the migration.

    root # rpm -e --nodeps yast2-branding-openSUSE
    root # rpm -e --nodeps yast2-branding-openSUSE-Oxygen
  4. Register at SCC to get the SUSE Linux Enterprise Server repositories.

    root # SUSEConnect -r REGISTRATION_CODE -p SLES/15.0/x86_64
  5. List and disable all openSUSE repositories on your system.

    root # zypper lr
    root # zypper mr -d REPO_IDS

    Replace REPO_IDS with a space character separated list of all enabled openSUSE repositories.

  6. Now add the modules you need for your installation.

    root # SUSEConnect --list-extensions
    [...]
    root # SUSEConnect -p sle-module-basesystem/15.0/x86_64

    To have replacements for most Leap packages, we recommend to enable the Basesystem, Desktop Applications, Server Applications and Legacy modules. Additionally, we recommend to enable the SUSE Package Hub.

  7. Migrate installed packages to the SUSE Linux Enterprise Server repositories.

    root # zypper dup --force-resolution
  8. Remove orphaned packages.

    root # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  9. Finally, reboot the system.

Print this page