III.  Boot managers

III.1  Solaris boot manager

Primary boot

Solaris boot process consists of two conceptually distinct phases, primary boot and secondary boot. The primary boot is implemented in the BIOS ROM on the system board and in BIOS extensions in ROMs on peripheral boards. The code is x86 real-mode code. This part of the boot process is common for all PC-compatible systems.

A Solaris boot partition is a primary partition, and must be active in order to boot Solaris. It begins with one-cylinder boot slice, which contains the partition boot program pboot in the first sector, the standard Solaris disk label and the VTOC in the second and third sectors, and the bootblk program in the fourth and subsequent sectors (VTOC is discussed later).

When a system is booted from a hard disk drive, MBR of that disk is read into memory. If Solaris was the last operating system installed to this disk, its MBR contains mboot - master boot program. The program, though specific for Solaris, works as usual Master Boot Code, that is, it reads the first sector of the first active primary partition on the boot disk, and jumps to its first byte. If the active partition is Solaris boot partition, its VBS is read and pboot - partition boot program contained there is invoked. Then pboot in turn loads and runs bootblk program.

In case Solaris is boot from floppy or CD-ROM, the first physical sector of the media read by BIOS, is a VBS not MBR. The pboot program contained there is responsible for loading the image of the boot manager strap.com.

Note: From version 8 up, Solaris x86 installation CDs are boot-able.

Note: Some releases of Solaris 8 are affected by a bug which causes that Solaris Master Boot Code always loads Solaris VBS (PBR) from the first physical hard disk drive in the system. If Solaris is on second drive the error message "Bad PBR" is reported. See IV.4 Troubleshooting.

Boot manager

Programs bootblk and strap.com, loaded in result of primary boot, are very similar. Both contain Solaris boot manager code, which reads current disk partition information, and in case there is more than one primary partition, displays the table with all available partitions. It gives an opportunity to reboot another partition, in other words, another operating system. The default one is Solaris. The default timeout to make selection is 30 seconds. The difference between bootblk and strap.com is that, the first one is placed on UFS file systems and can not be configured, while the second is placed on FAT file systems (floppy disk or x86 Boot partition) and the timeout may be set in /solaris/strap.rc file.

Secondary boot

If Solaris partition is selected to boot off, the secondary boot - boot.bin - is loaded by the boot manager. The secondary boot is capable of reading and booting from a UFS file system on a hard disk or CD, or by way of LAN using NFS protocol. It switches the processor to 32-bit, paged, protected mode and performs some limited machine initialization. Then, it runs Device Configuration Assistant, which either, boots the system automatically, or let the user select boot device, depending on the state of auto-boot eeprom variable (see eeprom man page). After that, root file system specified in bootpath eeprom variable is mounted.

Secondary boot is programmable, which makes it very flexible. If the root file system is successfully mounted, boot.bin invokes a command interpreter, that interprets /etc/bootrc script. The /etc/bootrc script lets the user to specify additional options for booting kernel, e.g. -r to reconfigure devices automatically.

Device Configuration Assistant

Device Configuration Assistant, or shortly DCA, is used to add, remove and configure device drivers necessary to boot a machine up. Note that keyboard, display and mouse are configured with kdmconfig (see kdmconfig man page). DCA is run at the beginning of Solaris setup to determine what device drivers need to be load, and to select the device from which the installation software will be loaded. DCA is shipped with Solaris media kit on a floppy disk. Solaris 8 installation CD (Installation as well as Software 1 CD) is boot-able and contains DCA.

DCA is invoked by the secondary boot every time Solaris is boot up. In this situation DCA behavior is determined by the state of two eeprom variables: auto-boot and auto-boot-timeout. The first one, if true, causes DCA to boot Solaris kernel off the device and partition specified in bootpath variable, otherwise presents a list of all devices capable of doing that and waits for a user selection. The list usually contains all hard disk drives, CD-ROMs, and LAN adapters. The second variable auto-boot-timeout determines the amount of time DCA waits for pressing Esc (escape) key to enter into DCA utility.

By default auto-boot is set to true, and auto-boot-timeout to 5 seconds. With these settings DCA displays information that it waits for pressing Esc and delays boot process for 5 seconds. Both variables may be modified using either, DCA itself, or eeprom utility. To modify variables with DCA one needs to enter DCA utility pressing Esc key during Solaris boot time. First, DCA probes hardware, then presents the list of possible boot devices. New values may be assigned to variables under Boot Tasks option. If Solaris is already running, type as root:

eeprom auto-boot?=true

to set auto-boot to true, or

eeprom auto-boot-timeout=0

to make DCA not to wait for Esc key.

Restoring Solaris boot manager

Solaris Master Boot Code of the MBR might be overwritten during installation of other operating system or a third party boot manager after Solaris was installed. Solaris Master Boot Code is stored in the file /usr/lib/fs/ufs/mboot. It can be restored using Solaris fdisk utility (see fdisk man page) as follows:

fdisk -b /usr/lib/fs/ufs/mboot -n /dev/rdsk/c0d0p0

where /dev/rdsk/c0d0p0 stands for the raw device associated with the first (usually primary master) IDE/ATA hard disk drive on the system.

Sometimes it is necessary to recover VBS of a Solaris boot partition or Solaris boot manager program. installboot utility is capable of doing that (see installboot man page). To refresh VBS of Solaris partition located on the first IDE/ATA drive type as root:

installboot /usr/platform/i86pc/lib/fs/ufs/pboot \
/usr/platform/i86pc/lib/fs/ufs/bootblk /dev/rdsk/c0d0s2

Since installboot can not verify the partition specified as its argument, it may write Solaris boot manager into any partition. Therefore care must be taken not to destroy other partitions. The same operation may be also done with fmthard utility discussed later.

The following files contain critical executable code for boot process:

x86 Boot partition

x86 Boot partition was introduced in Solaris 8. Normally, it is a small primary partition, with FAT file system and DCA installed. It is necessary when Webstart installation is used in order to boot Solaris kernel from miniroot (temporary) file system. It provides also a user the way to load Solaris kernel from non-boot hard disk drive, select one of multiple Solaris installations, or boot Solaris across a network - all that DCA booted from floppy can do.

It is created by default during Solaris 8 installation. Practice shows, however, that x86 Boot partition is not necessary to run Solaris 8. DCA is still below /boot directory and can be run during boot time.

x86 Boot partition can be created with Solaris fdisk program. At this stage it is simply a reserved portion of a hard disk with partition ID set to 0xBE. To make it functional FAT file system must be constructed, and Solaris boot manager installed. If x86 Boot partition is created and set active, on c0d0 (the first IDE drive), then command:

mkfs -F pcfs -o b=BOOT,B=/boot/mdbootbp,s,i=/boot/strap.com /dev/rdsk/c0d0p0:boot

will do the job. To install DCA mount the partition and copy necessary files:

mount -F pcfs /dev/dsk/c0d0p0:boot /mnt
cp -r /boot/* /mnt
echo "/boot/ / p"> /mnt/solaris.map

/dev/dsk/c0d0p0:boot is always the right address for x86 Boot partition on c0d0 drive. solaris.map file is required when DCA is installed on a FAT file system to remap default UFS paths to FAT ones. It is present on DCA floppy disk, but redundant on UFS variant of DCA.

Reconfiguring boot device

Solaris requires details on physical connection of all devices to function properly. It saves these data during installation. When disk controller or cables are changed the data gets outdated. The following needs to be updated to boot Solaris:

The first and the last must be done manually while the rest can be fixed with devfsadm utility (Solaris 8 or later). This is how to achieve that:

Assume that the old boot path was:



The boot path represents a subdirectory in /devices, Particular parts of the boot path change depending on what has changed in physical connection. For instance, when the controller is moved from one slot to another on the same motherboard the IRQ may change only.

The first question that arises here is what is the current boot path? It can be found with DCA. When the boot device is selected, the suitable boot path is displayed. Yet better method is to mount the root slice and check the full path associated to the disk device node used (the one under /dev/dsk).

The step by step procedure would look as follows:

  1. Boot the system from the Solaris installation disk (in case of Solaris 8 use "Software 1 CD") to single user mode, that is, at the prompt to select between Interactive and Jump Start installation enter b -s. A shell will follow after this.
  2. Set terminal type to AT386 to avoid problems with vi editor. Type in:

    TERM=AT386; export TERM

  3. Mount root / file system:

    mount /dev/dsk/c0t0d0s0 /a

    The command is for the first disk on the first SCSI controller. It varies from system to system. Consult Disks, partitions and slices under Solaris for details.

  4. Determine the slice number of /usr file system:

    grep /usr /a/etc/vfstab

    You will see a line:

    /dev/dsk/c0t0d0s4   /dev/rdsk/c0t0d0s4    /usr   ufs   1   no   logging

    which means that the number of the /usr slice is 4.

  5. Mount /usr file system:

    mount /dev/dsk/c0t0d0s4 /a/usr

  6. Rebuild /a/devices and /a/dev:

    /usr/sbin/chroot /a /usr/sbin/devfsadm -C -v
    /usr/sbin/chroot /a /usr/sbin/devfsadm -v

    The first command cleans up invalid entries, the second creates new ones. -v stands for verbose mode. If you prefer to see first what is going to be changed without actually changing anything add -s option.
  7. Either, modify /a/etc/vfstab, or recreate soft links under /a/dev/dsk and /a/dev/rdsk, so that vfstab entries match appropriate slices on appropriate disks on the system. The second is more risky, but all customizations that involve disk device names are retained. Make sure that /a/dev/dsk links match /a/dev/rdsk links. Note that all those soft links can be removed and recreate with devfsadm as above safely.
  8. Unmount the hard disk

    umount /a/usr
    umount /a

  9. Try to reboot from hard disk.

    init 6

Note: Backup all of your data prior any modification to the system hardware which have direct relation with the hard disk, i.e. motherboard, disk controller including IDE or SCSI adapter.