Chapter 3 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 about upgrading in Upgrade Planning in Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade.

This chapter describes Solaris Live Upgrade for UFS file systems. For planning information for migrating a UFS file system to a ZFS root pool or creating and installing a ZFS root pool, see Chapter 12, Solaris Live Upgrade for ZFS (Planning).

This chapter contains the following sections:

• Solaris Live Upgrade Requirements

• Upgrading a System With Packages or Patches

• 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

Solaris Live Upgrade Requirements

Before you install and use Solaris Live Upgrade, become familiar with these requirements.

Solaris Live Upgrade System Requirements

Solaris Live Upgrade is included in the Solaris software. You need to install the Solaris Live Upgrade packages on your current OS. The release of the Solaris Live Upgrade packages must match the release of the OS you are upgrading to. For example, if your current OS is the Solaris 9 release and you want to upgrade to the Solaris 10 5/09 release, you need to install the Solaris Live Upgrade packages from the Solaris 10 5/09 release.

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

Installing Solaris Live Upgrade

You can install the Solaris Live Upgrade packages by using the following:

• The pkgadd command. The Solaris Live Upgrade packages are SUNWlucfg, SUNWlur, and SUNWluu, and these packages must be installed in that order.

• An installer on the Solaris Operating System DVD, the Solaris Software - 2 CD, or a network installation image.

Be aware that the following patches might need to be installed for the correct operation of Solaris Live Upgrade.

ERROR: Cannot find or is not executable: 
</sbin/biosdev>.
ERROR: One or more patches required 
by Live Upgrade has not been installed.

For instructions about installing the Solaris Live Upgrade software, see Installing Solaris Live Upgrade.

Required Packages

If you have problems with Solaris Live Upgrade, you might be missing packages. In the following table, check that your OS has the listed packages , which are required to use Solaris Live Upgrade.

For the Solaris 10 release:

• If you install one of the following software groups, these software groups contain all the required Solaris Live Upgrade packages.

  • Entire Solaris Software Group Plus OEM Support

  • Entire Solaris Software Group

  • Developer Solaris Software Group

  • End User Solaris Software Group

• If you install one of these Software Groups, then you might not have all the packages required to use Solaris Live Upgrade.

  • Core System Support Software Group

  • Reduced Network Support Software Group

For information about software groups, see Disk Space Recommendations for Software Groups in Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade.

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

% pkginfo package_name

Solaris Live Upgrade Disk Space Requirements

Follow general disk space requirements for an upgrade. See Chapter 4, System Requirements, Guidelines, and Upgrade (Planning), in Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade.

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 that 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 about 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). Solaris Live Upgrade does not implement the full functionality of Solaris Volume Manager, but does require the following components of Solaris Volume Manager.

Upgrading a System With Packages or Patches

You can use Solaris Live Upgrade to add patches and packages to a system. 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. When you use luupgrade command, you can also use a Solaris Flash archive to install patches or packages.

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 about packaging requirements, see Appendix B, Additional SVR4 Packaging Requirements (Reference).

Upgrading and Patching Limitations

For upgrading and patching limitations, see Upgrading and Patching Limitations in Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade.

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. 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. To create the same number of files systems that is on your current system, you must specify one -m option for each file system to be created.

  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 that is specified by the -m option. If you specify the -m option twice, you create two file systems. 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 OS. 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 which is an invalid division of the root (/) file system.

Do not overlap slices when reslicing 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 the root (/) file system 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.

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

• Can be a Veritas Volume Manager volume (VxVM). 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.

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 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.

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

General Guidelines When Creating RAID-1 Volumes (Mirrored) File Systems

Use the following guidelines to check if a RAID-1 volume is busy, resyncing, or if volumes contain file systems that are in use by a Solaris Live Upgrade boot environment.

For volume naming guidelines, see RAID Volume Name Requirements and Guidelines for Custom JumpStart and Solaris Live Upgrade in Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade.

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 see 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 Volume

These guidelines contain configuration recommendations and examples for a swap slice.

Configuring Swap for the New Boot Environment

You can configure a swap slice in three ways by 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 /:/dev/dsk/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 /:/dev/dsk/c0t1d0s0:ufs -m -:/dev/dsk/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 /:/dev/dsk/c0t1d0s0:ufs -m -:shared:swap \

  -m -:/dev/dsk/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 use 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 OS 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.

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 reinstate 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.

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. You can choose from three methods to update 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 addition 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 addition 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 a synchronization, 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 OS. 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, despite 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 of or in control of changes that might have occurred in the last-active boot environment. For example, if you were running Solaris 10 5/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 5/09 files might not be compatible with the Solaris 9 files.

Booting Multiple Boot Environments

If your system has more than one OS installed on the system, you can boot from these boot environments for both SPARC and x86 platforms. The boot environments available for booting include Solaris Live Upgrade inactive boot environments.

• Starting with the Solaris 10 10/08 release for a SPARC based system, you can boot a ZFS root file system in a ZFS pool. For ZFS root pools, you can list the available boot environments with the boot command with the -L option. You can then choose a boot environment and use the OBP boot command with the -Z option to boot that boot environment. The -Z option is an alternative for the luactivate command that is also used to boot a new boot environment for a ZFS root pool. The luactivate command is the preferred method of switching boot environments. For a UFS file system, you continue to use the OpenBoot^TM PROM OBP as the primary administrative interface, with boot options selected by using OBP commands.

• Starting with the Solaris 10 1/06 release for x86 based systems, a GRUB boot menu provides the interface for booting between different boot environments. Starting with the Solaris 10 10/08 release, this menu lists ZFS boot environments that are available for booting. If the default boot environment is a ZFS file system and the GRUB menu is displayed, you can let the default boot environment boot or choose another boot environment to boot. The GRUB menu is an alternative to using the luactivate command that is also used to boot a new boot environment for a ZFS root pool. The luactivate is the preferred method of switching boot environments.

On both SPARC and x86 based systems, each ZFS root pool has a dataset designated as the default root file system. If for SPARC, you type the boot command or for x86, you take the default from the GRUB menu, then this default root file system is booted.

If the GRUB menu has been explicitly modified to designate a default menu item other than the one set by Solaris Live Upgrade, then selecting that default menu entry might not result in the booting of the pool's default root file system.

For more information about booting and modifying the GRUB boot menu, see the following references.

Solaris Live Upgrade Character User Interface

Sun no longer recommends use of the lu command. The lu command displays a character user interface (CUI). The underlying command sequence for the CUI, typically the lucreate, luupgrade, and luactivate commands, is straightforward to use. Procedures for these commands are provided in the following chapters.