When a system is powered on, the system is controlled by the read-only-memory (ROM) Basic Input/Output System (BIOS). The BIOS is the firmware interface on Solaris Operating Systems that have 64-bit and 32-bit x86 support.

Hardware adapters usually have an on-board BIOS that displays the physical characteristics of the device. The BIOS is used to access the device. During the startup process, the system BIOS checks for the presence of any adapter BIOS. If any adapters are found, the system then loads and executes each adapter BIOS. Each adapter's BIOS runs self-test diagnostics and then displays device information.

The BIOS on most systems has a user interface, where you can select an ordered list of boot devices that consists of the following selections:

The BIOS attempts to boot from each device, in turn, until a valid device with a bootable program is found.

Boot devices are either local media or network devices. When you boot from local media, the BIOS loads, then executes a 512-byte program that is located in the first physical sector of the media. This program is supplied by the operating system vendor. The program is then installed on the disk as part of the normal Solaris software installation or upgrade process. After the BIOS transfers control to this program, the OS takes over the system.

To boot a system from a network interface, a DHCP server is required. A boot file server is also required. These servers can reside on the same machine or on separate machines. The de facto boot protocol for an x86 network is PXE, which works in conjunction with DHCP. The BIOS boots the system from a network interface. The BIOS then issues a DHCP request for the name of the boot program and the IP address of the server that the program is to be downloaded from. After the BIOS receives the DHCP response, the BIOS downloads the program by using the TFTP protocol and executes the program. The boot program is supplied by the OS vendor. You install the boot program on the boot file server.

Current operation system kernels are too large for the BIOS to load directly. Therefore, the OS needs a boot subsystem to bootstrap the kernel into existence. This process involves several stages, whereby a small program loads and executes a larger program. Eventually, control is handed over to the Solaris OS kernel. On x86 based systems, the Solaris OS uses the open source GRUB program to bootstrap the kernel.

The /platform/i86pc/multiboot program is an ELF32 executable that contains a header which is defined in the Multiboot Specification. The multiboot program is responsible for performing the following tasks:

After the kernel gains control of the system, the kernel initializes the CPU, memory, and device subsystems. The kernel then mounts the root device, which corresponds to the bootpath and fstype properties that are specified in the /boot/solaris/bootenv.rc file. This file is part of the boot archive. If these properties are not specified in the bootenv.rc file, or on the GRUB command line, the root (/) file system defaults to UFS on /devices/ramdisk:a. The root (/) file system defaults to UFS when you boot the installation miniroot. After the root device is mounted, the kernel initializes the sched and init commands. These commands start the Service Management Facility (SMF) services.

This section describes multiple operating systems that are supported on the same disk with GRUB. The following is an example of an x86 based system that has the Solaris Express 6/05 OS, the Solaris 9 OS, Linux, and Microsoft Windows installed on the same disk.

Based on the preceding information, the GRUB menu appears as follows:

title Solaris 6/05 Express
			root (hd0,2,d)
			kernel /platform/i86pc/multiboot
			module /platform/i86pc/boot_archive
title Solaris 9
			root (hd0,2,a)
			chainloader +1
			makeactivetitle Linux
			root (hd0,1)
			kernel <from Linux GRUB menu...>
			initrd <from Linux GRUB menu...>
title Windows
			root (hd0,0)
			chainloader +1

The Solaris partition must be the active partition. Also, do not indicate makeactive under the Microsoft Windows menu. Doing so causes the system to boot Microsoft Windows every time. Note that if Linux installed GRUB on the master boot block, you cannot access the Solaris boot option. The inability to access the Solaris boot option occurs whether or not you designate it as the active partition. In this case, you can do one of the following:

The boot archive contains core kernel modules, including drivers and configuration files, that are needed to initialize the OS kernel. After the I/O subsystem is initialized, the kernel mounts the root (/) file system on the real root device. The Solaris OS updates the boot archive from files on the root (/) file system whenever necessary. This update typically occurs when a kernel patch is applied or when a driver package is added. To detect any file updates that were performed manually, the boot archive might also be updated during system shutdown.

If a system failure, a power failure, or a kernel panic occurs, immediately following a kernel file update, the boot archive and the root (/) file system might not be synchronized. Although the system might still boot with the old boot archive, you should boot the system in the failsafe archive to rebuild the boot archive. On mission critical systems, where system availability is essential, you might choose to set up a cron job to run the bootadm command on a regular basis. If the boot archive does not need to be updated, this process uses very little resources and usually takes only 0.1 to 0.2 seconds to complete.

The boot archive is updated by using the bootadm command. Immediately after you perform a system upgrade or apply a patch, manually rebuild the boot archive by running the following command as superuser:

# bootadm update-archive

For more information, see the bootadm ( 1M ) man page. For step-by-step instructions, see How to Boot the Failsafe Archive to Forcibly Update a Corrupt Boot Archive.

GRUB has two kinds of boot archives:

A failsafe boot archive has the following benefits and characteristics:

A primary boot archive shadows a root (/) file system. This boot archive contains all of the kernel modules, driver.conf files, plus a few configuration files. These files are located in the /etc directory. The files in the boot archive are read by the kernel before the root (/) file system is mounted. After the root (/) file system is mounted, the boot archive is discarded by the kernel from memory. Then, file I/O is performed against the root device.

By default, the primary boot archive contains the following files:

If any files in the archive are updated, the boot archive must be rebuilt. For modifications to take effect, the rebuild of the archive must take place before the next system reboot.

To rebuild the boot archive manually, use the bootadm command. You can also rebuild the boot archive by booting the system in the failsafe archive which is an available option in the GRUB main menu. During the failsafe boot procedure, when prompted by the system, type y to rebuild the primary boot archive. For more information, see How to Boot the Failsafe Archive for Recovery Purposes.