Contents
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.
This chapter uses several terms. In order to understand the information, read the definitions below:
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.
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.
A package is a compressed file in rpm format that
contains the files for a particular program.
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.
Installation of a newer minor version of a package.
Installation of a newer major version of a package or distribution, which brings new features.
Updating to a Service Pack (SP) by using the online update tools (rather than the installation media) to install the respective patches. There are two possible migration paths. In the following, SPx+1 refers to the new Service Pack that is going to be installed, whereas SPx refers to the currently installed Service Pack.
Updates all Packages of the installed system to the latest state—including updates—of SPx+1 plus SPx updates.
Updates all Packages of the installed system to the latest state of SPx+1 Core packages, SPx+1 Updates and few SPx updates.
The SUSE Linux Enterprise 11 Maintenance Model combines flexibility and control of your service packs. It offers the following benefits:
Makes service packs more lightweight and easier to test and deploy.
Allows staying with older versions, but with support for the full system.
Answers market needs in between service packs by selective enhancements and allows more updates in the general update repository. By selecting the enhancements, it mitigates longer periods between service packs.
Figure 4.1, “Maintenance Delivery Evolution (also applies to SLED)” depicts some of the mentioned aspects above.
Our products have a 10-year life-cycle: 7 years general support and 3 years extended support. Major releases are made every 4 years and service packs every 18 months. The Long Term Service Pack Support is an extended window or extended major release life-cycle (see Figure 4.2, “Long Term Service Pack Support”).
The Long Term Service Pack Support requires active subscription, either standard or priority. It does not affect L1 or L2 subscription terms. Security updates are handled “proactively”: these are any non-user driven critical vulnerabilities, local root exploits in Kernel or other root exploits directly executable without user interaction.
The range for extended support levels starts from year 8 and ends in year 10. These contain continued L3 engineering level diagnosis and reactive critical bug fixes. These support levels proactively update trivial local root exploits in Kernel or other root exploits directly executable without user interaction. Furthermore they support existing workloads, software stacks, and hardware with limited package exclusion list. Find an overview in Table 4.1, “Security Updates and Bug Fixes”.
Table 4.1. Security Updates and Bug Fixes¶
|
— General Support — |
Extended Support | ||||
|---|---|---|---|---|---|
|
Topic |
Current SP |
SP (n-1) 6 months |
SP (n-1) with LTSS |
Year 6 & 7 with LTSS |
Year 8, 9, 10 with LTSS |
|
L1/L2 Technical Services |
✓ |
✓ |
✓ |
✓ |
✓ |
|
Proactive Maintenance |
✓ |
✓ |
✓ | ||
|
Driver Updates via PLDP |
✓ |
✓ |
✓ | ||
|
Proactive Security Updates |
✓ |
✓ |
✓ |
✓ | |
|
L3 Engineering Support |
✓ |
✓ |
✓ |
✓ |
✓ |
|
Back-ports available |
✓ |
✓ |
✓ |
✓ | |
With the former maintenance model, SUSE Linux Enterprise Desktop, had two channels
assigned: SLED11-SPx-pool and
SLED11-SPx-Updates. During an online migration
to SPx+1 these channels were temporary replaced by
SLED11-SPx-Online.
With SUSE Linux Enterprise SP 2 the channel layout has changed to support the benefits of the new maintenance model. The following channels are assigned to a product:
SLED11-SPx-Updates
SLED11-SPx-Core
SLED11-SPx-LTSS-Updates (optional)
SLED11-SPx-Extension-Store (optional)
SLED11-SP(x-1)-Updates
SLED11-SP(x-1)-Core
SLED11-SP(x-2)-Updates
SLED11-SP(x-2)-Core
...
SLED11-SP1-Updates
SLED11-SP1-Pool
Each repository type contains a different set of packages:
A subset of the unpacked installation media, it only contains those packages that are considered to be the "core" of SPx (approximately 30% of the package total). The SP repositories only contain packages specific to a SP and its themes (e.g. hardware enablement)
Maintenance updates to packages in the corresponding
Core or Pool repository.
Maintenance updates to packages in the corresponding
Core repository for installations with Long Term
Support Service.
Not yet in use, yet. Supposed to contain packages for (future) add-on products.
The unpacked SP1 installation media, containing all binary RPMs from the installation media, plus pattern information and support status metadata. This repository is only available for SP1.
The base channel for SUSE Linux Enterprise 11 is SLED11-SP1-Pool. It's the only channel containing
all packages. This channel and it's content will not
change throughout the entire life cycle of SUSE Linux Enterprise 11. A package will be
served from this channel as long as no update for this package is
available.
Once a package gets updated, the update is served from SLED11-SP1-Updates. This channel contains all
packages having been updated since the release of SP1.
Once Service Pack 2 is installed, two additional channels will be added:
SLED11-SP2-Core and SLED11-SP2-Updates. SP2-Core
contains a subset of packages from SP1-Pool. These
packages are newer than the versions in both SP1 channels. Once an
SP2-Core package gets updated, the update is served
from SLED11-SP2-Updates. This channel contains all
packages having been updated since the release of SP2.
Starting with the installation of SP2 the following rules on the origin of packages apply:
Non-core-packages will be served from SP1-Pool or
SP1-Updates throughout the entire life cycle of SUSE Linux Enterprise
11.
Core packages will always be served from SPx-Core or
SPx-Update. In case a package gets dropped from the
Core in SPx, it will be served from SPx-1 for the entire rest of the
life cycle of SUSE Linux Enterprise 11.
There is no supported direct upgrade path from these versions. Instead it is recommended to perform a new installation.
There is no supported direct migration path to SUSE Linux Enterprise 11. An update has to be performed from SUSE Linux Enterprise 10 GA to SP 1, then to SP 2, further to SP 3, and then to SP4 by using the respective boot media. SP4 can be updated to SUSE Linux Enterprise 11 SP2 following the procedure outlined in Section 4.6, “Updating SLE 10 SP4 to SLE 11 SP2”.
The supported migration path from SUSE Linux Enterprise 10 SP4 to SUSE Linux Enterprise 11 Service Pack 2 is by using the SUSE Linux Enterprise 11 SP 2 boot media. See Section 4.6, “Updating SLE 10 SP4 to SLE 11 SP2” for details.
There is no supported direct migration path to SUSE Linux Enterprise 11 SP2. An update hast to be performed from SUSE Linux Enterprise 11 GA to SP1 first. Proceed with Section 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” afterwards.
Refer to Section 4.5, “Updating SLE 11 SP1 to SLE 11 SP2” for details.
Before starting the update procedure, make sure your system is properly prepared. Among others, preparation involves backing up data and checking the release notes.
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.
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.
If your machine serves as a VM Host Server for KVM or Xen, make sure to properly shut down all running VM Guests prior to the update. Otherwise you may not be able to acces the guests after the update.
For version specific requirements, refer to the release notes coming with the update product. In the release notes you can find additional information about upgrade procedures.
The current version of the release notes document containing the latest information on SUSE Linux Enterprise Desktop can be read online at http://www.suse.com/documentation/sles11/#additional.
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.
Updating your system via online migration is done from within the running system. You only need to reboot once, after the update is completed.
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”.
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 commandline tool to start the registration.
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 patchReboot 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.
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. | |
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 root from
the command line.
Confirm the dialog with .
If finds that the requirements are not met (needed maintenance updates available but not yet installed) it will do an automatic self update that may require to reboot. Follow the on-screen instructions.
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-Core and
SP2-Updates channels.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-Core and SP2-Updates channels
will be added to the system (see Section 4.2.1, “Channel Model” for more information). Confirm the
addition of the channels.
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. See Section 4.1, “Terminology” for details.
Updates all packages to the latest SP2 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 add SUSE Linux Enterprise Server add-on products or 3rd 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.
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.
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 example
zypper 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-Pool
SLED11-SP1-Updates
SLED11-SP2-Core
SLED11-SP2-Updates
Depending on the scope of your installation, further repositories for add-on products or extensions need to be enabled.
If one of these repositories is not enabled (the SP2
ones are not enabled by default when following this workflow), enable
them with zypper modifyrepo --enable REPOSITORY
ALIAS, for example:
zypper modifyrepo --enable SLED11-SP2-Core SLED11-SP2-Updates
If your setup contains 3rd party repositories that may not be
compatible with SP2, disable them with zypper modifyrepo
--disable REPOSITORY ALIAS.
Now everything is in place to perform the distribution upgrade with
zypper dup --from REPO 1 --from
REPO 2
.... Make sure to list all needed
repositories with --from, for example:
zypper dup --from SLED11-SP2-Core --from SLED11-SP2-Updates
Confirm with 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.
As an alternative to the Online Migration (see Section 4.5.1, “Online Migration” for details) you may also update your system by booting from an installation source—either a DVD or a network installation source. The update will start like a normal installation.
Service Pack 2 ISO images can be obtained from http://download.novell.com/. Either burn it to a DVD or prepare a network installation source as described in Section 11.2, “Setting Up the Server Holding the Installation Sources”.
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.
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.
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”.
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”.
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.
As an alternative to downloading the updates for each single client system from the Novell update server, it is possible to use the Subscription Management Tool (SMT) for SUSE Linux Enterprise to mirror the updates to a local server.
This tool acts as Novell Customer Center proxy both for client registrations and as software update repository. The SMT documentation at http://www.suse.com/documentation/smt11/ gives an overview of its features as well as instructions on how to implement it.
SUSE Manager is a server solution for providing updates, patches, and security fixes for SUSE Linux Enterprise clients. It comes with a set of tools and a Web-based user interface for management tasks.
The SUSE Manager documentation at http://www.suse.com/documentation/suse_manager/ gives an overview of its features as well as instructions on how to set up server and clients.
The supported migration path from SUSE Linux Enterprise 10 SP4 to SUSE Linux Enterprise 11 SP2 is by using the SUSE Linux Enterprise 11 SP 2 boot media. Please refer to the instructions at Section 4.5.2, “Updating by Booting from an Installation Source”. Make sure to update your SUSE Linux Enterprise 10 system to the latest patch level by running an online update prior to starting the update to SP2.
If you update a default system from the previous version to the current version, YaST works out necessary changes and performs them. Depending on your customizations, some steps or the entire update procedure may fail and you must resort to copying back your backup data. Check the following issues before starting the system update.
Before updating the system, make sure that
/etc/passwd and /etc/group do
not contain any syntax errors. For this purpose, start the verification
utilities pwck and grpck as
root and eliminate any
reported errors.
Before updating PostgreSQL
(postgres), dump the
databases. See the manual page of pg_dump. This is
only necessary if you actually used PostgreSQL prior to your update.
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.
![]() | 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/sda1 as 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-tools package 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/fstab
of the target system.
If needed, do further customizations(*).
Run multi-update-setup --bootloader to initialize the bootloader setup. The bootloader menu will then contain an entry to boot the other system.
![]() | GRUB Bootloader Mandatory |
|---|---|
Installation of the GRUB bootloader is mandatory. The tools are not compatible with other bootloaders. | |
If there are no customizations to be done as marked with (*), run multi-update-setup --complete which performs all the three steps.
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.
If the updated system has a damaged bootloader after the update, you must change the “Active” flag and set it for the root partition of the other system in order to boot it.
If the updated system does not boot at all, you need access to the bootloader menu to select the other system.
For more information about GRUB, see Chapter 11, The Boot Loader GRUB (↑Administration Guide).
For more information, see
/usr/share/doc/packages/multi-update-tools/README
coming with the multi-update-tools package.