20 Upgrading SUSE Linux Enterprise #

Upgrading the system is only supported from the most recent patch level. Make sure the latest system updates are installed by either running zypper patch or by starting the YaST module Online-Update.

In the release notes you can find additional information on changes since the previous release of SUSE Linux Enterprise Server. Check the release notes to see whether:

The release notes also provide information that could not make it into the manual on time. They also contain notes about known issues.

If you are skipping one or more Service Packs, check the release notes of the skipped Service Packs as well. The release notes usually only contain the changes between two subsequent releases. You can miss important changes if you are only reading the current release notes.

Find the release notes locally in the directory /usr/share/doc/release-notes or online at https://www.suse.com/releasenotes/.

Before updating, copy existing configuration files to a separate medium (such as tape device, removable hard disk, etc.) to back up the data. This primarily applies to files stored in /etc and some directories and files in /var and /opt. You may also want to write the user data in /home (the HOME directories) to a backup medium. Back up this data as root. Only root has read permissions for all local files.

If you have selected Update an Existing System as the installation mode in YaST, you can choose to do a (system) backup at a later point in time. You can choose to include all modified files and files from the /etc/sysconfig directory. However, this is not a complete backup, as all the other important directories mentioned above are missing. Find the backup in the /var/adm/backup directory.

20.3.3.1 Listing Installed Packages and Repositories #

  

It is often useful to have a list of installed packages, for example when doing a fresh install of a new major SLE release or reverting to the old version.

Be aware that not all installed packages or used repositories are available in newer releases of SUSE Linux Enterprise. Some may have been renamed and others replaced. It is also possible that some packages are still available for legacy purposes while another package is used by default. Therefore some manual editing of the files might be necessary. This can be done with any text editor.

Create a file named repositories.bak containing a list of all used repositories:

root # zypper lr -e repositories.bak

Also create a file named installed-software.bak containing a list of all installed packages:

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

Back up both files. The repositories and installed packages can be restored with the following commands:

root # zypper ar repositories.bak
root # zypper install $(cat installed-software.bak)

Note: Amount of Packages Increases with an Update to a New Major Release

A system upgraded to a new major version (SLE X+1) may contain more packages than the initial system (SLE X). It will also contain more packages than a fresh installation of SLE X+1 with the same pattern selection. Reasons for this are:

• Packages got split to allow a more fine-grained package selection. For example, 37 texlive packages on SLE 11 were split into 422 packages on SLE 12.

• When a package got split into other packages all new packages are installed in the upgrade case to retain the same functionality as with the previous version. However, the new default for a fresh installation of SLE X+1 may be to not install all packages.

• Legacy packages from SLE X may be kept for compatibility reasons.

• Package dependencies and the scope of patterns may have changed.

If you upgrade a SUSE Linux Enterprise Server system with Long Term Service Pack Support (LTSS) to a version that is still under general support, the upgrade will fail with the error No migration available. This happens because zypper migration tries to migrate all repositories , but there is no LTSS repository for the new version yet.

To fix this issue, disable the LTSS extension before the upgrade.

As of SUSE Linux Enterprise 12, SUSE switched from MySQL to MariaDB. Before you start any upgrade, it is highly recommended to back up your database.

To perform the database migration, do the following:

A newer version of the PostgreSQL database is shipped as a maintenance update. Because of the required migration work of the database, there is no automatic upgrade process. As such, the switch from one version to another needs to be done manually.

The migration process is conducted by the pg_upgrade command which is an alternative method of the classic dump and reload. In comparison with the “dump & reload” method, pg_upgrade makes the migration less time-consuming.

The program files for each PostgreSQL version are stored in different, version-dependent directories. For example, in /usr/lib/postgresql96/ for version 9.6 and in /usr/lib/postgresql10/ for version 10. Note that the versioning policy of PostgreSQL has changed between the major versions 9.6 and 10. For details, see https://www.postgresql.org/support/versioning/.

Important: Upgrading from SLE 11

When upgrading from SLE 11, postgresql94 will be uninstalled and cannot be used for the database migration to a higher PostgreSQL version. Therefore in this case make sure to migrate the PostgreSQL database before you upgrade your system.

The procedure below describes the database migration from version 9.6 to 10. When using a different version as start or target, replace the version numbers accordingly.

To perform the database migration, do the following:

To connect to PostgreSQL via the unixODBC driver the psqlODBC package needs to be installed.

During the update from SP1 to SP2, MD5-based certificates were disabled as part of a security fix. If you have certificates created as MD5, re-create your certificates with the following steps:

If your machine serves as a VM Host Server for KVM or Xen, make sure to properly shut down all running VM Guests prior to the update. Otherwise you may not be able to access the guests after the update.

If the machine you want to upgrade is registered as a client against an SMT server, take care of the following:

Check if the version of the clientSetup4SMT.sh script on your host is up to date. clientSetup4SMT.sh from older versions of SMT cannot manage SMT 12 clients. If you apply software patches regularly on your SMT server, you can always find the latest version of clientSetup4SMT.sh at <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

In case upgrading your machine to a higher version of SUSE Linux Enterprise Server fails, de-register the machine from the SMT server as described in Procedure 20.1. Afterward, restart the upgrade process.

Software tends to grow from version to version. Therefore, take a look at the available partition space before updating. If you suspect you are running short of disk space, back up your data before increasing the available space by resizing partitions, for example. There is no general rule regarding how much space each partition should have. Space requirements depend on your particular partitioning profile and the software selected.

Note: Automatic Check for Enough Space in YaST

During the update procedure, YaST will check how much free disk space is available and display a warning to the user if the installation may exceed the available amount. In that case, performing the update may lead to an unusable system! Only if you know exactly what you are doing (by testing beforehand), you can skip the warning and continue the update.

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       44G    4G   40G   9% /data

root # df -h /

SUSE Linux Enterprise Server allows installing multiple kernel versions by enabling the respective settings in /etc/zypp/zypp.conf. Support for this feature needs to be temporarily disabled to upgrade to a service pack. When the update has successfully finished, multiversion support can be re-enabled. To disable multiversion support, comment the respective lines in /etc/zypp/zypp.conf. The result should look similar to:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

To re-activate this feature after a successful update, remove the comment signs. For more information about multiversion support, refer to Section 16.1, “Enabling and Configuring Multiversion Support”.