Understanding the New SPARC Boot Architecture

The boot processes on the SPARC platform have been redesigned and improved to increase commonality with the x86 boot experience. The new 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:

• Commonality in boot processes on the SPARC and x86 platforms

• Commonality in the network boot experience

• Boot architecture flexibility that enables booting a system from different file system types more easily

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 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 any other components that are required to boot an instance of the Oracle Solaris OS. or an installation miniroot.

   The SPARC boot archive is identical to an 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 Oracle Solaris OS is initialized and a minimal root file system is mounted on the ramdisk that was constructed from the boot archive. In some environments, such as an installation, the ramdisk is used as the root (/) file system and remains mounted.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 - The Oracle Solaris 10 version of the root_archive tool is not compatible with versions of the tool that are included in other Oracle Solaris releases. Therefore, ramdisk manipulation should only be performed on a system that is running the same 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 Oracle Solaris OS, you need to boot 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 or DVD without having to reboot the system. Note that the boot archive contains the entire miniroot. The construction of the installation DVD 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

For Oracle Solaris 10 9/10, the minimum memory requirement to install a SPARC based system is 384 Mbytes of memory. This amount of memory enables a text-based installation only. For x86 based systems, the minimum memory requirement is 768 Mbytes of memory. Also, to run the installation GUI program a minimum of 768 Mbytes of memory is required.

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 Kernels

On SPARC based systems, when you boot the system from the ok prompt, the default boot device is automatically selected. An alternate boot device can be specified by changing the NVRAM variable for the boot-device. You can also specify an alternate boot device or an alternate kernel (boot file) from the command line at boot time. See SPARC: How to Boot a Kernel Other Than the Default Kernel.