19 Upgrading SUSE Linux Enterprise #
SUSE® Linux Enterprise (SLE) allows to upgrade an existing system to the new version, for example, going from SLE 11 SP4 to the latest SLE 12 service pack. No new installation is needed. Existing data, such as home and data directories and system configuration, is kept intact. You can update from a local CD or DVD drive or from a central network installation source.
This chapter explains how to manually upgrade your SUSE Linux Enterprise system, be it by DVD, network, an automated process, or SUSE Manager.
19.1 Supported Upgrade Paths to SLE 12 SP3 #
Important: Cross-architecture Upgrades Are Not Supported
Cross-architecture upgrades, such as upgrading from a 32-bit version of SUSE Linux Enterprise Server to the 64-bit version, or upgrading from big endian to little endian are not supported!
Specifically, SLE 11 on POWER (big endian) to SLE 12 SP2 on POWER (new: little endian!), is not supported.
Also, since SUSE Linux Enterprise 12 is 64-bit only, upgrades from any 32-bit SUSE Linux Enterprise 11 systems to SUSE Linux Enterprise 12 and later are not supported.
To make a cross-architecture upgrade, you need to perform a new installation.
Before you perform any migration, read Section 19.3, “Preparing the System”.
Note: Skipping Service Packs
Consecutively installing all Service Packs is the safest upgrade path. In some cases it is supported to skip 1 or 2 Service Packs when upgrading. However, we recommend to not skip any Service Pack.
Note: Upgrading Major Releases
We recommend to do a fresh install when upgrading to a new Major Release, for example from SUSE Linux Enterprise 11 to SUSE Linux Enterprise 12.
- Upgrading from SUSE Linux Enterprise 10 (any Service Pack)
There is no supported direct migration path to SUSE Linux Enterprise 12. We recommend a fresh installation in this case.
- Upgrading from SUSE Linux Enterprise 11 GA / SP1 / SP2 / SP3
There is no supported direct migration path to SUSE Linux Enterprise 12. You need at least SLE 11 SP4 before you can proceed to SLE 12 SP3.
If you cannot do a fresh install, first upgrade your installed SLE 11 Service Pack to SLE 11 SP4. These steps are described in the SUSE Linux Enterprise 11 Deployment Guide.
- Upgrading from SUSE Linux Enterprise 11 SP4
Upgrading from SLE 11 SP4 to SLE 12 SP3 is only supported via an offline upgrade. Refer to Section 19.2, “Online and Offline Upgrade” for details.
- Upgrading from SUSE Linux Enterprise 12 GA to SP3
A direct upgrade from SLE 12 GA to SP3 is not supported. Upgrade to SLE 12 SP2 first.
- Upgrading from SUSE Linux Enterprise 12 SP1 / SP2 to SP3
Upgrading from SUSE Linux Enterprise 12 SP1 or SP2 to SP3 is supported.
- Upgrading from SUSE Linux Enterprise 12 LTSS GA / SP1 LTSS / SP2 to SP3
Updating any previous SLE 12 LTSS version to SP3 is supported.
Figure 19.1: Overview of Shortest Upgrade Paths #
19.2 Online and Offline Upgrade #
SUSE supports two different upgrade and migration methods. For more information about the terminology, see Section 18.1, “Terminology”. The methods are:
- Online
All upgrades that are executed from the running system are considered to be online. Examples: Connected through SUSE Customer Center, Subscription Management Tool (SMT), SUSE Manager using Zypper or YaST.
When migrating between Service Packs of the same major release, we suggest following Section 21.4, “Upgrading with the Online Migration Tool (YaST)” or Section 21.5, “Upgrading with Zypper”.
- Offline
Offline methods usually boot another operating system from which the installed SLE version is upgraded. Examples are: DVD, flash disk, ISO image, AutoYaST, “plain RPM” or PXE boot.
Important: SUSE Manager Clients
If your machine is managed by SUSE Manager, the upgrade procedure should be started in the management interface. For details, see Section 20.6, “Updating via SUSE Manager” and https://www.suse.com/documentation/suse-manager-3/singlehtml/book_suma_best_practices_31/book_suma_best_practices_31.html#bp.client.migration.
19.3 Preparing the System #
Before starting the upgrade procedure, make sure your system is properly prepared. Among others, preparation involves backing up data and checking the release notes.
19.3.1 Make Sure the Current System is Up-To-Date #
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
.
19.3.2 Read the Release Notes #
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 release notes locally in the directory
/usr/share/doc/release-notes
or online at
https://www.suse.com/releasenotes/.
19.3.3 Make a Backup #
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 /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.
19.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.bakroot #
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.
19.3.4 Migrate your MySQL Database #
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:
Log in to your SUSE Linux Enterprise 11 machine.
Create a dump file:
root #
mysqldump
-u root -p --all-databases > mysql_backup.sqlBy default,
mysqldump
does not dump theINFORMATION_SCHEMA
orperformance_schema
database. For more details refer to https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.Store your dump file, the configuration file
/etc/my.cnf
, and the directory/etc/mysql/
for later investigation (NOT installation!) in a safe place.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
.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.
Make sure you start the MariaDB server:
root #
systemctl
start mysqlIf you want to start the MariaDB server on every boot, enable the service:
root #
systemctl
enable mysqlVerify that MariaDB is running properly by connecting to the database:
root #
mysql
-u root -p
19.3.5 Migrate your PostgreSQL Database #
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:
- SLE11 SP3/SP4
/usr/lib/postgresql91/
to/usr/lib/postgresql94/
- SLE12 GA
/usr/lib/postgresql93/
to/usr/lib/postgresql94/
To perform the database migration, do the following:
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 SLE12 this means to install postgresql94-server and all the packages it depends on.
Install the package postgresql94-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
Stop the PostgreSQL server:
root #
/usr/sbin/rcpostgresql
stopRename your old data directory:
root #
mv
/var/lib/pgsql/data /var/lib/pgsql/data.oldCreate a new data directory:
root #
mkdir
-p /var/lib/pgsql/dataIf you have changed your configuration files in the old version, copy the files
postgresql.conf
pg_hba.conf
to your newdata
directory:root #
cp
/var/lib/pgsql/data.old/*.conf \ /var/lib/pgsql/dataInitialize your new database instance either manually with
initdb
or by starting and stopping PostgreSQL, which will do it automatically:root #
/usr/sbin/rcpostgresql
startroot #
/usr/sbin/rcpostgresql
stopStart the migration process and replace the OLD placeholder with the older version:
root #
pg_upgrade
\ --old-datadir "/var/lib/pgsql/data.old" \ --new-datadir "/var/lib/pgsql/data" \ --old-bindir "/usr/lib/postgresqlOLD/bin/" \ --new-bindir "/usr/lib/postgresql94/bin/"Start your new database instance:
root #
/usr/sbin/rcpostgresql
startCheck if the migration was successful. There is no general tool to automate this step. It depends on your use case how much and what you want to test.
Remove any old PostgreSQL packages and your old data directory:
root #
zypper
search -s postgresqlOLD | xargs zypper rm -uroot #
rm
-rf /var/lib/pgsql/data.old
19.3.6 Create Non-MD5 Server Certificates for Java Applications #
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:
Open a terminal and log in as
root
.Create a private key:
root #
openssl
genrsa -out server.key 1024If you want a stronger key, replace
1024
with a higher number, for example,4096
.Create a certificate signing request (CSR):
root #
openssl
req -new -key server.key -out server.csrSelf-sign the certificate:
root #
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crtCreate the PEM file:
root #
cat
server.key server.crt > server.pemPlace the files
server.crt
,server.csr
,server.key
, andserver.pem
in the respective directories where the keys can be found. For Tomcat, for example, this directory is/etc/tomcat/ssl/
.
19.3.7 Shut Down Virtual Machine Guests #
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.
19.3.8 Check the clientSetup4SMT.sh
Script on SMT Clients #
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
.
19.3.9 Disk Space #
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.
19.3.9.1 Checking Disk Space on Non-Btrfs File Systems #
Use the df
command to list available disk space. For
example, in Example 19.1, “List with df -h
”, the root partition is
/dev/sda3
(mounted as /
).
Example 19.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
19.3.9.2 Checking Disk Space on Btrfs Root File Systems #
If you use Btrfs as root file systems on your machine, make sure there is
enough free space. In the worst case, an upgrade needs as much disk space as the current root
file system (without /.snapshot
) for a new snapshot.
To display available disk space use the command:
root #
df
-h /
Check the available space on all other mounted partitions as well. 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
listroot #
snapper
delete NUMBERHowever, this may not help in all cases. Before migration, most snapshots occupy only little space.
19.3.10 Temporarily Disabling Kernel Multiversion Support #
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 15.1, “Enabling and Configuring Multiversion Support”.
19.4 Upgrading on IBM z Systems #
Upgrading a SUSE Linux Enterprise installation on z Systems requires the
Upgrade=1
kernel parameter, for example via the
parmfile. See Section 4.3, “The parmfile—Automating the System Configuration”.
19.5 IBM POWER: Starting an X Server #
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"