5 Upgrading online #

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

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

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

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

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

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.

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

If the migration tool offers update repositories, it is recommended to proceed with Yes.

If the online migration tool finds obsolete repositories from DVD or a local server, it is highly recommended to disable them. Obsolete repositories are for a previous service pack. Old repositories from SUSE Customer Center or RMT are removed automatically.

If the registration server does not offer migrations for a module or extension, its repository configuration will remain unchanged. This usually happens with 3rd party repositories such as the NVIDIA Compute Module that are not specific to a product version or service pack. If necessary, you can manually check the repository configuration after the migration.

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

After the successful migration restart your system.

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

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

> sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE

Start the migration:

> sudo zypper migration

Some notes about the migration process:

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 are logged in to a graphical session running on the machine you are going to migrate, log out of that session and switch to a text console. Running the update from within a graphical 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 X).

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

> sudo zypper patch --updatestack-only

Get a list of packages that currently do not have a repository assigned to them (orphaned packages). These packages will not be migrated and there is no guarantee that they will work after the migration (because other packages they rely on may have changed in such a way that they are no longer compatible). To get the list, run:

> sudo zypper packages --orphaned

Carefully review the list and remove all orphaned packages that are no longer needed. Make a note of all remaining orphaned packages, you will need it later for comparison.

Get a list of all repositories that the system is currently subscribed to by running:

> sudo zypper repos -u

Update each repository URL so that its product version number is 15-SP4. For example, if the URL of a repository is

http://rmt.example.com/repo/SUSE/Products/SLE-15-SP2-Product-SLES/x86_64/product/

change it to

http://rmt.example.com/repo/SUSE/Products/SLE-15-SP3-Product-SLES/x86_64/product/

This needs to be done with all repositories that are enabled. You may want to consider also doing this for repositories that are currently disabled, to avoid having wrong installation sources in the system when activating them at a later point in time.

To change the repository URLs you have the following options:

1. Using YaST › Software › Software Repositories. Select a repository and click Edit to make the required change. Repeat this for all repositories.

2. Using Zypper. Remove the old repository by running

   > sudo zypper removerepo OLD_REPO_ID

   Then add the corresponding new repository by running

    > sudo zypper addrepo -f URL NAME-15-SP4

3. By editing repository configuration files in /etc/zypp/repos.d. Each repository is represented by one configuration file. Changing the value for the baseurl parameter is required in each file.

Review your changes by running zypper repos -u and update the repositories by running:

> sudo zypper refresh -f -s

In case updating a repository fails, double-check whether you entered the wrong URL. If the problem cannot be fixed, it is recommended to disable the failing repository.

If all repositories are correctly configured, run

> sudo zypper refresh -f -s

again, to make sure all repositories are up-to-date.

Before starting the migration it is recommended do a test run first:

> sudo zypper dup -D --no-allow-vendor-change --no-recommends

The parameter -D will perform a dry run that simulates the migration without actually changing the system. If problems occur, fix them before proceeding. In case the test run succeeds, perform the real migration by running:

> sudo zypper dup --no-allow-vendor-change --no-recommends

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

When the migration has finished and the system has booted into the new service pack version, run the check for orphaned packages again:

> sudo zypper packages --orphaned

Compare the new list with the one you generated before starting the migration. If new packages appear in the list, it may be because they were moved to a different module in the new service pack. If you did not have that module in the previous installation, the package did not get updated.

You can check to which module a package belongs at https://scc.suse.com/packages. Add the missing modules using zypper addrepo or the YaST Software Repositories module, and update the orphaned packages afterwards by running:

> sudo zypper install --no-recommends LIST OF PACKAGES

You have successfully migrated to a new service pack!

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

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 15 SP4 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 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:

> sudo snapper rollback

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

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

   > sudo zypper ref -fs

2. 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. For example, if you are rolling back from SLES 15 SP4 to SLES15 GA, the list must contain the SLES15-GA repositories, and not the SLES15-SP4 repositories.

   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 lifecycles”. (Note that manual intervention should not be necessary, as the repositories should be updated automatically, but it is a best practice to verify and make any necessary corrections.)

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

   > sudo SUSEConnect --status

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

   > sudo SUSEConnect --rollback