Understanding the New Solaris SPARC Boot Architecture
The boot processes on the Solaris SPARC platform have been redesigned and improved
to increase commonality with the Solaris x86 boot experience. The new Solaris 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 Solaris 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:
Open Boot PROM (OBP) phase
The OBP phase of the boot process on the Solaris 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.
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.
Ramdisk phase
The ramdisk is a boot archive that is comprised of kernel modules or an installation miniroot.
The Solaris SPARC boot archive is identical to a Solaris 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.
Kernel phase
The kernel phase is the final stage of the boot process. During this phase, the Solaris OS is initialized and a minimal root file system is mounted on the ramdisk that was constructed from the boot archive. 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 Solaris Express version of the root_archive tool is not compatible with the Solaris
10 version of the tool. Therefore, ramdisk manipulation should only be performed on
a system that is running the same Solaris 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 Solaris OS, you need to boot the
miniroot 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 without having to reboot the system. Note that the boot
archive contains the entire miniroot. The construction of the installation CD 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
If you are running a Solaris Express Community release or an OpenSolaris release, the
minimum memory requirements to install a system is 512 Mbytes of memory.
For the Solaris 10 release, the minimum memory requirements to install a system have
been increased from 256 Mbytes of memory to minimum of 384 Mbytes of
memory. This amount of memory enables a text-based installation only. To
run the installation GUI program requires a minimum of 768 Mbytes of memory.
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:
The boot server transfers a bootstrap in the form of a boot archive to the target system.
The target system unpacks the boot archive in a ramdisk.
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 Solaris Kernels
On SPARC based systems, when you type boot at the ok prompt,
the default boot device is automatically selected. An alternate boot device can be
specified by changing the boot-device NVRAM variable. You can also specify an alternate
boot device or alternate kernel (boot file) from the command line at boot
time. See SPARC: How to Boot a Solaris Kernel Other Than the Default Kernel.
