Bootstrapping is the process of loading and executing a standalone program. For the purpose of this discussion, bootstrapping means the process of loading and executing the bootable operating system. Typically, the standalone program is the operating system kernel (see kernel
(1M)), but any standalone program can be booted instead. On a SPARC-based system, the diagnostic monitor for a machine is a good example of a standalone program other than the operating system that can be booted.
If the standalone is identified as a dynamically-linked executable, boot
will load the interpreter (linker/loader) as indicated by the executable format and then transfer control to the interpreter. If the standalone is statically-linked, it will jump directly to the standalone.
Once the kernel is loaded, it starts the UNIX system, mounts the necessary file systems (see vfstab
(4)), and runs /sbin/init
to bring the system to the "initdefault" state specified in /etc/inittab
. See inittab
SPARC Bootstrap Procedure
On SPARC based systems, the bootstrap procedure on most machines consists of the following basic phases.
After the machine is turned on, the system firmware (in PROM) executes power-on self-test (POST). The form and scope of these tests depends on the version of the firmware in your system.
After the tests have been completed successfully, the firmware attempts to autoboot if the appropriate flag has been set in the non-volatile storage area used by the firmware. The name of the file to load, and the device to load it from can also be manipulated.
These flags and names can be set using the eeprom
(1M) command from the shell, or by using PROM
commands from the ok
prompt after the system has been halted.
The second level program is either a filesystem-specific boot block (when booting from a disk), or inetboot
(when booting across the network).
Network booting occurs in two steps: the client first obtains an IP address and any other parameters necessary to permit it to load the second-stage booter. The second-stage booter in turn loads the boot archive from the boot device.
An IP address can be obtained in one of three ways: RARP, DHCP, or manual configuration, depending on the functions available in and configuration of the PROM. Machines of the sun4u
kernel architectures have DHCP-capable PROMs.
The boot command syntax for specifying the two methods of network booting are:
without a rarp
specifier, invokes the default method for network booting over the network interface for which net
is an alias.
The sequence of events for network booting using RARP/bootparams
is described in the following paragraphs. The sequence for DHCP follows the RARP/ bootparams
When booting over the network using RARP/bootparams
, the PROM begins by broadcasting a reverse ARP request until it receives a reply. When a reply is received, the PROM then broadcasts a TFTP request to fetch the first block of inetboot
. Subsequent requests will be sent to the server that initially answered the first block request. After loading, inetboot
will also use reverse ARP to fetch its IP address, then broadcast bootparams
RPC calls (see bootparams
(4)) to locate configuration information and its root file system. inetboot
then loads the boot archive by means of NFS and transfers control to that archive.
When booting over the network using DHCP, the PROM broadcasts the hardware address and kernel architecture and requests an IP address, boot parameters, and network configuration information. After a DHCP server responds and is selected (from among potentially multiple servers), that server sends to the client an IP address and all other information needed to boot the client. After receipt of this information, the client PROM examines the name of the file to be loaded, and will behave in one of two ways, depending on whether the file's name appears to be an HTTP URL. If it does not, the PROM downloads inetboot
, loads that file into memory, and executes it. inetboot
loads the boot archive, which takes over the machine and releases inetboot
. Startup scripts then initiate the DHCP agent (see dhcpagent
(1M)), which implements further DHCP activities.
iSCSI boot is currently supported only on x86. The host being booted must be equipped with NIC(s) capable of iBFT (iSCSI Boot Firmware Table) or have the mainboard's BIOS be iBFT-capable. iBFT, defined in the Advanced Configuration and Power Interface (ACPI) 3.0b specification, specifies a block of information that contains various parameters that are useful to the iSCSI Boot process.
Firmware implementing iBFT presents an iSCSI disk in the BIOS during startup as a bootable device by establishing the connection to the iSCSI target. The rest of the process of iSCSI booting is the same as booting from a local disk.
To configure the iBFT properly, users need to refer to the documentation from their hardware vendors.
Booting from Disk
When booting from disk, the OpenBoot PROM firmware reads the boot blocks from blocks 1 to 15 of the partition specified as the boot device. This standalone booter usually contains a file system-specific reader capable of reading the boot archive.
If the pathname to the standalone is relative (does not begin with a slash), the second level boot will look for the standalone in a platform-dependent search path. This path is guaranteed to contain /platform/platform-name
. Many SPARC platforms next search the platform-specific path entry /platform/hardware-class-name
. See filesystem
(5). If the pathname is absolute, boot
will use the specified path. The boot
program then loads the standalone at the appropriate address, and then transfers control.
Once the boot archive has been transferred from the boot device, Solaris can initialize and take over control of the machine. This process is further described in the "Boot Archive Phase," below, and is identical on all platforms.
If the filename is not given on the command line or otherwise specified, for example, by the boot-file
NVRAM variable, boot
chooses an appropriate default file to load based on what software is installed on the system and the capabilities of the hardware and firmware.
The path to the kernel must not contain any whitespace.
Booting from ZFS Booting from ZFS differs from booting from UFS in that, with ZFS, a device specifier identifies a storage pool, not a single root file system. A storage pool can contain multiple bootable datasets (that is, root file systems). Therefore, when booting from ZFS, it is not sufficient to specify a boot device. One must also identify a root file system within the pool that was identified by the boot device. By default, the dataset selected for booting is the one identified by the pool's bootfs property. This default selection can be overridden by specifying an alternate bootable dataset with the -Z option.
Boot Archive Phase
The boot archive contains a file system image that is mounted using an in-memory disk. The image is self-describing, specifically containing a file system reader in the boot block. This file system reader mounts and opens the RAM disk image, then reads and executes the kernel contained within it. By default, this kernel is in:
If booting from ZFS, the pathnames of both the archive and the kernel file are resolved in the root file system (that is, dataset) selected for booting as described in the previous section.
The initialization of the kernel continues by loading necessary drivers and modules from the in-memory filesystem until I/O can be turned on and the root filesystem mounted. Once the root filesystem is mounted, the in-memory filesystem is no longer needed and is discarded.
OpenBoot PROM boot Command Behavior
The OpenBoot boot
command takes arguments of the following form:
ok boot [device-specifier
The default boot
command has no arguments:
If no device-specifier
is given on the boot
command line, OpenBoot typically uses the boot-device
or diag-device NVRAM
variable. If no optional arguments
are given on the command line, OpenBoot typically uses the boot-file
or diag-file NVRAM
variable as default boot
arguments. (If the system is in diagnostics mode, diag-device
are used instead of boot-device
may include more than one string. All argument
strings are passed to the secondary booter; they are not interpreted by OpenBoot.
If any arguments
are specified on the boot
command line, then neither the boot-file
nor the diag-file NVRAM
variable is used. The contents of the NVRAM
variables are not merged with command line arguments. For example, the command:
ok boot -s
ignores the settings in both boot-file
; it interprets the string "-s"
will not use the contents of boot-file
With older PROMs, the command:
ok boot net
took no arguments, using instead the settings in boot-file
(if set) as the default file name and arguments to pass to boot. In most cases, it is best to allow the boot
command to choose an appropriate default based upon the system type, system hardware and firmware, and upon what is installed on the root file system. Changing boot-file
can generate unexpected results in certain circumstances.
This behavior is found on most OpenBoot 2.x and 3.x based systems. Note that differences may occur on some platforms.
ok boot cdrom
...also normally takes no arguments. Accordingly, if boot-file
is set to the 64-bit kernel filename and you attempt to boot the installation CD or DVD with boot cdrom
, boot will fail if the installation media contains only a 32-bit kernel.
Because the contents of boot-file
can be ignored depending on the form of the boot
command used, reliance upon boot-file
should be discouraged for most production systems.
Modern PROMs have enhanced the network boot support package to support the following syntax for arguments to be processed by the package:
All arguments are optional and can appear in any order. Commas are required unless the argument is at the end of the list. If specified, an argument takes precedence over any default values, or, if booting using DHCP, over configuration information provided by a DHCP server for those parameters.
, above, specifies the address discovery protocol to be used.
Configuration parameters, listed below, are specified as key
IP address of the TFTP server
file to download using TFTP
IP address of the client (in dotted-decimal notation)
IP address of the default router
subnet mask (in dotted-decimal notation)
DHCP client identifier
hostname to use in DHCP transactions
HTTP proxy server specification (IPADDR[:PORT])
maximum number of TFTP retries
maximum number of DHCP retries
The list of arguments to be processed by the network boot support package is specified in one of two ways:
As arguments passed to the package's open method, or
arguments listed in the NVRAM variable network-boot-arguments.
Arguments specified in network-boot-arguments
will be processed only if there are no arguments passed to the package's open
specifies the address discovery protocol to be used. If present, the possible values are rarp
If other configuration parameters are specified in the new syntax and style specified by this document, absence of the protocol
parameter implies manual configuration.
If no other configuration parameters are specified, or if those arguments are specified in the positional parameter syntax currently supported, the absence of the protocol
parameter causes the network boot support package to use the platform-specific default address discovery protocol.
Manual configuration requires that the client be provided its IP address, the name of the boot file, and the address of the server providing the boot file image. Depending on the network configuration, it might be required that subnet-mask
also be specified.
If the protocol
argument is not specified, the network boot support package uses the platform-specific default address discovery protocol.
is the IP address (in standard IPv4 dotted-decimal notation) of the TFTP server that provides the file to download if using TFTP.
When using DHCP, the value, if specified, overrides the value of the TFTP server specified in the DHCP response.
The TFTP RRQ is unicast to the server if one is specified as an argument or in the DHCP response. Otherwise, the TFTP RRQ is broadcast.
specifies the file to be loaded by TFTP from the TFTP server.
When using RARP and TFTP, the default file name is the ASCII hexadecimal representation of the IP address of the client, as documented in a preceding section of this document.
When using DHCP, this argument, if specified, overrides the name of the boot file specified in the DHCP response.
When using DHCP and TFTP, the default file name is constructed from the root node's name
property, with commas (,) replaced by periods (.).
When specified on the command line, the filename must not contain slashes ( /
specifies the IP address (in standard IPv4 dotted-decimal notation) of the client, the system being booted. If using RARP as the address discovery protocol, specifying this argument makes use of RARP unnecessary.
If DHCP is used, specifying the host-ip
argument causes the client to follow the steps required of a client with an "Externally Configured Network Address", as specified in RFC 2131.
is the IP address (in standard IPv4 dotted-decimal notation) of a router on a directly connected network. The router will be used as the first hop for communications spanning networks. If this argument is supplied, the router specified here takes precedence over the preferred router specified in the DHCP response.
(specified in standard IPv4 dotted-decimal notation) is the subnet mask on the client's network. If the subnet mask is not provided (either by means of this argument or in the DHCP response), the default mask appropriate to the network class (Class A, B, or C) of the address assigned to the booting client will be assumed.
specifies the unique identifier for the client. The DHCP client identifier is derived from this value. Client identifiers can be specified as:
The ASCII hexadecimal representation of the identifier, or
both represent a DHCP client identifier of 6F70656E626F6F74.
Identifiers specified on the command line must must not include slash (/
) or spaces.
The maximum length of the DHCP client identifier is 32 bytes, or 64 characters representing 32 bytes if using the ASCII hexadecimal form. If the latter form is used, the number of characters in the identifier must be an even number. Valid characters are 0-9, a-f, and A-F.
For correct identification of clients, the client identifier must be unique among the client identifiers used on the subnet to which the client is attached. System administrators are responsible for choosing identifiers that meet this requirement.
Specifying a client identifier on a command line takes precedence over any other DHCP mechanism of specifying identifiers.
(specified as a string) specifies the hostname to be used in DHCP transactions. The name might or might not be qualified with the local domain name. The maximum length of the hostname is 255 characters.
The hostname parameter can be used in service environments that require that the client provide the desired hostname to the DHCP server. Clients provide the desired hostname to the DHCP server, which can then register the hostname and IP address assigned to the client with DNS.
is specified in the following standard notation for a host:
is specified as an IP ddress (in standard IPv4 dotted-decimal notation) and the optional port
is specified in decimal. If a port is not specified, port 8080 (decimal) is implied.
is the maximum number of retries (specified in decimal) attempted before the TFTP process is determined to have failed. Defaults to using infinite retries.
is the maximum number of retries (specified in decimal) attempted before the DHCP process is determined to have failed. Defaults to of using infinite retries.
x86 Bootstrap Procedure
On x86 based systems, the bootstrapping process consists of two conceptually distinct phases, kernel loading and kernel initialization. Kernel loading is implemented in the boot loader using the BIOS ROM on the system board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads boot loader, starting with the first physical sector from a hard disk, DVD, or CD. If supported by the ROM on the network adapter, the BIOS can also download the pxeboot
binary from a network boot server. Once the boot loader is loaded, it in turn will load the unix
kernel, a pre-constructed boot archive containing kernel modules and data, and any additional files specified in the boot loader configuration. Once specified files are loaded, the boot loader will start the kernel to complete boot.
If the device identified by the boot loader as the boot device contains a ZFS storage pool, the menu.lst
file used to create the Boot Environment menu will be found in the dataset at the root of the pool's dataset hierarchy. This is the dataset with the same name as the pool itself. There is always exactly one such dataset in a pool, and so this dataset is well-suited for pool-wide data such as the menu.lst
file. After the system is booted, this dataset is mounted at / poolname
in the root file system.
There can be multiple bootable datasets (that is, root file systems) within a pool. The default file system to load the kernel is identified by the boot pool bootfs
property (see zpool
(1M)). All bootable datasets are listed in the menu.lst
file, which is used by the boot loader to compose the Boot Environment menu, to implement support to load a kernel and boot from an alternate Boot Environment.
Kernel initialization starts when the boot loader finishes loading the files specified in the boot loader configuration and hands control over to the unix
binary. The Unix operating system initializes, links in the necessary modules from the boot archive and mounts the root file system on the real root device. At this point, the kernel regains storage I/O, mounts additional file systems (see vfstab
(4)), and starts various operating system services (see smf
X86 PRIMARY BOOT
The first sector on a hard disk contains the master boot block (first stage of the boot program), which contains the master boot program and the Master Boot Record ( MBR
) table. The master boot program has recorded the location of the secondary stage of the boot program and using this location, master boot will load and start the secondary stage of the boot program.
To support booting multiple operating systems, the master boot program is also installed as the first sector of the partition with the illumos root file system. This will allow configuring third party boot programs to use the chainload technique to boot illumos system.
If the first stage is installed on the master boot block (see the -m
option of installboot
(1M)), then stage2
is loaded directly from the Solaris partition regardless of the active partition.
A similar sequence occurs for DVD or CD boot, but the master boot block location and contents are dictated by the El Torito specification. The El Torito boot will then continue in the same way as with the hard disk.
Floppy booting is not longer supported. Booting from USB devices follows the same procedure as with hard disks.
An x86 MBR
partition for the Solaris software begins with a one-cylinder boot slice, which contains the boot loader stage1
in the first sector, the standard Solaris disk label and volume table of contents (VTOC) in the second and third sectors, and in case the UFS file system is used for the root file system, stage2
in the fiftieth and subsequent sectors.
If the zfs boot is used, stage2
is always stored in the zfs pool boot program area.
The behavior is slightly different when a disk is using EFI
To support a UFS root file system in the EFI
partition, the stage2
must be stored on separate dedicated partition, as there is no space in UFS file system boot program area to store the current stage2
. This separate dedicated partition is used as raw disk space, and must have enough space for both stage1
. The type (tag) of this partition must be boot
For the UUID reference, please see /usr/include/sys/efi_partition.h
In case of a whole disk zfs pool configuration, the stage1
is always installed in the first sector of the disk, and it always loads stage2
from the partition specified at the boot loader installation time.
is running, it will load and start the third stage boot program from root file system. Boot loader supports loading from the ZFS, UFS and PCFS file systems. The stage3 boot program defaults to be /boot/loader
, and implements a user interface to load and boot the unix kernel.
For network booting, the supported method is Intel's Preboot eXecution Environment (PXE) standard. When booting from the network using PXE, the system or network adapter BIOS uses DHCP to locate a network bootstrap program ( pxeboot
) on a boot server and reads it using Trivial File Transfer Protocol (TFTP). The BIOS executes the pxeboot
by jumping to its first byte in memory. The pxeboot
program is combined stage2 and stage2 boot program and implements user interface to load and boot unix kernel.