Go to main content

Booting and Shutting Down Oracle® Solaris 11.3 Systems

Exit Print View

Updated: October 2017

x86: Introducing GRUB 2

GRUB 2 is a powerful and more modular boot loader that supports a wider range of platforms and firmware types, including booting from Unified Extensible Firmware Interface (UEFI) firmware, and booting from GUID Partition Table (GPT) partitioned disks of any size, on systems with BIOS or UEFI firmware. GRUB 2 also supports the UEFI-specified, GPT partitioning scheme.

Like GRUB Legacy, GRUB 2 uses a two-stage boot process. The key difference between GRUB 2 and GRUB Legacy is that GRUB 2 places many facilities in dynamically loaded modules, which enables the core GRUB 2 (second-stage boot loader) image to be smaller and therefore load faster and be more flexible. As a result, GRUB functionality is loaded on demand at boot time.

    GRUB 2 introduces the following key changes:

  • Configuration changes

    The GRUB 2 configuration differs syntactically from the GRUB Legacy configuration. The menu.lst file that is used by GRUB Legacy has been replaced by a new configuration file, grub.cfg. Unlike the menu.lst file, the grub.cfg file is automatically regenerated by boot management commands. Therefore, this file should never be directly edited. as any edits are immediately destroyed when the grub.cfg file is regenerated. See Description of the GRUB 2 Configuration.

  • Partition and device naming changes

    Instead of 0-based indexes, GRUB 2 uses 1-based indexes for partitions and a changed device naming scheme. See GRUB 2 Partition and Device Naming Scheme.

  • Boot loader and GRUB menu administration changes

    You administer the grub.cfg file through the bootadm command. Modified subcommands and new subcommands enable you to perform most of the administrative tasks that were previously accomplished by editing the menu.lst file. Two examples include setting boot attributes (such as kernel arguments) for an Oracle Solaris boot instance and managing boot loader settings. See Administering the GRUB Configuration by Using the bootadm Command.

  • GRUB menu and screen changes

    The various GRUB menus and some tasks, for example, adding kernel arguments by editing the GRUB menu at boot time, work somewhat differently now. These differences are documented in the various tasks within this document, where appropriate.

  • Other boot loader related command changes

    The installgrub command is deprecated in this release. Do not use this command to install the boot loader on systems that support GRUB 2, as doing so can prevent the system from booting. Instead, if you are running a release that supports GRUB 2, use the bootadm install-bootloader command. This command supersedes the functionality of the installgrub command on x86 platforms and the installboot command on SPARC platforms. See Installing GRUB 2 by Using the bootadm install-bootloader Command.

    You can use the installgrub command to install GRUB Legacy on a system, but only after you have verified that the version of GRUB Legacy you are installing supports the ZFS pool version of your root pool, and that there are no remaining GRUB 2 boot environments on the system. For instructions, see How to Install GRUB Legacy on a System That Has GRUB 2 Installed.

x86: Description of the GRUB 2 Configuration

GRUB 2 uses an entirely different configuration than GRUB Legacy. The GRUB Legacy configuration is managed through the menu.lst file, but GRUB 2 does not use a menu.lst file. Instead, GRUB 2 uses a configuration file, grub.cfg, to store the same type of information. Similar to the menu.lst file, the grub.cfg file is located at the top-level of the ZFS dataset for the root pool, /pool-name/boot/grub, for example, /rpool/boot/grub/grub.cfg.

The syntax of the grub.cfg file is based on a subset of bash scripting, which is more complex and powerful than the directive-like language that is used in the menu.lst file that is shown in the following example:

title title
             bootfs pool-name/ROOT/bootenvironment-name
             kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
             module$ /platform/i86pc/$ISADIR/boot_archive

By comparison, the same configuration is stored in the grub.cfg file, as follows:

menuentry "<title>" {
        insmod part_msdos
        insmod part_sunpc
        insmod part_gpt
        insmod zfs
        search --no-floppy --fs-uuid --set=root f3d8ef099730bafa
        zfs-bootfs /ROOT/<BE name>/@/ zfs_bootfs
        set kern=/platform/i86pc/kernel/amd64/unix
        echo -n "Loading ${root}/ROOT/<BE name>/@$kern: "
        $multiboot /ROOT/<BE name>/@/$kern $kern -B $zfs_bootfs
        set gfxpayload="1024x768x32;1024x768x16;800x600x16;640x480x16;640x480x15;640x480x32"
        insmod gzio
        echo -n "Loading ${root}/ROOT/<BE name>/@/platform/i86pc/amd64/boot_archive: "
        $module /ROOT/<BE name>/@/platform/i86pc/amd64/boot_archive

Another significant difference between the grub.cfg file and the menu.lst file is that you do not edit the grub.cfg file. The menu.lst file supports user-created menu entries and manual changes to global GRUB configuration file settings and variables, in addition to menu entries that are automatically generated by the system. In contrast, the grub.cfg file is administered by using various bootadm subcommands, many of which are new in this release. The various bootadm subcommands enable you to administer most boot loader administration tasks. See Administering the GRUB Configuration by Using the bootadm Command.

Another feature of the grub.cfg file is that it is autogenerated whenever you make changes to the boot loader configuration. The file is also autogenerated during some operations and when certain boot administration commands are used. If necessary, you can manually generate a new grub.cfg file by running the bootadm command with the new generate-menu subcommand. Use this subcommand to create a new grub.cfg file only if the boot configuration becomes corrupted. See How to Manually Regenerate the GRUB Menu.

Note -  The autogeneration mechanism for the grub.cfg file is intended for installed systems only.

    For reference, the GRUB 2 configuration is stored in the following files:

  • grub.cfg – Is the main configuration file that is used by GRUB 2.

  • /pool-name/boot/grub/menu.conf – Is a file that is used by Oracle Solaris to generate the final grub.cfg configuration file.

    The menu.conf file is a separate GRUB meta configuration file that stores the machine-parsable representation of the GRUB 2 configuration.

    Note -  Do not attempt to edit this file.
  • /pool-name/boot/grub/custom.cfg – Is an editable file that resides in the same location as the grub.cfg and menu.conf files. The custom.cfg file is created by the administrator (and not on the system by default). This file is reserved for the purpose of adding more complex constructs (menu entries or other scripting information) to the basic GRUB configuration.

    The custom.cfg file is referenced in the grub.cfg file. If a custom.cfg file exists on the system, the commands or directives that are in that file are then processed by the grub.cfg file. For more information, see Customizing the GRUB Configuration.

x86: GRUB 2 Partition and Device Naming Scheme

If you are familiar with how device naming for GRUB Legacy works, you need to be aware of the differences between the GRUB Legacy naming scheme and the GRUB 2 naming scheme. While GRUB Legacy implements a 0-based naming scheme for partition indexes, GRUB 2 uses a 1-based naming scheme for partition indexes.

The GRUB 2 device naming scheme uses the following format:

(hdX, part-typeY, part-typeZ, ...)

Because partition schemes can be nested, GRUB's device naming scheme has been changed to support arbitrary nesting levels. GRUB accepts either the old-style device naming (“(hd0,1)”) or the new-style device naming that includes the partition scheme name. For example:

(hd0, gpt1)

The previous example refers to the first GPT partition on the first disk.

Note -  Only the GRUB partition numbering has changed, not disk numbering. Disk numbers remain 0-based.

Because GRUB 2 relies on file system UUIDs (or labels) and a built-in search command for automatically locating the proper device or partition name, you are not required to manually specify device names. The following table provides examples of the partition indexes and device names that GRUB uses.

Table 2  GRUB 2 Partition and Device Naming Scheme
Device Name
(hd0, msdos1)
Specifies the first DOS partition on the first disk.
(hd0, gpt2)
Specifies the second GPT partition on the disk.
This is an example of the prototypical partition where the current release would be installed.
(hd0, msdos1, sunpc1)
Specifies the first VTOC slice in the Oracle Solaris partition that is stored in the first DOS partition on the first disk.
This is an example of the prototypical partition where versions of Oracle Solaris prior to this release would be installed.

If you need to determine which partition number refers to a partition that interests you, access the GRUB command-line interpreter by pressing the C key (or Control-C, if you are editing a menu entry). Then, run the ls command to list all of the partitions that GRUB can identify, which is similar to the following figure.

image:Figure of the GRUB 2 command interpreter screen                                                 where information about devices can be                                                 retrieved.

The –l option to the ls command displays more detailed information about each partition, including file system and file system UUID information, which is similar to the following figure.

image:Figure of GRUB 2 command interpreter screen showing                                                 command output displaying devices that GRUB has                                                 identified.

Note -  GRUB counts the drive numbers from zero, regardless of their type and does not distinguish between Integrated Drive Electronics (IDE) and Small Computer Systems Interface (SCSI) devices.

x86: GRUB 2 and GRUB Legacy Task Comparison

Although GRUB 2 shares several characteristics with GRUB Legacy, because GRUB 2 does not use a menu.lst file, many boot administration tasks are performed differently on systems that support GRUB 2. For example, you manage the GRUB menu and perform various boot loader administrative tasks by using new subcommands of the bootadm command.

A new –P pool argument is available for most of the bootadm subcommands. This option enables you to view or make changes to the GRUB menu and boot entries for a particular root pool. If you are running an operating system that supports GRUB Legacy, the –P option might not be available for these bootadm subcommands.

For example, you would list the GRUB menu for a specific root pool, as follows:

# bootadm list-menu -P pool-name

The following table compares some common GRUB 2 tasks and commands to the GRUB Legacy equivalent. For detailed instructions, see the bootadm(1M) man page and Administering the GRUB Configuration by Using the bootadm Command.

Table 3  GRUB 2 Tasks Compared to GRUB Legacy Tasks
Task or Command
GRUB 2 Method
GRUB Legacy Method
List the current boot entries in the GRUB menu.
bootadm list-menu
You can also view individual entries by the entry number or by title. To view an entry by title:
bootadm list-menu entry-title
If the title has spaces, quotation marks must be used to protect the title from being parsed as multiple arguments. For example:
bootadm list-menu `This is a menu entry with a title'
To view an entry by its entry number:
bootadm list-menu –i entry-number
bootadm list-menu
Generate a new GRUB configuration file (grub.cfg) that contains the default boot loader settings and one menu entry for each Oracle Solaris boot environment on each root pool on the system.
bootadm generate-menu
If there is an existing grub.cfg file on the system, use the –f option with the generate-menu subcommand. This syntax destroys the existing GRUB 2 configuration and replaces it with the new configuration.
If you use the –P option to generate a new GRUB 2 configuration file for a specific root pool on the system, note that the grub.cfg file that is generated is stored in the top-level ZFS dataset for that root pool.
Manually edit the menu.lst file to add the new information.
Add a new entry to the GRUB menu.
To add an entry by specifying its entry number:
bootadm add-entry –i entry-number
To add an entry by specifying its title:
bootadm add-entry entry-title
Manually add the entry to the menu.lst file.
Change an entry in the GRUB menu.
To change an entry by specifying its entry number:
bootadm change-entry –i entry-numberkey=value
To change an entry by specifying its title:
bootadm change-entry entry-title key=value
If the title has spaces, quotation marks must be used to protect the title from being parsed as multiple arguments.
This subcommand is used to make changes to an individual boot entry, for example, to specify the Oracle Solaris console device as a kernel argument. If the entry title matches multiple menu entries, only the first entry is modified.
A boot entry can also be changed by editing the GRUB menu at boot time, just as was done in previous releases with a GRUB Legacy entry.
Manually edit the menu.lst file to make persistent changes.
As an alternative, edit the GRUB menu at boot time to make changes to the boot entry that persist just until the next time the system is booted.
Remove an entry from the GRUB menu.
To remove an entry by specifying its entry number:
bootadm remove-entry –i entry-number
To remove an entry by specifying its title:
bootadm remove-entry entry-title
If a title is specified, all of the entries with that title are removed.
Manually remove the entry from the menu.lst file.
Manage the GRUB menu. For example, set the default GRUB menu entry from which to boot.
bootadm set-menu key=value
bootadm set-menu
Add custom menu entries to the GRUB menu, for example, a Linux entry.
Add the entry to the custom.cfg file, making sure to use the proper GRUB 2 configuration file syntax. See Customizing the GRUB Configuration.

Note -  You must create this file first.

Add the information to the menu.lst file after installing Oracle Solaris.
Edit the GRUB menu at boot time to add boot arguments.
1. Interrupt the boot process by using the arrow keys to select the desired menu entry, then type e.
2. Add boot arguments to the end of the $multiboot line for the specified boot entry.
3. Press Control-X to boot from the modified entry. If the system console is on a serial device, F10 might not be properly recognized on a UEFI system. In that case, use Control-X.

Note -  Pressing the Escape key while editing a menu entry returns you to the menu entry list, and all edits are discarded.

1. Interrupt the boot process by typing e.
2. Add the boot arguments to the end of the kernel$ line for the specified boot entry.
3. Press Return, then type b to boot the system.
Install the boot loader program.
bootadm install-bootloader
This command installs the boot loader on all of the devices in a mirrored root pool automatically.
installgrub for x86 based systems and installboot for SPARC based systems.
Create boot partitions for either UEFI or BIOS firmware.
Use the new –B option of the zpool create command to automatically create the firmware-appropriate boot partition, and the ZFS data partition into which the new ZFS pool will be stored, at the same time.
Attaching a disk to a root pool automatically creates the proper boot partitions and installs the boot loader on that disk. See Chapter 6, Managing the ZFS Root Pool in Managing ZFS File Systems in Oracle Solaris 11.3.
GRUB Legacy supports systems with BIOS firmware only and therefore does not require a separate boot partition.