Documentation > Deployment Guide > Manual Deployment > ◀ ▶

Chapter 4. Updating SUSE Linux Enterprise

Contents

4.1. Terminology
4.2. New Maintenance Model
4.3. Preparations
4.4. Upgrading with YaST Wagon
4.5. Upgrading with zypper
4.6. Updating SLE 10 SP4 to SLE 11 SP2
4.7. Updating SLE 11 SP1 to SLE 11 SP2
4.8. Installing Service Packs
4.9. 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. Old 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 and correct software defects. Install from a local CD or DVD drive or from a central network installation source.

[Note]Release Notes

The current version of the release notes document can be read online at http://www.suse.com/documentation/sles11/#additional.

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.

Migration

Installation from a non-SUSE operating system or product to a SUSE product, for example from Windows to SUSE Linux Enterprise Server.

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 version of a package or distro.

Upgrade

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

4.2. New Maintenance Model

The new 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” depicts some of the mentioned aspects above.

Figure 4.1. Maintenance Delivery Evolution

Maintenance Delivery Evolution

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

Before updating, copy the old configuration files to a separate medium (such as tape device, removable hard disk, etc.) to secure 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.

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.

[Note]System Version Requirement

For exact system version requirements, from which you can upgrade to this version, refer to the release notes coming with the update product. In the release notes you can find additional information about upgrade procedures.

[Note]Product Version Upgrade Requirement

Upgrade from the last version (for example, SUSE Linux Enterprise 11 SP1) to the current version (SUSE Linux Enterprise 11 SP2)—do not skip any service pack version in-between; this means, neither upgrade from SUSE Linux Enterprise 10 SP3 or earlier to this service pack, nor from SUSE Linux Enterprise 11 GA to SUSE Linux Enterprise 11 SP2. Make sure all available online updates are successfully applied before starting the system upgrade.

4.4. Upgrading with YaST Wagon

YaST Wagon is the automated YaST Online Migration procedure. Before initiating YaST Wagon to upgrade to the SP feature level, make sure that the following requirements are met:

  • The system must be online throughout the entire update process, because this process requires access to the Novell Customer Center.

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

  • Make sure that the entire process is completed successfully. Otherwise the system becomes inconsistent.

[Note]

During upgrade migration with Wagon, the update stack is updated. Therefore, it is advisable to avoid using any other software management tools such as zypper or desktop update applets. It is recommended to stop the desktop update applets during the migration.

  1. If the migration patch (Update stack update) is available in the update repository, initiate the migration procedure from the command-line as root with wagon.

    [Note]Migration Patch Notification

    On the GNOME desktop a notification message appears in the bottom right corner when the migration is available. Click the link in this notification message to initiate the migration procedure.

  2. Confirm the Welcome dialog.

  3. If not already installed during the regular YaST Online Updates, wagon at first installs the preselected migration patch (Update stack update). The patch contains updates of the package management stack, and—if necessary—a new Kernel. Therefore, a system reboot is required.

    For more information about YOU, see Chapter 1, YaST Online Update (↑Administration Guide).

  4. Reboot the system, and wagon continues the migration with the Update Method. Keep the preselected Customer Center setting. Enable Check Automatic Repository Changes, if you want to verify any third-party related repository configuration later on. Confirm this dialog.

  5. Register the migration status in the Novell Customer Center Configuration and confirm the updated software repositories (SLES11-SP1-Pool instead of SLES11-Updates).

  6. If you enabled Check Automatic Repository Changes, the Configured Software Repositories menu follows.

  7. Distribution Upgrade Settings is the final dialog, before the actual migration procedure takes place. Check all the settings carefully—after confirmation, no roll-back is possible.

    Package installation and system configuration (SuSEconfig) will run automatically. Rebooting is necessary.

  8. Register the new version in the Novell Customer Center. Confirm the once again updated software repositories, where the SLES11-SP1-Updates are enabled now.

  9. Finally confirm the Migration Completed dialog and reboot the system.

4.5. Upgrading with zypper

Use zypper, if you need a scriptable solution for the update.

Before initiating the online update using zypper to progress to the SP2 feature level, make sure that the requirements are met as listed in Section 4.4, “Upgrading with YaST Wagon”.

This it the minimal command sequence needed to upgrade the system to the SP2 patch level:

  1. Refresh all services and repositories: 

    zypper refresh -s

  2. Update patches, especially the package management stack: 

    zypper update -t patch

  3. Update the remaining patches using the just updated package management stack: 

    zypper update -t patch

  4. Read product specific information about distribution updates from /etc/products.d/*.prod. They contain information about distribution upgrades.

  5. Use the previously retrieved names to install the migration product information, for example: 

    grep '<product>' /etc/products.d/*.prod
/etc/products.d/sle-sdk.prod:      <product>sle-sdk-SP2-migration</product>
/etc/products.d/SLES.prod:         <product>SUSE_SLES-SP2-migration</product>

  6. Register the products to get the pool repositories: 

    suse_register -d 2 -L /root/.suse_register.log
...
Execute command: /usr/bin/zypper ... modifyservice --ar-to-enable SMT-https_srv64_suse_de:SLES11-SP2-Pool SMT-https_srv64_suse_de
Execute command exit(0):
Execute command: /usr/bin/zypper ... modifyservice --ar-to-enable SMT-https_srv64_suse_de:SLE11-SDK-SP2-Pool SMT-https_srv64_suse_de
Execute command exit(0):

  7. Refresh the services and repositories: 

    zypper refresh -s

  8. Disable all repositories from the old GA product and enable the new SP2 pool repositories. For ISV, the same applies for add-on products. Old repositories stay enabled, if they have no SP2 upgrade.

    Use the following commands to disable your repositories: 

    zypper services
zypper modifyrepo --disable REPO_ALIAS

    Use the following command to enable repositories: 

    zypper modifyrepo --enable REPO_ALIAS

  9. Perform a distribution upgrade (dup) with zypper: 

    zypper dup

  10. After the migration is finished, register the new product again: 

    suse_register -d 2 -L /root/.suse_register.log

    It should remove the old GA update repositories and add the new SP2 update repositories. The SP1-Pool and SP1-Update repositories should stay untouched.

  11. Reboot your system to run the SP2 Kernel.

4.6. Updating SLE 10 SP4 to SLE 11 SP2

Follow the steps outlined in this section, if you want to upgrade from SUSE Linux Enterprise Desktop 10 SP4 or 11 GA to SUSE Linux Enterprise Desktop 11 SP2. Make sure you update the old system to the most recent patch level first.

  1. Follow the preparation procedure outlined in Section 4.3, “Preparations”.

  2. Perform the YaST approach (Section 4.4) or the zypper approach (Section 4.5) to progress to the SP feature level.

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. Updating SLE 11 SP1 to SLE 11 SP2

Follow the steps outlined in this section, if you want to upgrade from SLE 11 SP1 to SLE 11 SP2.

  1. Follow the preparation procedure outlined in Section 4.3, “Preparations”.

  2. Run the Novell Customer Center registration.

  3. Add the SP2 repositories to the client.

  4. Run yast2 online_update

4.8. Installing Service Packs

Use Service Packs to update a SUSE Linux Enterprise installation. There are different ways how to apply a service pack. You can either update the existing installation or start a whole new installation using the service pack media. Possible scenarios for updating the system and setting up a central network installation source are described in Section 11.2, “Setting Up the Server Holding the Installation Sources”.

[Tip]Installation Changes

Read the installation instructions on the service pack media for further information on changes.

4.8.1. Installing a Service Pack

[Note]

To upgrade an existing SUSE Linux Enterprise 11 system to a SUSE Linux Enterprise 11 Service Pack (SP), see Section 4.8.2, “Upgrading to a Service Pack”.

Installing a SUSE Linux Enterprise Service Pack is very similar to installing the original SUSE Linux Enterprise media. As with the original installation, you can choose to install from a local DVD drive or from a central network installation source.

4.8.1.1. Installing 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.8.1.2. Network Installation

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

4.8.1.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 from DVD, then use F3 to enable Further Options, and finally 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 Chapter 3, Installation with YaST.

4.8.1.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. Accept the license agreement then select a language, default desktop, and other installation settings.

  6. Click Yes, Install to start the installation.

  7. Continue with the installation entering a password for root, completing the network configuration, testing your Internet connection, activating the Online Update service, selecting the user authentication method, and entering a username and password.

    For detailed instructions on how to install SUSE Linux Enterprise, see Chapter 3, Installation with YaST.

4.8.2. Upgrading to a Service Pack

There are two preferred ways to upgrade the system to the Service Pack (SP) feature level. One way is to boot from the SP medium. Alternatively you can run Wagon. By updating to the new feature level, additional features like new drivers or software enhancements become available on your system.

Other methods to upgrade are, for example, using zypper commands manually, using the Patch CD, or using a locally installed SMT system.

4.8.2.1. Booting from the SP Medium

Boot from the SP medium and choose Update as the installation mode in YaST.

4.9. 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.9.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.9.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.9.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.9.4. For More Information

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

Documentation > Deployment Guide > Manual Deployment > ◀ ▶