x86: Boot Processes

This section includes information about boot processes that are unique
to booting an x86 based system.

x86: System BIOS

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 x86 64-bit and 32-bit 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:

Diskette

CD or DVD

Hard disk

Network

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

x86: Kernel Initialization Process

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:

Interpreting the content of boot archive

Autodetection of systems that are 64-bit capable

Selecting the best kernel mode for booting the system

Assembling core kernel modules in memory

Handing control of the system to the Solaris kernel

x86: Solaris Support for the GRUB Bootloader

The following sections contain additional reference information for
administering GRUB in the Solaris OS

x86: GRUB Terminology

To thoroughly grasp GRUB concepts, an understanding of the following
terms is essential.

Note –

Some of the terms that are described in this list are not exclusive
to GRUB based booting.

boot archive

A collection of critical files that is used to boot the Solaris
OS. These files are needed during system startup before the root file system
is mounted. Multiple boot archives are maintained on a system:

A primary boot archive is used to boot
the Solaris OS on an x86 based system.

Note –

On
the x86 platform, when you install the Solaris OS, two primary boot archives
are created, one 32-bit archive and one 64-bit archive.

A failsafe boot archive that is used
for recovery when a primary boot archive is damaged. This boot archive starts
the system without mounting the root file system. On the GRUB menu, this boot
archive is called failsafe. The archive's primary purpose
is to regenerate the primary boot archives, which are usually used to boot
the system.

boot loader

The first software program that runs after you power on a
system. This program begins the booting process.

failsafe archive

See boot archive.

GRUB

GNU GRand Unified Bootloader (GRUB) is an open-source boot
loader with a menu interface. The menu displays a list of the operating systems
that are installed on a system. GRUB enables you to easily boot these various
operating systems, such as the Solaris OS, Linux, or Windows.

GRUB main menu

A boot menu that lists the operating systems that are installed
on a system. From this menu, you can easily boot an operating system without
modifying the BIOS or fdisk partition settings.

GRUB edit menu

A submenu of the GRUB main menu. GRUB commands are displayed
on this submenu. These commands can be edited to change boot behavior.

menu.lstfile

A configuration file that lists all the operating systems
that are installed on a system. The contents of this file dictate the list
of operating systems that is displayed in the GRUB menu. From the GRUB menu,
you can easily boot an operating system without modifying the BIOS or fdisk partition settings.

miniroot

A minimal, bootable root (/) file system
that resides on the Solaris installation media. A miniroot consists of the
Solaris software that is required to install and upgrade systems. On x86 based
systems, the miniroot is copied to the system to be used as the failsafe boot
archive. See boot archive for details about the failsafe boot archive.

stage2 – Is an image that is installed
in a reserved area in the Solaris fdisk partition. The stage2 image is the core image of GRUB.

menu.lst file – Is typically located
in the /boot/grub directory on systems with a UFS root
and in the /pool-name/boot/grub directory
on systems with a ZFS root. This file is read by the GRUB stage2 file.
For more information, see the section, x86: Modifying Boot Behavior by Editing the menu.lst File.

You cannot use the dd command to write stage1 and stage2 images to disk. The stage1 image must
be able to receive information about the location of the stage2 image
that is on the disk. Use the installgrub command, which
is the supported method for installing GRUB boot blocks.

Naming Conventions That Are Used for Configuring GRUB

GRUB uses conventions that are slightly different from previous Solaris
releases. Understanding the GRUB device-naming conventions can assist you
in correctly specifying drive and partition information when you configure
GRUB on your system.

The following table describes the GRUB device-naming conventions for
this Solaris release.

Naming
Conventions That Are Used by the findroot Command

Starting with the Solaris 10 10/08 release, the findroot command
replaces the root command that was previously used by GRUB.
The findroot command provides enhanced capabilities for
discovering a targeted disk, regardless of the boot device. The findroot command also supports booting from a ZFS root file system This
command replaces the root command that was formerly used
by GRUB.

The following is a description of the device naming convention that
is used by the findroot command for various GRUB implementations:

Solaris Live Upgrade:

findroot (BE_x,0,a)

The x variable is the name of the boot environment.

Standard system upgrades and new installations for systems
with ZFS support:

findroot(pool_p,0,a)

The p variable is the name of the root pool.

Standard system upgrades and new installations for systems
with UFS support:

findroot (rootfsN,0,a)

The N variable is an integer number that
starts at 0.

How Multiple Operating Systems Are Supported by GRUB

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

Table 15–2 Sample GRUB Menu Configuration

Operating System

Location on Disk

Windows

fdisk partition 0

Linux

fdisk partition 1

Solaris

fdisk partition 2

Solaris 9 OS

Slice 0

Solaris 10 10/08 OS

Slice 3

Based on the preceding information, the GRUB menu would look like the
following:

The Solaris slice must be the active partition. Also, do not indicate makeactive under the Windows menu. Doing so causes the system to
boot Windows every time. Note that if Linux has 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:

Chain-load from the Linux GRUB by modifying the menu on Linux.

Chain-loading is a mechanism for loading unsupported
operating systems by using another boot loader.

Replace the master boot block with the Solaris GRUB by running
the installgrub command with the -m option:

x86: Supported GRUB Implementations

In
the Solaris Express release, GRUB uses the direct boot implementation. The
contents of the menu.lst file varies, depending on the
Solaris release you are running, the installation method that is used, and
whether you are booting the system from a ZFS root or a UFS root.

In this implementation
of GRUB, the multiboot module is no longer used.

Description of the menu.lst File
(ZFS Support)

The following are various
examples of a menu.lst file
for a boot environment that contains a ZFS boot loader:

Note –

Because the miniroot is mounted as the real root file system,
the entry for failsafe booting in the menu.lst file does not change to the ZFS bootfs property, even
if the failsafe archive is read from a ZFS dataset. The ZFS dataset is not
accessed after the boot loader reads the miniroot.

Description of a menu.lst File That Supports Hypervisor Technology

You can run the Solaris OS as a virtualized control domain, with the
hypervisor. To run the Solaris release with this support, there must be an
entry in menu.lst file that specifies the hypervisor.
This entry can either be the default boot menu item, or you can select this
entry manually at boot time. After you upgrade your system for the first
time to a Solaris release that includes this support, the bootadm command
automatically adds a GRUB menu.lst entry for the hypervisor.

The kernel$ line specifies a path to xen.gz file, followed by optional hypervisor arguments.

The first module$ line includes the path
to UNIX twice, followed by any arguments for the Solaris dom0 kernel.

The second module$ line provides the
path to the boot archive.

Note that the path to UNIX in the menu.lst entry
for the hypervisor uses i86xpv, noti86pc. The options that are interpreted by the hypervisor are added
to end of the kernel$ line, after the xen.gz file
information.

If you choose to run the Solaris release as a stand-alone OS, you can
continue to use the same GRUB menu entries that you used previously.