Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 11 SP4

7 Updating SUSE Linux Enterprise

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.

7.1 Terminology

This chapter uses several terms. In order 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.

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.

Downstream

A metaphor of how software is developed in the open source world (compare it with upstream). The term downstream refers to people or organisations 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.

Online Migration

Updating to a Service Pack (SP) by using the online update tools (rather than the installation media) to install the respective patches. It updates all packages of the installed system to the latest state—including updates—of SP3 plus SP2 updates.

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 deltarpms. It may also introduce dependencies to packages that are not installed yet.

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.

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 which 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 have to keep their patches in sync 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.

Upgrade

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

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

7.2.1 Background Information

Over the last few years, with a clear desire for improvements based on customer feedback, SUSE has implemented various changes regarding the way we deliver updates to our users:

  • In SLES 9, there was only one update repository that collected all the updates; the most recent release update was the only one to be supported.

  • Starting with SLES 10 SP1, the concept of a SP-specific repository was introduced. This means that all the updates for a specific service pack are delivered in one specific repository. Once users migrate to a newer service pack, they lose access to the preceding repositories if they registered directly at the Novell Customer Center. Users of SMT or SUSE Manager were able and are still able to subscribe to any SP channel freely. The main reason for this change was the concept of a 6-month overlap period (n-1 service pack support) to allow validation of the released service pack and a window of migration for customers, whereby they would continued to be maintained and supported fully within the old SP.

  • SLES 11 GA and SLES 11 SP1 followed the SLES 10 model. With SLES 11 SP2 we introduced a new repository model, consisting of the following:

    1. SLES 11 SP1 Updates repository remained subscribed. All updates that were also applicable to SP2 were also or only released into the SP1 Updates repository. This means that all the updates that don't break the ABI and API compatibility continued to be delivered here.

    2. SLES 11 SP2 Updates repository includes only the latest and any innovative updates that can't be delivered to the SP1 Updates repository (for various reasons). In addition to this, we introduced a core repository, which provided a gap for packages that were neither released into the SP1 nor the SP2 Updates repository.

    3. SLES 11 SP4 will have a simplified channel model. All updates will be shipped via an update channel special. Only in case of online migration, additional channels will be made available on the machine. Any custom repositories stay untouched.

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

Maintenance Delivery Evolution (also applies to SLED)
Figure 7.1: Maintenance Delivery Evolution (also applies to SLED)

Our products have a 10-year life-cycle: 10 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 7.2, “Long Term Service Pack Support”).

Long Term Service Pack Support
Figure 7.2: 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.

7.2.2 Support Levels

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 7.1, “Security Updates and Bug Fixes”.

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

 

7.2.3 Channel Model

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

With SUSE Linux Enterprise SP 2 the channel layout has changed to support the benefits of the new maintenance model. Table 7.2, “Channel Layout for SUSE Linux Enterprise 11 SP1 to SP4” contains a list of all channels from SP1 to SP3.

Table 7.2: Channel Layout for SUSE Linux Enterprise 11 SP1 to SP4

Type

SLES

SLED

Required Channels

SP1

SLES11-SP1-Pool
SLES11-SP1-Updates

SP2

SLES11-SP1-Pool
SLES11-SP1-Updates
SLES11-SP2-Core
SLES11-SP2-Updates

SP3

SLES11-SP3-Pool
SLES11-SP3-Updates

SP4

SLES11-SP4-Pool
SLES11-SP4-Updates

SP1

SLED11-SP1-Pool
SLED11-SP1-Updates

SP2

SLED11-SP1-Pool
SLED11-SP1-Updates
SLED11-SP2-Core
SLED11-SP2-Updates

SP3

SLED11-SP3-Pool
SLED11-SP3-Updates

SP4

SLED11-SP4-Pool
SLED11-SP4-Updates

Optional Channels

SP1

SLES11-SP1-Debuginfo-Pool
SLES11-SP1-Debuginfo-Updates

SP2

SLES11-SP2-Debuginfo-Core
SLES11-SP2-Debuginfo-Updates
SLES11-Extras
SLES11-SP2-Extension-Store

SP3

SLES11-SP3-Debuginfo-Core
SLES11-SP3-Debuginfo-Updates
SLES11-SP3-Extension-Store
SLES11-Extra

SP4

SLES11-SP4-Debuginfo-Pool
SLES11-SP4-Debuginfo-Updates
SLES11-Extra
SLES11-Security-Module

SP1

SLED11-SP1-Debuginfo-Pool
SLED11-SP1-Debuginfo-Updates

SP2

SLED11-SP2-Debuginfo-Core
SLED11-SP2-Debuginfo-Updates
SLED11-Extras
SLED11-SP2-Extension-Store

SP3

SLED11-SP3-Debuginfo-Core
SLED11-SP3-Debuginfo-Updates
SLED11-SP3-Extension-Store
SLED11-Extra

SP4

SLED11-SP4-Debuginfo-Pool
SLED11-SP4-Debuginfo-Updates

Product-Specific (Examples)

SLES11-WebYaST-SP2-Pool
SLES11-WebYaST-SP2-Updates
SLED11-MSI-Updates
Description of Required Channels
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 (for example, hardware enablement). Exists only in SP2.

Updates

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

Pool

Containing all binary RPMs from the installation media, plus pattern information and support status metadata.

Description of Optional Channels
Debuginfo-Pool, Debuginfo-Updates

These channels contain static content. However, only the Debuginfo-Updates channel receives updates. Enable these channels if you need to install libraries with debug information in case of an issue.

Extension-Store

Not in use, yet. Supposed to contain packages for (future) add-on products. The Extension Store channel will be removed starting with SLES 11 SP4.

LTSS-Updates

Maintenance updates to packages in the corresponding Pool repository for installations with Long Term Support Service (LTSS). This specific channels require an LTSS contract.

7.2.3.1 Origin of Packages

SUSE Linux Enterprise 11 SP3/SP4.  With the installation of SP3 there are only two channels available: SLES11-SP3-Pool and SLES11-SP3-Updates. Any previous channels from SP2 are visible, but not enabled. These disabled channels are only needed for users who have particular needs.

7.2.3.2 Working with Channels

On registration, the system receives channels from the Customer Center. The channel names map to specific URIs in the customer center (see http://scc.suse.com). To list all available channels on your system, use zypper as follows:

zypper repos -u

This gives you a list of all available channels on your system. Each channel 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.

If you want to remove old channels (for example, from SP1), use zypper removerepo and the name(s) of the channel(s). For example, to remove the old SP1 and SP2 channels, use the following command:

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

If you want to re-add some of your channels, log in to http://www.novell.com/ncc and select from the menu My Products › Mirror Credentials. There you can see a list of URIs; Only channels from this list of products can be added. For example, to add the SP2 Extension Store, use the following command (one line, without the backslash):

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

7.3 Supported Upgrade Paths to SLE SP4

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 (any Service Pack)

There are supported ways to upgrade from SLES 10 GA and SPx or SLES 11 GA and SP1 to SLES 11 SP3, which may require intermediate upgrade steps:

  • SLES 10 GA -> SLES 10 SP1 -> SLES 10 SP2 -> SLES 10 SP3 -> SLES 10 SP4 -> SLES 11 SP4, or

  • SLES 11 GA -> SLES 11 SP1 -> SLES 11 SP2 -> SLES 11 SP3 -> SLES 11 SP4

Upgrade is supported from SLES 10 SP4 via bootable media (including PXE boot). For reference, see the releasenotes at https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP4/#Update.General.Sequence.

Attention for SLED users: some devel packages have been moved from the SLED11-SP2 installation media to the SLED11-Extras repository. In order to avoid dependency conflicts during upgrade, enable this repository before performing the actual upgrade. Execute yast2 repositories and enable SLED11-Extras there. On SLES this extra step is not needed.

Upgrading from SUSE Linux Enterprise 11 GA

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

Upgrading from SUSE Linux Enterprise 11 SP1

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

Upgrading from SUSE Linux Enterprise 11 SP2

Refer to Section 7.6, “Updating SLE 11 SP2 to SLE 11 SP3” for details.

Upgrading from SUSE Linux Enterprise 11 SP3

Refer to Section 7.7, “Updating SLE 11 SP3 to SLE 11 SP4” for details.

Important
Important: Cross-architecture Upgrades are not Supported

Cross-architecture upgrades (32-bit to 64-bit and 64-bit to 32-bit) are not supported.

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

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

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.

7.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 7.1, “List with df -h, the root partition to write down is /dev/sda3 (mounted as /).

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

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.

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

7.4.4 Temporarily Disable Kernel Multiversion Support

SUSE Linux Enterprise Server allows to install multiple Kernel versions by enabling the respective settings in /etc/zypp/zypp.conf. Support for this feature needs to be disabled for updating to a service pack. Once the update has successfully finished. multiversion support can be re-enabled again. To disable multiversion support, comment the respective lines in /etc/zypp/zypp.conf. The result shoul look like this:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

To re-activate this feature after a successful update, remove the comment signs.

7.4.5 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 Server can be read online at http://www.suse.com/doc/sles11/#additional.

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

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

7.5.1.1 Requirements

In order to do an online update, the following requirements must be met. Make sure to also read Section 7.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 it is not registered yet, either run the Novell 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 or Section 6.1.3, “Updating Software with Zypper” 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
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.

7.5.1.2 Online Migration with YaST Wagon

If you have a SLES 11 SP1 system, find the needed steps at https://www.suse.com/support/kb/doc.php?id=7011872. The following procedure applies to an online migration from SP1 to SP2.

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.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 (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 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 7.2.3, “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:

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

7.5.1.3 Online Migration with zypper

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.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_SLES-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_SLES-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:

    • SLES11-SP1-Pool

    • SLES11-SP1-Updates

    • SLES11-SP2-Core

    • SLES11-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 SLES11-SP2-Core SLES11-SP2-Updates

    If your setup contains third-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 SLES11-SP2-Core --from SLES11-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.

7.5.2 Updating by Booting from an Installation Source

As an alternative to the Online Migration (see Section 7.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 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 14.2, “Setting Up the Server Holding the Installation Sources”.

7.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 7.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 6, Installation with YaST.

7.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 14, Remote Installation for in-depth information on starting the upgrade from a remote server.

7.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 6.1.2, “Installing from a Network Source without SLP”. YaST starts.

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

7.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 14.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 14.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 14.5.1, “VNC Installation” for more information.

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

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

7.5.3 Updating via Subscription Management Tool (SMT)

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/doc/smt11/ gives an overview of its features as well as instructions on how to implement it.

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

7.6 Updating SLE 11 SP2 to SLE 11 SP3

Online Migration is supported by the following tools:

  • YaST wagon (graphical user interface)

  • zypper (command line)

If updating your system via online migration, the update is carried out while the system is running. You only need to reboot once, after the update is completed. It is still possible to update with the following alternatives:

7.6.1 Requirements

In order to do an online update, the following requirements must be met. Make sure to also read Section 7.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 it is not registered yet, either run the Novell 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 or Section 6.1.3, “Updating Software with Zypper” 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
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.

7.6.2 Online Migration with YaST Wagon

If you have a SLES 11 SP2 system, find the needed steps at https://www.suse.com/support/kb/doc.php?id=7011872. The following procedure applies to an online migration from SP2 to SP3.

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.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 (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 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 SP3 update source(s). This can either be the SP3 installation media or the SLES11-SP3-Pool and SLES11-SP3-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 SLES11-SP3-Pool and SLES11-SP3-Updates channels will be added to the system (see Section 7.2.3, “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. 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
    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.

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

  9. Your system has been successfully updated to Service Pack 3.

7.6.3 Online Migration with zypper

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.5.1.1, “Requirements”), the products needed for the online migration are 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_SLES-SP3-migration. Depending on the scope of your installation, more products may be listed.

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

    zypper in -t product SUSE_SLES-SP3-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 the repositories and services:

    zypper ref -s
  5. Check the list of repositories you can retrieve with zypper lr.

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

    zypper modifyrepo --enable SLES11-SP3-Pool SLES11-SP3-Updates

    If your setup contains third-party repositories that may not be compatible with SP3, 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 SLES11-SP3-Pool --from SLES11-SP3-Updates

    Confirm with y to start the upgrade.

  7. Upon completion of the distribution upgrade from the previous step, run the following command:

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

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

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

7.7 Updating SLE 11 SP3 to SLE 11 SP4

There are different supported ways for updating a SUSE Linux Enterprise Server 11 SP3 system to a Service Pack 4. 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 (SMT) 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.

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

7.7.1.1 Requirements

In order to do an online update, the following requirements must be met. Make sure to also read Section 7.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 it is not registered yet, either run the Novell 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 Section 1.0, YaST Online Update, (↑Administration Guide) or at Section 6.1.3, Updating Software with Zypper, (↑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
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.

7.7.1.2 Online Migration with YaST Wagon

If you have a SLES 11 SP3 system, find the needed steps at https://www.suse.com/support/kb/doc.php?id=7011872. The following procedure applies for an online migration from SP3 to SP4.

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.7.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 (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 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 SP4 update source(s). This can either be the SP4 installation media or the SP4-Pool and SP4-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 SP4-Pool and SP4-Updates channels will be added to the system (see Section 7.2.3, “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:

    Full migration

    Updates all packages to the latest SP4 level.

    Minimal Migration

    Updates a minimal set of packages to the latest SP4 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
    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 SP4 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 4.

7.7.1.3 Online Migration with zypper

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

  1. When all requirements are met (see Section 7.5.1.1, “Requirements”), the products needed for the online migration are 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_SLES-SP4-migration. Depending on the scope of your installation, more products may be listed.

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

    zypper in -t product SUSE_SLES-SP4-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 the repositories and services:

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

    • SLES11-SP4-Pool

    • SLES11-SP4-Updates

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

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

    zypper modifyrepo --enable SLES11-SP4-Pool --enable SLES11-SP4-Updates

    If your setup contains third-party repositories that may not be compatible with SP4, 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 SLES11-SP4-Pool --from SLES11-SP4-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 SP4 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 SP4 level), run the following command:

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

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

Your system has been successfully updated to Service Pack 4.

7.7.1.4 Updating by Booting from an Installation Source

As an alternative to the Online Migration 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 4 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 14.2, “Setting Up the Server Holding the Installation Sources”.

7.7.2 Getting Packages from Older Service Packs

In order to install packages from an older Service Pack, add the respective repositories of the older Service Pack. This can be done via:

root # zypper ar URL ALIAS

ALIAS can be any string which will identify the repository inside the system. We strongly recommend to add both *-POOL and *-UPDATES repositories of the respective Service Pack.

The easiest way to find the URL is having a local mirror, ideally provided by a local SMT server. After the repository is mirrored on SMT, find the repositories via pointing your browser to http://SMT_HOSTNAME/repo. A typical URL looks like this: http://SMT_HOSTNAME/repo/$RCE/SLES11-SP1-POOL/sle-11-x86_64. If you have staging enabled, you can also browse the staged repositories.

7.8 Backporting Source Code

SUSE uses backports extensively. The information in this section helps you understand why it can be deceptive to compare version numbers in order to judge software's capabilities and problems.

7.8.1 Why Backporting?

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:

  • bugfixes with a limited potential for disrupting functionality; and

  • changes that may disrupt existing functionality.

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:

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

7.8.2 Reasons for Backporting

SUSE uses backports extensively as we strike a good balance between a number of concerns for enterprise software. The most important of these 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 version of the product as good as they can make it, rather than them having to spread 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.

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

7.8.4 The Implications of Backports for Interpreting Version Numbers

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

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

  • The package's changelog:

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

    The output briefly documents the change history of the package.

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

  • A package may contain a /usr/share/doc/packagename/README.SUSE or 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 the Maximum RPM book for more information.

  • For security bug fixes, 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 project.

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 isn't vulnerable) when backports are involved. When evaluating reports from security scanning tools, one should always investigate whether an entry is based just on a version number or on an actual test of whether an actual vulnerability exists.

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

7.9.1 Setup

Warning
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 boot loader setup. The boot loader menu will then contain an entry to boot the other system.

    Warning
    Warning: GRUB Bootloader Mandatory

    Installation of the GRUB boot loader is mandatory. The tools are not compatible with other boot loaders.

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

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

7.9.3 Troubleshooting

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, see Chapter 11, The Boot Loader GRUB.

7.9.4 Limitation

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.

7.9.5 For More Information

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

7.10 Migration Hooks for YaST Wagon

Migration hooks allow you to run a custom external script at some point during the migration process. These scripts allow you to handle specific problems that cannot be handled via the usual RPM scripts, or allow you to perform any extra actions that might be needed during migration (not required during normal package update).

The migration hooks are executed with root privileges so it is possible to do any maintenance tasks in the scripts (starting/stopping services, data backup, data migration, etc...). The scripts must not be interactive; STDIN and STDOUT are redirected to pipes when running in YaST. The X session should not be used, as it might not be available in all cases (e.g. when running in text mode). Do not forget to set the executable permission for the hook scripts.

Migration hooks are supported in yast2-wagon package version 2.17.32.1 (provided as an update for SLES11-SP2) or 2.17.34 (included in SLES11-SP3) or higher versions.

7.10.1 Hook Script Location and Name Conventions

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

step

is a predefined migration step name, describing the current migration step.

seq

is a sequence number in range 00...99, which makes it possible to set the order in which the scripts are executed. (It is important to keep the beginning zeros for correct sorting!)

prefix

should be unique to avoid conflicts (like a namespace). Use package name (if it is part of a package) or your vendor name, Internet domain name, etc., basically anything that can be considered sufficiently unique

name

can be any string (just to differentiate the scripts). Some descriptive name is recommended.

Example 7.2: Hook Script with Full Path
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

7.10.2 Hook Script Exit Value

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.

7.10.3 Idempotent Scripts

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

7.10.4 List of Supported Hooks

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 (e.g. registration is called before migration and after migration). Here is the list of supported hooks (step names) in execution order:

before_init

started at the very beginning (note: it is called again after Wagon restarts)

before_welcome, after_welcome

started before/after displaying the welcome dialog

before_registration_check, after_registration_check

Wagon checks the registration status (if registration of some products has expired the migration might fail). If everything is OK, no dialog is displayed and Wagon automatically continues with the next step

before_custom_url, after_custom_url

repository manager is started (optional, in Patch CD mode only)

before_self_update, after_self_update

called before/after Wagon updates itself (to ensure the latest version is used for migration)

before_installing_migration_products, after_installing_migration_products

called before/after installing the migration products

before_selecting_migration_source, after_selecting_migration_source

Wagon asks the user to migrate via Novell Customer Center repositories or using a custom repository; the next step depends on the user selection

before_registration, after_registration

running SUSE register (to add migration repositories)

before_repo_selection, after_repo_selection

manual repository management

before_set_migration_repo, after_set_migration_repo

selecting migration repositories (full/minimal migration when using Novell Customer Center) or update repository selection (custom repository migration)

before_package_migration

before package update starts, after this step the real migration starts and it is not possible to go back to the previous state automatically (aborting in this phase results in an inconsistent (half upgraded) system, and manual rollback is needed)

before_registration, after_registration

running SUSE register (to register updated products)

before_congratulate, after_congratulate

before/after Wagon displays the congratulation dialog as a result of a successful migration

before_exit

called just before Wagon exits (always, regardless the migration result, also after abort and at restart)

7.10.5 Abort Hooks

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.

before_abort

user confirmed aborting the migration

before_abort_rollback, after_abort_rollback

user confirmed rollback after abort (reverting to the old products installed before starting migration). These hooks are called after before_abort and skipped when the user does not confirm rollback.

7.10.6 Restart Hooks

These hooks are called whenever Wagon restarts itself.

before_restart

Wagon is finishing and will be started again

after_restart

Wagon has restarted and runs the next step in the migration workflow

7.10.7 Usually Used Hooks

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:

  • To do some action before the system is migrated (still running the previous version) use the before_package_migration hook.

    At this point it is clear that the migration is ready and is about to start, whereas in all steps before it was possible to abort the migration.

  • To do some action after the system has migrated (the system is running the new migrated version, but some things might not be active yet, e.g. updated kernel requires reboot, updated services might need restart etc..), use before_congratulate or after_congratulate hook.

    This can be also used for cleaning up the temporary results of the before_package_migration hook. At this point the migration has successfully finished.

  • To reverse the changes if the migration is aborted, use one of the abort hooks depending on the case. Keep in mind that the abort hooks can be called anytime, so the revert might not be needed (the hook that does the changes might not have been called yet). The abort hooks need to check the current state.

7.10.8 Obsolete Hooks

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.

Print this page