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

#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 10.1, “Enabling and Configuring Multiversion Support”.

In the release notes you can find additional information on what has changed since the previous release of SUSE Linux Enterprise. Verify there if your specific hardware or setup needs special considerations, which of your favorite specific software packages have changed significantly, and which precautions you should take in addition to the general recommendations of this section. The release notes also provide last-minute information and known issues that could not make it to the manual on time.

The current version of the release notes document containing the latest information on SUSE Linux Enterprise Desktop can be read online at http://www.suse.com/documentation/.

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.

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:

SLE11 SP3 and SLE12 GA get a newer version of the PostgreSQL database 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.

Each PostgreSQL version stores its files in different, version-dependent directories. After the update the directories will change to:

To perform the database migration, do the following:

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, recreate 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 you are migrating your client OS that is registered against an SMT server, you need to 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.

Use the df command to list available disk space. For example, in Example 14.1, “List with df -h”, the root partition is /dev/sda3 (mounted as /).

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       39G  1.6G   37G   4% /windows/C
/dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

If you use Btrfs as root file systems on your machine, make sure there is enough free space. Getting disk space can be done with these two commands:

root # btrfs filesystem df /
root # df /

The results of the two commands show similar numbers of how much disk space is used. However, the problem with Btrfs and free space is that you do not know what is referenced in a snapshot and what is not; you cannot calculate how much disk space a change would need.

In the worst case, an upgrade needs as much disk space as the current root file system (without /.snapshot). Besides any Btrfs file systems, check for free space on other file systems as well. The following recommendation has been proven:

The procedure below describes booting from a DVD as an example, but you can also use another local installation medium like an ISO image on a USB mass storage device. The way to select the boot method and to start up the system from the medium depends on the system architecture and on whether the machine has a traditional BIOS or UEFI. For details, see the links below.

If you want to start an upgrade from a network installation source, make sure that the following requirements are met:

When upgrading from network installation source, you can either boot from the local medium and then select the respective network installation type, or boot via PXE. Select the method of your choice and proceed as described in Procedure 14.2 or Procedure 14.3.

The default behavior is defined in the configuration file /etc/zypp/zypp.conf:

root # grep ^multiversion /etc/zypp/zypp.conf
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,running

Remove any hash mark (#) before the line multiversion above to enable this feature (which should already be the case). The second line is used to configure which kernels need to be preserved. You need to enable both, otherwise the system will keep all kernels and it will fill up your hard disk.

The multiversion.kernels line can contain several keywords in different combinations and order:

You want to make sure that an old kernel will only be deleted after the system has rebooted successfully of the new kernel.

Change the following line in /etc/zypp/zypp.conf:

multiversion.kernels = latest,running

The previous parameters tell the system to keep the latest kernel and the running one only if they differ.

You want to keep one or more kernel versions to have one or more “spare” kernels.

This use case can be useful if you need kernels for testing reasons. In case something goes wrong, for example, your machine does not boot, you still can use one or more kernel versions which are known to be good.

Change the following line in /etc/zypp/zypp.conf:

multiversion.kernels = latest,latest-1,latest-2,running

When you reboot your system after the installation of a new kernel, the system will keep three kernels: the new and running kernel (configured as latest,running), the previous kernel version of the new kernel (configured as latest-1), and the predecessor of the previous kernel version (configured as latest-2).

You make regular system updates and install new kernel versions. However, you are also compiling your own kernel version for various reasons and want to make sure that the system will keep it.

Change the following line in /etc/zypp/zypp.conf:

multiversion.kernels = latest,3.12.28-4.20,running

When you reboot your system after the installation of a new kernel, the system will keep two kernels: the new and running kernel (configured as latest,running) and your self-compiled kernel (configured as 3.12.28-4.20).