4. Solaris (Intel Platform Edition) Bootstraps

The previous chapters have provided an overview of Open Firmware, the Solaris booting architecture, and the x86 BIOS, booting, and configuration architectures. With this background, it is now possible to discuss the Solaris (Intel Platform Edition) realmode environment.

The first and most basic component of the Solaris (Intel Platform Edition) realmode environment is the bootstrap, a sequence of programs that, starting from the BIOS handoff, causes the loading of a specified operating system.

4.1 Design Goals

The Solaris (Intel Platform Edition) bootstraps should be able to boot an operating system from any disk, CD, or network adapter, and be able to do so independently of whether or not the BIOS supports booting or even reading from those devices.

The Solaris (Intel Platform Edition) bootstraps should be able to automatically boot a designated operating system from a default device, or to permit a user to manually intervene and request the booting of an arbitrary file from an arbitrary device. They should also support the ability to maintain multiple operating systems on a machine (for example, Windows, NT, or Linux) and to boot any of them.

The Solaris (Intel Platform Edition) booting mechanisms should be compatible with and exploit all available BIOS mechanisms.

The Solaris (Intel Platform Edition) booting mechanisms should provide Open Firmware-like services to the client operating system, and all information that the OS needs to use the machine.

4.2 First-Stage Bootstrap

The bootstrap process is somewhat arbitrarily divided into two phases: the first stage and the second stage. The second-stage bootstrap is a large, general, and complex program that is capable of loading a kernel from a wide range of devices. The first-stage bootstrap is a sequence of simpler programs to get the second-stage bootstrap loaded into memory.

It is also worth distinguishing the initial boot device (from which the first-stage bootstrap will be loaded, and which must be supported by BIOS) from the eventual boot device (which need not be supported by BIOS, and from which the operating system will be loaded).

As described in the previous chapter, the BIOS will load 512 bytes from the beginning of some boot device into memory and transfer control to it. This initiates the first-stage bootstrap process. The code in that 512 bytes locates and reads a slightly larger program. This program, in turn, locates and reads in the second-stage bootstrap.

At present, the only supported initial boot devices are hard disks and diskettes. The first-stage bootstrap process works differently for each of these devices (as it likely will for future initial boot devices like CDs and network interfaces). The primary differences between first-stage booting from a disk and a diskette are:

Hard disks involve FDISK partitioning and VTOC slicing, whereas diskettes are unpartitioned.
The second-stage bootstrap on a hard disk is stored in a UFS file system, whereas the second-stage bootstrap on a diskette is stored in a FAT12 DOS file system.

In Solaris the structure of the FDISK table is defined by the include file /usr/include/sys/dktp/fdisk.h, and the structure of the VTOC is defined by the include file /usr/include/sys/vtoc.h (you can view these files now by entering the following "file" links in your browser's location field: file:/usr/include/sys/dktp/fdisk.h or file:/usr/include/sys/vtoc.h).

4.2.1 First-Stage Booting From a Disk

The BIOS reads a standard master boot record (MBR), which in turn reads the first sector (partition boot record (PBR)) from the active boot partition. The PBR on a Solaris partition contains a 512-byte program called pboot.

This program consults the FDISK table to find out where the Solaris partition starts, seeks to the third sector in the first cylinder (immediately past the Solaris VTOC), and reads in a large program installed there, called "bootblock." All of the required disk I/O is performed by using BIOS INT13 block I/O reads.

MBR, FDISK Table, PBR, VTOC, Solaris bootblock

Figure 4-1 Physical Bootstrap Layout on Disk

The bootblock program is large enough to talk to the user and interpret file systems. The bootblock program does the following:

It consults the FDISK table and sees if it describes more than one partition.
If there are multiple partitions, it displays a list of available partitions, asks the user to choose which one to boot from, and starts a timeout clock.
If the user selects some partition other than the Solaris partition, it reads in the partition boot record from that partition and branches to it, as if that had been the active partition.
If the timeout interval expires or the user selects the Solaris partition, the bootblock program proceeds to load the second-stage bootstrap into memory.
a. It reads the VTOC for the Solaris partition and searches it to find the root slice.
b. It interprets the root slice as a UFS file system and searches for the second-stage bootstrap (in a file named /platform/i86pc/boot/solaris/boot.bin).
c. The second-stage bootstrap is loaded into memory, and control is transferred to it.

The PBR program (pboot) and the large, first-stage bootstrap (bootblk) can be found in the directory /usr/lib/fs/ufs, and are installed onto a newly formatted disk by the script /usr/sbin/installboot.

4.2.2 First-Stage Booting From a Diskette

The process for booting from a diskette differs from the process for booting from a hard disk because bootable diskettes are written in DOS (FAT12) format rather than as Solaris file systems. They are not divided into logical subdisks by either FDISK tables or Solaris VTOC.

The BIOS reads 512 bytes from the first sector on the diskette. In Solaris, these first 512 bytes come from a program called mdboot. The first 512 bytes of this program load in the second 512 bytes (which are always found in cluster 2/sector 32), and then locate the larger program strap.com (which is always a contiguous file beginning in cluster 3), load it into memory, and transfer control to it.

The strap.com program knows how to interpret a FAT12 file system and looks for a configuration file on the diskette (strap.rc). This file contains instructions on what load module should be loaded, and where in memory. The default solarisstrap.rc instructs strap.com to load the program solarisboot.bin from the diskette. This is the same second-stage bootstrap program that the bootblock program loads from a hard disk.

Figure 4-2 Physical Diskette Bootstrap Layout

The mdboot and strap.com programs and the program that installs them onto a bootable diskette (a special PCFS newfs command) are not distributed with the Solaris environment but only exist as internal build tools. In essence, however, the process:

Copies the first 512 bytes of the mdboot program onto the first sector of the diskette
Copies the remainder of the mdboot program into normal data blocks starting with cluster 2
Copies the strap.com program to the diskette, as a normal file in contiguous clusters (starting with cluster 3)

4.3 Second-Stage Bootstrap

The whole purpose of the various first-stage bootstrap processes is to get the second-stage bootstrap loaded into memory. The second-stage bootstrap is a large and versatile program that is capable of loading and executing files stored on a wide range of different devices and file system types. Its primary purpose is to load a selected kernel from a selected root device. On x86 based systems, the second-stage bootstrap serves another very important purpose: it provides (for the kernel and other clients) the services that are performed by Open Firmware on SPARC based systems.

It is worthwhile to distinguish the boot device from the root device. The boot device is the device from which the second-stage bootstrap, Configuration Assistant, and realmode device drivers are loaded. The root device is the device from which the desired operating system is loaded. There are many situations where these are not the same device, so it is important to be mindful of the difference.

The configuration analysis and device methods are provided by other components of the Solaris (Intel Platform Edition) realmode environment (the Configuration Assistant and the realmode drivers), but the second-stage bootstrap loads and provides services for those programs. The second-stage bootstrap depends only on the hardware BIOS, and on extensions to that BIOS that are provided by the realmode drivers.

There are several features of the second-stage bootstrap that warrant description:

An interactive command interpreter, and the control scripts that are written in the interactive command language
The ability to interpret multiple file system formats (UFS, PCFS, HSFS), and the ability to use NFS to access remote file systems
The ability to interpret the EXE and ELF formats and to load such programs into memory
A logical (composite) file system that facilitates the handling of removable volumes and enables one file system to be superimposed on another
A set of Open Firmware-like services that are provided to a newly loaded kernel
A limited DOS emulation provided to the Configuration Assistant (and possibly to other realmode clients)

Figure 4-3 Second-Stage Bootstrap Components and Interfaces

4.3.1 Boot Shell

Because of the wide diversity and rapid evolution of x86 platforms, the startup procedures in the second-stage bootstrap are not hard-coded to allow easier maintenance and updating. Instead, a simple (shell-like) scripting language is used, and the system startup process is implemented by scripts written in that language. These scripts are easy to understand and update.

The scripting language is documented in boot(1M), but a summary of its features is presented here. The language includes general programming and scripting features, augmented by a set of extensions for traversing and manipulating a device information tree.

The general programming features include several commands and constructs from the Bourne shell:

Nestable if, elseif, else, endif statements
Simple variables and set, unset, setenv, and printenvcommands
C-style arithmetic/logical expressions involving constants and shell variables, tand a few built-in functions for string comparison
The echo and read commands, and a readt command twith a timeout
A stackable source command for running one script from within tanother script
A run command for loading and executing programs
A map command to set up new mappings in the composite file system
A mount command to identify the root file system from which booting should proceed

There are some additional functions for traversing and building a device information tree:

A mknod command to create new nodes
The cd and pwd commands to change and display position in the tree
An ls command to display the nodes at any level in the tree
The getprop and setprop commands to query and set properties associated with a node
The claim and release commands for using a new generalized resource manager

4.3.2 Boot Control Scripts

Almost every aspect of the booting process is controlled by a series of scripts. The primary boot control script is expected to be on the boot device (the device from which the second-stage bootstrap was loaded) in a file named boot.rc. All subsequent processing is controlled by this script.

In practice the primary boot control script does not change much, and its primary job is to run other scripts. It:

Sources the file bootenv.rc, from the boot device, to get standard information (for example, default boot path, keyboard language, input device) that, on an Open Firmware machine, would have been found in EEPROM
Sources the file bootargs.rc (which is usually empty), from the boot device, to get any parameters that may have been passed into this boot
Runs the Configuration Assistant, from the boot device, to build a device information tree, loads any necessary realmode device drivers, and selects a root device (the device from which Solaris will be loaded)
Looks on the specified root device for a boot control script (/etc/bootrc) that will control the loading of the Solaris kernel from that file system

Device	File	Format	Purpose
boot	/solaris/boot.bin	exe	second-stage bootstrap
boot	/solaris.map	script	composite fs mappings
boot	/solaris/boot.rc	script	initial control script
boot	/solaris/bootenv.rc	script	options and defaults
boot	/solaris/bootargs.rc	script	reboot parameters
boot	/solaris/bootconf.exe	exe	Configuration Assistant
root	/etc/bootrc	script	control script to load kernel

Figure 4-4 Files in Second-Stage Booting

In principle the /etc/bootrc script is specific to the system being loaded. In most cases, however, this script:

Looks at the passed boot arguments
Announces that a specified kernel will be automatically booted unless the user presses a key within the next few seconds
Loads the specified kernel if the timeout expires
Prints out a prompt and allows the user to enter (the full command language) directly if the user intervenes, or if the specified kernel cannot be loaded

4.3.3 File System Interpretation

The scripts to be executed and files to be loaded can be found on diskettes (in DOS FAT12 format), on hard disks (with FDISK partitions, Solaris VTOC, and UFS file systems), or on CDs (in High Sierra/RockRidge format). If the system is being booted over a network, the control scripts and programs to be loaded will be accessed via the NFS protocol.

The file system implementations are used by the:

Bootstrap, to access control scripts (for example, boot.rc, bootargs.rc, and bootenv.rc)
Bootstrap, to load programs (for example, the Configuration Assistant and realmode drivers)
DOS emulation, to implement the file access functions
Boot operations, to open and read files for the initializing kernel

The second-stage bootstrap understands all necessary file system formats and protocols, and it is able to access files in any combination of these file systems. To do this it must be able to read from the disk (or communicate over the network). All disk access is performed with BIOS INT13 disk I/O functions (perhaps augmented by realmode device drivers). All network I/O is performed with BIOS INTFB packet transport functions (entirely provided by realmode device drivers).

4.3.4 Program Loader

The second-stage bootstrap understands two load module formats: EXE and ELF. The .exe support is used primarily to load the Configuration Assistant and realmode device drivers from the boot device. It can also be used to load arbitrary realmode programs (or any DOS program that works under the emulation).

The ELF support is not as general. While the kernel and its runtime loader are ELF load modules, and the second-stage bootstrap is capable of loading and transferring control to them, the environment in which they are loaded may not be one in which an arbitrary ELF (even for a standalone program) could run.

4.3.5 Composite File System

The "composite file system" provides several valuable features that can be used in combination with any of the other standard file systems. These features, which are all implemented in the second-stage bootstrap, have no analog on Open Firmware machines, but were necessitated by two problems with the x86 architecture:

The PC firmware is not capable of booting from any devices, so it is necessary to put some of the booting software on a diskette.
Platforms and devices come out continuously, and supporting them requires delivering device drivers on some media other than the formal release CD.

Most of the features of the composite file system are designed to make it easy to augment the standard release CD with additional files distributed on one or more diskettes. These features include:

Path Mapping

One problem with storing updated Solaris files on a DOS diskette is the fact that DOS file systems are limited to 8.3 naming (an eight-character name and a three-character suffix, limited to uppercase letters). You cannot, for example, create a file named "name_to_major."
The composite file system includes a path mapping mechanism that maps path names specified by client programs into path names for files to be actually opened. This mapping is controlled by a configuration file (solaris.map) on the boot device. An entry like:
                /etc/name_to_major      /nam2maj.txt
would cause an open of /etc/name_to_major to be translated into an open of nam2maj.txt.
This mapping capability can also be used to relocate directory trees. On a hard disk, for instance, the realmode software lives under the directory /platform/i86pc/boot, whereas it is kept in the root directory of a boot diskette. Adding a solaris.map file to the root directory of the diskette that contains the entry:
                /platform/i86pc/boot    /
will automatically redirect all references to /platform/i86pc/boot to the root directory, and the client software will no longer be able to tell the difference between the directory layouts on the hard disk and on the diskette.

File Overlaying

To support the delivery of new device drivers on one or more diskettes and to make it appear that they are actually on the CD, the composite file system also has the ability to overlay files from one file system on top of another file system. This is controlled by the same solaris.map mechanism that is used for path mapping.
A solaris.map entry can be used to make files on a diskette appear to be on the CD. If the file already exists on the CD, the file on the diskette will appear to replace it. It is also possible to make a file on a diskette appear to have been appended to a file on the CD.
If a solaris.map entry specifies an optional "a" flag (/etc/driver_classes /classes.txt a), a program that attempts to open and read the file /etc/driver_classes will read all of the text from the file on the CD, after which it will read all of the text from /classes.txt on the diskette.

Compressed Files

Another problem with diskettes is that they are small. By compressing files, it is possible to deliver many more drivers on a small number of diskettes. Rather than requiring the programs that open and read files to support compression, the composite file system provides a transparent detection and decompression facility, one that can be used on any device or file system.
Any file can be compressed (with the compress command), and this will be automatically detected at open time (based on the magic number). Subsequent read calls will transparently decompress the data (in place) before delivering it to the client's input buffer.

Symbolic Links

DOS file systems do not support links (either hard or symbolic). If the same data is needed in multiple places, replicating that data consumes valuable space on the diskette and complicates software maintenance.
The composite file system supports its own symbolic link files, which are detected at open time (based on a magic number), and automatically followed.

PCFS Volume/Drive Specifications

Dealing with multiple diskettes is required because:

After the bootstraps and the Configuration Assistant have been put on a diskette, there may only be room for a dozen or so drivers. Additional drivers will have to go on additional diskettes.
Some supplementary diskettes may be produced by OEMs or IHVs, and be used in conjunction with a standard Solaris (Intel Platform Edition) boot diskette.
Large localizations (for example, Japanese) may require the delivery of fonts on additional diskettes.
This means that it may be necessary for the user to change diskettes occasionally to find a required file, and for the software to prompt the user to change diskettes and to verify that the proper diskette has been inserted.
Rather than change all the programs that open files to support multiple diskettes, this support is built into the composite file system. A file name can be preceded with a drive specifier (for example, A:solarisboot.bin) or a volume specifier (for example, [ITU4.1J]:fontskanji). If the specified volume is not currently inserted, the user is automatically prompted to insert the required volume, and the proper volume ID will be verified.

A RAM-based Pseudo File System

The composite file system also includes a RAM-based pseudo file system, where files can be created, and subsequently opened and read back. There are a few situations where a RAMFS comes in handy:

It may be necessary to create a new configuration file on the fly, by combining information from the CD with information on the diskette.
It may be desirable to cache a driver from an Install-Time Update diskette the first time it is seen so the user isn't asked to reinsert the diskette later when the kernel finally tries to open it. The solaris.map mechanism can then be used to make the files in the RAMFS appear to be on the CD.

In using these features, it is important to remember that they are all implemented in the second-stage bootstrap and are only available to programs that use the second-stage bootstrap for file access. The Configuration Assistant uses the second-stage bootstrap (through DOS emulation) to access files. The newly booted kernel uses the second-stage bootstrap (through the boot operations) to access files, but only until it quiesces the bootstrap and takes over the machine. Once this happens, the composite file system features are no longer in effect.

4.3.6 Boot Operations

As described in Chapter 2, Open Firmware provides a variety of services for the loaded client software. A basic Solaris kernel uses these services to read configuration files and to load additional drivers and services, until it is complete enough to assume control of the machine.

Virtually none of these services are provided by standard PC BIOS. The second-stage bootstrap bridges the gap by providing the loaded kernel with call vectors to access Open Firmware-style services. For more information on Open Firmware, see the Open Firmware home page. To summarize here, the services include:

Memory management and allocation (get a list of how memory is allocated, allocate and free virtual memory)
File access and I/O (mount file system, open, close read, seek, and get directory entries)
Device information tree access (traversal, node creation, get and set properties)
Console I/O (printf, putchar)
Program loading
Quiescing the bootstrap and letting the client OS take over

These entry points are defined (for Solaris) by the include file /usr/include/sys/bootconf.h (to view this file, type file:/usr/include/sys/bootconf.h in your browser's location field).

There are a few other PROM diagnostic services that are supposed to continue to be available even after the bootstrap has been quiesced. These entry points are defined (for Solaris) by the include file /usr/include/sys/promif.h (to view this file, type file:/usr/include/sys/promif.h in your browser's location field).

In addition to these standard services, there are also a set of specialized x86 services to permit kernel initialization code to directly make BIOS calls (for example, to access EISA configuration data or Power Management services).

4.3.7 DOS Emulation

The Device Configuration Assistant (discussed in the next chapter) needs a variety of services in order to read its configuration files and load realmode drivers. While these services could have been obtained from the boot operations vector (described in the previous section), it was better to write the Configuration Assistant to standard DOS interfaces.

The second-stage bootstrap provides an emulation of a large number of INT21 DOS services for loaded EXEs. While this is not intended as a general purpose DOS emulator, it is adequate to run a fair number of interesting programs and debuggers.

The supported functions include:

Terminal input and output
File open/close/read/write/seek/ioctl
File creation, deletion, and renaming
Getting and setting file attributes, dates, and times
Parsing file names and enumerating wildcards
Getting and setting the current working directory
Allocating, freeing, and resizing memory
Getting the current time and date
Getting and setting interrupt vectors

4.4 Standard Booting Scenarios

4.4.1 Booting From an Installed Disk

In a normal Solaris bootstrap from an installed disk:

The Solaris partition is made active.
The BIOS loads the master boot record, which in turn loads the Solaris partition boot record.
The Solaris PBR (pboot) reads in the larger bootblk program, which is installed after the VTOC in the (reserved) first cylinder of the Solaris partition.
The bootblk program finds the root UFS slice in the Solaris partition and searches that file system to find the second-stage bootstrap (boot.bin).
The second-stage bootstrap loads and runs the Device Configuration Assistant (described in the next chapter) from the same UFS slice, after which a root device has been selected (the disk), a realmode device driver for the disk controller has been made available, and the boot-path property has been set to the physical device information tree path to the root disk.
The second-stage bootstrap mounts the selected root file system (using the now available realmode device driver) and reads the file /etc/bootrc from the selected root file system.
The commands in /etc/bootrc direct the second-stage bootstrap to load the selected kernel (and runtime loader) from the root disk and transfer control to it.
The newly loaded kernel uses the boot operations vector to make calls back into the second-stage bootstrap to access the devinfo tree and properties, and to open and read additional files from the root file system on the disk.
When the kernel has loaded all necessary drivers and service modules, it makes a call into the second-stage bootstrap telling it to "quiesce" itself, and the Solaris device drivers take over.

4.4.2 Booting From an Installation CD

Because booting directly from a CD isn't yet available (see Section 4.5.2), a diskette is used to boot from a Solaris installation CD.

The BIOS loads the first sector from the boot diskette, which loads the rest of the mdboot program from cluster 2 of the DOS file system on the diskette.
The mdboot program reads the larger strap.com program in from cluster 3 of the DOS file system on the diskette.
The strap.com program reads the file solarisstrap.rc from the DOS file system on the diskette, which in turn instructs it to load the second-stage bootstrap from the DOS file system on the diskette.
The second-stage bootstrap loads and runs the Device Configuration Assistant (described in the next chapter) from the diskette, after which a root device has been selected (the CD), a realmode device driver for the associated disk controller has been made available, and the boot-path property has been set to the physical device information tree path to the CD.
The second-stage bootstrap mounts the selected root file system (using the now available realmode device driver) and reads the file /etc/bootrc from the selected root file system.
The commands in /etc/bootrc direct the second-stage bootstrap to load the selected kernel (and runtime loader) from the CD and transfer control to it.
The newly loaded kernel uses the boot operations vector to make calls back into the second-stage bootstrap to access the devinfo tree and properties, and to open and read additional files from the root file system on the CD.
When the kernel has loaded all necessary drivers and service modules, it makes a call into the second-stage bootstrap telling it to "quiesce" itself, and the Solaris device drivers take over.

4.4.3 Booting Over the Network

Because booting directly from a network adapter isn't yet available (see Section 4.5.1), a diskette is used to boot Solaris from a network server.

The BIOS loads the first sector from the boot diskette, which loads the rest of the mdboot program from cluster 2 of the DOS file system on the diskette.
The mdboot program reads the larger strap.com program in from cluster 3 of the DOS file system on the diskette.
The strap.com program reads the file solarisstrap.rc from the DOS file system on the diskette, which in turn instructs it to load the second-stage bootstrap from the DOS file system on the diskette.
The second-stage bootstrap loads and runs the Device Configuration Assistant (described in the next chapter) from the diskette, after which a root device has been selected (the network adapter), and a realmode device driver for that network adapter has been made available.
The second-stage bootstrap recognizes that the root device is a network interface and:
    a. Uses RARP to find out the IP address associated with this machine/adapter.
    b. Uses BOOTPARAMS to find out what root server is associated with this machine/adapter and to get the path to the root file system on that server.
    c. Sets the boot-path property to refer to the reported host and path.
The second-stage bootstrap uses NFS to mount the selected root file system (over the now available network adapter device driver).
For an installation boot, the specified root file system will be a copy of the root slice on an installation CD. For a normal diskless client, the root file system will be a pre-configured standard Solaris root file system.
The second-stage bootstrap finds and reads the file /etc/bootrc from the NFS root file system.
The commands in /etc/bootrc direct the second-stage bootstrap to load the selected kernel (and runtime loader) from the CD and transfer control to it.
The newly loaded kernel uses the boot operations vector to make calls back into the second-stage bootstrap to access the devinfo tree and properties, and to open and read additional files from the root file system over NFS.
When the kernel has loaded all necessary drivers and service modules, it makes a call into the second-stage bootstrap telling it to "quiesce" itself, and the Solaris device drivers and protocol stack take over.

4.5 Future Booting Scenarios

The mechanisms and scenarios discussed above are all in everyday use for normal Solaris systems. There has also been considerable thought given to how other booting scenarios could be supported:

Booting directly from a network adapter (without a boot diskette)
Booting directly from a CD (without a boot diskette)
Booting from a non-bootable device

This section lays out the thinking that has gone into these scenarios, the issues that have been recognized, and how we believe these features will be implemented.

4.5.1 Direct Booting From a Network Adapter

Many network adapters are available with RPL, BOOTP, or DHCP boot ROMs. All of these protocols are capable of fetching and loading large programs, making it possible for the ROM to directly load boot.bin (with no first-stage bootstrap required beyond the ROM). This has been implemented (and worked on Solaris 2.1 for x86).

The problem is that the second-stage bootstrap needs to have BIOS (or emulated BIOS) support for the root device so that it can load additional components over NFS. Unfortunately, very few network adapter ROMs provide interfaces for packet services. They are capable of loading boot.bin, but without a properly configured driver for the active network adapter, the loaded second-stage bootstrap will be unable to do any further network I/O.

Initially we tried binding network adapter drivers into the downloaded second-stage bootstrap. This required the boot servers to know what types of network adapters were on each host and how they were configured, and to assemble an appropriate bootstrap/driver pair on demand. This approach proved complex to develop, administer, and support, and it was ultimately abandoned in favor of the boot diskette-based model described in the previous section.

It appears that the emergence of Network Computers, and NetPCs, is producing a new generation of network adapter ROMs that will provide packet services, via a standard BIOS interface, for the loaded client software. Once these are available, it should be relatively straightforward to implement direct network booting without the need for a boot diskette.

4.5.2 Direct Booting From a CD

Historically the boot ROMs on SCSI host bus adapters have refused to attempt to boot from CD-ROM drives. Now most motherboard disk controllers are capable of supporting CD-ROM drives, and all new machines have CD-ROM drives, and most major software is distributed on CDs. BIOS developers have recognized the need to be able to boot directly from a CD, a new standard (El Torito) has been proposed for bootable CDs, and the BIOS on newer disk controllers now recognizes and is willing to boot from one of these devices.

We have built El Torito format Solaris CDs, and run through the entire first- and second-stage bootstrap processes. The only problem with booting from an El Torito format CD is that we still need a realmode driver for the associated disk controller (see Chapter 6). The BIOS provides all of the INT13 block I/O services that we need, but it hides the type of the disk controller to which the CD-ROM drive is attached. If we don't know what disk controller the CD-ROM drive is connected to, we cannot put the physical path to that device in the boot-path property, and the Solaris kernel will not be able to directly open that device for its own use. A realmode driver is needed to generate the required physical path.

4.5.3 Fast Booting From a Non-Bootable Device

Early in the chapter, we made a distinction between the device from which the first- and second-stage bootstraps were loaded and the device from which the client operating system would be loaded. This section describes how a diskette can be used as the initial boot device, and then how Solaris can be loaded from a non-bootable CD or network interface. Booting through a diskette may be acceptable when a system is to be installed, but it is a very slow and cumbersome process if the system is to be regularly booted from a non-bootable device.

The files that are placed on a diskette can (with minimal changes) also be placed on a hard disk partition. The second-stage bootstrap on that partition can be configured (through the bootenv.rc file) to automatically load a specified file from a specified device. The sequence of operations in this case is a combination of the hard disk and diskette booting sequences:

A special boot partition (type 190) is created, initialized with a DOS FAT12 file system with essentially the same contents as a bootable diskette, and made the active partition.
The BIOS will load the master boot record, which will load the partition boot record from the booting partition.
The partition boot record contains a modified version of the mdboot program that is used on diskettes. This program, like the diskette version, finds and loads the larger strap.com from a known location (cluster 3) in the file system.
The strap.com program reads solarisstrap.rc , and following those instructions loads and transfers control to solarisboot.bin.

From this point the booting process continues exactly as it does from a diskette, but the boot control files and programs are all read from the boot partition on the hard disk.

Solaris (Intel Platform Edition) Realmode Environment

Contents