Jump to content
SUSE Linux Enterprise Server 15 SP1

Upgrade Guide

This book guides you through upgrades and updates of SUSE Linux Enterprise Server. Different approaches are described, for example upgrading from an installation DVD, via network boot, or a running system.

Publication Date: June 21, 2019
About This Guide
Available Documentation
Feedback
Documentation Conventions
1 Upgrade Paths and Methods
1.1 Supported Upgrade Paths to SLES 15 SP1
1.2 Online and Offline Upgrade
2 Life Cycle and Support
2.1 Terminology
2.2 Product Life Cycle
2.3 Module Dependencies and Life Cycles
2.4 Generating Periodic Life Cycle Report
2.5 Support Levels
2.6 Registering and Deregistering Machines with SUSEConnect
2.7 Identifying the SLE Version
3 Preparing the Upgrade
3.1 Make Sure the Current System Is Up-To-Date
3.2 Read the Release Notes
3.3 Make a Backup
3.4 Listing Installed Packages and Repositories
3.5 Upgrading from SUSE Linux Enterprise Server 11 SP4
3.6 Shut Down Virtual Machine Guests
3.7 Adjusting Your SMT Client Setup
3.8 Disk Space
3.9 Upgrading a Subscription Management Tool (SMT) Server
3.10 Temporarily Disabling Kernel Multiversion Support
3.11 Upgrading on IBM Z
3.12 IBM POWER: Starting an X Server
4 Upgrading Offline
4.1 Conceptual Overview
4.2 Starting the Upgrade from an Installation Medium
4.3 Starting the Upgrade from a Network Source
4.4 Upgrading SUSE Linux Enterprise
4.5 Upgrading with AutoYaST
4.6 Upgrading with SUSE Manager
4.7 Updating Registration Status after Rollback
4.8 Registering Your System
5 Upgrading Online
5.1 Conceptual Overview
5.2 Service Pack Migration Workflow
5.3 Canceling Service Pack Migration
5.4 Upgrading with the Online Migration Tool (YaST)
5.5 Upgrading with Zypper
5.6 Upgrading with Plain Zypper
5.7 Rolling Back a Service Pack
5.8 Upgrading with SUSE Manager
5.9 Upgrading from openSUSE Leap to SUSE Linux Enterprise Server
6 Backports of Source Code
6.1 Reasons for Backporting
6.2 Reasons against Backports
6.3 The Implications of Backports for Interpreting Version Numbers
6.4 Checking for Fixed Bugs and Backported Features
A GNU Licenses
A.1 GNU Free Documentation License
List of Examples
3.1 List with df -h

Copyright © 2006– 2019 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled GNU Free Documentation License.

For SUSE trademarks, see http://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.

About This Guide

There are different ways to upgrade SUSE Linux Enterprise Server. It is impossible to cover all combinations of boot, or installation server, automated installations or deploying images. This manual should help with selecting the appropriate method of upgrading your installation.

Upgrade Guide

This part will give you some background information on terminology, SUSE product lifecycles and Service Pack releases, and recommended upgrade policies.

1 Available Documentation

Note
Note: Online Documentation and Latest Updates

Documentation for our products is available at http://www.suse.com/documentation/, where you can also find the latest updates, and browse or download the documentation in various formats.

In addition, the product documentation is usually available in your installed system under /usr/share/doc/manual.

The following documentation is available for this product:

Article “Installation Quick Start

This Quick Start guides you step-by-step through the installation of SUSE® Linux Enterprise Server 15 SP1.

Book “Deployment Guide

Shows how to install single or multiple systems and how to exploit the product inherent capabilities for a deployment infrastructure. Choose from various approaches, ranging from a local installation or a network installation server to a mass deployment using a remote-controlled, highly-customized, and automated installation technique.

Book “Administration Guide

Covers system administration tasks like maintaining, monitoring and customizing an initially installed system.

Book “Virtualization Guide

Describes virtualization technology in general, and introduces libvirt—the unified interface to virtualization—and detailed information on specific hypervisors.

Book “Storage Administration Guide

Provides information about how to manage storage devices on a SUSE Linux Enterprise Server.

Book “AutoYaST Guide

AutoYaST is a system for unattended mass deployment of SUSE Linux Enterprise Server systems using an AutoYaST profile containing installation and configuration data. The manual guides you through the basic steps of auto-installation: preparation, installation, and configuration.

Book “Security Guide

Introduces basic concepts of system security, covering both local and network security aspects. Shows how to use the product inherent security software like AppArmor or the auditing system that reliably collects information about any security-relevant events.

Book “Security and Hardening Guide”

Deals with the particulars of installing and setting up a secure SUSE Linux Enterprise Server, and additional post-installation processes required to further secure and harden that installation. Supports the administrator with security-related choices and decisions.

Book “System Analysis and Tuning Guide

An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to efficiently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources.

Book “Repository Mirroring Tool for SLES 15 SP1

An administrator's guide to Subscription Management Tool—a proxy system for SUSE Customer Center with repository and registration targets. Learn how to install and configure a local SMT server, mirror and manage repositories, manage client machines, and configure clients to use SMT.

Book “GNOME User Guide

Introduces the GNOME desktop of SUSE Linux Enterprise Server. It guides you through using and configuring the desktop and helps you perform key tasks. It is intended mainly for end users who want to make efficient use of GNOME as their default desktop.

2 Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

For services and support options available for your product, refer to http://www.suse.com/support/.

Help for openSUSE is provided by the community. Refer to https://en.opensuse.org/Portal:Support for more information.

To report bugs for a product component, go to https://scc.suse.com/support/requests, log in, and click Create New.

User Comments

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/documentation/feedback.html and enter your comments there.

Mail

For feedback on the documentation of this product, you can also send a mail to doc-team@suse.com. Make sure to include the document title, the product version and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

3 Documentation Conventions

The following notices and typographical conventions are used in this documentation:

  • /etc/passwd: directory names and file names

  • PLACEHOLDER: replace PLACEHOLDER with the actual value

  • PATH: the environment variable PATH

  • ls, --help: commands, options, and parameters

  • user: users or groups

  • package name : name of a package

  • Alt, AltF1: a key to press or a key combination; keys are shown in uppercase as on a keyboard

  • File, File › Save As: menu items, buttons

  • x86_64 This paragraph is only relevant for the AMD64/Intel 64 architecture. The arrows mark the beginning and the end of the text block.

    System z, POWER This paragraph is only relevant for the architectures IBM Z and POWER. The arrows mark the beginning and the end of the text block.

  • Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

  • Commands that must be run with root privileges. Often you can also prefix these commands with the sudo command to run them as non-privileged user.

    root # command
    tux > sudo command
  • Commands that can be run by non-privileged users.

    tux > command
  • Notices

    Warning
    Warning: Warning Notice

    Vital information you must be aware of before proceeding. Warns you about security issues, potential loss of data, damage to hardware, or physical hazards.

    Important
    Important: Important Notice

    Important information you should be aware of before proceeding.

    Note
    Note: Note Notice

    Additional information, for example about differences in software versions.

    Tip
    Tip: Tip Notice

    Helpful information, like a guideline or a piece of practical advice.

1 Upgrade Paths and Methods

Abstract

SUSE® Linux Enterprise (SLE) allows to upgrade an existing system to the new version, for example, going from SLE 12 SP4 to the latest SLE 15 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.

1.1 Supported Upgrade Paths to SLES 15 SP1

Before you perform any migration, read Chapter 3, Preparing the Upgrade.

Important
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 15 SP1 on POWER (new: little endian!) is not supported.

Also, since SUSE Linux Enterprise 15 SP1 is 64-bit only, upgrades from any 32-bit SUSE Linux Enterprise 11 systems to SUSE Linux Enterprise 15 SP1 and later are not supported.

To make a cross-architecture upgrade, you need to perform a new installation.

Note
Note: Skipping Service Packs

Consecutively installing all Service Packs is the easiest upgrade path. For the SUSE Linux Enterprise 15 product line (GA and the following Service Packs) it is supported to skip one service pack when upgrading. For example, it is supported to upgrade from SLE 15 GA to 15 SP2 or from SLE 15 SP1 to 15 SP3.

Note
Note: Upgrading Major Releases

We recommend to do a fresh install when upgrading to a new Major Release, for example from SUSE Linux Enterprise 12 to SUSE Linux Enterprise 15.

Overview of Supported Upgrade Paths
Figure 1.1: Overview of Supported Upgrade Paths
Supported Upgrade Paths per Version
Upgrading from SUSE Linux Enterprise Server 11 GA / SP1 / SP2 / SP3

Upgrading from SLES 12 SP2 or older service packs directly is not supported. You need at least SLES 11 SP4 before you can proceed to SLES 15 SP1.

If you cannot do a fresh installation, first upgrade your installed SLES 11 service pack to SLES 11 SP4. This upgrade is described in the SLES 11 Deployment Guide.

Upgrading from SUSE Linux Enterprise Server11 SP4

Upgrading from SLES 11 SP4 is only supported via an offline upgrade. Refer to Section 1.2, “Online and Offline Upgrade” for details.

Upgrading from SUSE Linux Enterprise Server 12 GA / SP1 / SP2

Upgrading from SLES 12 SP2 or older service packs directly is not supported. You need at least SLES 12 SP3 before you can proceed to SLES 15 SP1.

If you cannot do a fresh installation, first upgrade your installed SLES 12 service pack to SLES 12 SP3. This upgrade is described in the SLES 12 Deployment Guide .

Upgrading from SUSE Linux Enterprise Server 12 SP3 / SP4

Upgrading from SLES 12 SP3 / SP4 is only supported via an offline upgrade. Refer to Section 1.2, “Online and Offline Upgrade” for details.

Upgrading from SUSE Linux Enterprise Server 15

Upgrading from SLES 15 is supported both online and offline. Refer to the following for details:

Upgrading from openSUSE Leap 15

Upgrading from openSUSE Leap 15 is supported. See Section 5.9, “Upgrading from openSUSE Leap to SUSE Linux Enterprise Server. Only the server installation of Leap is supported for an upgrade.

1.2 Online and Offline Upgrade

SUSE supports the following upgrade and migration methods. For more information about the terminology, see Section 2.1, “Terminology”. The methods are:

Online

Upgrades that are executed from the running operating system itself (system up and running state). Examples: online update with Zypper or YaST, connected through SUSE Customer Center or Repository Mirroring Tool (RMT), Salt Policy via SUSE Manager.

For details, see Chapter 5, Upgrading Online.

When migrating between Service Packs of the same major release, we suggest following Section 5.4, “Upgrading with the Online Migration Tool (YaST)” or Section 5.5, “Upgrading with Zypper”.

Offline

Upgrading offline implies that the operating system to be upgraded is not running (system down state). Instead, the installer for the target operating system is booted (for example, from the installation media, via network or via local boot loader), and performs the upgrade.

For details, see Chapter 4, Upgrading Offline.

Important
Important: SUSE Manager Clients

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Best Practices Guide, available at https://www.suse.com/documentation/suse-manager.

2 Life Cycle and Support

Abstract

This chapter provides background information on terminology, SUSE product lifecycles and Service Pack releases, and recommended upgrade policies.

2.1 Terminology

This section uses several terms. To understand the information, read the definitions below:

Backporting

Backporting is the act of adapting specific changes from a newer version of software and applying it to an older version. The most commonly used case is fixing security holes in older software components. Usually it is also part of a maintenance model to supply enhancements or (less commonly) new features.

Delta RPM

A delta RPM consists only of the binary diff between two defined versions of a package, and therefore has the smallest download size. Before being installed, the full RPM package is rebuilt on the local machine.

Downstream

A metaphor of how software is developed in the open source world (compare it with upstream). The term downstream refers to people or organizations like SUSE who integrate the source code from upstream with other software to build a distribution which is then used by end users. Thus, the software flows downstream from its developers via the integrators to the end users.

Extensions, Add-On Products

Extensions and third party add-on products provide additional functionality of product value to SUSE Linux Enterprise Server. They are provided by SUSE and by SUSE partners, and they are registered and installed on top of the base product SUSE Linux Enterprise Server.

LTSS

LTSS is the abbreviation for Long Term Service Pack Support, which is available as an extension for SUSE Linux Enterprise Server.

Major Release, General Availability (GA) Version

The major release of SUSE Linux Enterprise (or any software product) is a new version which brings new features and tools, decommissions previously deprecated components and comes with backward-incompatible changes. Major releases for example are SUSE Linux Enterprise 11 or 12.

Migration

Updating to a Service Pack (SP) by using the online update tools or an installation medium to install the respective patches. It updates all packages of the installed system to the latest state.

Migration Targets

Set of compatible products to which a system can be migrated, containing the version of the products/extensions and the URL of the repository. Migration targets can change over time and depend on installed extensions. Multiple migration targets can be selected, for example SLE 12 SP2 and SES2 or SLE 12 SP2 and SES3.

Modules

Modules are fully supported parts of SUSE Linux Enterprise Server with a different life cycle. They have a clearly defined scope and are delivered via online channel only. Registering at the SUSE Customer Center, RMT (Repository Mirroring Tool), or SUSE Manager is a prerequisite for being able to subscribe to these channels.

Package

A package is a compressed file in rpm format that contains all files for a particular program, including optional components like configuration, examples, and documentation.

Patch

A patch consists of one or more packages and may be applied by means of delta RPMs. It may also introduce dependencies to packages that are not installed yet.

Service Packs (SP)

Combines several patches into a form that is easy to install or deploy. Service packs are numbered and usually contain security fixes, updates, upgrades, or enhancements of programs.

Upstream

A metaphor of how software is developed in the open source world (compare it with downstream). The term upstream refers to the original project, author or maintainer of a software that is distributed as source code. Feedback, patches, feature enhancements, or other improvements flow from end users or contributors to upstream developers. They decide if the request will be integrated or rejected.

If the project members decide to integrate the request, it will show up in newer versions of the software. An accepted request will benefit all parties involved.

If a request is not accepted, it may be for different reasons. Either it is in a state that is not compliant with the project's guidelines, it is invalid, it is already integrated, or it is not in the interest or roadmap of the project. An unaccepted request makes it harder for upstream developers as they need to synchronize their patches with the upstream code. This practice is generally avoided, but sometimes it is still needed.

Update

Installation of a newer minor version of a package, which usually contains security or bug fixes.

Upgrade

Installation of a newer major version of a package or distribution, which brings new features. For a distinction between the upgrade options, see Section 1.2, “Online and Offline Upgrade”.

2.2 Product Life Cycle

SUSE has the following lifecycle for products:

  • SUSE Linux Enterprise Server has a 13-year lifecycle: 10 years of general support and three years of extended support.

  • SUSE Linux Enterprise Desktop has a 10-year lifecycle: seven years of general support and three years of extended support.

  • Major releases are made every four years. Service packs are made every 12-14 months.

SUSE supports previous service packs for six months after the release of the new service pack. Figure 2.1, “Major Releases and Service Packs” depicts some mentioned aspects.

Major Releases and Service Packs
Figure 2.1: Major Releases and Service Packs

If you need additional time to design, validate and test your upgrade plans, Long Term Service Pack Support can extend the support you get by an additional 12 to 36 months in 12-month increments. This gives you a total of 2 to 5 years of support on any service pack. For details, see Figure 2.2, “Long Term Service Pack Support”.

Long Term Service Pack Support
Figure 2.2: Long Term Service Pack Support

For more information refer to https://www.suse.com/products/long-term-service-pack-support/.

Refer to https://www.suse.com/lifecycle for more information about lifecycles, release frequency, and the overlay support period.

2.3 Module Dependencies and Life Cycles

For a list of modules, their dependencies and lifecycles see the Article “Modules and Extensions Quick Start”.

2.4 Generating Periodic Life Cycle Report

SUSE Linux Enterprise Server can regularly check for changes in the support status of all installed products and send the report via e-mail in case of changes. To generate the report, install the zypper-lifecycle-plugin with zypper in zypper-lifecycle-plugin.

Enable the report generation on your system with systemctl:

root # systemctl enable lifecycle-report

The recipient and subject of the report e-mail, and the report generation period can be configured in the file /etc/sysconfig/lifecycle-report with any text editor. The settings MAIL_TO and MAIL_SUBJ define the mail recipient and subject, while DAYS sets the interval at which the report is generated.

The report displays changes in the support status after the change occurred and not in advance. If the change occurs right after the generation of the last report, it can take up to 14 days until you are notified of the change. Take this into account when setting the DAYS option. Change the following configuration entries to fit your requirements:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

The latest report is available in the file /var/lib/lifecycle/report. The file contains two sections. The first section informs about the end of support for used products. The second section lists packages with their support end dates and update availability.

2.5 Support Levels

The range for extended support levels starts from year 10 and ends in year 13. These contain continued L3 engineering level diagnosis and reactive critical bug fixes. With these support levels, you will receive updates for trivially exploitable root exploits in the kernel and other root exploits directly executable without user interaction. Furthermore, they support existing workloads, software stacks, and hardware with limited package exclusion list. Find an overview in Table 2.1, “Security Updates and Bug Fixes”.

Table 2.1: Security Updates and Bug Fixes
 

General Support for Most Recent Service Pack (SP)

General Support for Previous SP, with LTSS

Extended Support with LTSS

Feature

Year 1-5

Year 6-7

Year 8-10

Year 4-10

Year 10-13

Technical Services

Yes

Yes

Yes

Yes

Yes

Access to Patches and Fixes

Yes

Yes

Yes

Yes

Yes

Access to Documentation and Knowledge Base

Yes

Yes

Yes

Yes

Yes

Support for Existing Stacks and Workloads

Yes

Yes

Yes

Yes

Yes

Support for New Deployments

Yes

Yes

Limited (Based on partner and customer requests)

Limited (Based on partner and customer requests)

No

Enhancement Requests

Yes

Limited (Based on partner and customer requests)

Limited (Based on partner and customer requests)

No

No

Hardware Enablement and Optimization

Yes

Limited (Based on partner and customer requests)

Limited (Based on partner and customer requests)

No

No

Driver updates via SUSE SolidDriver Program (formerly PLDP)

Yes

Yes

Limited (Based on partner and customer requests)

Limited (Based on partner and customer requests)

No

Backport of Fixes from Recent SP

Yes

Yes

Limited (Based on partner and customer requests)

N/A

N/A

Critical Security Updates

Yes

Yes

Yes

Yes

Yes

Defect Resolution

Yes

Yes

Limited (Severity Level 1 and 2 defects only)

Limited (Severity Level 1 and 2 defects only)

Limited (Severity Level 1 and 2 defects only)

2.6 Registering and Deregistering Machines with SUSEConnect

On registration, the system receives repositories from the SUSE Customer Center (see https://scc.suse.com/) or a local registration proxy like SMT. The repository names map to specific URIs in the customer center. To list all available repositories on your system, use zypper as follows:

root # zypper repos -u

This gives you a list of all available repositories on your system. Each repository is listed by its alias, name and whether it is enabled and will be refreshed. The option -u gives you also the URI from where it originated.

To register your machine, run SUSEConnect, for example:

root # SUSEConnect -r REGCODE

To deregister your machine, you can use SUSEConnect too:

root # SUSEConnect --de-register

To check your locally installed products and their status, use the following command:

root # SUSEConnect -s

2.7 Identifying the SLE Version

If you need to identify the version of an SLE installation, check the content of the file /etc/os-release.

A machine readable XML output is available with zypper:

tux > zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

3 Preparing the Upgrade

Abstract

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

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

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

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

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

3.5 Upgrading from SUSE Linux Enterprise Server 11 SP4

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

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

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

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

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

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

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

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

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 Book “Storage Administration Guide”, Chapter 1 “Overview of File Systems in Linux”, 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 Upgrading a Subscription Management Tool (SMT) Server

A server running SMT requires a special upgrade procedure. Please refer to Book “Repository Mirroring Tool for SLES 15 SP1”, Chapter 2 “Migrate from SMT to RMT” in the Repository Management Tool Guide.

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 Book “Deployment Guide”, Chapter 19 “Installing Multiple Kernel Versions”, Section 19.1 “Enabling and Configuring Multiversion Support”.

3.11 Upgrading on IBM Z

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

3.12 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"

4 Upgrading Offline

Abstract

This chapter describes how to upgrade an existing SUSE Linux Enterprise installation using YaST which is booted from an installation medium. The YaST installer can, for example, be started from a DVD, over the network, or from the hard disk the system resides on.

4.1 Conceptual Overview

Before upgrading your system, read Chapter 3, Preparing the Upgrade first.

To upgrade your system, boot from an installation source, as you would do for a fresh installation. However, when the boot screen appears, you need to select Upgrade (instead of Installation). The upgrade can be started from:

4.2 Starting the Upgrade from an Installation Medium

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

Procedure 4.1: Manually Upgrading to SUSE Linux Enterprise Server 15 SP1
  1. Select and prepare a boot medium, see Book “Deployment Guide.

  2. Insert the Installer DVD for SUSE Linux Enterprise Server 15 SP1 and boot your machine. A Welcome screen is displayed, followed by the boot screen.

  3. Optional: To force the installer to only install packages from the DVD and not from network sources, add the boot option media_upgrade=1.

  4. Start up the system by selecting Upgrade in the boot menu.

  5. Proceed with the upgrade process as described in Section 4.4, “Upgrading SUSE Linux Enterprise”.

4.3 Starting the Upgrade from a Network Source

To start an upgrade from a network installation source, make sure that the following requirements are met:

Requirements for Upgrading from a Network Installation Source
Network Installation Source

A network installation source is set up according to Book “Deployment Guide”, Chapter 14 “Setting Up a Network Installation Source”.

Network Connection and Network Services

Both the installation server and the target machine must have a functioning network connection. Required network services are:

  • Domain Name Service

  • DHCP (only needed for booting via PXE, IP can be set manually during setup)

  • OpenSLP (optional)

Boot Medium

A bootable SUSE Linux Enterprise DVD, ISO image or functioning PXE setup. For details about booting via PXE, see Book “Deployment Guide”, Chapter 15 “Preparing Network Boot Environment”, Section 15.4 “Preparing the Target System for PXE Boot”. Refer to Book “Deployment Guide”, Chapter 11 “Remote Installation” for in-depth information on starting the upgrade from a remote server.

4.3.1 Manually Upgrading via Network Installation Source—Booting from DVD

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

  1. Insert the Installer DVD for SUSE Linux Enterprise Server 15 SP1 and boot your machine. A Welcome screen is displayed, followed by the boot screen.

  2. Select the type of network installation source you want to use (FTP, HTTP, NFS, SMB, or SLP). Usually you get this choice by pressing F4, but in case your machine is equipped with UEFI instead of a traditional BIOS, you may need to manually adjust boot parameters. For details, see Book “Deployment Guide”, Chapter 7 “Boot Parameters” and Book “Deployment Guide”, Chapter 8 “Installation Steps”.

  3. Proceed with the upgrade process as described in Section 4.4, “Upgrading SUSE Linux Enterprise”.

4.3.2 Manually Upgrading via Network Installation Source—Booting via PXE

To perform an upgrade from a network installation source using PXE boot, proceed as follows:

  1. Adjust the setup of your DHCP server to provide the address information needed for booting via PXE. For details, see Book “Deployment Guide”, Chapter 15 “Preparing Network Boot Environment”, Section 15.1 “Setting Up a DHCP Server”.

  2. Set up a TFTP server to hold the boot image needed for booting via PXE. Use the Installer DVD for SUSE Linux Enterprise Server 15 SP1 for this or follow the instructions in Book “Deployment Guide”, Chapter 15 “Preparing Network Boot Environment”, Section 15.2 “Setting Up a TFTP Server”.

  3. Prepare PXE Boot and Wake-on-LAN on the target machine.

  4. Initiate the boot of the target system and use VNC to remotely connect to the installation routine running on this machine. For more information, see Book “Deployment Guide”, Chapter 11 “Remote Installation”, Section 11.3 “Monitoring Installation via VNC”.

  5. Proceed with the upgrade process as described in Section 4.4, “Upgrading SUSE Linux Enterprise”.

4.4 Upgrading SUSE Linux Enterprise

Before you upgrade your system, read Chapter 3, Preparing the Upgrade first. To perform an automated migration, proceed as follows:

  1. After you have booted (either from an installation medium or the network), select the Upgrade entry on the boot screen.

    Warning
    Warning: Wrong Choice May Lead to Data Loss

    Make sure you selected Upgrade at this point. In case you select Installation by mistake, your data partition will be overwritten with a fresh installation.

    YaST starts the installation system.

  2. On the Welcome screen, choose Language and Keyboard. Proceed with Next.

    YaST checks your partitions for already installed SUSE Linux Enterprise systems.

  3. On the Select for Upgrade screen, select the partition to upgrade and click Next.

  4. YaST mounts the selected partition and displays the license agreement for the upgraded product. To continue, accept the license.

  5. On the Previously Used Repositories screen, adjust the status of the repositories: enable those you want to include in the upgrade process and disable any repositories that are no longer needed. Proceed with Next.

  6. The next step depends on whether the upgraded system is registered or not.

    1. If the system is not registered, YaST displays a pop-up message suggesting using a second installation medium, the SLE-15-SP1-Packages medium.

      If you do not have that medium the system cannot be upgraded without registration.

    2. If the system is registered, YaST will show possible migration targets and a summary.

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

  7. In the next dialog you can optionally add an additional installation medium. If you have additional installation media, activate the I would like to install an additional Add On Product option and specify the media type.

  8. Review the Installation Settings for the upgrade.

  9. If all settings are according to your wishes, start the installation and removal procedure by clicking Update.

  10. After the upgrade process was finished successfully, check for any orphaned packages. Orphaned packages are packages which belong to no active repository anymore. The following command gives you a list of these:

    tux > zypper packages --orphaned

    With this list, you can decide if a package is still needed or can be uninstalled safely.

If the machine to upgrade is an SMT client, and the upgrade fails, see Procedure 3.1, “De-registering a SUSE Linux Enterprise Client from an SMT Server” and restart the upgrade procedure afterward.

4.5 Upgrading with AutoYaST

The upgrade process can be executed automatically. For details, see Book “AutoYaST Guide”, Chapter 4 “Configuration and Installation Options”, Section 4.10 “Upgrade”.

4.6 Upgrading with SUSE Manager

SUSE Manager is a server solution for providing updates, patches, and security fixes for SUSE Linux Enterprise clients. It comes with a set of tools and a Web-based user interface for management tasks. See https://www.suse.com/products/suse-manager/ for more information about SUSE Manager.

With SUSE Manager you can perform a system upgrade. With the integrated AutoYaST technology, upgrades from one major version to the next are possible.

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Best Practices Guide, available at https://www.suse.com/documentation/suse-manager.

4.7 Updating Registration Status after Rollback

When performing a service pack upgrade, it is necessary to change the configuration on the registration server to provide access to the new repositories. If the upgrade process is interrupted or reverted (via restoring from a backup or snapshot), the information on the registration server is inconsistent with the status of the system. This may lead to you being prevented from accessing update repositories or to wrong repositories being used on the client.

When a rollback is done via Snapper, the system will notify the registration server to ensure access to the correct repositories is set up during the boot process. If the system was restored with another method, or the communication with the registration server failed, trigger the rollback on the client manually. An example for manually triggering a rollback can be that the server was not accessible because of network issues. To do a rollback, execute:

tux > sudo snapper rollback

We suggest always checking that the correct repositories are set up on the system, especially after refreshing the service using:

tux > sudo zypper ref -s

This functionality is available in the rollback-helper package.

4.8 Registering Your System

If the system was not registered before running the upgrade you can register your system at any time using the Product Registration module in YaST.

Registering your systems has these advantages:

  • Eligibility for support

  • Availability of security updates and bug fixes

  • Access to SUSE Customer Center

  1. Start YaST and select Software › Product Registration to open the Registration dialog.

  2. Provide the E-mail address associated with the SUSE account you or your organization uses to manage subscriptions. In case you do not have a SUSE account yet, go to the SUSE Customer Center home page (https://scc.suse.com/) to create one.

  3. Enter the Registration Code you received with your copy of SUSE Linux Enterprise Server.

  4. If one or more local registration servers are available on your network, you can choose one of them from a list.

  5. To start the registration, proceed with Next.

    After successful registration, YaST lists extensions, add-ons, and modules that are available for your system. To select and install them, proceed with Book “Deployment Guide”, Chapter 18 “Installing Modules, Extensions, and Third Party Add-On Products”, Section 18.1 “Installing Modules and Extensions from Online Channels”.

5 Upgrading Online

Abstract

SUSE offers an intuitive graphical and a simple command line tool to upgrade a running system to a new service pack. They provide support for rollback of service packs and more. This chapter explains how to do a service pack upgrade step by step with these tools.

5.1 Conceptual Overview

SUSE releases new service packs for the SUSE Linux Enterprise family at regular intervals. To make it easy for customers to migrate to a new service pack and minimize downtime, SUSE supports migrating online while the system is running.

Starting with SLE 12, YaST Wagon has been replaced by YaST migration (GUI) and Zypper migration (command line). This has the following advantages:

  • The system is always in a defined state until the first RPM is updated.

  • Canceling is possible until the first RPM is updated.

  • Simple recovery, if there is an error.

  • It is possible to do a rollback via system tools—no backup or restore needed.

  • Use of all active repositories.

  • The ability to skip a service pack

Warning
Warning: Online Migration Not Supported for Major Releases

The online migration is only supported for migrating between service packs. Online migration is not supported for upgrading to new major releases. For details, see Chapter 1, Upgrade Paths and Methods.

Use the offline migration to upgrade to a new major release. For details, see Chapter 4, Upgrading Offline.

5.2 Service Pack Migration Workflow

A service pack migration can be executed by either YaST, zypper, or AutoYaST.

Before you can start a service pack migration, your system must be registered at the SUSE Customer Center or a local RMT server. SUSE Manager can also be used.

Regardless of the method, a service pack migration consists of the following steps:

  1. Find possible migration targets on your registered systems.

  2. Select one migration target.

  3. Request and enable new repositories.

  4. Run the migration.

The list of migration targets depends on the products you have installed and registered. If you have an extension installed for which the new SP is not yet available, it could be that no migration target is offered to you.

The list of migration targets available for your host will always be retrieved from the SUSE Customer Center and depend on products or extensions installed.

5.3 Canceling Service Pack Migration

A service pack migration can only be canceled at specific stages during the migration process:

  1. Until the package upgrade starts, there are only minimal changes on the system, like for services and repositories. Restore /etc/zypp/repos.d/* to revert to the former state.

  2. After the package upgrade starts, you can revert to the former state by using a Snapper snapshot (see Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper”).

  3. After the migration target was selected, SUSE Customer Center changes the repository data. To revert this state manually, use SUSEConnect --rollback.

5.4 Upgrading with the Online Migration Tool (YaST)

To perform a service pack migration with YaST, use the Online Migration tool. By default, YaST does not install any packages from a third-party repository. If a package was installed from a third-party repository, YaST prevents packages from being replaced with the same package coming from SUSE.

Note
Note: Reduce Installation Size

When performing the Service Pack migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.

To change this default behavior and allow only required packages, adjust the solver.onlyRequires option in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Additionally, edit the file /etc/zypp/zypper.conf and change the installRecommends option.

installRecommends=false

This changes the behavior of all package operations, such as the installation of patches or new packages. To change the behavior of Zypper for a single invocation, add the parameter --no-recommends to your command line.

To start the service pack migration, do the following:

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

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

  3. If you are an LTSS subscriber, make sure that the LTSS extension repository is active.

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

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

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

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

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

  9. In case the migration tool offers update repositories, it is recommended to proceed with Yes.

  10. If the Online Migration tool finds obsolete repositories coming from DVD or a local server, it is highly recommended to disable them. Obsolete repositories are from a previous SP. Any old repositories from SUSE Customer Center or RMT are removed automatically.

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

  12. After the successful migration restart your system.

5.5 Upgrading with Zypper

To perform a service pack migration with Zypper, use the command line tool zypper migration from the package zypper-migration-plugin.

Note
Note: Reduce Installation Size

When performing the Service Pack migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.

To change this default behavior and allow only required packages, adjust the solver.onlyRequires option in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Additionally, edit the file /etc/zypp/zypper.conf and change the installRecommends option.

installRecommends=false

This changes the behavior of all package operations, such as the installation of patches or new packages. To change the behavior of Zypper for a single invocation, add the parameter --no-recommends to your command line.

To start the service pack migration, do the following:

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

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

    tux > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. If you are an LTSS subscriber, make sure that the LTSS extension repository is active.

  4. Run zypper migration:

    tux > sudo zypper migration
    Executing 'zypper  patch-check'
    
    Refreshing service 'SUSE_Linux_Enterprise_Server_12_x86_64'.
    Loading repository data...
    Reading installed packages...
    0 patches needed (0 security patches)
    
    Available migrations:
    
        1 | SUSE Linux Enterprise Server 12 SP1 x86_64
        2 | SUSE Linux Enterprise Server 12 SP2 x86_64

    Some notes about the migration process:

    • If more than one migration target is available for your system, Zypper allows you to select one SP from the list. This is the same as skipping one or more SPs. Keep in mind, online migration for base products (SLES, SLED) remains available only between the SPs of a major version.

    • By default, Zypper uses the option --no-allow-vendor-change which is passed to zypper dup. If a package was installed from a third-party repository, this option prevents packages from being replaced with the same package coming from SUSE.

    • If Zypper finds obsolete repositories coming from DVD or a local server, it is highly recommended to disable them. Old SUSE Customer Center or RMT repositories are removed automatically.

  5. 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 ShiftPage ↑ or ShiftPage ↓ keys to scroll in your shell.

  6. After successful migration restart your system.

5.6 Upgrading with Plain Zypper

If your system is not registered because you do not have access to the Internet or a registration server, migrating to a new service pack is not possible with YaST Migration or zypper migration. In this case you can still migrate to a new service pack with plain Zypper and some manual interactions.

Important
Important: For Unregistered Systems Only

This migration path to a new service pack is only supported for unregistered systems that do not have access to the Internet or a registration server. This may, for example, be the case for machines in a specially protected network. In case you have a registered system, use YaST or Zypper migration.

Important
Important: Installation Sources

This migration path requires you to provide the installation sources for the new service pack in a place that can be accessed by the machine you are going to migrate. This can for example be achieved by setting up an RMT server or an SLP server.

It is also required that the system has access to an up-to-date update repository for the installed product version.

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

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

    tux > sudo zypper patch --updatestack-only
  3. 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 a way they are no longer compatible). To get the list, run

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

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

    tux > sudo zypper repos -u

    In the following you need to rewrite the repository URLs so they point to the respective repositories for the new service pack (SLE-15 needs to be replaced with SLE-15-SP1. If the URL for a repository looks like this:

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

    it needs to be changed to

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP1-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. Add a new repository and remove the corresponding old one afterwards:

      tux > sudo zypper addrepo -f URL NAME-15-SP1
      tux > sudo zypper removerepo  NAME
    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.

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

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

    tux > sudo zypper refresh -f -s

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

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

    tux > 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. In case problems occur, fix them before proceeding. In case the test run succeeds, perform the real migration by running

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

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

    tux > sudo zypper packages --orphaned

    Compare the new list with the one you generated before starting the migration. In case new packages appear in the list, it may be because they were moved to a different module in the new service pack. In case 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:

    tux > sudo zypper install --no-recommends LIST OF PACKAGES
  8. You have successfully migrated to a new service pack!

5.7 Rolling Back a Service Pack

If a service pack does not work for you, SUSE Linux Enterprise supports reverting the system to the state before the service pack migration was started. Prerequisite is a Btrfs root partition with snapshots enabled (this is the default when installing SLES 12). See Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper” for details.

  1. Get a list of all Snapper snapshots:

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

  2. 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 12 and boot it.

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

    tux > sudo snapper rollback

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

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

      tux > sudo zypper ref -fs
    2. Get a list of active repositories by running

      tux > 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 12 SP1 to SLES 12 SP2, the list must contain the SP1 repositories, and not the repositories SLES12-SP2-Pool and SLES12-SP2-Updates.

      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 Life Cycles”.

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

      tux > sudo SUSEConnect --status

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

      tux > sudo SUSEConnect --rollback

Now you have successfully reverted the system to the state that was captured immediately before the service pack migration was started.

5.8 Upgrading with SUSE Manager

SUSE Manager is a server solution for providing updates, patches, and security fixes for SUSE Linux Enterprise clients. It comes with a set of tools and a Web-based user interface for management tasks. See https://www.suse.com/products/suse-manager/ for more information about SUSE Manager.

SP Migration allows migrating from one Service Pack (SP) to another within one major version (for example, from SLES 12 SP1 to 12 SP2).

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Best Practices Guide, available at https://www.suse.com/documentation/suse-manager.

5.9 Upgrading from openSUSE Leap to SUSE Linux Enterprise Server

You can upgrade an openSUSE installation online to SUSE Linux Enterprise Server. The procedure is analogous to Section 5.5, “Upgrading with Zypper”, but some additional steps are required. Before executing this procedure on a production system, we recommend to first run it on a test system that replicates your production setup.

To see for which openSUSE Leap versions a migration is supported, read Section 1.1, “Supported Upgrade Paths to SLES 15 SP1.

Warning
Warning: Not All openSUSE Packages Can Be Migrated

The openSUSE repositories provide more packages than are available in the SUSE Linux Enterprise Server repositories. If you have any of these packages installed, they will no longer receive updates after the migration. These packages will be removed when following the procedure below.

Make sure that all packages you need for operating your system are available in the SUSE Linux Enterprise Server repository. You can also check if the packages are available in the SUSE Package Hub repository. For details, see Book “Deployment Guide”, Chapter 18 “Installing Modules, Extensions, and Third Party Add-On Products”, Section 18.3 “SUSE Package Hub”.

To migrate from openSUSE Leap, execute the following procedure:

  1. Switch to a TTY, for example by pressing CtrlAltF1. Then log in as root.

  2. Install SUSEConnect.

    root # zypper in SUSEConnect
  3. Register at SCC to get the SUSE Linux Enterprise Server repositories.

    root # SUSEConnect -r REGISTRATION_CODE -p SLES/15.1/x86_64
  4. List and disable all openSUSE repositories on your system.

    root # zypper lr
    root # zypper mr -d REPO_IDS

    Replace REPO_IDS with a space character separated list of all enabled openSUSE repositories.

  5. Now add the modules you need for your installation.

    root # SUSEConnect --list-extensions
    [...]
    root # SUSEConnect -p sle-module-basesystem/15.1/x86_64

    To have replacements for most Leap packages, we recommend to enable the Basesystem, Desktop Applications, Server Applications and Legacy modules. Additionally, we recommend to enable the SUSE Package Hub.

  6. Migrate installed packages to the SUSE Linux Enterprise Server repositories.

    root # zypper dup --force-resolution
  7. Remove orphaned packages.

    root # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  8. Finally, reboot the system.

6 Backports of Source Code

Abstract

SUSE extensively uses backports, for example for the migration of current software fixes and features into released SUSE Linux Enterprise packages. The information in this chapter explains why it can be misleading to compare version numbers to judge the capabilities and the security of SUSE Linux Enterprise software packages. This chapter also explains how SUSE keeps the system software secure and current while maintaining compatibility for your application software on top of SUSE Linux Enterprise products. You will also learn how to check which public security issues actually are addressed in your SUSE Linux Enterprise system software, and the current status of your software.

6.1 Reasons for Backporting

Upstream developers are primarily concerned with advancing the software they develop. Often they combine fixing bugs with introducing new features which have not yet received extensive testing and which may introduce new bugs.

For distribution developers, it is important to distinguish between:

  • bugfixes with a limited potential for disrupting functionality; and

  • changes that may disrupt existing functionality.

Usually, distribution developers do not follow all upstream changes when a package has become part of a released distribution. Usually they stick instead with the upstream version that they initially released and create patches based on upstream changes to fix bugs. This practice is known as backporting.

Distribution developers generally will only introduce a newer version of software in two cases:

  • when the changes between their packages and the upstream versions have become so large that backporting is no longer feasible, or

  • for software that inherently ages badly, like anti-malware software.

SUSE uses backports extensively as we strike a good balance between several concerns for enterprise software. The most important of them are:

  • Having stable interfaces (APIs) that software vendors can rely on when building products for use on SUSE's enterprise products.

  • Ensuring that packages used in the release of SUSE's enterprise products are of the highest quality and have been thoroughly tested, both in themselves and as part of the whole enterprise product.

  • Maintaining the various certifications of SUSE's enterprise products by other vendors, like certifications for Oracle or SAP products.

  • Allowing SUSE's developers to focus on making the next product version, rather than spreading their focus thinly across a wide range of releases.

  • Keeping a clear view of what is in a particular enterprise release, so that our support can provide accurate and timely information about it.

6.2 Reasons against Backports

It is a general policy rule that no new upstream versions of a package are introduced into our enterprise products. This rule is not an absolute rule however. For certain types of packages, in particular anti-virus software, security concerns weigh heavier than the conservative approach that is preferable from the perspective of quality assurance. For packages in that class, occasionally newer versions are introduced into a released version of an enterprise product line.

Sometimes also for other types of packages the choice is made to introduce a new version rather than a backport. This is done when producing a backport is not economically feasible or when there is a very relevant technical reason to introduce the newer version.

6.3 The Implications of Backports for Interpreting Version Numbers

Because of the practice of backporting, one cannot simply compare version numbers to determine whether a SUSE package contains a fix for a particular issue or has had a particular feature added to it. With backporting, the upstream part of a SUSE package's version number merely indicates what upstream version the SUSE package is based on. It may contain bug fixes and features that are not in the corresponding upstream release, but that have been backported into the SUSE package.

One particular area where this limited value of version numbers when backporting is involved can cause problems is with security scanning tools. Some security vulnerability scanning tools (or particular tests in such tools) operate solely on version information. These tools and tests are therefore prone to generating false positives (when a piece of software is incorrectly identified as vulnerable) when backports are involved. When evaluating reports from security scanning tools, always check whether an entry is based on a version number or on an actual vulnerability test.

6.4 Checking for Fixed Bugs and Backported Features

There are several locations where information regarding backported bug fixes and features are stored:

  • The package's changelog:

    tux > rpm -q --changelog name-of-installed-package
    tux > rpm -qp --changelog packagefile.rpm

    The output briefly documents the change history of the package.

  • The package changelog may contain entries like bsc#1234 (Bugzilla Suse.Com) that refer to bugs in SUSE's Bugzilla tracking system or links to other bugtracking systems. Because of confidentiality policies, not all such information may be accessible to you.

  • A package may contain a /usr/share/doc/PACKAGENAME/README.SUSE file which contains general, high-level information specific to the SUSE package.

  • The RPM source package contains the patches that were applied during the building of the regular binary RPMs as separate files that can be interpreted if you are familiar with reading source code. See Book “Administration Guide”, Chapter 6 “Managing Software with Command Line Tools”, Section 6.1.2.5 “Installing or Downloading Source Packages” for installing sources of SUSE Linux Enterprise software. See Book “Administration Guide”, Chapter 6 “Managing Software with Command Line Tools”, Section 6.2.5 “Installing and Compiling Source Packages” for building packages on SUSE Linux Enterprise. See the Maximum RPM book for details about software package builds for SUSE Linux Enterprise.

  • For security bug fixes, consult the SUSE security announcements. These often refer to bugs through standardized names like CAN-2005-2495 which are maintained by the Common Vulnerabilities and Exposures (CVE) project.

Print this page