Chapter 5 Upgrading With Solaris Live Upgrade (Tasks)

This chapter explains how to use Solaris Live Upgrade to upgrade and
activate an inactive boot environment.

Note –

This chapter describes Solaris Live Upgrade for UFS file systems.
The usage is the same for the luupgrade and luactivate commands for a ZFS boot environment. For procedures for migrating
a UFS file system to a ZFS root pool or creating and installing a ZFS root
pool, see Chapter 13, Creating a Boot Environment for ZFS Root Pools.

Upgrading a Boot Environment

Use the luupgrade command
to upgrade a boot environment. This section provides the procedure for upgrading
an inactive boot environment from files that are located on the following
media:

NFS server

Local file

Local tape

Local device, including DVD or CD

Guidelines for Upgrading

When you upgrade a boot environment with the latest OS, you do
not affect the active boot environment. The new files merge with the inactive
boot environment critical file systems, but shareable file systems are not
changed.

You can upgrade when RAID-1 volumes are installed, or if non-global
zones are installed, or you can install a Solaris Flash:

You can upgrade an inactive boot environment that contains
any combination of physical disk slices, Solaris Volume Manager volumes, or
Veritas Volume Manager volumes. The slice that is chosen for the root (/) file system must be a single-slice concatenation that is included
in a RAID–1 volume (mirror). For procedures about creating a boot environment
with mirrored file systems, see To Create a Boot Environment With RAID-1 Volumes (Mirrors).

Note –

If VxVM volumes are configured on your current system, the lucreate command can create a new boot environment. When the data is copied
to the new boot environment, the Veritas file system configuration is lost
and a UFS file system is created on the new boot environment.

Rather than upgrading, if you have created a Solaris Flash archive,
you could install the archive on an inactive boot environment. The new files
overwrite critical file systems of the inactive boot environment, but shareable
file systems are not changed. See Installing Solaris Flash Archives on a Boot Environment.

Upgrading a System With Packages or Patches

You can use Solaris Live Upgrade to add patches and packages to
a system. Solaris Live Upgrade creates a copy of the currently running system.
This new boot environment can be upgraded or you can add packages or patches.
When you use Solaris Live Upgrade, the only downtime the system incurs is
that of a reboot. You can add patches and packages to a new boot environment
with the luupgrade command.

Caution –

When adding and removing packages or patches, Solaris Live
Upgrade requires packages or patches that comply with the SVR4 advanced packaging
guidelines. While Sun packages conform to these guidelines, Sun cannot guarantee
the conformance of packages from third-party vendors. If a package violates
these guidelines, the package can cause the package-addition software to fail
or alter the active boot environment during an upgrade.

In this example, the second_disk boot environment
is upgraded and the installation image is on two CDs: the Solaris Software - 1 and
the Solaris Software - 2 CDs. The -u option determines if
sufficient space for all the packages is on the CD set. The -O option
with the -nodisplay and -noconsole options
prevents the character user interface from displaying after the reading of
the second CD. If you use these options, you are not prompted to type information.

Note: If you do not use the -O option
with the -nodisplay and -noconsole options,
the character user interface (CUI) is displayed. Sun no longer recommends
using the CUI to do Solaris Live Upgrade tasks.

Install the Solaris Live Upgrade packages from the release you are upgrading
to.

To Add Packages to a Network Installation Image on
a Boot Environment

In the following procedure, packages are removed from and added to a
new boot environment.

Caution –

When you are upgrading. adding and removing packages or patches,
Solaris Live Upgrade requires packages or patches that comply with the SVR4
advanced packaging guidelines. While Sun packages conform to these guidelines,
Sun cannot guarantee the conformance of packages from third-party vendors.
If a package violates these guidelines, the package can cause the package-addition
software to fail or can alter the active boot environment.

To Add Patches to a Network Installation Image on
a Boot Environment

In the following procedure, patches are removed from and added to a
new boot environment.

Caution –

When you are adding and removing packages or patches, Solaris
Live Upgrade requires packages or patches that comply with the SVR4 advanced
packaging guidelines. While Sun packages conform to these guidelines, Sun
cannot guarantee the conformance of packages from third-party vendors. If
a package violates these guidelines, the package can cause the package-addition
software to fail or can alter the active boot environment.

Caution –

You cannot use Solaris Live Upgrade to patch a Solaris 10 inactive
boot environment when the active boot environment is running the Solaris 8
or 9 OS. Solaris Live Upgrade will invoke the patch utilities on the active
boot partition to patch the inactive boot partition. The Solaris 8 and Solaris
9 patch utilities are unaware of Solaris Zone, Service Management Facility
(SMF), and other enhancements in the Solaris 10 OS. Therefore the patch utilities
fail to correctly patch an inactive Solaris 10 boot environment. Therefore,
if you are using Solaris Live Upgrade to upgrade a system from the Solaris
8 or Solaris 9 OS to the Solaris 10 OS, you must first activate the Solaris
10 boot environment before patching. After the Solaris 10 boot environment
is activated, you can either patch the active boot environment directly or
set up another inactive boot environment and patch that one by using Solaris
Live Upgrade. For an example of upgrading and patching from the Solaris 8
to the Solaris 10 release, see Restrictions for Using Solaris Live Upgrade.

To check the integrity of the newly installed packages on the
new boot environment, type:

# luupgrade -C -n BE_name -O "-v" package-name

-C

Indicates to run the pkgchk command on
the named packages

-nBE_name

Specifies the name of the boot environment where the check
is to be performed

-O

Passes the options directly to the pkgchk command

package-name

Specifies the names of the packages to be checked. Separate
multiple package names with spaces. If package names are omitted, the check
is done on all packages in the specified boot environment.

“-v”

Specifies to run the command in verbose mode

Example 5–6 Checking the Integrity of Packages on a Boot Environment

In this example, the packages SUNWabc,SUNWdef, and SUNWghi are checked to make sure they were
installed properly and are not damaged.

# luupgrade -C -n second_disk SUNWabc SUNWdef SUNWghi

Upgrading by Using a JumpStart Profile

You can create a JumpStart profile to use with Solaris Live Upgrade.
If you are familiar with the custom JumpStart program, this is the same profile
that custom JumpStart uses. The following procedures enable you to create
a profile, test the profile, and install by using the luupgrade command
with the -j option.

Caution –

When you install the Solaris OS with a Solaris Flash archive,
the archive and the installation media must contain identical OS versions.
For example, if the archive is the Solaris 10 operating system and you are
using DVD media, then you must use Solaris 10 DVD media to install the archive.
If the OS versions do not match, the installation on the target system fails.
Identical operating systems are necessary when you use the following keyword
or command:

Name the
file descriptively. Ensure that the name of the profile reflects how you intend
to use the profile to install the Solaris software on a system. For example,
you might name this profile upgrade_Solaris_10.

Add profile keywords and values to the profile.

Only
the upgrade keywords in the following tables can be used in a Solaris Live
Upgrade profile.

The following table lists the keywords you can use
with the Install_type keyword values of upgrade or flash_install.

Keywords for an Initial Archive Creation

Description

Reference

(Required) Install_type

Defines whether to upgrade the existing Solaris environment on a system
or install a Solaris Flash archive on the system. Use the following values
with this keyword:

Before you install a Solaris Flash archive on a clone system, you
can create custom scripts to preserve local configurations on the clone system.
The local_customization keyword designates the directory
where you have stored these scripts. The value is the path to the script on
the clone system.

Forces the installation
of a Solaris Flash differential archive onto a clone system that is different
than the software expects. If you use forced_deployment,
all new files are deleted to bring the clone system to the expected state.
If you are not certain that you want files to be deleted, use the default,
which protects new files by stopping the installation.

Before
you install a Solaris Flash archive on a clone system, you can create
custom scripts to preserve local configurations on the clone system. The local_customization keyword designates the directory where you have
stored these scripts. The value is the path to the script on the clone system.

When installing a clone system with a Solaris Flash differential
archive, you can use the no_content_check keyword to ignore
file-by-file validation. File-by-file validation ensures that the clone system
is a duplicate of the master system. Avoid using this keyword unless you are
sure the clone system is a duplicate of the original master system.

When installing a clone system with a Solaris Flash differential
archive, you can use the no_master_check keyword to ignore
a check of files. Clone system files are not checked. A check would ensure
the clone was built from the original master system. Avoid using this keyword
unless you are sure the clone system is a duplicate of the original master
system.

Example 5–7 Creating a Solaris Live Upgrade Profile

In this example, a profile provides the upgrade parameters. This
profile is to be used to upgrade an inactive boot environment with the Solaris
Live Upgrade luupgrade command and the -u and -j options. This profile adds a package and a cluster. A regional
locale and additional locales are also added to the profile. If you add locales
to the profile, make sure that you have created a boot environment with additional
disk space.

Example 5–8 Creating a Solaris Live Upgrade Profile to Install a Differential Archive

The following example of a profile is to be
used by Solaris Live Upgrade to install a differential archive on a clone
system. Only files that are specified by the differential archive are added,
deleted, or changed. The Solaris Flash archive is retrieved from an NFS server.
Because the image was built by the original master system, the clone system
is not checked for a valid system image. This profile is to be used with the
Solaris Live Upgrade luupgrade command and the -u and -j options.

To Test a Profile to Be Used by Solaris Live
Upgrade

After you create a profile, use the luupgrade command
to test the profile. By looking at the installation output that is generated
by luupgrade, you can quickly determine if a profile works
as you intended.

luupgrade command uses the selected boot
environment's disk configuration to test the profile options that are passed
with the -j option.

-sos_image_path

Specifies the path name of a directory that contains an operating
system image. This directory can be on an installation medium, such as a DVD-ROM,
CD-ROM, or it can be an NFS or UFS directory.

-jprofile_path

Path to a profile that is configured for an upgrade. The profile
must be in a directory on the local machine.

Example 5–9 Testing a Profile by Using Solaris Live Upgrade

In the following example, the profile is named Flash_profile. The profile is successfully tested on the inactive boot environment
that is named second_disk.

# luupgrade -u -n u1b08 -D -s /net/installsvr/export/u1/combined.u1wos \-j /var/tmp/flash_profile
Validating the contents of the media /net/installsvr/export/u1/combined.u1wos.
The media is a standard Solaris media.
The media contains an operating system upgrade image.
The media contains Solaris version 10.
Locating upgrade profile template to use.
Locating the operating system upgrade program.
Checking for existence of previously scheduled Live Upgrade requests.
Creating upgrade profile for BE second_disk.
Determining packages to install or upgrade for BE second_disk.
Simulating the operating system upgrade of the BE second_disk.
The operating system upgrade simulation is complete.
INFORMATION: var/sadm/system/data/upgrade_cleanup contains a log of the
upgrade operation.
INFORMATION: var/sadm/system/data/upgrade_cleanup contains a log of
cleanup operations required.
The Solaris upgrade of the boot environment second_disk is complete.

You can now use the profile to upgrade an inactive boot environment.

To Upgrade With a Profile by Using Solaris
Live Upgrade

This procedure provides step-by-step instructions for upgrading an OS
by using a profile.

If you added locales to the profile, make sure that you have created
a boot environment with additional disk space.

Caution –

When you install the Solaris OS with a Solaris Flash archive,
the archive and the installation media must contain identical OS versions.
For example, if the archive is the Solaris 10 operating system and you are
using DVD media, then you must use Solaris 10 DVD media to install the archive.
If the OS versions do not match, the installation on the target system fails.
Identical operating systems are necessary when you use the following keyword
or command:

Example 5–10 Upgrading a Boot Environment by Using a Custom JumpStart Profile

In this example, the second_disk boot environment
is upgraded by using a profile. The -j option is used to access
the profile. The boot environment is then ready to be activated. To create
a profile, see To Create a Profile to be Used by Solaris Live Upgrade. The pkgadd command
adds the Solaris Live Upgrade packages from the release you are upgrading
to.

Installing Solaris Flash Archives on
a Boot Environment

This section provides the procedure
for using Solaris Live Upgrade to install Solaris Flash archives. Installing
a Solaris Flash archive overwrites all files on the new boot environment
except for shared files. Archives are stored on the following media:

HTTP server

FTP server – Use this path from the command line only

NFS server

Local file

Local tape

Local device, including DVD or CD

Note the following issues with installing and creating a Solaris Flash archive.

Description

Example

Caution –

When you install the Solaris OS with a Solaris Flash archive,
the archive and the installation media must contain identical OS versions.
If the OS versions do not match, the installation on the target system fails.
Identical operating systems are necessary when you use the following keyword
or command:

archive_location keyword in a profile

luupgrade command with -s, -a, -j, and -J options

For example, if the archive is the Solaris 10 operating system and you
are using DVD media, then you must use Solaris 10 DVD media to install the
archive.

Caution –

A Solaris Flash archive cannot be properly created when
a non-global zone is installed. The Solaris Flash feature is not compatible
with the Solaris Zones feature. If you create a Solaris Flash archive in
a non-global zone or create an archive in a global zone that has non-global
zones installed, the resulting archive does not install properly when the
archive is deployed.

Description

For More Information

For examples of the correct syntax for paths that are associated with
archive storage.

Indicates to install an operating system from a Solaris Flash archive.

-nBE_name

Specifies the name of the boot environment that is to be installed
with an archive.

-sos_image_path

Specifies the path name of a directory that contains an operating
system image. This directory can be on an installation medium, such as a DVD-ROM,
CD-ROM, or it can be an NFS or UFS directory. This OS image provides a miniroot
that boots a minimal, bootable root (/) file system to facilitate the installation
of the Solaris Flash archive. The miniroot is not the image that is installed.
The -a option provides the operating system image.

-aarchive

Path to the Solaris Flash archive when the archive is
available on the local file system. The operating system image versions that
are specified with the -s option and the -a option
must be identical.

Example 5–11 Installing Solaris Flash Archives on a Boot Environment

In this example, an archive is installed on the second_disk boot
environment. The archive is located on the local system. The -s option
provides a miniroot that boots a minimal, bootable root (/) file system to
facilitate the installation of the Solaris Flash archive. The miniroot is
not the image that is installed. The -a option provides the
operating system image. The operating system versions for the -s and -a options are both Solaris 10 10/09 releases. All files are
overwritten on second_disk except shareable files. The pkgadd command adds the Solaris Live upgrade packages from the release
you are upgrading to.

Indicates to install an operating system from a Solaris Flash archive.

-nBE_name

Specifies the name of the boot environment that is to be upgraded.

-sos_image_path

Specifies the path name of a directory that contains an operating
system image. This directory can be on an installation medium, such as a DVD-ROM,
CD-ROM, or it can be an NFS or UFS directory. This OS image provides a miniroot
that boots a minimal, bootable root (/) file system to facilitate the installation
of the Solaris Flash archive. The miniroot is not the image that is installed.
The -j option provides the path to the profile that contains
the Solaris Flash archive operating system image.

-jprofile_path

Path to a JumpStart profile that is configured for a flash
installation. The profile must be in a directory on the local machine. The -s option's operating system version and the Solaris Flash archive
operating system version must be identical.

After creating the profile, you can run the luupgrade command
and install the archive. The -s option provides a miniroot
that boots a minimal, bootable root (/) file system to facilitate the installation
of the Solaris Flash archive. The miniroot is not the image that is installed.
The -j option provides the path to the profile that contains
the path to the Solaris Flash archive operating system image. The -j option
is used to access the profile. The pkgadd command adds
the Solaris Live Upgrade packages from the release you are upgrading to.

To Install a Solaris Flash Archive With
a Profile Keyword

This procedure enables you to install
a Solaris Flash archive and use the archive_location keyword
at the command line rather than from a profile file. You can quickly retrieve
an archive without the use of a profile file.

Specifies to upgrade an operating system from a Solaris Flash archive.

-nBE_name

Specifies the name of the boot environment that is to be upgraded.

-sos_image_path

Specifies the path name of a directory that contains an operating
system image. This directory can be on an installation medium, such as a DVD-ROM,
CD-ROM, or it can be an NFS or UFS directory. This OS image provides a miniroot
that boots a minimal, bootable root (/) file system to facilitate the installation
of the Solaris Flash archive. The miniroot is not the image that is installed.
The -j option provides the path to the profile that contains
the Solaris Flash archive operating system image.

Example 5–13 Installing a Solaris Flash Archive By Using a Profile Keyword

In this example, an archive is installed on the second_disk boot
environment. The -s option provides a miniroot that boots
a minimal, bootable root (/) file system to facilitate the installation of
the Solaris Flash archive. The miniroot is not the image that is installed.
The -j option provides the path to the Solaris Flash archive
operating system image. The -J option and the archive_location keywords are used to retrieve the archive. All files are overwritten
on second_disk except shareable files. The pkgadd command
adds the Solaris Live Upgrade packages from the release you are upgrading
to.

If you have an x86 based system, you can also activate
with the GRUB menu. Note the following exceptions:

If a boot environment was created with the Solaris 8, 9, or 10 3/05 release, the boot environment
must always be activated with the luactivate command. These
older boot environments do not display on the GRUB menu.

The first time you activate a boot environment, you must use
the luactivate command. The next time you boot, that boot
environment's name is displayed in the GRUB main menu. You can thereafter
switch to this boot environment by selecting the appropriate entry in the
GRUB menu.

To Activate a Boot Environment

The following procedure switches a new boot environment to become the
currently running boot environment.

x86 only –

If you have an x86 based system, you can also activate
with the GRUB menu. Note the following exceptions:

If a boot environment was created with the Solaris 8, 9, or 10 3/05 release, the boot environment
must always be activated with the luactivate command. These
older boot environments do not display on the GRUB menu.

The first time you activate a boot environment, you must use
the luactivate command. The next time you boot, that boot
environment's name is displayed in the GRUB main menu. You can thereafter
switch to this boot environment by selecting the appropriate entry in the
GRUB menu.

Use only the init or shutdown commands
to reboot. If you use the reboot, halt,
or uadmin commands, the system does not switch boot environments.
The last-active boot environment is booted again.

Example 5–14 Activating a Boot Environment

In this example, the second_disk boot environment
is activated at the next reboot.

# /sbin/luactivate second_disk
# init 6

To Activate a Boot Environment and Synchronize
Files

The first time you boot from a newly created boot environment, Solaris
Live Upgrade software synchronizes the new boot environment with the boot
environment that was last active. “Synchronize” means that certain
critical system files and directories are copied from the last-active boot
environment to the boot environment being booted. Solaris Live Upgrade does
not perform this synchronization after the initial boot, unless you force
synchronization with the luactivate command and the -s option.

x86 only –

When you switch between boot environments with the
GRUB menu, files also are not synchronized. You must use the following procedure
to synchronize files.

Forces a synchronization of files between the last-active
boot environment and the new boot environment. The first time that a boot
environment is activated, the files between the boot environment are synchronized
With subsequent activations, the files are not synchronized unless you use
the -s option.

Caution –

Use this option with great care, because you might not be
aware of or in control of changes that might have occurred in the last-active
boot environment. For example, if you were running Solaris 10 10/09 software
on your current boot environment and booted back to a Solaris 9 release with
a forced synchronization, files could be changed on the Solaris 9 release.
Because files are dependent on the release of the OS, the boot to the Solaris
9 release could fail because the Solaris 10 10/09 files might not
be compatible with the Solaris 9 files.

BE_name

Specifies the name of the boot environment that is to be activated.

Reboot.

# init 6

Example 5–15 Activating a Boot Environment

In this example, the second_disk boot environment
is activated at the next reboot and the files are synchronized.

# /sbin/luactivate -s second_disk
# init 6

x86: Activating a Boot Environment With the
GRUB Menu

A GRUB menu provides an optional method of switching between boot environments.
The GRUB menu is an alternative to activating (booting) with the luactivate command. The table below notes cautions and limitations when using
the GRUB menu.

Table 5–3 x86: Activating
With the GRUB Menu Summary

Task

Description

For More Information

Caution

After you have activated a boot environment, do not change the disk
order in the BIOS. Changing the order might cause the GRUB menu to become
invalid. If this problem occurs, changing the disk order back to the original
state fixes the GRUB menu.

Activating a boot environment for the first time

The first time you activate a boot environment, you must use the luactivate command. The next time you boot, that boot environment's name is
displayed in the GRUB main menu. You can thereafter switch to this boot environment
by selecting the appropriate entry in the GRUB menu.

The first time you activate a boot environment, files are synchronized
between the current boot environment and the new boot environment. With subsequent
activations, files are not synchronized. When you switch between boot environments
with the GRUB menu, files also are not synchronized. You can force a synchronization
when using the luactivate command with the -s option.

If a boot environment was created with the Solaris
8, 9, or 10 3/05 release, the boot environment must always be activated
with the luactivate command. These older boot environments
do not display on the GRUB menu.

Do not use the GRUB menu.lst file to modify
Solaris Live Upgrade entries. Modifications could cause Solaris Live Upgrade
to fail. Although you can use the menu.lst file to customize
booting behavior, the preferred method for customization is to use the eeprom command. If you use the menu.lst file to customize,
the Solaris OS entries might be modified during a software upgrade. Changes
to the file could be lost.

x86: To Activate a Boot Environment With the
GRUB Menu

You can switch between two boot environments with the GRUB menu. Note
the following limitations:

The first activation of a boot environment must be done with
the luactivate command. After the initial activation, the
boot environment is displayed on the GRUB menu. The boot environment can then
be booted from the GRUB menu.

If a boot environment was created with the Solaris 8, 9, or 10 3/05 release, the boot environment
must always be activated with the luactivate command. These
older boot environments are not displayed on the GRUB menu.

The GRUB main menu is displayed. The two operating systems are listed,
Solaris and second_disk, which is a Solaris Live Upgrade
boot environment. The failsafe entries are for recovery,
if for some reason the primary OS does not boot.