III. Boot managers
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
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
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
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.
Programs
If Solaris partition is selected to boot off, the secondary boot -
Secondary boot is programmable, which makes it very flexible. If the root file
system is successfully mounted,
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
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:
By default
eeprom auto-boot?=true
to set
eeprom auto-boot-timeout=0
to make DCA not to wait for Esc key.
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
fdisk -b /usr/lib/fs/ufs/mboot -n /dev/rdsk/c0d0p0
where
Sometimes it is necessary to recover VBS of a Solaris boot partition or Solaris
boot manager program.
installboot /usr/platform/i86pc/lib/fs/ufs/pboot \
Since
The following files contain critical executable code for boot process:
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
x86 Boot partition can be created with Solaris
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
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
Assume that the old boot path was:
where:
The boot path represents a subdirectory in
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
The step by step procedure would look as follows:
TERM=AT386; export TERM
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.
grep /usr /a/etc/vfstab
You will see a line:
which means that the number of the
mount /dev/dsk/c0t0d0s4 /a/usr
/usr/sbin/chroot /a /usr/sbin/devfsadm -C -v
sync
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.
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).
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.
pboot program
contained there is responsible for loading the image of the boot manager
strap.com.
Boot manager
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
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.
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
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.
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.
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:
auto-boot to true, or
Restoring Solaris boot manager
/usr/lib/fs/ufs/mboot.
It can be restored using Solaris fdisk utility (see fdisk man page) as
follows:
/dev/rdsk/c0d0p0 stands for the raw device associated
with the first (usually primary master) IDE/ATA hard disk drive on the system.
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:
/usr/platform/i86pc/lib/fs/ufs/bootblk /dev/rdsk/c0d0s2
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.
/usr/lib/fs/ufs/mboot - Master Boot Code,
/usr/platform/i86pc/lib/fs/ufs/pboot - Volume Boot Code,
/usr/platform/i86pc/lib/fs/ufs/bootblk - Solaris boot manager.
x86 Boot partition
/boot directory and can be run during boot time.
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:
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
bootpath in /boot/solaris/bootenv.rc,
/devices,
/etc/vfstab, or device links under /dev/dsk
and /dev/rdsk.
devfsadm utility (Solaris 8 or later). This is how to achieve that:
/pci@0,0/pci9004,7881@13/sd@0,0:a,
pci@0,0 is the architecture of the disk controller and its address,
pci9004,7881 is a device PNP identification, consists of
a vendor and part number,
13 is an IRQ level,
sd means SCSI driver (you may have ata, cmdk or eisa here),
0,0:a is the address of the Solaris root file system (slice)
on the Solaris fdisk partition.
/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.
/dev/dsk).
b -s.
A shell will follow after this.
vi editor. Type in:
/ file system:
/usr file system:
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /usr ufs 1 no logging
/usr slice is 4.
/usr file system:
/a/devices and /a/dev:
/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.
/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.
umount /a/usr
umount /a