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 SP4
- 4.4. General Preparations for Updating
- 4.5. Updating SLE 11 SP1 to SLE 11 SP2
- 4.6. Updating SLE 11 SP2 to SLE 11 SP3
- 4.7. Updating SLE 11 SP3 to SLE 11 SP4
- 4.8. Backporting Source Code
- 4.9. The Atomic Update
- 4.10. Migration Hooks for YaST Wagon
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:
- 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
rpmformat 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.
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.
4.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:
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.
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.
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 4.1, “Maintenance Delivery Evolution (also applies to SLED)” depicts some of the mentioned aspects above.
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 4.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.
4.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 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.3. 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. Table 4.2, “Channel Layout for SUSE Linux Enterprise 11 SP1 to SP4” contains a list of all channels from SP1 to SP3.
Table 4.2. Channel Layout for SUSE Linux Enterprise 11 SP1 to SP4¶
|
Type |
SLES |
SLED | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Required Channels |
SP1
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
Optional Channels |
SP1
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
Product-Specific (Examples) |
|
|
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
CoreorPoolrepository.- 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-Updateschannel 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
Poolrepository for installations with Long Term Support Service (LTSS). This specific channels require an LTSS contract.
4.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.
4.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 +. 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
4.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-SP2installation media to theSLED11-Extrasrepository. In order to avoid dependency conflicts during upgrade, enable this repository before performing the actual upgrade. Execute yast2 repositories and enableSLED11-Extrasthere. 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 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” and Section 4.6, “Updating SLE 11 SP2 to SLE 11 SP3” afterwards.
- Upgrading from SUSE Linux Enterprise 11 SP1
Refer to Section 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” for details.
- Upgrading from SUSE Linux Enterprise 11 SP2
Refer to Section 4.6, “Updating SLE 11 SP2 to SLE 11 SP3” for details.
- Upgrading from SUSE Linux Enterprise 11 SP3
Refer to Section 4.7, “Updating SLE 11 SP3 to SLE 11 SP4” for details.
![[Important]](static/images/important.png) | Cross-architecture Upgrades are not Supported |
|---|---|
Cross-architecture upgrades (32-bit to 64-bit and 64-bit to 32-bit) are not supported. | |
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.
If you have selected 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.
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/DSoftware 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 access 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/doc/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:
(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 module in YaST or the suse_register command line tool to start the registration.
- Run an Online Update
Make sure the currently installed version has the latest patches installed. Run an Online Update prior to the Online Migration. When using a graphical interface, start the YaST Online Update or the updater applet. On the command line, run the following commands (the last command needs to be run twice):
zypper ref -s zypper update -t patch zypper update -t patch
Reboot the system if needed.
See Chapter 1, YaST Online Update (↑Administration Guide) or at Section “Updating Software with Zypper” (Chapter 7, Managing Software with Command Line Tools, ↑Administration Guide). for more information. on the online update tools.
- Third-Party Software
If your setup involves third-party software or add-on software, test this procedure on another machine to make sure that the dependencies are not broken by the update.
| 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 ¶
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 for an online migration from SP2 to SP3.
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 . Alternatively run /usr/sbin/wagon as
rootfrom the command line.Confirm the dialog with .
If 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.
Choose the update method in the following dialog. Choose to use the default setup (recommended).
Click 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-CoreandSP2-Updateschannels. Click to return to the dialog.If you want to review changes to the channel setup caused by the update process, select .
Proceed with .
The system will be re-registered. During this process the
SP2-CoreandSP2-Updateschannels will be added to the system (see Section 4.2.3, “Channel Model” for more information). Confirm the addition of the channels.If you have selected in the dialog, the list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Proceed with when finished.
Choose the migration type:
Updates all packages to the latest SP4 level.
Updates a minimal set of packages to the latest SP2 level.
Click to manually select the repositories used for upgrading.
Confirm your selection.
The screen opens, presenting a summary of the update configuration. The following sections are available:
You may add SUSE Linux Enterprise Server add-on products or third-party products here.
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.
Statistical overview of the update.
- Backup
Set backup options.
Click and to proceed.
Aborting the Online Migration It is safe to abort the online migration on this screen prior to clicking and on all previous screens. Click 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.
During the update procedure the following steps are executed:
Packages will be updated.
SuSEconfig will be run.
The system will be rebooted (press ).
The newly updated system will be re-registered.
Your system has been successfully updated to Service Pack 2.
4.5.1.3. Online Migration with zypper¶
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.Install the migration products retrieved on the previous step with the command zypper in -t product
LIST_OF_PRODUCTS, for examplezypper in -t product SUSE_SLED-SP2-migration
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
Refresh repositories and services again:
zypper ref -s
Check the list of repositories you can retrieve with zypper lr. At least the following repositories need to be :
SLED11-SP1-PoolSLED11-SP1-UpdatesSLED11-SP2-CoreSLED11-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
SP2ones are not enabled by default when following this workflow), enable them with zypper modifyrepo --enableREPOSITORY ALIAS, for example:zypper modifyrepo --enable SLED11-SP2-Core SLED11-SP2-Updates
If your setup contains third-party repositories that may not be compatible with SP2, disable them with zypper modifyrepo --disable
REPOSITORY ALIAS.Now everything is in place to perform the distribution upgrade with zypper dup --from
REPO 1--fromREPO 2.... Make sure to list all needed repositories with--from, for example:zypper dup --from SLED11-SP2-Core --from SLED11-SP2-Updates
Confirm with to start the upgrade.
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
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
Last, reboot your system.
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 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¶
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.
Select 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:
A network installation source is setup according to Section 11.2, “Setting Up the Server Holding the Installation Sources”.
A working network connection on both the installation server and the target machine that includes a name service, DHCP (optional, but needed for PXE boot), and OpenSLP (optional) exists.
The SUSE Linux Enterprise SP DVD 1 to boot the target system or a target system set up for PXE boot according to Section 11.3.5, “Preparing the Target System for PXE Boot” exist.
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:
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.
Select to boot the SP Kernel then use F4 to select the type of network installation source (FTP, HTTP, NFS, or SMB).
Provide the appropriate path information or select as the installation source.
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:
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”.
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”.
Prepare PXE boot and Wake-on-LAN on the target machine.
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.
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:
On the screen choose and and Accept the license agreement. Proceed with .
In case you have booted from a physical medium, perform a to verify the integrity of the medium. Only skip this step if you have checked the medium before.
On the screen, choose . Clicking on will start the update procedure.
4.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.
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/doc/suse_manager/ gives an overview of its features as well as instructions on how to set up server and clients.
4.6. Updating SLE 11 SP2 to SLE 11 SP3¶
Online Migration is supported by the following tools:
(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:
4.6.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 module in YaST or the suse_register command line tool to start the registration.
- Run an Online Update
Make sure the currently installed version has the latest patches installed. Run an Online Update prior to the Online Migration. When using a graphical interface, start the YaST Online Update or the updater applet. On the command line, run the following commands (the last command needs to be run twice):
zypper ref -s zypper update -t patch zypper update -t patch
Reboot the system if needed.
See Chapter 1, YaST Online Update (↑Administration Guide) or Section “Updating Software with Zypper” (Chapter 7, Managing Software with Command Line Tools, ↑Administration Guide) for more information on the online update tools.
- Third-Party Software
If your setup involves third-party software or add-on software, test this procedure on another machine to make sure that the dependencies are not broken by the update.
| 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. | |
4.6.2. Online Migration with YaST ¶
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 . Alternatively run /usr/sbin/wagon as
rootfrom the command line.Confirm the dialog with .
If 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.
Choose the update method in the following dialog. Choose to use the default setup (recommended).
Click 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
SLES11-SP4-PoolandSLES11-SP4-Updateschannels. Click to return to the dialog.If you want to review changes to the channel setup caused by the update process, select .
Proceed with .
The system will be re-registered. During this process the
SLES11-SP4-PoolandSLES11-SP4-Updateschannels will be added to the system (see Section 4.2.3, “Channel Model” for more information). Confirm the addition of the channels.If you have selected in the dialog, the list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Proceed with when finished.
The screen opens presenting a summary of the update configuration. The following sections are available:
You may add SUSE Linux Enterprise Server add-on products or third-party products here.
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.
Statistical overview of the update.
- Backup
Set backup options.
Click and to proceed.
Aborting the Online Migration It is safe to abort the online migration on this screen prior to clicking and on all previous screens. Click 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.
During the update procedure the following steps are executed:
Packages will be updated.
SuSEconfig will be run.
The system will be rebooted (press ).
The newly updated system will be re-registered.
Your system has been successfully updated to Service Pack 3.
4.6.3. Online Migration with zypper¶
When all requirements are met (see Section 4.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_SLED-SP4-migration. Depending on the scope of your installation, more products may be listed.Install the migration products retrieved in the previous step with the command zypper in -t product
LIST_OF_PRODUCTS, for examplezypper in -t product SUSE_SLED-SP3-migration
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
Refresh the repositories and services:
zypper ref -s
Check the list of repositories you can retrieve with zypper lr.
If any of these repositories is not enabled (the
SP3ones are not enabled by default when following this workflow), enable them with zypper modifyrepo --enableREPOSITORY ALIAS, for example:zypper modifyrepo --enable SLED11-SP3-Core SLED11-SP3-Updates
If your setup contains third-party repositories that may not be compatible with SP3, disable them with zypper modifyrepo --disable
REPOSITORY ALIAS.Now everything is in place to perform the distribution upgrade with zypper dup --from
REPO 1--fromREPO 2.... Make sure to list all needed repositories with--from, for example:zypper dup --from SLED11-SP3-Pool --from SLED11-SP3-Updates
Confirm with to start the upgrade.
Upon completion of the distribution upgrade from the previous step, run the following command:
zypper update -t patch
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
Lastly, reboot your system.
Your system has been successfully updated to Service Pack 3.
4.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.
4.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.
4.7.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 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.
| 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.7.1.2. Online Migration with YaST ¶
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 for an online migration from SP3 to SP4.
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 . Alternatively run /usr/sbin/wagon as
rootfrom the command line.Confirm the dialog with .
If 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.
Choose the update method in the following dialog. Choose to use the default setup (recommended).
Click 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-PoolandSP4-Updateschannels. Click to return to the dialog.If you want to review changes to the channel setup caused by the update process, select .
Proceed with .
The system will be re-registered. During this process the
SP4-PoolandSP4-Updateschannels will be added to the system (see Section 4.2.3, “Channel Model” for more information). Confirm the addition of the channels.If you have selected in the dialog, the list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Proceed with when finished.
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 to manually select the repositories used for upgrading. Confirm your selection.
The screen opens presenting a summary of the update configuration. The following sections are available:
You may add SUSE Linux Enterprise Server add-on products or third-party products here.
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.
Statistical overview of the update.
- Backup
Set backup options.
Click and to proceed.
Aborting the Online Migration It is safe to abort the online migration on this screen prior to clicking and on all previous screens. Click 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.
During the update procedure the following steps are executed:
Packages will be updated.
SuSEconfig will be run.
The system will be rebooted (press ).
The newly updated system will be re-registered.
Your system has been successfully updated to Service Pack 4.
4.7.1.3. Online Migration with zypper¶
When all requirements are met (see Section 4.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_SLED-SP4-migration. Depending on the scope of your installation, more products may be listed.Install the migration products retrieved in the previous step with the command zypper in -t product
LIST_OF_PRODUCTS, for examplezypper in -t product SUSE_SLED-SP4-migration
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
Refresh the repositories and services:
zypper ref -s
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
SP4ones are not enabled by default when following this workflow), enable them with zypper modifyrepo --enableREPOSITORY ALIAS, for example:zypper modifyrepo --enable SLED11-SP4-Pool --from SLED11-SP4-Updates
If your setup contains third-party repositories that may not be compatible with SP4, disable them with zypper modifyrepo --disable
REPOSITORY ALIAS.Now everything is in place to perform the distribution upgrade with zypper dup --from
REPO 1--fromREPO 2.... Make sure to list all needed repositories with--from, for example:zypper dup --from SLED11-SP4-Pool --from SLED11-SP4-Updates
Confirm with to start the upgrade.
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
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
Lastly, reboot your system.
Your system has been successfully updated to Service Pack 4.
4.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 11.2, “Setting Up the Server Holding the Installation Sources”.
4.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.
4.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.
4.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.
4.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.
4.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#1234that 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.SUSEorREADME.SuSEfile 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-2495which 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.
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]](static/images/warning.png) | Strict Partitioning Requirements |
|---|---|
The implementation has strict requirements on disk partitioning: the
first root partition is
The size of the complete disk minus size of
| |
Install the system with
/dev/sda1as the single root partition and with less than half of the entire disk size.Customize the installed system as needed. Make sure to have the
multi-update-toolspackage installed.Run multi-update-setup --partition, which creates the system's second root partition (
/dev/sda2) of the similar size.Partition the rest of the disk as needed and continue with customizations(*).
Run multi-update-setup --clone to copy the system to the other partition. With this command you also change the
/(root) entry in/etc/fstabof the target system.If needed, do further customizations(*).
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.
GRUB Bootloader Mandatory Installation of the GRUB boot loader is mandatory. The tools are not compatible with other boot loaders.
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 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 12, The Boot Loader GRUB (↑Administration Guide).
4.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.
4.9.5. For More Information¶
For more information, see
/usr/share/doc/packages/multi-update-tools/README
coming with the multi-update-tools package.
4.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.
4.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:
stepis a predefined migration step name, describing the current migration step.
seqis 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!)
prefixshould 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
namecan be any string (just to differentiate the scripts). Some descriptive name is recommended.
Example 4.2. Hook Script with Full Path
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup
4.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.
4.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).
4.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)
4.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.
4.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
4.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.
4.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.