Go to main content

Booting and Shutting Down Oracle® Solaris 11.3 Systems

Exit Print View

Updated: October 2017

Overview of the Oracle Solaris Boot Architecture

    The Oracle Solaris boot architecture includes the following fundamental characteristics:

  • Uses a boot archive.

    The boot archive contains a file system image that is mounted by using an in-memory disk. The image is self-describing, specifically containing a file system reader in the boot block (or GRUB boot loader in the case of x86 platforms). On SPARC platforms, the file system reader mounts and opens the RAM disk image, then reads and executes the kernel that is contained within it. By default, this kernel is in /platform/`uname -m'/kernel/unix. On x86 platforms, the GRUB boot loader loads the kernel file and the boot archive into memory, then transfers control to the kernel. The default kernel on x86 platforms is /platform/i86pc/kernel/amd64/unix.

    Note -  When booting a SPARC based system from disk, the OBP firmware reads the boot blocks from the partition that is specified as the boot device. This stand-alone booter usually contains a file reader that is capable of reading the Oracle Solaris boot archive. See boot(1M).

    If you are booting from a ZFS root file system, the path names of both the archive and the kernel file are resolved in the root file system (dataset) that is selected for booting.

  • Uses a boot administration interface to maintain the Oracle Solaris boot archives and to manage GRUB configuration and the GRUB menu on x86 platforms.

    The bootadm command handles the details of boot archive update and verification. During an installation or upgrade, the bootadm command creates an initial boot archive. During the process of a normal system shutdown, the shutdown process compares the boot archive's contents with the root file system. If there have been updates to the system such as drivers or configuration files, the boot archive is rebuilt to include these changes so that upon reboot, the boot archive and root file system are synchronized. You can use the bootadm command to manually update the boot archive.

    On x86 based systems, the grub.cfg file and the x86 boot loader are administered with the bootadm command. In this release, the bootadm commands has been modified, and some new subcommands have been added. to enable you to perform most of the administrative tasks that were previously done by editing the menu.lst file. These tasks include managing the GRUB menu, setting kernel arguments for a specific boot entry, and managing the boot loader. See Administering the GRUB Configuration by Using the bootadm Command for instructions.

    Note -  Some bootadm command options do not apply to SPARC platforms.

    For more information, see the bootadm(1M) and boot(1M) man pages.

  • Uses a ramdisk image as the root file system during installation.

    This process is the same on SPARC and x86 platforms. The ramdisk image is derived from the boot archive and then transferred to the system from the boot device.

    Note -  On SPARC platforms, the OpenBoot PROM continues to be used to access a system's boot device and to transfer the boot archive to the system's memory.

    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 access frequently needed installation components from removable media. The ramdisk file system type can be a High Sierra File System (HSFS) or UFS.

  • Supports booting from GPT labeled disks.

    Oracle Solaris includes support for booting from GPT labeled disks. Booting from a GPT labeled disk is slightly different from booting from a disk that uses the MSDOS partitioning scheme. Installing Oracle Solaris 11.3 on an x86 or SPARC based system with GPT-aware firmware applies a GPT disk label on the root pool disk that uses the entire disk in most cases. See SPARC: GPT Labeled Disk Support in Oracle Solaris 11.3 Release Notes for more information about applying GPT-aware firmware on supported SPARC based systems. Otherwise, installing Oracle Solaris 11.3 on a SPARC based system applies an SMI (VTOC) label to the root pool disk with a single slice 0.

    On x86 platforms, the introduction of GRUB 2 enables this support. On systems with BIOS firmware, the MBR is still the first chunk of code that the firmware loads to initiate the boot process. There is no longer a VTOC on GPT labeled disks, only discrete partitions. GRUB now has direct support for reading and interpreting the GPT partitioning scheme, which enables the boot loader to locate the Oracle Solaris kernel and the boot archive inside the root pool that is hosted in a ZFS GPT partition.

    On systems with UEFI firmware, the key difference is that the firmware loads the boot application from the (FAT-based) EFI System Partition. After GRUB is loaded on a UEFI system, it performs similar tasks to the BIOS-targeted GRUB.