Chapter 31 Solaris Live Upgrade (Planning)

This chapter provides guidelines and requirements for review before installing and using Solaris Live Upgrade. You also should review general information on upgrading in Checklist for Upgrading. This chapter contains the following sections:

• Solaris Live Upgrade Requirements

• Managing Packages and Patches With Solaris Live Upgrade

• Guidelines for Creating File Systems With the lucreate Command

• Guidelines for Selecting Slices for File Systems

• Customizing a New Boot Environment's Content

• Synchronizing Files Between Boot Environments

• Using Solaris Live Upgrade From a Remote System

Solaris Live Upgrade Requirements

Solaris Live Upgrade System Requirements

Solaris Live Upgrade is included in the Solaris 9 software. If you want to upgrade by using Solaris Live Upgrade, you need to install the Solaris Live Upgrade packages on your current operating environment. You can upgrade a boot environment to a release of the Solaris Operating Environment that is the same as the release of the Solaris Live Upgrade packages installed on your machine. For example, if on your current Solaris 8 operating environment, you installed Solaris 9 Live Upgrade packages, you could upgrade a boot environment to the Solaris 9 marketing or update release.

Table 31–1 lists releases that are supported by Solaris Live Upgrade.

You cannot upgrade to the Solaris 7 operating environment.

You can install the Solaris Live Upgrade packages from the following:

• An installer on the Solaris DVD, the Solaris Software 2 of 2 CD, or a net installation image.

• The pkgadd command. If you are using the pkgadd command, the packages are SUNWlur and SUNWluu, and these packages must be installed in that order.

For instructions on installing the Solaris Live Upgrade software, see To Install Solaris Live Upgrade.

Solaris Live Upgrade Disk Space Requirements

Follow general disk space requirements for an upgrade. See Chapter 5, System Requirements and Guidelines (Planning).

To estimate the file system size that is needed to create a boot environment, start the creation of a new boot environment. The size is calculated. You can then abort the process.

The disk on the new boot environment must be able to serve as a boot device. Some systems restrict which disks can serve as a boot device. Refer to your system's documentation to determine if any boot restrictions apply.

The disk might need to be prepared before you create the new boot environment. Check to make sure the disk is formatted properly:

• Identify slices large enough to hold the file systems to be copied.

• Identify file systems that contain directories that you want to share between boot environments rather than copy. If you want a directory to be shared, you need to create a new boot environment with the directory put on its own slice. The directory is then a file system and can be shared with future boot environments. For more information on creating separate file systems for sharing, see Guidelines for Selecting Slices for Shareable File Systems.

Solaris Live Upgrade Requirements If Creating RAID-1 Volumes (Mirrors)

Solaris Live Upgrade uses Solaris Volume Manager technology to create a boot environment that can contain file systems that are RAID-1 volumes (mirrors). To use the mirroring capabilities of Solaris Live Upgrade, you must create at least one state database and at least three state database replicas. A state database stores information on disk about the state of your Solaris Volume Manager configuration. The state database is a collection of multiple, replicated database copies. Each copy is referred to as a state database replica. When a state database is copied, the replica protects against data loss from single points of failure. For procedures about creating a state database, see “State Database (Overview)” in Solaris Volume Manager Administration Guide.

Solaris Live Upgrade does not implement the full functionality of Solaris Volume Manager. Solaris Live Upgrade supports only a RAID-1 volume (mirror) with single-slice concatenations on the root (/) file system. A mirror can be comprised of a maximum of three concatenations. For guidelines on creating mirrored file systems, see Guidelines for Selecting Slices for Mirrored File Systems.

Managing Packages and Patches With Solaris Live Upgrade

The following sections list packages required by Solaris Live Upgrade and provide information on recommended patches. See Upgrading a System With Packages and Patches for information on using Solaris Live Upgrade to add packages and patches.

When upgrading and 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 during an upgrade to fail or alter the active boot environment.

For more information on adding and removing packages with Solaris Live Upgrade, see the man page, luupgrade(1M). For more information on packaging requirements, see Appendix G, Additional SVR4 Packaging Requirements (Reference).

Required Packages

Check your current operating environment for the packages in the following table, which are required to use Solaris Live Upgrade. If packages in the column for your release are missing, use the pkgadd command to add the packages.

To check for packages on your system, type the following command.

% pkginfo [[package_name]]

Upgrading a System With Packages and Patches

You can use Solaris Live Upgrade to add patches and packages to a system. By using Solaris Live Upgrade to add patches to a machine, the only downtime the system incurs is that of a reboot. You can add patches and packages to a boot environment with the luupgrade command or with a Solaris Flash archive.

• To add patches to a boot environment directly, create a new boot environment and use the luupgrade command with the -t option. To add packages to a boot environment, use the luupgrade command with the -p option. For more information, see the man page, luupgrade(1M).

• Or, you can use Solaris Live Upgrade to install a Solaris Flash archive. An archive contains a complete copy of a boot environment with new packages and patches already included. This complete boot environment or single reference system is called a master system. The process of creating a Solaris Flash archive begins with creating a master system. After you have created a master system, add any patches and packages that you want to install. Then, create a Solaris Flash archive of the master system. Use Solaris Live Upgrade to install the archive on the new boot environment. You can copy the boot environment and change and distribute the boot environment as many times as necessary. For details about how to create a Solaris Flash archive, see Chapter 18, Creating Solaris Flash Archives (Tasks). For information on using Solaris Live Upgrade to install a Solaris Flash archive, see Installing Solaris Flash Archives on a Boot Environment.

When upgrading and 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.

For more information on adding and removing packages with Solaris Live Upgrade, see the man page, luupgrade(1M). For more information on packaging requirements, see Appendix G, Additional SVR4 Packaging Requirements (Reference).

Checking System Patch Levels

Solaris Live Upgrade software is designed to be installed and to be run on multiple versions of the Solaris operating environment. Correct operation of Solaris Live Upgrade requires the latest recommended patches and security patches for a given OS version. Consult http://sunsolve.sun.com for the correct revision level for a patch cluster for the release of Solaris that you are running.

Guidelines for Creating File Systems With the lucreate Command

The lucreate -m option specifies which file systems and the number of file systems to be created in the new boot environment You must specify the exact number of file systems you want to create by repeating this option. For example, a single use of the -m option specifies where to put all the file systems. You merge all the file systems from the original boot environment into the one file system specified by the -m option. If you specify the -m option twice, you create two file systems. When using the -m option to create file systems, follow these guidelines:

• You must specify one -m option for the root (/) file system for the new boot environment. If you run lucreate without the -m option, the Configuration menu is displayed. The Configuration menu enables you to customize the new boot environment by redirecting files onto new mount points.

• Any critical file systems that exist in the current boot environment and that are not specified in a -m option are merged into the next highest-level file system created.

• Only the file systems that are specified by the -m option are created on the new boot environment. If your current boot environment contains multiple file systems, and you want to have the same number of file systems in the new boot environment created, you must specify one -m option for each file system to be created. For example, if you have file systems for root (/), /opt, and /var, you would use one -m option for each file system on the new boot environment.

• Do not duplicate a mount point. For example, you cannot have two root (/) file systems.

Guidelines for Selecting Slices for File Systems

When you create file systems for a boot environment, the rules are identical to the rules for creating file systems for the Solaris operating environment. Solaris Live Upgrade cannot prevent you from creating invalid configurations for critical file systems. For example, you could type a lucreate command that would create separate file systems for root (/) and /kernel—an invalid division of root (/).

Do not overlap slices when re-slicing disks. If this condition exists, the new boot environment appears to have been created, but when activated, the boot environment does not boot. The overlapping file systems might be corrupted.

For Solaris Live Upgrade to work properly, the vfstab file on the active boot environment must have valid contents and must have an entry for root (/) at the minimum.

Guidelines for Selecting a Slice for the root (/) File System

When you create an inactive boot environment, you need to identify a slice where the root (/) file system is to be copied. Use the following guidelines when you select a slice for the root (/) file system. The slice must comply with the following:

• Must be a slice from which the system can boot.

• Must meet the recommended minimum size.

• If you have a sun4m system, the root (/) file system cannot be greater than 2 Gbytes.

• Can be on different physical disks or the same disk as the active root (/) file system.

• Can be a Veritas Volume Manager volume, but these volumes are not supported.

Guidelines for Selecting Slices for Mirrored File Systems

You can create a new boot environment that contains any combination of physical disk slices, Solaris Volume Manager volumes, or Veritas Volume Manager volumes. Critical file systems that are copied to the new boot environment can be of the following types:

• A physical slice.

• A single-slice concatenation that is included in a RAID–1 volume (mirror). The slice that contains the root (/) file system can be a RAID–1 volume.

• A single-slice concatenation that is included in a RAID–0 volume. The slice that contains the root (/) file system can be a RAID–0 volume.

When you create a new boot environment, the lucreate -m command recognizes the following three types of devices:

• A physical slice in the form of /dev/dsk/cwtxdysz

• A Solaris Volume Manager volume in the form of /dev/md/dsk/dnum

• A Veritas Volume Manager volume in the form of /dev/vx/dsk/volume_name

If you have problems upgrading with Veritas VxVM, see System Panics When Upgrading With Solaris Live Upgrade Running Veritas VxVm.

General Guidelines for Creating Mirrored File Systems

Specifying a Volume

You can choose to specify a mirror or submirror or allow the lucreate command to choose a free volume for you.

• To specify a volume, append a comma and the name of the submirror or mirror to the device name. In the following option, the submirror d1 is specified.

  -m /:/dev/dsk/c0t0d0s0,d1:attach

• To enable the software to choose a free volume, do not name the submirror or mirror. In this option, the submirror is not specified, and the software chooses a free volume.

  -m /:/dev/dsk/c0t0d0s0:attach

Volume Naming Shortcuts

You can abbreviate the names of physical disk slices and Solaris Volume Manager volumes. The abbreviation is the shortest name that uniquely identifies a device. Examples follow.

• A Solaris Volume Manager volume can be identified by its dnum designation, so that, for example, /dev/md/dsk/d10 becomes simply d10.

• If a system has a single controller and multiple disks, you might use t0d0s0, but with multiple controllers use c0t0d0s0.

For more information on naming requirements and guidelines, see “Overview of Solaris Volume Manager Components” in Solaris Volume Manager Administration Guide.

Checking Status of Volumes

If a mirror or submirror needs maintenance or is busy, components cannot be detached. You should use the metastat command before creating a new boot environment and using the detach keyword. The metastat command checks if the mirror is in the process of resynchronization or if the mirror is in use. For information, see the man page metastat(1M).

Detaching Volumes and Resynchronizing Mirrors

If you use the detach keyword to detach a submirror, lucreate checks if a device is currently resyncing. If the device is resyncing, you cannot detach the submirror and you get an error message.

Resynchronization is the process of copying data from one submirror to another submirror after the following problems:

• Submirror failures.

• System crashes.

• A submirror has been taken offline and brought back online.

• The addition of a new submirror.

For more information about resynchronization, see “RAID 1 Volume (Mirror) Resynchronization” in Solaris Volume Manager Administration Guide.

Using Solaris Volume Manager Commands

Use the lucreate command rather than Solaris Volume Manager commands to manipulate volumes on inactive boot environments. The Solaris Volume Manager software has no knowledge of boot environments, whereas the lucreate command contains checks that prevent you from inadvertently destroying a boot environment. For example, lucreate prevents you from overwriting or deleting a Solaris Volume Manager volume.

However, if you have already used Solaris Volume Manager software to create complex Solaris Volume Manager concatenations, stripes, and mirrors, you must use Solaris Volume Manager software to manipulate them. Solaris Live Upgrade is aware of these components and supports their use. Before using Solaris Volume Manager commands that can create, modify, or destroy volume components, use the lustatus or lufslist commands. These commands can determine which Solaris Volume Manager volumes contain file systems that are in use by a Solaris Live Upgrade boot environment.

Guidelines for Selecting a Slice for a Swap File System

Configuring Swap for the New Boot Environment

You can configure a swap slice in three ways using the lucreate command with the -m option:

• If you do not specify a swap slice, the swap slices belonging to the current boot environment are configured for the new boot environment.

• If you specify one or more swap slices, these slices are the only swap slices that are used by the new boot environment. The two boot environments do not share any swap slices.

• You can specify to both share a swap slice and add a new slice for swap.

The following examples show the three ways of configuring swap. The current boot environment is configured with the root (/) file system on c0t0d0s0. The swap file system is on c0t0d0s1.

• In the following example, no swap slice is specified. The new boot environment contains the root (/) file system on c0t1d0s0. Swap is shared between the current and new boot environment on c0t0d0s1.

  # lucreate -n be2 -m /:c0t1d0s0:ufs

• In the following example, a swap slice is specified. The new boot environment contains the root (/) file system on c0t1d0s0. A new swap file system is created on c0t1d0s1. No swap slice is shared between the current and new boot environment.

  # lucreate -n be2 -m /:c0t1d0s0:ufs -m -:c0t1d0s1:swap

• In the following example, a swap slice is added and another swap slice is shared between the two boot environments. The new boot environment contains the root (/) file system on c0t1d0s0. A new swap slice is created on c0t1d0s1. The swap slice on c0t0d0s1 is shared between the current and new boot environment.

  # lucreate -n be2 -m /:c0t1d0s0:ufs -m -:shared:swap -m -:c0t1d0s1:swap

Failed Boot Environment Creation If Swap Is In Use

A boot environment creation fails if the swap slice is being used by any boot environment except for the current boot environment. If the boot environment was created using the -s option, the alternate-source boot environment can be using the swap slice, but not any other boot environment.

Guidelines for Selecting Slices for Shareable File Systems

Solaris Live Upgrade copies the entire contents of a slice to the designated new boot environment slice. You might want some large file systems on that slice to be shared between boot environments rather than copied to conserve space and copying time. File systems that are critical to the operating environment such as root (/) and /var must be copied. File systems such as /home are not critical file systems and could be shared between boot environments. Shareable file systems must be user-defined file systems and on separate swap slices on both the active and new boot environments. You can reconfigure the disk several ways, depending your needs.

• You can reslice the disk before creating the new boot environment and put the shareable file system on its own slice. For example, if root (/), /var, and /home are on the same slice, reconfigure the disk and put /home on its own slice. When you create any new boot environments, /home is shared with the new boot environment by default.

• If you want to share a directory, the directory must be split off to its own slice. The directory is then a file system that can be shared with another boot environment. You can use the lucreate command with the -m option to create a new boot environment and split a directory off to its own slice. But, the new file system cannot yet be shared with the original boot environment. You need to run the lucreate command with the -m option again to create another boot environment. The two new boot environments can then share the directory.

  For example, if you wanted to upgrade from the Solaris 8 release to the Solaris 9 release and share /home, you could run the lucreate command with the -m option. You could create a Solaris 8 release with /home as a separate file system on its own slice. Then run the lucreate command with the -m option again to duplicate that boot environment. This third boot environment can then be upgraded to the Solaris 9 release. /home is shared between the Solaris 8 and Solaris 9 releases.

For a description of shareable and critical file systems, see File System Types.

Customizing a New Boot Environment's Content

When you create a new boot environment, some directories and files can be excluded from a copy to the new boot environment. If you have excluded a directory, you can also re-include specified subdirectories or files under the excluded directory. These subdirectories or files that have been restored are then copied to the new boot environment. For example, you could exclude from the copy all files and directories in /etc/mail, but include all files and directories in /etc/mail/staff. The following command copies the staff subdirectory to the new boot environment.

# lucreate -n second_disk -x /etc/mail -y /etc/mail/staff

Use the file-exclusion options with caution. Do not remove files or directories that are required by the system.

The following table lists the lucreate command options for removing and restoring directories and files.

For examples of customizing the directories and files when creating a boot environment, see To Create a Boot Environment and Customize the Content (Command-Line Interface).

Synchronizing Files Between Boot Environments

When you are ready to switch and make the new boot environment active, you quickly activate the new boot environment and reboot. Files are synchronized between boot environments the first time that you boot a newly created boot environment. “Synchronize” means that certain critical system files and directories might be copied from the last-active boot environment to the boot environment being booted. Those files and directories that have changed are copied.

Adding Files to the /etc/lu/synclist

Solaris Live Upgrade checks for critical files that have changed. If these files' content is not the same in both boot environments, they are copied from the active boot environment to the new boot environment. Synchronizing is meant for critical files such as /etc/passwd or /etc/group files that might have changed since the new boot environment was created.

The /etc/lu/synclist file contains a list of directories and files that are synchronized. In some instances, you might want to copy other files from the active boot environment to the new boot environment. You can add directories and files to /etc/lu/synclist if necessary.

Adding files not listed in the /etc/lu/synclist could cause a system to become unbootable. The synchronization process only copies files and creates directories. The process does not remove files and directories.

The following example of the /etc/lu/synclist file shows the standard directories and files that are synchronized for this system.

/var/mail                    OVERWRITE
/var/spool/mqueue            OVERWRITE
/var/spool/cron/crontabs     OVERWRITE
/var/dhcp                    OVERWRITE
/etc/passwd                  OVERWRITE
/etc/shadow                  OVERWRITE
/etc/opasswd                 OVERWRITE
/etc/oshadow                 OVERWRITE
/etc/group                   OVERWRITE
/etc/pwhist                  OVERWRITE
/etc/default/passwd          OVERWRITE
/etc/dfs                     OVERWRITE
/var/log/syslog              APPEND
/var/adm/messages            APPEND

Examples of directories and files that might be appropriate to add to the synclist file are the following:

/var/yp                    OVERWRITE
/etc/mail                  OVERWRITE
/etc/resolv.conf           OVERWRITE
/etc/domainname            OVERWRITE

The synclist file entries can be files or directories. The second field is the method of updating that occurs on the activation of the boot environment. There are three methods for updating the files:

• OVERWRITE — The contents of the active boot environment's file overwrites the contents of the new boot environment file. OVERWRITE is the default action if no action is specified in the second field. If the entry is a directory, all subdirectories are copied. All files are overwritten. The new boot environment file has the same date, mode, and ownership as the same file on the previous boot environment.

• APPEND — The contents of the active boot environment's file are added to the end of the new boot environment's file. This might lead to duplicate entries in the file. Directories cannot be listed as APPEND. The new boot environment file has the same date, mode, and ownership as the same file on the previous boot environment.

• PREPEND — The contents of the active boot environment's file are added to the beginning of the new boot environment's file. This might lead to duplicate entries in the file. Directories can not be listed as PREPEND. The new boot environment file has the same date, mode, and ownership as the same file on the previous boot environment.

Forcing a Synchronization Between Boot Environments

The first time you boot from a newly created boot environment, Solaris Live Upgrade synchronizes the new boot environment with the boot environment that was last active. After this initial boot and synchronization, Solaris Live Upgrade does not perform a synchronization unless requested.

• To force synchronization using the CUI, you type yes when prompted

• To force synchronization using the CLI, you use the luactivate command with the -s option

You might want to force a synchronization if you are maintaining multiple versions of the Solaris operating environment. You might want changes in files such as email or passwd/group to be in the boot environment you are activating to. If you force a synchronization, Solaris Live Upgrade checks for conflicts between files that are subject to synchronization. When the new boot environment is booted and a conflict is detected, a warning is issued and the files are not synchronized. Activation can be completed successfully, in spite of such a conflict. A conflict can occur if you make changes to the same file on both the new boot environment and the active boot environment. For example, you make changes to the /etc/passwd file on the original boot environment. Then you make other changes to /etc/passwd file on the new boot environment. The synchronization process cannot choose which file to copy for the synchronization.

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

Using Solaris Live Upgrade From a Remote System

When viewing the character interface remotely, such as over a tip line, you might need to set the TERM environment variable to VT220. Also, when using the Common Desktop Environment (CDE), set the value of the TERM variable to dtterm, rather than xterm.