Chapter 15 x86: GRUB Based Booting (Reference)

This chapter contains information about x86 boot processes, including GRUB implementation details and additional GRUB reference information.

For overview information, see Chapter 9, Shutting Down and Booting a System (Overview).

For step-by-step instructions on booting a system, see Chapter 12, Booting a Solaris System (Tasks).

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

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.

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.

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.

• 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.lst file

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.

primary boot archive

See boot archive.

x86: Functional Components of GRUB

GRUB consists of the following functional components:

• stage1 – Is an image that is installed on the first sector of the Solaris fdisk partition. You can optionally install stage1 on the master boot sector by specifying the -m option with the installgrub command. See the installgrub(1M) man page and Disk Management in the GRUB Boot Environment in System Administration Guide: Devices and File Systems for more information.

• 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 device-naming 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.

All GRUB device names must be enclosed in parentheses.

For more information about fdisk partitions, see Guidelines for Creating an fdisk Partition in System Administration Guide: Devices and File Systems.

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.

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.

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

title Solaris 10
			findroot (pool_rpool,0,a)
			kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS
			module /platform/i86pc/boot_archive
title Solaris 9 OS (pre-GRUB)
			root (hd0,2,a)
			chainloader +1
			makeactive
title Linux
			root (hd0,1)
			kernel <from Linux GRUB menu...>
			initrd <from Linux GRUB menu...>
title Windows
			root (hd0,0)
			chainloader +1

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:

  # installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/root-slice

  See the installgrub(1M) man page for more information.

For information about the Solaris Live Upgrade boot environment, see Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning.

x86: Supported GRUB Implementations

In the Solaris 10 OS, GRUB uses the multiboot implementation. In the Solaris Express release, 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.

• GRUB ZFS boot support

  For a description of the menu.lst file and an example, see Description of the menu.lst File (ZFS Support).

• GRUB UFS boot support

  For a description of the menu.lst file and an example, see Description of the menu.lst File (UFS Support).

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:

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.

Example 15–1 Default menu.lst File (New Installation or Standard Upgrade)

title Solaris 10 5/08 s10x_nbu6wos_nightly X86
findroot (pool_rpool,0,a)
kernel$  /platform/i86pc/multiboot  -B $ZFS-BOOTFS
module /platform/i86pc/boot_archive

title Solaris failsafe
findroot (pool_rpool,0,a)
kernel /boot/multiboot kernel/unix -s    -B console=ttyb
module /boot/x86.miniroot-safe

Example 15–2 Default menu.lst File (Solaris Live Upgrade)

title be1
findroot (BE_be1,0,a)
bootfs rpool/ROOT/szboot_0508
kernel$  /platform/i86pc/multiboot  -B $ZFS-BOOTFS
module /platform/i86pc/boot_archive

title be1 failsafe
findroot (BE_be1,0,a)
kernel /boot/multiboot kernel/unix -s    -B console=ttyb
module /boot/x86.miniroot-safe

Description of the menu.lst File (UFS Support)

The following are examples of a menu.lst file on a system that supports booting from UFS.

Example 15–3 Default GRUB menu.lst File (New Installation or Standard Upgrade)

title Solaris 10 5/08 s10x_nbu6wos_nightly X86 
findroot (pool_rpool,0,a)
kernel /platform/i86pc/multiboot
module /platform/i86pc/boot_archive

title Solaris failsafe
findroot (rootfs0,0,a)
kernel /boot/multiboot kernel/unix -s -B console-ttyb
module /boot/x86.miniroot-safe

Example 15–4 Default GRUB menu.lst File (Solaris Live Upgrade)

title be1
findroot (BE_be1,0,a)
kernel /platform/i86pc/multiboot
module /platform/i86pc/boot_archive

title be1 failsafe
findroot (BE_be1,0,a)
kernel /boot/multiboot kernel/unix -s    -B console=ttyb
module /boot/x86.miniroot-safe