test

System Administration Guide: Basic Administration

Chapter 9 Shutting Down and Booting a System (Overview)

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.

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.

Fundamentals of the Solaris Boot Design

The Solaris boot design, for both the SPARC and x86 platforms, includes the following characteristics:

Understanding the New Solaris SPARC Boot Architecture

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:

The following four boot phases are now independent of each other:

  1. Open Boot PROM (OBP) phase

    The 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.

  2. Booter phase

    During 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.

  3. Ramdisk phase

    The 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.

    Note –

    This utility has a private interface to the file compression file system, dcfs.

  4. Kernel phase

    The 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.

Packing and Unpacking the Miniroot

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.

Caution – Caution –

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_archive(1M) man page.

Software Installation and Upgrades

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.

Installation Memory Requirements

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.

Changes to the Network Boot Server Setup Process

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:

  1. The boot server transfers a bootstrap in the form of a boot archive to the target system.

  2. The target system unpacks the boot archive in a ramdisk.

  3. 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).

Support for Booting Multiple Solaris Kernels

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 SPARC: How to Boot a Solaris Kernel Other Than the Default Kernel.

Implementation of the Boot Archives on Solaris SPARC

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:

Note –

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:

For information about managing the boot archives, see Managing the Solaris Boot Archives (Task Map).

x86: Administering the GRUB Bootloader

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 http://www.gnu.org/software/grub/grub.html. See also the grub(5) man page.

How GRUB Based Booting Works

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 http://www.gnu.org/software/grub/grub.html.

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:

GRUB Support for New findroot Command

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_archive

For more information, see x86: Implementation of the findroot Command.

For GRUB reference information, see Chapter 15, x86: GRUB Based Booting (Reference).

x86: Introducing Fast Reboot

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.

Note –

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).

Modifications to the reboot Command to Support Fast Reboot

To support Fast Reboot, the reboot command has been modified to include two new options:

-f

Initiates the fast reboot process, when used with the reboot command.

-e

Initiates a fast reboot to an alternate boot environment (BE), when used in conjunction with the -f option,

Note –

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 x86: Initiating a Fast Reboot to an Alternate Boot Environment in the OpenSolaris 2008.11 OS.

For more information, see the reboot(1M) man page.

Implementation of the quiesce 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 quiesce(9E) and dev_ops(9S) man pages.

Note –

Not all device drivers implement the quiesce function. For troubleshooting instructions, see x86: Troubleshooting Conditions That Might Prevent Fast Reboot From Working.

New uadmin Function

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.

Note –

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 uadmin(2)man page.

Booting From a ZFS Root File System

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.

Solaris Installation Requirements for ZFS

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:

How Booting From a ZFS Root File System Works

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.

On 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 Options That Support Booting From a ZFS Root File System

On the SPARC platform, the following two boot options are new:

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 Options That Support Booting From a ZFS Root File System

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-safe

This 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_archive

For step-by-step instructions on booting a system from ZFS, see Booting From a ZFS Root File System on an x86 Based System.