4    Encapsulating and Mirroring the Boot Disk

This chapter describes how to encapsulate and create mirrored volumes for all the partitions on the boot disk including the root file system, swap, usr, and var partitions.

Encapsulating and creating mirrored volumes for the partitions on the boot disk provides complete redundancy and recovery capability in the event of a boot disk failure. For example, if the system experiences failure of the primary boot disk, you can boot the system using the mirrored volumes.

4.1    Boot Disk Encapsulating and Mirroring Overview

Encapsulating the boot disk creates the necessary scripts that convert all the partitions on the boot disk to LSM volumes.

Mirroring the boot disk automatically creates mirrored volumes for:

• The root file system. This partition is called the root volume or rootvol. During startup, the system sees the rootvol volume as a regular partition, and accesses it using standard partition naming.

• The primary swap partition if it is on the boot disk. This partition is called the swap volume or swapvol. Other volumes that you use for swap (secondary swap volumes) are treated as ordinary LSM volumes.

• The usr partition if it is on the boot disk. This partition is called the usr volume or usrvol.

• The var partition if it is on the boot disk. This partition is called the var volume or varvol.

4.1.1    Root and Swap Usage Types

A volume that contains a file system has a usage type of fsgen. A volume that does not contain a file system has a usage type of gen. Because the root file system and swap partitions need special handling during system startup, LSM automatically sets up and uses the following special usage:

• root

  This type is intended for volumes used as root devices. Because the root volume contains a file system, the root usage type resembles the fsgen usage type. The root usage type restricts the configuration of the volume such that all plexes of the volume are accessible as a root device through normal disk drivers.

• swap

  This type is intended for volumes used as the primary swap device. Unlike the root device, a swap device does not contain a file system; therefore, it resembles the gen usage type.

4.1.2    Boot Disk Encapsulation and Mirror Restrictions

LSM setups and configures the boot disk for use with the LSM software . Because the boot disk needs to be handled specially, you should be aware of the following restrictions:

• The root volume, swap volume, usr volume, var volume, and volumes created for any secondary swap volumes must be in the rootdg disk group.

• The rootvol volume cannot be striped.

• The rootvol and swapvol volumes must not span or contain a plex with multiple noncontiguous subdisks.

• The rootvol and swapvol volumes cannot be RAID5 volumes.

• Do not configure the swapvol volume with logging. There is no need for logging and resynchronization of mirrored swap volumes because swap data is not reused across system reboots.

• The names rootvol and swapvol are automatically assigned to the root volume and swap volume. Do not change these names.

  If rootvol and swapvol exist, then the encapsulation procedure creates a rootvol and swapvol with a -02 suffix. You cannot use the suffix to differentiate between booted and mirrored plexes because LSM assigns plex suffixes in ascending order beginning with -01 and reuses available numbers. Therefore, note the name of the plex from which the system boots in the event that you need to disassociate the plex.

• The root and swap volumes have the following specific minor device numbers, which should not be changed:

  • rootvol is minor device 0

  • swapvol is minor device 1

LSM will configure the boot disk for mirroring; however, be aware that the rootvol and swapvol volumes differ from other volumes in that they have the following LSM volume restrictions:

• You must have two unused partitions, which cannot be the a or c partitions.

• You must encapsulate the root file system and primary swap partitions at the same time.

4.2    Encapsulating the Boot Disk

To encapsulate the boot disk, you can:

• Select the option to encapsulate the boot disk directly into an LSM volume during the full installation process. See the Installation Guide for more information.

• Manually encapsulate the boot disk into LSM. See Section 4.2.1 for more information.

As part of the encapsulation process the system must be rebooted, and the following files are changed:

• The /etc/fstab (UFS root file system) is changed to use LSM volumes instead of disk partitions.

• The /etc/sysconfigtab is changed to update the swapdevice entry.

• If you are using AdvFS, the /etc/fdmns/* directory is updated to change domain directories that have disk partitions associated with the root disk.

4.2.1    Manually Encapsulating the Boot Disk

You can manually encapsulate the boot disk if you did not encapsulate it during the full installation. The steps to encapsulate the boot disk are the same whether you are using the UFS or the AdvFS. You should encapsulate the entire boot disk.

Follow these steps to encapsulate the entire boot disk:

1. Enter the disklabel command to verify that there is at least one free partition on the boot disk. The LSM encapsulation process requires one free partition-table entry to store LSM disk label tags. Note that the encapsulation procedure requires only the partition-table entry; it does not need the disk space associated with the partition. LSM uses space from the swap partition to create an LSM private region for the boot disk. After the encapsulation process completes, the swap partition is smaller by the size of the private region (by default 4096 sectors).

2. Enter the volencap command to create the LSM command scripts that convert all the partitions on the boot disk (including the root file system, swap, usr and var partitions) to LSM volumes. Specify the boot device with the volencap command instead of individual partitions so that the entire boot disk is encapsulated. For example:

   # volencap dsk1

   Output similar to the following is displayed:

   Setting up encapsulation for dsk1.
    
       - Creating simple disk dsk1h for config area (privlen=4096)
         Warning: space taken from -> dsk1b dsk1h
       - Creating nopriv disk dsk1a for rootvol
       - Creating nopriv disk dsk1b for swapvol
       - Creating nopriv disk dsk1g
    
   The following disks are queued up for encapsulation or use by LSM: 
   dsk1h dsk1a dsk1b dsk1g
    
   You must now run /sbin/volreconfig to perform actual encapsulations.
   

3. Enter the volreconfig command to encapsulate the boot disk, which also shuts down the system. For example:

   # volreconfig

   Output similar to the following is displayed:

   The system will need to be rebooted in order to continue with
   LSM volume encapsulation of:
    dsk1h dsk1a dsk1b dsk1g
    
   Would you like to either quit and defer encapsulation until later 
   or commence system shutdown now? Enter either 'quit' or time to be 
   used with the shutdown(8) command (e.g., quit, now, 1, 5): [quit]
   

4. Boot the system.

4.2.2    Mirroring the Boot Disk

After you encapsulate the boot disk, you can mirror it. Mirroring, which is typically used to mirror user data, cannot access some of the data that is required for a system to boot, such as the boot track. Boot disk mirroring is restricted such that the plexes on the mirrored disk must be accessible as root and swap partitions.

Mirror the entire original boot disk onto another disk. Having one contiguous mirror that contains the volumes for boot disk partitions makes it easier to convert from volumes back to partitions. Choose a target disk for the mirror that:

• Is as large as the total amount of space in use on the boot disk.

• Is uninitialized (not under LSM control) .

• Has a disk label with all the partitions marked unused. Enter the disklabel command to display, and if necessary, reinitialize the disk label. See the disklabel(8) reference page for more information on the disklabel command.

If you are mirroring only the root file system and swap partitions, the target mirror disk must be at least as large as the sum of the sizes of the root file system and swap partitions on the original boot disk, plus the length of the private region.

You can use a disk that is the same as the original. For example you can use an RZ1BB to mirror another RZ1BB, or you can use a disk with a physical geometry different from the original disk. For example, an RZ1CD can mirror an RZ1BB, because the RZ1CD is larger than the RZ1BB.

Enter the volrootmir -a command to create mirrored volumes for all the partitions on the boot disk, including the root file system, swap, usr and var partitions. For example, to create mirrored volumes for all the partitions on the boot disk onto a disk called dsk2, enter:

# volrootmir -a dsk2

4.3    Unencapsulating the Boot Disk

You can unencapsulate the boot disk to revert volumes on the boot disk (rootvol, swapvol, usrvol, and varvol) back to partitions.

Unencapsulating the boot disk requires that you reboot the system using the disk that was last used for the rootvol and swapvol volumes (which might require that you first change the default boot device on the system console) and changes the following files:

• The /etc/fstab (UFS root filesystem) is changed to use disk partitions instead of LSM volumes.

• The /etc/sysconfigtab is changed to update the swapdevice entry.

• If you are using AdvFS, the /etc/fdmns/* directory is updated to change domain directories that have disk partitions associated with the root disk.

Note

To unencapsulate the rootvol and swapvol volumes, you must be sure that they have only one plex, and therefore are not mirrored.

Follow these steps to unencapsulate the boot disk volumes:

1. Remove the secondary plexes for volumes related to the boot disk. For example, to remove the secondary plexes for the rootvol, swapvol, usrvol and varvol volumes, enter:

   # volplex -o rm dis rootvol-02 
   # volplex -o rm dis swapvol-02 
   # volplex -o rm dis usrvol-02 
   # volplex -o rm dis varvol-02
   

2. Revert all the LSM volumes back to partitions on the boot disk by entering the following command:

   # volunroot -a

3. Reboot the system using the disk that was last used for the rootvol volume.

4.4    Solving Boot Disk Encapsulation Problems

There are two recovery procedures if problems occur during the boot disk encapsulation process:

• If problems arise during the encapsulation procedure, you might need to manually reset the changes that were made by the encapsulation procedure.

• If booting to multiuser mode is impossible after boot disk encapsulation has succeeded, you can allow booting from the physical disk partition.

4.4.1    Resetting Changes Made During the Encapsulation Procedure

If problems occur during the encapsulation procedure, the encapsulation procedure tries to back out all changes made, and restore the use of partitions for the root file system. Under some circumstances, you might need to manually reset the changes made as a result of encapsulating the boot disk.

Follow these steps to manually reset the changes made during the encapsulation procedure:

1. Halt the machine.

2. At the console prompt, boot the machine in interactive mode. For example:

   >>> boot -fl i

3. When prompted for the kernel file name, enter:

   /vmunix lsm_rootdev_is_volume=2

4. When the system enters single-user mode, mount the root file system partition. For example:

   # mount -u /

5. If the root file system is:

   • UFS, edit the /etc/fstab file as follows:

     • Change the device-special file from /dev/vol/rootdg/rootvol to the a partition of the boot disk.

     • Change the /dev/vol/rootdg/usrvol to the g partition of the boot disk.

     • If the var file system is on a separate partition, change the fstab from /dev/vol/rootdg/varvol to the h partition of the boot disk.

   • AdvFS, enter:

     # cd /etc/fdmns/root_domain  
     # rm rootvol
     # ln -s /dev/dskxa dskxa
     

     For the usr file system, enter:

     # cd /etc/fdmns/usr_domain  
     # rm usrvol 
     # ln -s /dev/dskxg dskxg
     

     If the var file system is separate from usr file system, enter:

     # cd /etc/fdmns/var_domain 
     # rm varvol 
     # ln -s /dev/dskxh dskxh
     

6. Edit the /etc/sysconfigtab file and change the LSM entry from:

   lsm_rootdev_is_volume = 1

   to:

   lsm_rootdev_is_volume = 0

7. Configure the swap partition to no longer use the LSM volumes by updating the vm:swapdevice entry in the sysconfigtab file to not reference the LSM volumes.

   See the System Administration and the swapon(8) reference page for more information.

8. Remove files related to the conversion. For example:

   # rm -rf /etc/vol/reconfig.d/disk.d/*

9. Update the disk label to remove the LSMnopriv fstypes that were set up by the volencap command for the swap, usr, and var partitions. For example:

   If the swap partition is on the b partition, enter:

   # disklabel -sF dskxb swap

   If the usr file system is on the g partition, enter:

   # disklabel -sF dskxg (AdvFS/ufs)

   If the var file system is on the h partition, enter:

   # disklabel -sF dskxh (AdvFS/ufs)

10. Reboot the system on the same boot disk. The system reboots using disk partitions.

4.4.2    Booting From a Disk Partition

If you problems occur while booting to multiuser mode, follow these steps to boot from the physical disk partition:

1. Use the instructions for unencapsulating the boot disk in Section 4.3.

2. After the system reboots, enter the volmend command to set the good plex in the rootvol volume to ACTIVE.

3. Undo the changes that the encapsulation procedure made as described in Section 4.4.1.

4. Reboot the system.