This chapter provides an overview of booting a system. The Solaris boot design, boot processes, and various methods of booting a system in the Solaris OS are described.This is a list of the information in this chapter.Fundamentals of the Solaris Boot Design Understanding the New Solaris SPARC Boot Architecture Implementation of the Boot Archives on Solaris SPARC Administering the GRUB Bootloader Introducing Fast Reboot Booting From a ZFS Root File System For instructions on booting a Solaris system, see Chapter 12, Booting a Solaris System (Tasks)For what's new in shutting down and booting a system, see What's New in Shutting Down and Booting a System.For overview information and instructions on administering boot loaders and modifying Solaris boot behavior, see Chapter 11, Modifying Solaris Boot Behavior (Tasks).For information about managing boot services through the Service Management Facility (SMF), see SMF and Booting. The Solaris boot design, for both the SPARC and x86 platforms, includes the following characteristics:Use of a boot archiveThe boot archive is a ramdisk image that contains all of the files that are required for booting a system. When you install the Solaris OS, two boot archives are created, one primary archive and one failsafe archive. For more information, see Implementation of the Boot Archives on Solaris SPARC.The bootadm command has also been modified for use on the SPARC platform. This command functions the same way that it does on the Solaris x86 platform. The bootadm command handles the details of archive update and verification automatically. During an installation or system upgrade, the bootadm command creates the initial boot archive. During the process of a normal system shutdown, the shutdown process checks the boot archive contents against the root file system. If there are any inconsistencies, the system rebuilds the boot archive to ensure that on reboot, the boot archive and root (/) file system are synchronized. You can also use the bootadm command to manually update the boot archives. See Using the bootadm Command to Manage the Boot Archives.Some options of the bootadm command cannot be used on SPARC based systems. For more information, see the bootadm1M and boot1M man pages. Use of a ramdisk image as the root file system during installation and failsafe operationsThis process is now the same on the Solaris SPARC and Solaris x86 platforms. The ramdisk image is derived from the boot archive and is then transferred to the system from the boot device.On the SPARC platform, the OpenBoot PROM continues to be used to access the boot device and to transfer the boot archive to the system's memory. Conversely, on the x86 platform, the system is initially controlled by the BIOS. The BIOS is used to initiate a transfer of the boot archive from a network device or to run a boot loader. In the Solaris OS, the x86 boot loader that is used to transfer the boot archive from disk is GRUB. See Boot Processes. In the case of a software installation, the ramdisk image is the root file system that is used for the entire installation process. Using the ramdisk image for this purpose eliminates the need to boot the system from removable media. The ramdisk file system type can be either a High Sierra File System (HSFS) or UFS. The boot processes on the Solaris SPARC platform have been redesigned and improved to increase commonality with the Solaris x86 boot experience. The new Solaris SPARC boot design enables the addition of new features, for example new file system types, without necessitating any changes to multiple portions of the boot chain. Changes also include the implementation of boot phase independence.Highlights of these improvements include:Commonality in boot processes on the Solaris SPARC and x86 platforms Commonality in the network boot experience Boot architecture flexibility that enables booting a system from different file system types more easily The following four boot phases are now independent of each other:Open Boot PROM (OBP) phaseThe OBP phase of the boot process on the Solaris SPARC platform is unchanged.For disk devices, the firmware driver usually uses the OBP label package's load method, which parses the VTOC label at the beginning of the disk to locate the specified partition. Sectors 1-15 of the partition are then read into the system's memory. This area is commonly called the boot block and usually contains a file system reader. Booter phaseDuring this phase the boot archive is read and executed. Note that this is the only phase of the boot process that requires knowledge of the boot file system format. In some instances, the boot archive might also be the installation miniroot. Protocols that are used for the transfer of the boot loader and the boot archive include local disk access, NFS, and HTTP. Ramdisk phaseThe ramdisk is a boot archive that is comprised of kernel modules or an installation miniroot.The Solaris SPARC boot archive is identical to a Solaris x86 boot archive. The boot archive file system format is private. Therefore, knowledge of the file system type that is used during a system boot, for example an HSFS or a UFS file system, is not required by the booter or the kernel. The ramdisk extracts the kernel image from the boot archive and then executes it. To minimize the size of the ramdisk, in particular, the installation miniroot that resides in the system's memory, the contents of the miniroot are compressed. This compression is performed on a per-file level and is implemented within the individual file system. The /usr/sbin/fiocompress utility is then used to compress the file and mark the file as compressed.This utility has a private interface to the file compression file system, dcfs. Kernel phaseThe kernel phase is the final stage of the boot process. During this phase, the Solaris OS is initialized and a minimal root file system is mounted on the ramdisk that was constructed from the boot archive. If the boot archive is the installation miniroot, the OS continues executing the installation process. Otherwise, the ramdisk contains a set of kernel files and drivers that is sufficient to mount the root file system on the specified root device.The kernel then extracts the remainder of the primary modules from the boot archive, initializes itself, mounts the real root file system, then discards the boot archive. The ramdisk-based miniroot is packed and unpacked by the root_archive command. Note that only SPARC based systems that support the new boot architecture have the ability to pack and unpack a compressed version of the miniroot. The Solaris Express version of the root_archive tool is not compatible with the Solaris 10 version of the tool. Therefore, ramdisk manipulation should only be performed on a system that is running the same Solaris release as the archives. For more information about packing and unpacking the miniroot, see the root_archive1M man page. To install or upgrade the Solaris OS, you need to boot the miniroot from either CD/DVD or from the network. In both instances, the miniroot's root file system is the ramdisk. This process enables you to eject the Solaris boot CD without having to reboot the system. Note that the boot archive contains the entire miniroot. The construction of the installation CD has been modified to use an HSFS boot block. The miniroot is then packed into a single UFS file that is loaded as the ramdisk. Note that the miniroot is used for all OS installation types. If you are running a Solaris Express Community release or an OpenSolaris release, the minimum memory requirements to install a system is 512 Mbytes of memory.For the Solaris 10 release, the minimum memory requirements to install a system have been increased from 256 Mbytes of memory to minimum of 384 Mbytes of memory. This amount of memory enables a text-based installation only. To run the installation GUI program requires a minimum of 768 Mbytes of memory. The network boot server setup process has been modified. The boot server now serves a bootstrap program, as well as the ramdisk, which is downloaded and booted as a single miniroot for all installations, whether booting from CD/DVD or performing a network installation by using NFS or HTTP. The administration of a network boot server for a network boot over both NFS or the wanboot program (HTTP) remains the same. However, the internal implementation of the network boot process has been modified as follows:The boot server transfers a bootstrap in the form of a boot archive to the target system. The target system unpacks the boot archive in a ramdisk. The boot archive is then mounted as the initial read-only root device. For more information about booting a SPARC based system, see Booting a SPARC Based System (Task Map). On SPARC based systems, when you type boot at the ok prompt, the default boot device is automatically selected. An alternate boot device can be specified by changing the boot-device NVRAM variable. You can also specify an alternate boot device or alternate kernel (boot file) from the command line at boot time. See How to Boot a Solaris Kernel Other Than the Default Kernel. archiveSolaris failsafe and primarydescription normal archive in GRUBboot archivereference Solaris boot archivesfailsafe and normalreference failsafe archiveGRUB referencedescription boot archivestypes of The Solaris boot archives, previously only available on the x86 platform, are now an integral part of the Solaris SPARC boot architecture.The bootadm command has been modified for use on the Solaris SPARC platform. This command functions the same as it does on the Solaris x86 platform. The bootadm command handles the details of archive update and verification. On the x86 platform the bootadm command updates the GRUB menu during an installation or system upgrade. You can also use the bootadm command to manually manage the boot archives.The boot archive service is managed by the Service Management Facility (SMF). The service instance for the boot archive is svc:/system/boot-archive:default. To enable, disable, or refresh this service use the svcadm command. For information about managing services by using SMF, see Chapter 16, Managing Services (Overview).On supported Solaris releases, for both SPARC and x86 based systems, there are two kinds of boot archives:Primary boot archive Failsafe boot archive On x86 based systems, when you install the Solaris OS, two primary boot archives are created, one 32-bit boot archive and one 64-bit boot archive. The files that are included in the Solaris SPARC boot archives are located in the /platform directory.The contents of the /platform directory is divided into two groups of files:Files that are required for a sun4u boot archive Files that are required for sun4v boot archive For information about managing the boot archives, see Managing the Solaris Boot Archives (Task Map). GRUB-based bootingreference booting with GRUB, reference referenceadministering GRUB administering GRUBreference The open source GRand Unified Bootloader (GRUB) is the default boot loader on x86 based systems. GRUB is responsible for loading a boot archive into the system's memory. A boot archive is a collection of critical files that is needed during system startup before the root file system is mounted. The boot archive is the interface that is used to boot the Solaris OS. You can find more information about GRUB at . See also the grub5 man page.After an x86 based system is powered on, the Basic Input/Output System (BIOS) initializes the CPU, the memory, and the platform hardware. When the initialization phase has completed, the BIOS loads the boot loader from the configured boot device and then transfers control of the system to the boot loader. The boot loader is the first software program that runs after you turn on a system. This program starts the boot process.GRUB implements a menu interface that includes boot options that are predefined in a configuration file called the menu.lst file. GRUB also has a command-line interface that is accessible from the GUI menu interface that can be used to perform various boot functions, including modifying default boot behavior. In the Solaris OS, the GRUB implementation is compliant with the Multiboot Specification, which is described in detail at .Because the Solaris kernel is fully compliant with the Multiboot Specification, you can boot x86 based systems by using GRUB. With GRUB, you can boot various operating systems that are installed on a single x86 based system. For example, you can individually boot the Solaris OS, Linux, or Windows by selecting the boot entry in the GRUB menu at boot time or by configuring the menu.lst file to boot a specific OS by default.Because GRUB is intuitive about file systems and kernel executable formats, you can load an operating system without recording the physical position of the kernel on the disk. With GRUB-based booting, the kernel is loaded by specifying its file name, and the drive and the partition where the kernel resides. For more information see Naming Conventions That Are Used for Configuring GRUB.For step-by-step instructions on booting a system with GRUB, see Booting an x86 Based System by Using GRUB (Task Map).See also the following man pages:boot1M bootadm1M grub5 installgrub1M GRUB support for a new findroot command has been implemented in this Solaris release. The findroot command, which functions similarly to the root command that was previously used by GRUB, has enhanced capabilities for discovering a targeted disk, regardless of the boot device. The findroot command also supports booting from a ZFS root file system.The most common format for the menu.lst entry for this command is:findroot (rootfs0,0,a) kernel$ /platform/i86pc/kernel/$ISADIR/unix module$ /platform/i86pc/$ISADIR/boot_archiveFor more information, see Implementation of the findroot Command.For GRUB reference information, see Chapter 15, GRUB Based Booting (Reference). This feature is available, starting with build 100 of the Solaris Express Community Edition release, and in the OpenSolaris 2008.11 OS.Fast Reboot implements an in-kernel boot loader that loads the kernel into memory, then switches to that kernel, thus enabling the reboot process to occur within seconds. With Fast Reboot, you can reboot to a new kernel without experiencing the long delays that can be imposed by the BIOS and boot loader. The ability to fast reboot a system drastically reduces down time and improves efficiency.Fast Reboot is currently not available on the SPARC platform. The following sections provide a general overview of the Fast Reboot feature. For task related information, see Using Fast Reboot on the x86 Platform (Task Map).reboot commandf and e options described Fast Rebootmodifications to the reboot command To support Fast Reboot, the reboot command has been modified to include two new options:fInitiates the fast reboot process, when used with the reboot command. eInitiates a fast reboot to an alternate boot environment (BE), when used in conjunction with the f option,The e option cannot be used to fast reboot to an alternate BE in the OpenSolaris 2008.11 release. For instructions on initiating a fast reboot to an alternate BE in this release, see Initiating a Fast Reboot to an Alternate Boot Environment in the OpenSolaris 2008.11 OS. For more information, see the reboot1M man page. quiesce functionFast Reboot implementation Fast Rebootquiesce function device driversquiesce function The system's capability to bypass the firmware when booting a new OS image has dependencies on device drivers' implementation of a new device operation entry point, quiesce. On supported drivers, this implementation quiesces a device, so that at completion of the function, the driver no longer generates interrupts or access memory. This implementation also resets the device to a hardware state, from which the device can be correctly configured by the driver's attach routine, without a power cycle of the system or being configured by the firmware. For more information about this functionality, see the quiesce9E and dev_ops9S man pages.Not all device drivers implement the quiesce function. For troubleshooting instructions, see Troubleshooting Conditions That Might Prevent Fast Reboot From Working. uadmin functionFast Reboot implementation Fast Rebootuadmin command changes Other changes that support Fast Reboot on the x86 platform include the new uadmin function, AD_FASTREBOOT. This function resets the system, enabling the reboot command to bypass the BIOS and the boot loader phases.The uadmin 2 8 command has limited functionality. If the command is used to facilitate a fast reboot of the system, neither the boot archive, nor the menu.lst file are updated. For this reason, the reboot f command is the preferred method for initiating a fast reboot. For more information, see the uadmin2man page. Support for booting a system from a ZFS root file system has been added to the Solaris OS. The Solaris installation software also includes support for system upgrades and patching of systems with ZFS roots. Booting, system operations, and installation procedures have been modified to support this change. Changes to booting include the implementation of boot loaders the SPARC boot architecture to increase commonality with the Solaris x86 boot architecture. This implementation is described in the following sections.For more information about ZFS, including a complete list of terms, see ZFS Terminology in Solaris ZFS Administration Guide.Before performing a new installation of the Solaris software or using Solaris Live Upgrade to migrate a UFS root file system to a ZFS root file system, make sure the following requirements are met:Solaris release information:The ability to install and boot from a ZFS root file system is available in the Solaris 10 11/06 release. To perform a Solaris Live Upgrade operation to migrate to a ZFS root file system, you must have installed or upgraded to the Solaris 10 11/06 release. ZFS storage pool space requirements:The minimum amount of available pool space that is required for a bootable ZFS root file system is larger than for a bootable UFS root file system because swap and dump devices are not shared in a ZFS root environment.If you select a ZFS root file system during an initial software installation, or if you use Solaris Live Upgrade to migrate from a UFS root file system to a ZFS root file system, a swap area is created on a ZFS volume in the ZFS root pool. The default swap area is sized at 1/2 the size of physical memory, but no more than 2 Gbytes. A ZFS volume is also created for the dump device. The dump device is sized at 1/2 the size of physical memory, but no more than 2 Gbytes. Currently, the swap area and the dump device must reside on separate ZFS volumes.For more information, see ZFS Support for Swap and Dump Devices in Solaris ZFS Administration Guide. Booting from a ZFS root file system works differently than booting from a UFS file system. Because ZFS applies several new concepts for installation and booting, some basic administrative practices for booting a system have changed. The most significant difference between booting from a ZFS root file system and booting from a UFS root file system is that with ZFS a device identifier does not uniquely identify a root file system, and thus a BE. With ZFS, a device identifier uniquely identifies a storage pool. A storage pool can contain multiple bootable datasets (root file systems). Therefore, in addition to specifying a boot device, a root file system within the pool that was identified by the boot device must also be specified.On an x86 based system, if the boot device that is identified by GRUB contains a ZFS storage pool, the menu.lst file that is used to create the GRUB menu is located in the dataset at the root of that pool's dataset hierachy. This dataset has the same name as the pool. There is one such dataset in each pool.A default bootable dataset is the bootable dataset for the pool that is mounted at boot time and is defined by the root pool's bootfs property. When a device in a root pool is booted, the dataset that is specified by this property is then mounted as the root file system.The new bootfs pool property is a mechanism that is used by the system to specify the default bootable dataset for a given pool. When a device in a root pool is booted, the dataset that is mounted by default as the root file system is the one that is identified by the bootfs pool property.bootfs pool propertyOn a SPARC based system, the default bootfs pool property is overridden by using the new Z dataset option of the boot command.On an x86 based system, the default bootfs pool property is overridden by selecting an alternate boot environment in the GRUB menu at boot time. SPARC boot optionsbooting from a ZFS root file system booting from a ZFS root file systemSPARC boot options L optionZFS boot optionsdisplaying available BEs Z optionZFS boot options displaying a list of available BEsbooting a ZFS rootboot L option On the SPARC platform, the following two boot options are new:The L option, which is used to print a list of all the available BEs on a system.ok boot -LThe L option is run from the ok prompt. This option only presents the list of available BEs on the system. To boot the system, use the Z boot option. The Z option of the boot command enables you to specify a bootable dataset other than the default dataset that is specified by the bootfs pool property.ok boot -Z dataset The list of BEs that are displayed when you use the L option on a device that has a ZFS boot loader reflect the menu.lst entries that are available on that particular system. Along with the list of available BEs, instructions for selecting a BE and using the Z option to boot the system are also provided. The dataset specified by the bootfs value for the menu item is used for all subsequent files that are read by the booter, for example, the boot archive and various configuration files that are located in the /etc directory. This dataset is then mounted as the root file system.For step-by-step instructions, see Booting From a ZFS Root File System on a SPARC Based System. x86 boot optionsbooting from a ZFS root file system booting from a ZFS root file systemx86 boot options $ZFS-BOOTFSZFS boot options On the x86 platform, a new GRUB keyword, $ZFS-BOOTFS has been introduced. When booting an x86 based system, if the root file system that corresponds with the GRUB menu entry is a ZFS dataset, the GRUB menu entry contains the B option with the $ZFS-BOOTFS token by default. If you install or upgrade your system with a Solaris release that supports a ZFS boot loader, the GRUB menu.lst file is updated with this information automatically. The default bootable dataset is identified by the bootfs property.On x86 based systems that are running a Solaris release that supports a ZFS boot loader, this information is included in the GRUB menu.The following is an example of a default menu.lst file for a GRUB implementation that supports a ZFS boot loader:title Solaris 11 s10x_90 X86 findroot (pool_rpool,0,a) kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot_archive title Solaris 11 failsafe findroot (pool_rpool,0,a) kernel /boot/platform/i86pc/kernel/unix -s -B console=ttyb module /boot/x86.miniroot-safeThis example shows a menu.lst file that has been manually edited to include an alternate bootable dataset entry:title Solaris-alternate-dataset bootfs myrootpool/bootenv-alt kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot_archiveFor step-by-step instructions on booting a system from ZFS, see Booting From a ZFS Root File System on an x86 Based System.