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 favorite specific software packages have changed significantly, and which precautions you should take in addition to the general recommendations of this section. The Release Notes also provide last minute information and known issues, that 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/.

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.

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

To perform an automated migration, proceed as follows:

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/ gives an overview of its features as well as instructions on how to set up server and clients.

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.