The following procedure is a way to do a mass upgrade unattended from SUSE Linux Enterprise 11 SP2 to SUSE Linux Enterprise 11 SP3. Several preparation steps are needed to create a suitable AutoYaST profile. AutoYaST finally will execute the upgrade process.
The AutoYaST profile for the automated upgrade uses the same file format as the AutoYaST installation. For more information about AutoYaST, see Chapter 21, Automated Installation and AutoYaST.
However, there are some parts of the system (for example, partitioning) that do not make sense to be configured during the upgrade. On the other hand, it is useful to set upgrade-specific options by means of the AutoYaST profile.
The upgrade options define the behavior of the dependency solver during upgrade:
<upgrade>
<only_installed_packages
config:type="boolean">false</only_installed_packages>
<stop_on_solver_conflict
config:type="boolean">true</stop_on_solver_conflict>
</upgrade>only_installed_packages
Set to true for package-based upgrades
(recommended for upgrading to the next service pack of the same
product) or false for pattern-based upgrades
(recommended for an upgrade between versions of a product, for
example, from SLES10 to SLES11).
stop_on_solver_conflict
Defines whether to show the proposal in case of failure to resolve
package dependencies interactively (recommended to be set to
true, but this could result in an interactive
process, during which the user needs to resolve the conflicts
manually).
The software selection options define, which components to select or deselect in addition to the results of the resolver:
<software>
<packages config:type="list">
<package>autoyast2-installation</package>
<package>apparmor-profile-editor</package>
</packages>
<patterns config:type="list">
<pattern>base</pattern>
</patterns>
<remove-packages config:type="list"/>
<remove-patterns config:type="list"/>
</software>
It is especially important to set packages or patterns for being
selected or deselected in order to resolve package conflicts and thus to
avoid the need for interactive intervention. After the upgrade is done,
the newly created autoupg_updated.xml file contains
these packages and patterns plus those that were selected or deselected
for any other reason.
The backup before upgrade options match these features in the upgrade proposal.
<backup> <sysconfig config:type="boolean">true</sysconfig> <modified config:type="boolean">true</modified> <remove_old config:type="boolean">false</remove_old> </backup>
sysconfig
defines whether to back up sysconfig before upgrading.
modified
defines whether to back up the modified configuration files before upgrading.
remove_old
defines whether to remove old backups from previous upgrades.
To start the automated upgrade, boot the installation media and pass the AutoYaST profile to it. There are two ways to pass the profile to the system:
Pass the profile to the kernel command line the same way as for the
AutoYaST installation (use the autoupgrade=1
autoyast=http://host/path/profile.xml parameter.
For System z, this is the only possibility.
Pass the autoupgrade=1 parameter to the kernel
command line. Before you start the upgrade, copy the profile to
/root/autoupg.xml. Then there is no need for any
additional kernel parameter.
The latter approach allows you to have a single installation kernel command line for even different machines—just copy the appropriate profile into its file system.
As long as you have only one SUSE Linux Enterprise system installed on your machine, there are no package conflicts and you did not set the profile to stop on the upgrade proposal, the complete process will be non-interactive. In case you enter the upgrade proposal, you can modify its settings for the upgrade.
After the upgrade finishes, YaST writes the
/root/autoupg-updated.xml file, which contains the
profile with applied software selection changes done in the proposal.
This is especially useful in case of mass upgrades of machines with the
same package selection. This way, conflict resolutions from one machine
can easily be applied on other machines, which consequently will get
these conflicts resolved automatically and the upgrade itself will be
non-interactive.
If there are more SUSE Linux Enterprise systems installed on the machine, you will always be asked, which one to upgrade—there is no way to select it in advance.
An alternate way to boot the system is to create an additional section in
the GRUB 2 menu (and similar for other boot loaders and other
architectures), which starts the installation. The following example
assumes that there is a separate /boot partition,
which is referred in GRUB 2 as (hd0,0):
title Upgrade
root (hd0,0)
kernel /upgrade/linux
install=inst_source_url autoupgrade=1
autoyast=autoyast_profile_url vga=0x314
initrd /upgrade/initrd
The above example assumes that the installation kernel and the
installation initrd
are located in the /boot/upgrade directory.
On System z, you must add the parameters to the PARM file—proceed the same way as you do when performing an AutoYaST-driven installation.
The automated upgrade by default does not perform configuration changes during the second stage of the upgrade. The only exception is network configuration, which needs to be set to be preserved in the AutoYaST upgrade profile.
If configuration adjustment of some system areas is needed after the upgrade (for example, configuring a new service), add the relevant sections to the AutoYaST profile for the upgrade and the configuration of the selected system areas will be saved during the upgrade.
Be warned that existing configuration of that system area will be replaced and thus destroyed by the AutoYaST configuration.
Normally, the only configuration adjustment, which should be present in the AutoYaST profile, is the registration of the system with Subscription Management Tool (SMT) or SUSE Customer Center (SCC). If this is missing, the system will not get the update repository and updates will not be possible—unless configured later again.
In case of using NetworkManager for managing network devices and network connections, network connection is not available during the second stage of the upgrade. This prevents the system from performing the registration.
If you do any changes in your system in order to trigger the upgrade process (for example, adding a new section to the boot loader menu), you probably want to remove it after the upgrade is done.
You can do it automatically with a post-installation script. Find an
examples in Section “Custom User Scripts”, Chapter 4, Configuration and Installation Options, AutoYaST. A sample script
cleaning up GRUB 2's menu.lst is included in the
sample autoupg.xml file. Make sure that the script
matches your particular setup and that it does not remove more than you
actually want!
Linuxrc Documentation: http://en.opensuse.org/SDB:Linuxrc