In the release notes you can find additional information on what has changed since the previous release of SUSE Linux Enterprise. Please verify there if your specific hardware or set up needs special considerations, which of your favourite specific software packages have changed significantly, and which precautions you should take in addition to the general recommendations of this section. The Release Notes also provide last minute information and known issues, that couldn't make it to the manual on time.

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

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 as well as some of the 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.

Before starting your update, make note of the root partition. The command df / lists the device name of the root partition. For example, in Example 4.1, “List with df -h”, the root partition to write down is /dev/sda3 (mounted as /).

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       39G  1.6G   37G   4% /windows/C
/dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

Software tends to “grow” from version to version. Therefore, take a look at the available partition space with df before updating. If you suspect you are running short of disk space, secure your data before updating and repartitioning your system. 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.

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.

In order to do an online update, the following requirements must be met. Make sure to also read Section 4.3, “General Preparations for Updating”.

Important: Always Run a Complete Online Migration

The online migration always has to be completed from beginning to end. If an online migration is interrupted in between, the system will be corrupted beyond recovery.

Updating your system via online migration is done from within the running system. You only need to reboot once, after the update is completed.

4.4.4.1 Requirements #

In order to do an online update, the following requirements must be met. Make sure to also read Section 4.3, “General Preparations for Updating”.

Product Registration

In order to be able to connect to the update repositories, your product needs to be registered. If this is not the case, either run the SUSE Customer Center Configuration module in YaST or the suse_register command line tool to start the registration.

Run an Online Update

Make sure the currently installed version has the latest patches installed. Run an Online Update prior to the Online Migration. When using a graphical interface, start the YaST Online Update or the updater applet. On the command line, run the following commands (the last command needs to be run twice):

zypper ref -s
zypper update -t patch
zypper update -t patch

Reboot the system if needed.

See Chapter 1, YaST Online Update, Administration Guide or at Section “Updating Software with Zypper”, Chapter 7, Managing Software with Command Line Tools, Administration Guide. for more information. on the online update tools.

Third-Party Software

If your setup involves third-party software or add-on software, test this procedure on another machine to make sure that the dependencies are not broken by the update.

Important: Always Run a Complete Online Migration

The online migration always needs to be completed from beginning to end. If an online migration is interrupted in between, the system is corrupted beyond recovery.

4.4.4.2 Online Migration with YaST Wagon #

Note

The online migration with YaST Wagon is only available prior to SUSE Linux Enterprise Server 12.

1. When all requirements are met (see Section 4.4.4.1, “Requirements”), the update applet in the tray will display a message that a distribution upgrade is available. Click it to start YaST Wagon. Alternatively run /usr/sbin/wagon as root from the command line.

2. Confirm the Welcome dialog with Next.

3. If Wagon finds that the requirements are not met (required maintenance updates are available but not yet installed) it will do an automatic self-update, which may require a reboot. Follow the on-screen instructions.

4. Choose the update method in the following dialog. Choose Customer Center to use the default setup (recommended).

   Click Custom URL to manually choose the software repositories used for the online migration. A list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete repositories. Add the SP2 update source(s). This can either be the SP2 installation media or the SP2-Core and SP2-Updates repositories. Click OK to return to the Update Method dialog.

   If you want to review changes to the repository setup caused by the update process, select Check Automatic Repository Changes.

   Proceed with Next.

5. The system will be re-registered. During this process the SP2-Core and SP2-Updates repositories will be added to the system (see Section 4.7.2, “Repository Model” for more information). Confirm the addition of the repositories.

6. If you have selected Check Automatic Repository Changes in the Update Method dialog, the list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete repositories. Proceed with OK when finished.

7. Choose the migration type:

   Full migration

   Updates all packages to the latest SP2 level.

   Minimal Migration

   Updates a minimal set of packages to the latest SP2 level.

   Click Advanced to manually select the repositories used for upgrading.

   Confirm your selection.

8. The Distribution Upgrade Settings screen opens, presenting a summary of the update configuration. The following sections are available:

   Add-On Products

   You may add SUSE Linux Enterprise Server add-on products or third-party products here.

   Update Options

   Lists the actions that will be performed during the update. You can choose whether to download all packages before installing them (default, recommended), or whether to download and install packages one by one.

   Packages

   Statistical overview of the update.

   Backup

   Set backup options.

   Click Next and Start The Update to proceed.

   

   Important: Aborting the Online Migration

   It is safe to abort the online migration on this screen prior to clicking Start The Update and on all previous screens. Click Abort to leave the update procedure and restore the system to the state it was in prior to starting YaST wagon. Follow the instructions on screen and perform a re-registration before leaving Wagon to remove the SP2 repositories from your system.

9. During the update procedure the following steps are executed:

   1. Packages will be updated.

   2. The system will be rebooted (press OK).

   3. The newly updated system will be re-registered.

10. Your system has been successfully updated to Service Pack 2.

As an alternative to the Online Migration (see Section 4.4.4, “Online Migration” for details) you may also update your system by booting from an installation source—either a DVD or a network installation source. The update will start like a normal installation.

Service Pack 2 ISO images can be obtained from http://download.suse.com/. Either burn it to a DVD or prepare a network installation source as described in Section 11.2, “Setting Up the Server Holding the Installation Sources”.

As an alternative to downloading the updates for each single client system from the SUSE update server, it is possible to use the Subscription Management Tool (SMT) for SUSE Linux Enterprise to mirror the updates to a local server.

This tool acts as SUSE Customer Center proxy both for client registrations and as software update repository. The SMT documentation at http://www.suse.com/doc/smt11/ gives an overview of its features as well as instructions on how to implement it.

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.

The SUSE Manager documentation at http://www.suse.com/doc/suse_manager/ gives an overview of its features as well as instructions on how to set up server and clients.

You may upgrade your system by booting from an installation source—either a local DVD or a network installation source, just as if you'd perform a fresh install. You then just select "Upgrade" instead of "Install" in the Boot Screen to upgrade the system.

To perform an automated migration, proceed as follows:

Run multi-update. This command runs zypper in a chroot environment and updates the other system— it does not matter which one is active. Its boot menu will be offered as the default at boot time.

If the updated system has a damaged boot loader after the update, you must change the “Active” flag and set it for the root partition of the other system in order to boot it.

If the updated system does not boot at all, you need access to the boot loader menu to select the other system.

For more information about GRUB 2, see Chapter 13, The Boot Loader GRUB 2, Administration Guide.

The root partition must be mounted by partition name, by ID, or in another way. Mounting by partition UUID or by label is not supported.

For more information, see /usr/share/doc/packages/multi-update-tools/README coming with the multi-update-tools package.

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. These support levels proactively update trivial local root exploits in Kernel or 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 4.1, “Security Updates and Bug Fixes”.

The repository layout corresponds to the product lifecycles. Table 4.2, “Repository Layout for SUSE Linux Enterprise 11 SP2 and SP3 and for SUSE Linux Enterprise 12” contains a list of all repositories from SUSE Linux Enterprise 11 SP2 to SUSE Linux Enterprise 12.

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
    SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
    SLES11-SP2-Core SLES11-SP2-Updates \
    SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
    SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
    https://nu.novell.com/repo/\$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

Upstream developers are primarily concerned with advancing the software they develop. In many cases 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:

In most cases, distribution developers do not follow all upstream changes once 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:

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

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 a limited class 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.

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/tests are thus prone to generating “false positives” (claims that a vulnerable piece of software has been found which in fact is not vulnerable) when backports are involved. When evaluating reports from security scanning tools, one should always investigate whether an entry is based on a version number or on an actual test of whether an actual vulnerability exists.

There are a number of locations where information regarding backported bug fixes and features is stored:

The scripts are searched in /var/lib/YaST2/wagon/hooks/ directory. The expected script name is in the format step_seq_prefix_name, where:

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

The script should return exit value 0. If it fails (any non-zero exit value) an error message is displayed in Wagon and it is possible to restart the script, ignore the failure (and continue with other scripts) or completely cancel the hooks for the current step and stage.

The hook scripts can be potentially run more times (when going back and forth in the Wagon dialogs, Wagon might restart itself or some steps might be executed multiple times in the migration workflow), so the scripts have to cope with that fact (they can check at the beginning whether they need to do the action or the action has been already done or they can create a simple temporary stamp file or otherwise solve multiple runs properly).

Some hooks are optional (because the depend on the previous results or depend on user selected values). Note that some hooks are called multiple times (for example, registration is called before migration and after migration). Here is the list of supported hooks (step names) in execution order:

These are special abort hooks which are called when the user aborts the migration. These hooks can be called in any step in the migration workflow therefore the execution order cannot be guaranteed. The scripts need to check the current state if they rely on the results of other hooks.

These hooks are called whenever Wagon restarts itself.

The list of hooks is fairly large, but many of them only make sense in special cases. In normal use cases these should be given preference:

Older versions of Wagon supported only two hook scripts: /usr/lib/YaST2/bin/wagon_hook_init and /usr/lib/YaST2/bin/wagon_hook_finish. The problem was that only one script could be run as a hook and it was not possible to put hooks directly into RPM packages.

These old hook scripts are still supported in newer versions of Wagon for backward compatibility, but the new hooks before_init and before_exit should be used instead of the obsolete ones.