Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 15 SP1

3 Preparing the Upgrade Edit source

Before starting the upgrade procedure, make sure your system is properly prepared. Among others, preparation involves backing up data and checking the release notes.

3.1 Make Sure the Current System Is Up-To-Date Edit source

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.

3.2 Read the Release Notes Edit source

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:

  • your hardware needs special considerations;

  • any used software packages have changed significantly;

  • special precautions are necessary for your installation.

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 current release notes online at https://www.suse.com/releasenotes/.

Alternatively, find the release notes on the installation DVD in the docu directory.

3.3 Make a Backup Edit source

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.

3.4 Listing Installed Packages and Repositories Edit source

It is often useful to save 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.repo 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.repo
root # zypper install $(cat installed-software.bak)
Note
Note: Number 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 were split to allow a more fine-grained package selection. For example, 37 texlive packages on SLE 11 were split into over 3000 packages on SLE 15.

  • When a package has been split, 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.

3.5 Upgrading from SUSE Linux Enterprise Server 11 SP4 Edit source

If you are using MySQL, PostgreSQL or Java MD5 based certificates on SUSE Linux Enterprise Server 11 SP4, prepare your system as described in the following sections.

3.5.1 Migrate Your MySQL Database Edit source

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:

  1. Log in to your SUSE Linux Enterprise 11 machine.

  2. Create a dump file:

    root # mysqldump -u root -p --all-databases > mysql_backup.sql

    By default, mysqldump does not dump the INFORMATION_SCHEMA or performance_schema database. For more details refer to https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.

  3. Store your dump file, the configuration file /etc/my.cnf, and the directory /etc/mysql/ for later investigation (not installation!) in a safe place.

  4. Perform your upgrade. After the upgrade, your former configuration file /etc/my.cnf is still intact. You can find the new configuration in the file /etc/my.cnf.rpmnew.

  5. Configure your MariaDB database to your needs. Do not use the former configuration file and directory, but use it as a reminder and adapt it.

  6. Make sure you start the MariaDB server:

    root # systemctl start mysql

    If you want to start the MariaDB server on every boot, enable the service:

    root # systemctl enable mysql
  7. Verify that MariaDB is running properly by connecting to the database:

    root # mysql -u root -p

3.5.2 Migrate Your PostgreSQL Database Edit source

A newer version of the PostgreSQL database is shipped with SUSE Linux Enterprise Server 15 SP1. 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
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:

  1. Make sure the following preconditions are fulfilled:

    • If not already done, upgrade any package of the old PostgreSQL version to the latest release through a maintenance update.

    • Create a backup of your existing database.

    • Install the packages of the new PostgreSQL major version. For SLE 15 SP1 this means to install postgresql10-server and all the packages it depends on.

    • Install the package postgresql10-contrib which contains the command pg_upgrade.

    • Make sure you have enough free space in your PostgreSQL data area, which is /var/lib/pgsql/data by default. If space is tight, try to reduce size with the following SQL command on each database (can take very long!):

      VACUUM FULL
  2. Stop the PostgreSQL server with either:

    root # /usr/sbin/rcpostgresql stop

    or

    root # systemctl stop postgresql.service

    (depending on the SLE version you use as the start version for your upgrade).

  3. Rename your old data directory:

    root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old
  4. Initialize your new database instance either manually with initdb or by starting and stopping PostgreSQL, which will do it automatically:

    root # /usr/sbin/rcpostgresql start
    root # /usr/sbin/rcpostgresql stop

    or

    root # systemctl start postgresql.service
    root # systemctl stop postgresql.service

    (depending on the SLE version you use as the start version for your upgrade).

  5. If you have changed your configuration files in the old version, consider transferring these changes to the new configuration files. This may affect the files postgresql.auto.conf, postgresql.conf,pg_hba.conf and pg_ident.conf. The old versions of these files are located in /var/lib/pgsql/data.old/, the new versions can be found in /var/lib/pgsql/data.

    Note that just copying the old configuration files is not recommended, because this may overwrite new options, new defaults and changed comments.

  6. Start the migration process as user postgres:

    root # su - postgres
    postgres > pg_upgrade \
      --old-datadir "/var/lib/pgsql/data.old" \
      --new-datadir "/var/lib/pgsql/data" \
      --old-bindir "/usr/lib/postgresql96/bin/" \
      --new-bindir "/usr/lib/postgresql10/bin/"
  7. Start your new database instance with either:

    root # /usr/sbin/rcpostgresql start

    or

    root # systemctl start postgresql.service

    (depending on the SLE version you use as the start version for your upgrade).

  8. Check if the migration was successful. The scope of the test depends on your use case and there is no general tool to automate this step.

  9. Remove any old PostgreSQL packages and your old data directory:

    root # zypper search -s postgresql96 | xargs zypper rm -u
    root # rm -rf /var/lib/pgsql/data.old

3.5.3 Create Non-MD5 Server Certificates for Java Applications Edit source

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:

  1. Open a terminal and log in as root.

  2. Create a private key:

    root # openssl genrsa -out server.key 1024

    If you want a stronger key, replace 1024 with a higher number, for example, 4096.

  3. Create a certificate signing request (CSR):

    root # openssl req -new -key server.key -out server.csr
  4. Self-sign the certificate:

    root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
  5. Create the PEM file:

    root # cat server.key server.crt > server.pem
  6. Place the files server.crt, server.csr, server.key, and server.pem in the respective directories where the keys can be found. For Tomcat, for example, this directory is /etc/tomcat/ssl/.

3.6 Shut Down Virtual Machine Guests Edit source

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.

3.7 Adjusting Your SMT Client Setup Edit source

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 3.1. Afterward, restart the upgrade process.

Procedure 3.1: De-registering a SUSE Linux Enterprise Client from an SMT Server
  1. Log in to the client machine.

  2. The following step depends on the current operating system of the client:

    • For SUSE Linux Enterprise 11, execute the following commands:

      tux > sudo suse_register -E
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
      tux > sudo rm -f /var/cache/SuseRegister/*
      tux > sudo rm -f /etc/suseRegister*
      tux > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
      tux > sudo rm -f /etc/zmd/deviceid
      tux > sudo rm -f /etc/zmd/secret
    • For SUSE Linux Enterprise 12, execute the following commands:

      tux > sudo SUSEConnect --de-register
      tux > sudo SUSEConnect --cleanup
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
  3. Log in to the SMT server.

  4. Check if the client has successfully been de-registered by listing all client registrations:

    tux > sudo smt-list-registrations
  5. If the client's host name is still listed in the output of this command, get the client's Unique ID from the first column. (The client might be listed with multiple IDs.)

  6. Delete the registration for this client:

    tux > sudo smt-delete-registration -g UNIQUE_ID
  7. If the client is listed with multiple IDs, repeat the step above for each of its unique IDs.

  8. Check if the client has now successfully been de-registered by re-running:

    tux > sudo smt-list-registrations

3.8 Disk Space Edit source

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

3.8.1 Checking Disk Space on Non-Btrfs File Systems Edit source

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

Example 3.1: List with df -h
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

3.8.2 Checking Disk Space on Btrfs Root File Systems Edit source

On a Btrfs file system, the output of df can be misleading, because in addition to the space the raw data allocates, a Btrfs file system also allocates and uses space for metadata.

Consequently a Btrfs file system may report being out of space even though it seems that plenty of space is still available. In that case, all space allocated for the metadata is used up. For details on how to check for used and available space on a Btrfs file system, see Section 1.2.2.3, “Checking for Free Space”. For more information refer to man 8 btrfs-filesystem and https://btrfs.wiki.kernel.org/index.php/FAQ.

If you use Btrfs as root file systems on your machine, make sure there is enough free space. Check the available space on all mounted partitions. In the worst case, an upgrade needs as much disk space as the current root file system (without /.snapshot) for a new snapshot.

The following recommendations have been proven:

  • For all file systems including Btrfs you need enough free disk space to download and install big RPMs. The space of old RPMs are only freed after new RPMs are installed.

  • For Btrfs with snapshots, you need at minimum as much free space as your current installation takes. We recommend to have twice as much free space as the current installation.

    If you do not have enough free space, you can try to delete old snapshots with snapper:

    root # snapper list
    root # snapper delete NUMBER

    However, this may not help in all cases. Before migration, most snapshots occupy only little space.

3.9 Changes in AutoYaST Profiles from SLE 12 to 15 Edit source

To learn how to migrate your AutoYaST profiles, see Appendix D, Differences Between AutoYaST Profiles in SLE 12 and 15 .

3.10 Upgrading a Subscription Management Tool (SMT) Server Edit source

A server running SMT requires a special upgrade procedure. Please refer to Chapter 2, Migrate from SMT to RMT in the Repository Management Tool Guide.

3.11 Temporarily Disabling Kernel Multiversion Support Edit source

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

3.12 Upgrading on IBM Z Edit source

Upgrading a SUSE Linux Enterprise installation on IBM Z requires the Upgrade=1 kernel parameter, for example via the parmfile. See Section 5.4, “The Parmfile—Automating the System Configuration”.

3.13 IBM POWER: Starting an X Server Edit source

On SLES 12 for IBM POWER the display manager is configured not to start a local X Server by default. This setting was reversed on SLES 12 SP1—the display manager now starts an X Server.

To avoid problems during upgrade, the SUSE Linux Enterprise Server setting is not changed automatically. If you want the display manager to start an X Server after the upgrade, change the setting of DISPLAYMANAGER_STARTS_XSERVER in /etc/sysconfig/displaymanager as follows:

DISPLAYMANAGER_STARTS_XSERVER="yes"
Print this page