Chapter 4. Updating SUSE Linux Enterprise

Contents

4.1. Terminology
4.2. The SUSE Linux Enterprise 11 Maintenance Model
4.3. Supported Upgrade Paths to SLE SP2
4.4. General Preparations for Updating
4.5. Updating SLE 11 SP1 to SLE 11 SP2
4.6. Updating SLE 10 SP4 to SLE 11 SP2
4.7. The Atomic Update

Abstract

SUSE® Linux Enterprise (SLE) provides the option of updating an existing system to the new version without completely reinstalling it. No new installation is needed. Existing data, such as home directories and system configuration, is kept intact. During the life-cycle of the product, you can apply Service Packs to increase system security, correct software defects and get access to new features. Install from a local CD or DVD drive or from a central network installation source.

4.1. Terminology

This chapter uses several terms. In order to understand the information, read the definitions below:

Deltarpm

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

Patch

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

Package

A package is a compressed file in rpm format that contains the files for a particular program.

Service Packs (SP)

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

Update

Installation of a newer minor version of a package.

Upgrade

Installation of a newer major version of a package or distribution, which brings new features.

Online Migration

Updating to a Service Pack (SP) by using the online update tools (rather than the installation media) to install the respective patches. There are two possible migration paths. In the following, SPx+1 refers to the new Service Pack that is going to be installed, whereas SPx refers to the currently installed Service Pack.

Full Migration

Updates all Packages of the installed system to the latest state—including updates—of SPx+1 plus SPx updates.

Minimal Migration

Updates all Packages of the installed system to the latest state of SPx+1 Core packages, SPx+1 Updates and few SPx updates.

4.2. The SUSE Linux Enterprise 11 Maintenance Model

The SUSE Linux Enterprise 11 Maintenance Model combines flexibility and control of your service packs. It offers the following benefits:

  • Makes service packs more lightweight and easier to test and deploy.

  • Allows staying with older versions, but with support for the full system.

  • Answers market needs in between service packs by selective enhancements and allows more updates in the general update repository. By selecting the enhancements, it mitigates longer periods between service packs.

Figure 4.1, “Maintenance Delivery Evolution (also applies to SLED)” depicts some of the mentioned aspects above.

Figure 4.1. Maintenance Delivery Evolution (also applies to SLED)

Maintenance Delivery Evolution (also applies to SLED)

Our products have a 10-year life-cycle: 7 years general support and 3 years extended support. Major releases are made every 4 years and service packs every 18 months. The Long Term Service Pack Support is an extended window or extended major release life-cycle (see Figure 4.2, “Long Term Service Pack Support”).

Figure 4.2. Long Term Service Pack Support

Long Term Service Pack Support

The Long Term Service Pack Support requires active subscription, either standard or priority. It does not affect L1 or L2 subscription terms. Security updates are handled proactively: these are any non-user driven critical vulnerabilities, local root exploits in Kernel or other root exploits directly executable without user interaction.

The range for extended support levels starts from year 8 and ends in year 10. 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”.

Table 4.1. Security Updates and Bug Fixes

 

— General Support —

Extended Support

Topic

Current SP

SP (n-1) 6 months

SP (n-1) with LTSS

Year 6 & 7 with LTSS

Year 8, 9, 10 with LTSS

L1/L2 Technical Services

Proactive Maintenance

 

 

Driver Updates via PLDP

  

Proactive Security Updates

 

L3 Engineering Support

Back-ports available

 


4.2.1. Channel Model

With the former maintenance model, SUSE Linux Enterprise Desktop, had two channels assigned: SLED11-SPx-pool and SLED11-SPx-Updates. During an online migration to SPx+1 these channels were temporary replaced by SLED11-SPx-Online.

With SUSE Linux Enterprise SP 2 the channel layout has changed to support the benefits of the new maintenance model. The following channels are assigned to a product:

  • SLED11-SPx-Updates

  • SLED11-SPx-Core

  • SLED11-SPx-LTSS-Updates (optional)

  • SLED11-SPx-Extension-Store (optional)

  • SLED11-SP(x-1)-Updates

  • SLED11-SP(x-1)-Core

  • SLED11-SP(x-2)-Updates

  • SLED11-SP(x-2)-Core

  • ...

  • SLED11-SP1-Updates

  • SLED11-SP1-Pool

Each repository type contains a different set of packages:

Core

A subset of the unpacked installation media, it only contains those packages that are considered to be the "core" of SPx (approximately 30% of the package total). The SP repositories only contain packages specific to a SP and its themes (e.g. hardware enablement)

Updates

Maintenance updates to packages in the corresponding Core or Pool repository.

LTSS-Updates

Maintenance updates to packages in the corresponding Core repository for installations with Long Term Support Service.

Extension-Store

Not yet in use, yet. Supposed to contain packages for (future) add-on products.

Pool

The unpacked SP1 installation media, containing all binary RPMs from the installation media, plus pattern information and support status metadata. This repository is only available for SP1.

4.2.1.1. Origin of Packages

The base channel for SUSE Linux Enterprise 11 is SLED11-SP1-Pool. It's the only channel containing all packages. This channel and it's content will not change throughout the entire life cycle of SUSE Linux Enterprise 11. A package will be served from this channel as long as no update for this package is available.

Once a package gets updated, the update is served from SLED11-SP1-Updates. This channel contains all packages having been updated since the release of SP1.

Once Service Pack 2 is installed, two additional channels will be added: SLED11-SP2-Core and SLED11-SP2-Updates. SP2-Core contains a subset of packages from SP1-Pool. These packages are newer than the versions in both SP1 channels. Once an SP2-Core package gets updated, the update is served from SLED11-SP2-Updates. This channel contains all packages having been updated since the release of SP2.

Starting with the installation of SP2 the following rules on the origin of packages apply:

  1. Non-core-packages will be served from SP1-Pool or SP1-Updates throughout the entire life cycle of SUSE Linux Enterprise 11.

  2. Core packages will always be served from SPx-Core or SPx-Update. In case a package gets dropped from the Core in SPx, it will be served from SPx-1 for the entire rest of the life cycle of SUSE Linux Enterprise 11.

4.3. Supported Upgrade Paths to SLE SP2

Upgrading SLES 8, SLES 9 and NLD 9

There is no supported direct upgrade path from these versions. Instead it is recommended to perform a new installation.

Upgrading from SUSE Linux Enterprise 10 Prior to Service Pack 4

There is no supported direct migration path to SUSE Linux Enterprise 11. An update has to be performed from SUSE Linux Enterprise 10 GA to SP 1, then to SP 2, further to SP 3, and then to SP4 by using the respective boot media. SP4 can be updated to SUSE Linux Enterprise 11 SP2 following the procedure outlined in Section 4.6, “Updating SLE 10 SP4 to SLE 11 SP2”.

Upgrading from SUSE Linux Enterprise 10 Service Pack 4

The supported migration path from SUSE Linux Enterprise 10 SP4 to SUSE Linux Enterprise 11 Service Pack 2 is by using the SUSE Linux Enterprise 11 SP 2 boot media. See Section 4.6, “Updating SLE 10 SP4 to SLE 11 SP2” for details.

Upgrading from SUSE Linux Enterprise 11 GA

There is no supported direct migration path to SUSE Linux Enterprise 11 SP2. An update hast to be performed from SUSE Linux Enterprise 11 GA to SP1 first. Proceed with Section 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” afterwards.

Upgrading from SUSE Linux Enterprise SP1

Refer to Section 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” for details.

4.4. General Preparations for Updating

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

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

4.4.2. Partitioning and Disk Space

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

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

4.4.3. Shut Down Virtual Machines

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 acces the guests after the update.

4.4.4. Version Specific Requirements

For version specific requirements, refer to the release notes coming with the update product. In the release notes you can find additional information about upgrade procedures.

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/documentation/sles11/#additional.

4.5. Updating SLE 11 SP1 to SLE 11 SP2

There are different supported ways for updating a SUSE Linux Enterprise 11 SP1 system to a Service Pack 2. You may either update by using the online update tools to install the respective patches (Online Migration) or update via the Service Pack installation media. Furthermore, updates can be performed via servers hosting Subscription Management Tool or SUSE Manager.

An Online Migration is supported by the following tools:

  • YaST wagon (graphical user interface)

  • zypper (command line)

Alternatively, the full Service Pack media (DVD ISO image) can be downloaded. Start the update process by booting from the physical Service Pack media or a network installation source.

4.5.1. Online Migration

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

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

Product Registration

In order to be able to connect to the update channels, your product has to be registered. If this is not the case, either run the Novell Customer Center Configuration module in YaST or the suse_register commandline 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.

3rd 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 has to be completed from beginning to end. If an online migration is interrupted in between, the system is corrupted beyond recovery.

4.5.1.2. Online Migration with YaST Wagon

  1. When all requirements are met (see Section 4.5.1.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 (needed maintenance updates available but not yet installed) it will do an automatic self update that may require to 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 channels used for the online migration. A list of channels will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Add the SP2 update source(s). This can either be the SP2 installation media or the SP2-Core and SP2-Updates channels.Click OK to return to the Update Method dialog.

    If you want to review changes to the channel 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 channels will be added to the system (see Section 4.2.1, “Channel Model” for more information). Confirm the addition of the channels.

  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 channels. Proceed with OK when finished.

  7. Choose the migration type. See Section 4.1, “Terminology” for details.

    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 add SUSE Linux Enterprise Server add-on products or 3rd 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 channels from your system.

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

    1. Packages will be updated.

    2. SuSEconfig will be run.

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

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

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

4.5.1.3. Online Migration with zypper

  1. When all requirements are met (see Section 4.5.1.1, “Requirements”), the products needed for the online migration have been added to /etc/products.d. Get a list of these products by running the following command:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    This command should at least return SUSE_SLED-SP2-migration. Depending on the scope of your installation, more products may be listed.

  2. Install the migration products retrieved on the previous step with the command zypper in -t product LIST_OF_PRODUCTS, for example

    zypper in -t product SUSE_SLED-SP2-migration
  3. Register the products installed in the previous step in order to get the respective update channels:

    suse_register -d 2 -L /root/.suse_register.log'
  4. Refresh repositories and services again:

    zypper ref -s
  5. Check the list of repositories you can retrieve with zypper lr. At least the following repositories need to be Enabled:

    • SLED11-SP1-Pool

    • SLED11-SP1-Updates

    • SLED11-SP2-Core

    • SLED11-SP2-Updates

    Depending on the scope of your installation, further repositories for add-on products or extensions need to be enabled.

    If one of these repositories is not enabled (the SP2 ones are not enabled by default when following this workflow), enable them with zypper modifyrepo --enable REPOSITORY ALIAS, for example:

    zypper modifyrepo --enable SLED11-SP2-Core SLED11-SP2-Updates

    If your setup contains 3rd party repositories that may not be compatible with SP2, disable them with zypper modifyrepo --disable REPOSITORY ALIAS.

  6. Now everything is in place to perform the distribution upgrade with zypper dup --from REPO 1 --from REPO 2 .... Make sure to list all needed repositories with --from, for example:

    zypper dup --from SLED11-SP2-Core --from SLED11-SP2-Updates

    Confirm with y to start the upgrade.

  7. Upon completion of the distribution upgrade from the previous step, a Minimal Migration has been performed (a minimal set of packages has been updated to the latest SP2 level). Skip this step if you do not intend to do a Full Migration.

    In order to do a Full Migration (updates all packages to the latest SP2 level), run the following command:

    zypper update -t patch
  8. Now that the upgrade to SP2 has been completed, you need to re-register your product:

    suse_register -d 2 -L /root/.suse_register.log
  9. Last, reboot your system.

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

4.5.2. Updating by Booting from an Installation Source

As an alternative to the Online Migration (see Section 4.5.1, “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.novell.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”.

4.5.2.1. Updating from a Local DVD Drive

Before starting a new installation of a SUSE Linux Enterprise SP, ensure that all the Service Pack installation media (DVDs) are available.

Procedure 4.1. Booting from the Service Pack Medium

  1. Insert the first SUSE Linux Enterprise SP medium and boot your machine. A boot screen similar to the original installation of SUSE Linux Enterprise 11 is displayed.

  2. Select Installation and continue as outlined in the YaST installation instructions in Chapter 3, Installation with YaST.

4.5.2.2. Updating from a Network Installation Source

Before starting an update of a SUSE Linux Enterprise SP from a network installation source, make sure that the following requirements are met:

Please refer to Chapter 11, Remote Installation for in-depth information on starting the upgrade from a remote server.

4.5.2.2.1. Network Installation—Boot from DVD

To perform a network installation using the SP DVD as the boot medium, proceed as follows:

  1. Insert the SUSE Linux Enterprise SP DVD 1 and boot your machine. A boot screen similar to the original installation of SUSE Linux Enterprise 11 is displayed.

  2. Select Installation to boot the SP Kernel then use F4 to select the type of network installation source (FTP, HTTP, NFS, or SMB).

  3. Provide the appropriate path information or select SLP as the installation source.

  4. Select the appropriate installation server from those offered or use the boot options prompt to provide the type of installation source and its actual location as in Section 3.1.2, “Installing from a Network Source without SLP”. YaST starts.

    Finish the installation as outlined in Section 4.5.2.3, “The Update Procedure”.

4.5.2.2.2. Network Installation—PXE Boot

To perform a network installation of a SUSE Linux Enterprise Service Pack via network, proceed as follows:

  1. Adjust the setup of your DHCP server to provide the address information needed for PXE boot according to Section 11.3.5, “Preparing the Target System for PXE Boot”.

  2. Set up a TFTP server to hold the boot image needed for PXE boot.

    Use the first CD or DVD of your SUSE Linux Enterprise Service Pack for this or follow the instructions in Section 11.3.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. See Section 11.5.1, “VNC Installation” for more information.

  5. Finish the installation as outlined in Section 4.5.2.3, “The Update Procedure”.

4.5.2.3. The Update Procedure

Once you have successfully booted from installation medium or the network, proceed as follows to start the update:

  1. On the Welcome screen choose Language and Keyboard and Accept the license agreement. Proceed with Next.

  2. In case you have booted from a physical medium, perform a Media Check to verify the integrity of the medium. Only skip this step if you have checked the medium before.

  3. On the Installation Mode screen, choose Update. Clicking on Next will start the update procedure.

4.5.3. Updating via Subscription Management Tool

As an alternative to downloading the updates for each single client system from the Novell 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 Novell Customer Center proxy both for client registrations and as software update repository. The SMT documentation at http://www.suse.com/documentation/smt11/ gives an overview of its features as well as instructions on how to implement it.

4.5.4. Updating via 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.

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

4.6. Updating SLE 10 SP4 to SLE 11 SP2

The supported migration path from SUSE Linux Enterprise 10 SP4 to SUSE Linux Enterprise 11 SP2 is by using the SUSE Linux Enterprise 11 SP 2 boot media. Please refer to the instructions at Section 4.5.2, “Updating by Booting from an Installation Source”. Make sure to update your SUSE Linux Enterprise 10 system to the latest patch level by running an online update prior to starting the update to SP2.

4.6.1. Possible Problems

If you update a default system from the previous version to the current version, YaST works out necessary changes and performs them. Depending on your customizations, some steps or the entire update procedure may fail and you must resort to copying back your backup data. Check the following issues before starting the system update.

4.6.1.1. Checking passwd and group in /etc

Before updating the system, make sure that /etc/passwd and /etc/group do not contain any syntax errors. For this purpose, start the verification utilities pwck and grpck as root and eliminate any reported errors.

4.6.1.2. PostgreSQL

Before updating PostgreSQL (postgres), dump the databases. See the manual page of pg_dump. This is only necessary if you actually used PostgreSQL prior to your update.

4.7. The Atomic Update

The Atomic Update is based on tools that manage two copies of the system and allow easy recovery after an update failure. The delivered tools require a special disk partition setup. Every copy of the system resides on a primary partition of its own. If an update fails, you can always switch back to the previous state of the system, which is available on the other partition.

4.7.1. Setup

[Warning]Strict Partitioning Requirements

The implementation has strict requirements on disk partitioning: the first root partition is /dev/sda1 and must not occupy more than half of the entire disk size. Then the tools will create /dev/sda2 for the system's second root partition. Further partitions if available are shared on both root partitions—take their size into account, and reduce the size of the first partition accordingly; this is a rough calculation:

The size of the complete disk minus size of sda1 minus sda2 is the free space of additional partitions.

  1. Install the system with /dev/sda1 as the single root partition and with less than half of the entire disk size.

  2. Customize the installed system as needed. Make sure to have the multi-update-tools package installed.

  3. Run multi-update-setup --partition, which creates the system's second root partition (/dev/sda2) of the similar size.

  4. Partition the rest of the disk as needed and continue with customizations(*).

  5. Run multi-update-setup --clone to copy the system to the other partition. With this command you also change the / (root) entry in /etc/fstab of the target system.

  6. If needed, do further customizations(*).

  7. Run multi-update-setup --bootloader to initialize the bootloader setup. The bootloader menu will then contain an entry to boot the other system.

    [Warning]GRUB Bootloader Mandatory

    Installation of the GRUB bootloader is mandatory. The tools are not compatible with other bootloaders.

  8. If there are no customizations to be done as marked with (*), run multi-update-setup --complete which performs all the three steps.

4.7.2. Updating the Other System

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.

4.7.3. Troubleshooting

If the updated system has a damaged bootloader 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 bootloader menu to select the other system.

For more information about GRUB, see Chapter 11, The Boot Loader GRUB (↑Administration Guide).

4.7.4. For More Information

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