Using AP Boot Devices

5

Placing the Boot Disk Under AP Control

To allow for unattended system boot, even if the adapter for the boot disk fails, you can place your Sun server boot disk under AP control.

· To Place a Boot Disk under AP Control

Create an AP pathgroup for the boot disk.
This process is described in Chapter 4, "Using Meta-Disks and Disk Pathgroups".
Run apboot(1M) to define the new AP boot device. apboot modifies /etc/vfstab and /etc/system. Here is an example:


  # apboot mc2t0d0

where mc2t0d0 is the meta-disk name of the boot disk. apboot examines /etc/vfstab and replaces the physical device name of the disk (e.g., /dev/dsk/c2t0d0* or /dev/dsk/c1t0d0*) with the meta-disk name (e.g., /dev/dsk/mc2t0d0*). It also edits /etc/system so that the kernel drivers required for AP boot disk usage are loaded at the proper time.

Do not manually replace the physical devices in /etc/vfstab with meta-disks for the boot disk. Instead, use apboot to ensure that all required changes are made.

Set the Open Boot Prom (OBP) devalias variable boot-device to the physical path most likely to be used for booting.
For more information about OBP, refer to the "SSP Internals" chapter of the Ultra Enterprise 10000 SSP User's Guide.
Define a devalias for the alternate boot device path as a convenience in case you need to perform a manual boot.

At this point, reboot the system to begin using the AP boot device.

Note - If you wish to create a new AP database copy after you have placed the boot disk under AP control, and that database copy is to be located on a partition controlled by a pln port that does not control any of the current AP database partitions, you must first remove the boot disk from AP control. Make sure that the new AP database has been created. Then, place the boot disk under AP control again. Failure to follow this procedure may cause the database to become inaccessible during boot.

· To Remove the Boot Disk from AP Control

* Use apboot(1M) to specify an appropriate physical device node; for example:


  # apboot c2t0d0

In the above command, c2t0d0 is the physical device node of an alternate path for the boot disk (as currently specified in /etc/vfstab). apboot also edits the /etc/system file to remove force loading of AP kernel driver modules, since they are no longer needed when the boot disk is not an AP device.

Note - Normally, the file systems that are mounted as part of the boot process are split across two separate disks (because of disk space requirements). If you place the boot disk under AP control (via apboot(1M)), you must manually edit the /etc/vfstab file to also place other file systems that are mounted during the boot process under AP control. In the /etc/vfstab file, you must change the device to mount and device to fsck paths for all other mount points that you wish to place under AP control.

Warning - If you place the boot disk under AP control, and later decide to remove the AP package (via pkgrm(1M)), you must first use apboot(1M) to remove the boot disk from AP control. If you do not first remove the boot disk from AP control, the system on that disk becomes unbootable.

AP Boot Sequence

This subsection briefly describes the flow of events that occur when your Sun server is booted on an alternately pathed boot disk. The boot sequence proceeds as follows:

By default, the system is booted from the device specified by the OBP devalias boot-device. Note that this device may be different from the last active alternate for the boot disk.
OBP stores the path to the boot disk on the SSP.
If a failure occurs, it is detected after about one minute. Then, the AP Reboot Host program is executed.

Note - One or two minutes may pass before action is taken, so do not immediately enter new commands if you notice that the boot process has failed. If you attempt a manual recovery from a boot failure, be aware that the automatic reboot recovery process will still be executing and may override your manual recovery command.

AP Reboot Host retrieves the path stored earlier by OBP, and communicates the path to the AP SSP Daemon.
The AP SSP Daemon looks up the alternate path for the boot disk in the AP SSP database, and retries the boot process with the other alternate path.
After the reboot succeeds, AP determines the alternate from which the system was booted, and makes it the active alternate.

Using Single User Mode

Normally, when your Sun server is fully booted, you use the AP command versions located in /usr/sbin. However, if your Sun server comes up in single user mode because the boot process did not fully complete, you can use the commands in /sbin. The command versions under /sbin do not rely on the AP Daemon services (which are not available in single-user mode). If the system enters single-user mode because of a problem related to AP, you may be able to resolve the problem by using the /sbin commands to perform needed AP operations.

Two AP-related problems may cause the system to come up single user:

If two paths are supposed to lead to the same disk (according to the AP SSP database) but those paths actually lead to different disks, and if that disk needs to be mounted during the boot process. (This can only happen if you change the physical configuration of the pathgroup without running AP commands to update the database.)
If an active alternate for a disk turns out to be inaccessible and that disk is required during the boot process. A disk is required during the boot process if it has file systems that are mounted during the boot process (i.e., it has entries in the /etc/vsftab file).

These situations arise only with respect to disks, not networks. In either case, you may be able to use the AP commands under /sbin to resolve the problem.