Windows PowerShell command on Get-command boot

Manual Pages for UNIX Operating System command usage for man boot

System Administration Commands boot(1M)

NAME

boot - start the system kernel or a standalone program

SYNOPSIS

SPARC

boot [OBP names] [file] [-aLV] [-F object] [-D default-file]

[-Z dataset] [boot-flags] [--] [client-program-args]

x86

kernel$ /platform/i86pc/kernel/$ISADIR/unix [boot-args]

[-B prop=val [,val...]]

DESCRIPTION

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 exam-

ple of a standalone program other than the operating system

that can be booted.

If the standalone is identified as a dynamically-linked exe-

cutable, 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(4). 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

SunOS 5.11 Last change: 7 Jun 2010 1

System Administration Commands boot(1M)

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) com-

mand 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 fileystem-specific boot

block (when booting from a disk), or inetboot or wanboot

(when booting across the network).

Network Booting

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 and sun4v kernel architectures have DHCP-capable

PROMs.

The boot command syntax for specifying the two methods of

network booting are:

boot net:rarp

boot net:dhcp

The command:

boot net

without a rarp or dhcp specifier, invokes the default method

for network booting over the network interface for which net

is an alias.

SunOS 5.11 Last change: 7 Jun 2010 2

System Administration Commands boot(1M)

The sequence of events for network booting using

RARP/bootparams is described in the following paragraphs.

The sequence for DHCP follows the RARP/bootparams descrip-

tion.

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 inet-

boot. 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 broad-

casts the hardware address and kernel architecture and

requests an IP address, boot parameters, and network confi-

guration 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. If the file to be loaded is an HTTP URL, the PROM will use HTTP to load the referenced file. If the client has been

configured with an HMAC SHA-1 key, it will check the

integrity of the loaded file before proceeding to execute

it. The file is expected to be the wanboot binary. The WAN

boot process can be configured to use either DHCP or NVRAM

properties to discover the install server and router and the

proxies needed to connect to it. When wanboot begins execut-

ing, it determines whether sufficient information is avail-

able to it to allow it to proceed. If any necessary informa-

tion is missing, it will either exit with an appropriate error or bring up a command interpreter and prompt for

further configuration information. Once wanboot has obtained

the necessary information, it loads the boot loader into

memory by means of HTTP. If an encryption key has been

installed on the client, wanboot will verify the boot

SunOS 5.11 Last change: 7 Jun 2010 3

System Administration Commands boot(1M)

loader's signature and its accompanying hash. Presence of an encryption key but no hashing key is an error.

The wanboot boot loader can communicate with the client

using either HTTP or secure HTTP. If the former, and if the

client has been configured with an HMAC SHA-1 key, the boot

loader will perform an integrity check of the root file sys-

tem. Once the root file system has been loaded into memory

(and possibly had an integrity check performed), the boot

archive is transferred from the server. If provided with a

boot_logger URL by means of the wanboot.conf(4) file, wan-

boot will periodically log its progress.

Not all PROMs are capable of consuming URLs. You can deter-

mine whether a client is so capable using the list-

security-keys OBP command (see monitor(1M)).

WAN booting is not currently available on the x86 platform.

The wanboot Command Line

When the client program is wanboot, it accepts client-

program-args of the form:

boot ... -o opt1[,opt2[,...]]

where each option may be an action: dhcp

Require wanboot to obtain configuration parameters by

means of DHCP. prompt

Cause wanboot to enter its command interpreter.

One of the interpreter commands listed below.

SunOS 5.11 Last change: 7 Jun 2010 4

System Administration Commands boot(1M)

...or an assignment, using the interpreter's parameter names listed below.

The wanboot Command Interpreter

The wanboot command interpreter is invoked by supplying a

client-program-args of "-o prompt" when booting. Input con-

sists of single commands or assignments, or a comma-

separated list of commands or assignments. The configuration parameters are:

host-ip

IP address of the client (in dotted-decimal notation)

router-ip

IP address of the default router (in dotted-decimal

notation)

subnet-mask

subnet mask (in dotted-decimal notation)

client-id

DHCP client identifier (a quoted ASCII string or hex ASCII) hostname hostname to request in DHCP transactions (ASCII)

http-proxy

HTTP proxy server specification (IPADDR[:PORT]) The key names are: 3des the triple DES encryption key (48 hex ASCII characters)

SunOS 5.11 Last change: 7 Jun 2010 5

System Administration Commands boot(1M)

aes the AES encryption key (32 hex ASCII characters) sha1

the HMAC SHA-1 signature key (40 hex ASCII characters)

Finally, the URL or the WAN boot CGI is referred to by means

of:

bootserver

URL of WAN boot's CGI (the equivalent of OBP's file

parameter) The interpreter accepts the following commands: help Print a brief description of the available commands var=val Assign val to var, where var is one of the configuration

parameter names, the key names, or bootserver.

var= Unset parameter var. list List all parameters and their values (key values retrieved by means of OBP are never shown). prompt Prompt for values for unset parameters. The name of each parameter and its current value (if any) is printed, and the user can accept this value (press Return) or enter a new value.

SunOS 5.11 Last change: 7 Jun 2010 6

System Administration Commands boot(1M)

go Once the user is satisfied that all values have been

entered, leave the interpreter and continue booting.

exit

Quit the boot interpreter and return to OBP's ok prompt.

Any of these assignments or commands can be passed on the

command line as part of the -o options, subject to the OBP

limit of 128 bytes for boot arguments. For example, -o

list,go would simply list current (default) values of the

parameters and then continue booting.

iSCSI Boot

iSCSI boot is supported on both x86 and SPARC.

iSCSI Boot on x86

For iSCSI boot 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. iSCSI Boot on SPARC

iSCSI boot on SPARC is supported with OpenBoot level 4.31

and above, and does not require a specific NIC.

The boot command in OpenBoot takes a series of keywords to

identify the destination iSCSI target, following the

keyword=value format. The complete form of the iSCSI boot

command is:

boot net:iscsi-target-ip=t-ip,iscsi-target-name=name

host-ip=h-ip[,router-ip=r-ip]

SunOS 5.11 Last change: 7 Jun 2010 7

System Administration Commands boot(1M)

[,subnet-mask=m-ip]

[,iscsi-port=port]

[,iscsi-lun=lun]

[,iscsi-partition=partition]

The descriptions of the preceding keywords are as follows:

host-ip IP address of booting host.

router-ip IP address of routing gateway.

subnet-mask Subnet mask of host-ip.

iscsi-target-ip IP address of iSCSI target storing OS.

iscsi-target-name Name of iSCSI target storing OS.

iscsi-partition Partition containing the bootable root.

iscsi-port IP port of the target.

iscsi-lun LUN to be booted off on target.

The values of iscsi-target-ip, route-ip, and subnet-mask are

in standard, IPv4 dotted-decimal format; for example,

255.255.255.0 for subnet-mask. IPv6 is not supported in the

current OpenBoot implementation.

The value of iscsi-port, a decimal number, is in the range

of 1 to 65535.

The value of iscsi-lun is in the format of a dashed hexade-

cimal LUN, ffff-ffff-ffff-ffff. Please refer to section 5 of

RFC 4173 for details. Leading zeroes and trailing dashes can

be excluded, thus, 3, for example, is equivalent to 0003-

0000-0000-0000.

SunOS 5.11 Last change: 7 Jun 2010 8

System Administration Commands boot(1M)

The value of iscsi-partition is one ASCII character, used to

specify the root partition. Most commonly, it is a.

The value of iscsi-target-name is in the format of a string,

as specified by RFC 3720 and RFC 3722. Two security keys are added to provide CHAP authentication on the target side. These are:

chap-user CHAP name

chap-password CHAP secret

Currently these two keys can be set with the command set-

ascii-security-key at the Open Boot PROM (ok) prompt. For

example:

ok set-ascii-security-key chap-user chap name

ok set-ascii-security-key chap-password chap password

Bi-directional authentication is not yet supported. These

two variables can be changed only under the Open Boot PROM prompt.

RFC 4173 is supported, to retrieve iSCSI boot information

from a DHCP server. The DHCP server must specify the Root

Path option for the booting client, after which the client

can do an iSCSI boot by means of the simple command:

boot net:dhcp

Currently the key boot-device is used to retrieve the physi-

cal boot device path during iSCSI boot. This key is setup

during the Solaris installation. A manually modified key

value might break iSCSI boot.

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

SunOS 5.11 Last change: 7 Jun 2010 9

System Administration Commands boot(1M)

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 other-

wise specified, for example, by the boot-file NVRAM vari-

able, boot chooses an appropriate default file to load based

on what software is installed on the system and the capabil-

ities 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 identi-

fied 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:

/platform/`uname -i`/kernel/unix

SunOS 5.11 Last change: 7 Jun 2010 10

System Administration Commands boot(1M)

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 previ-

ous section.

The initialization of the kernel continues by loading neces-

sary 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] [arguments]

The default boot command has no arguments:

ok boot

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 and diag-file are used

instead of boot-device and boot-file).

arguments 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

SunOS 5.11 Last change: 7 Jun 2010 11

System Administration Commands boot(1M)

ignores the settings in both boot-file and diag-file; it

interprets the string "-s" as arguments. boot will not use

the contents of boot-file or diag-file.

With older PROMs, the command:

ok boot net

took no arguments, using instead the settings in boot-file

or diag-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 sys-

tem type, system hardware and firmware, and upon what is

installed on the root file system. Changing boot-file or

diag-file can generate unexpected results in certain cir-

cumstances. This behavior is found on most OpenBoot 2.x and 3.x based systems. Note that differences may occur on some platforms. The command:

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 ker-

nel.

Because the contents of boot-file or diag-file can be

ignored depending on the form of the boot command used,

reliance upon boot-file should be discouraged for most pro-

duction systems.

When executing a WAN boot from a local (CD or DVD) copy of

wanboot, one must use:

ok boot cdrom -F wanboot - install

SunOS 5.11 Last change: 7 Jun 2010 12

System Administration Commands boot(1M)

Modern PROMs have enhanced the network boot support package

to support the following syntax for arguments to be pro-

cessed by the package: [protocol,] [key=value,]*

All arguments are optional and can appear in any order. Com-

mas 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 configura-

tion information provided by a DHCP server for those parame-

ters. protocol, above, specifies the address discovery protocol to be used. Configuration parameters, listed below, are specified as key=value attribute pairs.

tftp-server

IP address of the TFTP server file

file to download using TFTP or URL for WAN boot

host-ip

IP address of the client (in dotted-decimal notation)

router-ip

IP address of the default router

subnet-mask

subnet mask (in dotted-decimal notation)

client-id

DHCP client identifier

SunOS 5.11 Last change: 7 Jun 2010 13

System Administration Commands boot(1M)

hostname hostname to use in DHCP transactions

http-proxy

HTTP proxy server specification (IPADDR[:PORT])

tftp-retries

maximum number of TFTP retries

dhcp-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: o As arguments passed to the package's open method, or

o arguments listed in the NVRAM variable network-

boot-arguments.

Arguments specified in network-boot-arguments will be pro-

cessed only if there are no arguments passed to the package's open method. Argument Values protocol specifies the address discovery protocol to be used. If present, the possible values are rarp or dhcp. 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

SunOS 5.11 Last change: 7 Jun 2010 14

System Administration Commands boot(1M)

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 and router-ip also be specified.

If the protocol argument is not specified, the network boot

support package uses the platform-specific default address

discovery protocol.

tftp-server 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. file specifies the file to be loaded by TFTP from the TFTP

server, or the URL if using HTTP. The use of HTTP is trig-

gered if the file name is a URL, that is, the file name

starts with http: (case-insensitive).

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 con-

structed from the root node's name property, with commas (,) replaced by periods (.). When specified on the command line, the filename must not contain slashes (/).

SunOS 5.11 Last change: 7 Jun 2010 15

System Administration Commands boot(1M)

The format of URLs is described in RFC 2396. The HTTP server must be specified as an IP address (in standard IPv4

dotted-decimal notation). The optional port number is speci-

fied in decimal. If a port is not specified, port 80 (decimal) is implied.

The URL presented must be "safe-encoded", that is, the pack-

age does not apply escape encodings to the URL presented. URLs containing commas must be presented as a quoted string. Quoting URLs is optional otherwise.

host-ip 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.

router-ip 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.

subnet-mask (specified in standard IPv4 dotted-decimal nota-

tion) is the subnet mask on the client's network. If the

subnet mask is not provided (either by means of this argu-

ment 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.

client-id specifies the unique identifier for the client.

The DHCP client identifier is derived from this value. Client identifiers can be specified as:

o The ASCII hexadecimal representation of the iden-

tifier, or o a quoted string

SunOS 5.11 Last change: 7 Jun 2010 16

System Administration Commands boot(1M)

Thus, client-id="openboot" and client-id=6f70656e626f6f74

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 sub-

net 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 pre-

cedence over any other DHCP mechanism of specifying identif-

iers. hostname (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.

Note -

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.

http-proxy is specified in the following standard notation

for a host: host [":"" port] ...where 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)

SunOS 5.11 Last change: 7 Jun 2010 17

System Administration Commands boot(1M)

is implied.

tftp-retries is the maximum number of retries (specified in

decimal) attempted before the TFTP process is determined to have failed. Defaults to using infinite retries.

dhcp-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 GRUB (GRand Unified Bootloader) using the BIOS ROM on the system board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads GRUB, starting with the first physical sector from a

hard disk, DVD, or CD. If supported by the ROM on the net-

work adapter, the BIOS can also download the pxegrub binary

from a network boot server. Once GRUB is located, it exe-

cutes a command in a menu to load the unix kernel and a

pre-constructed boot archive containing kernel modules and

data.

If the device identified by GRUB as the boot device contains

a ZFS storage pool, the menu.lst file used to create the GRUB 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. By default, the file system in which file name entries in a menu.lst file are resolved is the one

identified by the pool's bootfs property (see zpool(1M)).

However, a menu.lst entry can contain a bootfs command,

which specifies an alternate dataset in the pool. In this way, the menu.lst file can contain entries for multiple root file systems within the pool. Kernel initialization starts when GRUB finishes loading the

boot archive and hands control over to the unix binary. At

this point, GRUB becomes inactive and no more I/O occurs

with the boot device. The Unix operating system initializes,

SunOS 5.11 Last change: 7 Jun 2010 18

System Administration Commands boot(1M)

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(5)).

Enabling Automatic Rebooting (x86)

The Solaris operating system supports an smf(5) property

that enables a system to automatically reboot from the

current boot device, to recover from conditions such as an

out-of-date boot archive.

The service svc:/system/boot-config:default contains the

boolean property auto-reboot-safe, which is set to false by

default. Setting it to true communicates that both the

system's BIOS and default GRUB menu entry are set to boot

from the current boot device. The value of this property can

be changed using svccfg(1M) and svcadm(1M). For example, to

set auto-reboot-safe to enable automatic rebooting, enter a

command such as:

example# svccfg -s svc:/system/boot-config:default \

setprop config/auto-reboot-safe = true

Most systems are configured for automatic reboot from the

current boot device. However, in some instances, automatic

rebooting to an unknown operating system might produce

undesirable results. For these instances, the auto-reboot-

safe property allows you to specify the behavior you want. Failsafe Mode

A requirement of booting from a root filesystem image built

into a boot archive then remounting root onto the actual

root device is that the contents of the boot archive and the

root filesystem must be consistent. Otherwise, the proper operation and integrity of the machine cannot be guaranteed. The term "consistent" means that all files and modules in

the root filesystem are also present in the boot archive and

have identical contents. Since the boot strategy requires

first reading and mounting the boot archive as the first-

stage root image, all unloadable kernel modules and initial-

ization derived from the contents of the boot archive are

required to match the real root filesystem. Without such consistency, it is possible that the system could be running with a kernel module or parameter setting applied to the

root device before reboot, but not yet updated in the root

SunOS 5.11 Last change: 7 Jun 2010 19

System Administration Commands boot(1M)

archive. This inconsistency could result in system instabil-

ity or data loss.

Once the root filesystem is mounted, and before relinquish-

ing the in-memory filesystem, Solaris performs a consistency

verification against the two file systems. If an incon-

sistency is detected, Solaris suspends the normal boot

sequence and falls back to failsafe mode. Correcting this state requires the administrator take one of two steps. The

recommended procedure is to reboot to the failsafe archive

and rebuild the boot archive. This ensures that a known ker-

nel is booted and functioning for the archive rebuild pro-

cess. Alternatively, the administrator can elect to clear

the inconsistent boot archive service state and continue

system bring-up if the inconsistency is such that correct

system operation will not be impaired. See svcadm(1M).

If the boot archive service is cleared and system bring-up

is continued (the second alternative above), the system may be running with unloadable kernel drivers or other modules

that are out-of-date with respect to the root filesystem. As

such, correct system operation may be compromised.

To ensure that the boot archive is consistent, the normal

system shutdown process, as initiated by reboot(1M) and

shutdown(1M), checks for and applies updates to the boot

archive at the conclusion of the umountall(1M) milestone.

An update to any kernel file, driver, module or driver con-

figuration file that needs to be included in the boot

archive after the umountall service is complete will result

in a failed boot archive consistency check during the next

boot. To avoid this, it is recommended to always shut down a

machine cleanly. If an update is required to the kernel after completion of the umountall service, the administrator may elect to rebuild the archive by invoking:

# bootadm update-archive

Failsafe Boot Archive

The failsafe archive can be used to boot the machine at any

time for maintenance or troubleshooting. The failsafe boot

archive is installed on the machine, sourced from the

SunOS 5.11 Last change: 7 Jun 2010 20

System Administration Commands boot(1M)

miniroot archive. Booting the failsafe archive causes the

machine to boot using the in-memory filesystem as the root

device. SPARC The SPARC failsafe archive is:

/platform/`uname -i`/failsafe

...and can be booted as follows:

ok boot [device-specifier] -F failsafe

If a user wishes to boot a failsafe archive from a particu-

lar ZFS bootable dataset, this can be done as follows:

ok boot [device-specifier] -Z dataset -F failsafe

x86 The x86 failsafe archive is:

/boot/x86.miniroot-safe

...and can be booted by selecting the Solaris failsafe item

from the GRUB menu. OPTIONS SPARC The following SPARC options are supported:

-a

The boot program interprets this flag to mean ask me,

and so it prompts for the name of the standalone. The

'-a' flag is then passed to the standalone program.

-D default-file

Explicitly specify the default-file. On some systems,

boot chooses a dynamic default file, used when none is

SunOS 5.11 Last change: 7 Jun 2010 21

System Administration Commands boot(1M)

otherwise specified. This option allows the default-file

to be explicitly set and can be useful when booting

kmdb(1) since, by default, kmdb loads the default-file

as exported by the boot program.

-F object

Boot using the named object. The object must be either

an ELF executable or bootable object containing a boot

block. The primary use is to boot the failsafe or wan-

boot boot archive.

-L

List the bootable datasets within a ZFS pool. You can

select one of the bootable datasets in the list, after

which detailed instructions for booting that dataset are

displayed. Boot the selected dataset by following the instructions. This option is supported only when the

boot device contains a ZFS storage pool.

-V

Display verbose debugging information.

boot-flags

The boot program passes all boot-flags to file. They are

not interpreted by boot. See the kernel(1M) and kmdb(1)

manual pages for information about the options available with the default standalone program.

client-program-args

The boot program passes all client-program-args to file.

They are not interpreted by boot.

file

Name of a standalone program to boot. If a filename is

not explicitly specified, either on the boot command

line or in the boot-file NVRAM variable, boot chooses an

appropriate default filename.

SunOS 5.11 Last change: 7 Jun 2010 22

System Administration Commands boot(1M)

OBP names

Specify the open boot prom designations. For example, on

Desktop SPARC based systems, the designation /sbus/esp@0,800000/sd@3,0:a indicates a SCSI disk (sd) at target 3, lun0 on the SCSI bus, with the esp host adapter plugged into slot 0.

-Z dataset

Boot from the root file system in the specified ZFS dataset. x86 The following x86 options are supported:

-B prop=val...

One or more property-value pairs to be passed to the

kernel. Multiple property-value pairs must be separated

by a comma. Use of this option is the equivalent of the command: eeprom prop=val. See eeprom(1M) for available properties and valid values. If the root file system corresponding to this menu entry is a ZFS dataset, the menu entry needs the following option added:

-B $ZFS-BOOTFS

boot-args

The boot program passes all boot-args to file. They are

not interpreted by boot. See kernel(1M) and kmdb(1) for

information about the options available with the kernel.

/platform/i86pc/kernel/$ISADIR/unix

Name of the kernel to boot. When using the kernel$

token, $ISADIR expands to amd64 on 64-bit machines, and

a null string on other machines. As a result of this dereferencing, this path expands to the proper kernel for the machine.

SunOS 5.11 Last change: 7 Jun 2010 23

System Administration Commands boot(1M)

X86 BOOT SEQUENCE DETAILS

After a PC-compatible machine is turned on, the system

firmware in the BIOS ROM executes a power-on self test

(POST), runs BIOS extensions in peripheral board ROMs, and invokes software interrupt INT 19h, Bootstrap. The INT 19h

handler typically performs the standard PC-compatible boot,

which consists of trying to read the first physical sector from the first diskette drive, or, if that fails, from the first hard disk. The processor then jumps to the first byte of the sector image in memory. X86 PRIMARY BOOT

The first sector on a floppy disk contains the master boot

block (GRUB stage1). The stage 1 is responsible for loading

GRUB stage2. Now GRUB is fully functional. It reads and exe-

cutes the menu file /boot/grub/menu.lst. A similar sequence

occurs for DVD or CD boot, but the master boot block loca-

tion and contents are dictated by the El Torito specifica-

tion. The El Torito boot also leads to strap.com, which in

turn loads boot.bin.

The first sector on a hard disk contains the master boot

block, which contains the master boot program and the FDISK

table, named for the PC program that maintains it. The mas-

ter boot finds the active partition in the FDISK table,

loads its first sector (GRUB stage1), and jumps to its first

byte in memory. This completes the standard PC-compatible

hard disk boot sequence. If GRUB stage1 is installed on the

master boot block (see the -m option of installgrub(1M)),

then stage2 is loaded directly from the Solaris FDISK parti-

tion regardless of the active partition. An x86 FDISK partition for the Solaris software begins with

a one-cylinder boot slice, which contains GRUB stage1 in the

first sector, the standard Solaris disk label and volume table of contents (VTOC) in the second and third sectors, and GRUB stage2 in the fiftieth and subsequent sectors. The

area from sector 4 to 49 might contain boot blocks for older

versions of Solaris. This makes it possible for multiple Solaris releases on the same FDISK to coexist. When the

FDISK partition for the Solaris software is the active par-

tition, the master boot program (mboot) reads the partition

boot program in the first sector into memory and jumps to

it. It in turn reads GRUB stage2 program into memory and jumps to it. Once the GRUB menu is displayed, the user can

choose to boot an operating system on a different partition,

a different disk, or possibly from the network.

SunOS 5.11 Last change: 7 Jun 2010 24

System Administration Commands boot(1M)

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 (pxegrub) on a

boot server and reads it using Trivial File Transfer Proto-

col (TFTP). The BIOS executes the pxegrub by jumping to its first byte in memory. The pxegrub program downloads a menu file and presents the entries to user. X86 KERNEL STARTUP The kernel startup process is independent of the kernel

loading process. During kernel startup, console I/O goes to the device specified by the console property.

When booting from UFS, the root device is specified by the

bootpath property, and the root file system type is speci-

fied by the fstype property. These properties should be

setup by the Solaris Install/Upgrade process in

/boot/solaris/bootenv.rc and can be overridden with the -B

option, described above (see the eeprom(1M) man page).

When booting from ZFS, the root device is specified by a

boot parameter specified by the -B $ZFS-BOOTFS parameter on

either the kernel or module line in the GRUB menu entry.

This value (as with all parameters specified by the -B

option) is passed by GRUB to the kernel.

If the console properties are not present, console I/O defaults to screen and keyboard. The root device defaults to ramdisk and the file system defaults to ufs.

EXAMPLES

SPARC

Example 1 To Boot the Default Kernel In Single-User Interac-

tive Mode

To boot the default kernel in single-user interactive mode,

respond to the ok prompt with one of the following:

boot -as

boot disk3 -as

Example 2 Network Booting with WAN Boot-Capable PROMs

SunOS 5.11 Last change: 7 Jun 2010 25

System Administration Commands boot(1M)

To illustrate some of the subtle repercussions of various

boot command line invocations, assume that the network-

boot-arguments are set and that net is devaliased as shown

in the commands below. In the following command, device arguments in the device

alias are processed by the device driver. The network boot

support package processes arguments in network-boot-

arguments.

boot net

The command below results in no device arguments. The net-

work boot support package processes arguments in network-

boot-arguments.

boot net:

The command below results in no device arguments. rarp is

the only network boot support package argument. network-

boot-arguments is ignored.

boot net:rarp

In the command below, the specified device arguments are

honored. The network boot support package processes argu-

ments in network-boot-arguments.

boot net:speed=100,duplex=full

Example 3 Using wanboot with Older PROMs

The command below results in the wanboot binary being loaded

from DVD or CD, at which time wanboot will perform DHCP and

SunOS 5.11 Last change: 7 Jun 2010 26

System Administration Commands boot(1M)

then drop into its command interpreter to allow the user to enter keys and any other necessary configuration.

boot cdrom -F wanboot -o dhcp,prompt

x86 (32-bit)

Example 4 To Boot the Default Kernel In 32-bit Single-User

Interactive Mode

To boot the default kernel in single-user interactive mode,

edit the GRUB kernel command line to read:

kernel /platform/i86pc/kernel/unix -as

x86 (64-bit Only)

Example 5 To Boot the Default Kernel In 64-bit Single-User

Interactive Mode

To boot the default kernel in single-user interactive mode,

edit the GRUB kernel command line to read:

kernel /platform/i86pc/kernel/amd64/unix -as

Example 6 Switching Between 32-bit and 64-bit Kernels on

64-bit x86 Platform

To be able to boot both 32-bit and 64-bit kernels, add

entries for both kernels to /boot/grub/menu.lst, and use the

set-menu subcommand of bootadm(1M) to switch. See

bootadm(1M) for an example of the bootadm set-menu.

FILES

/platform/platform-name/ufsboot

Second-level program to boot from a disk, DVD, or CD

/etc/inittab

SunOS 5.11 Last change: 7 Jun 2010 27

System Administration Commands boot(1M)

Table in which the initdefault state is specified /sbin/init Program that brings the system to the initdefault state

64-bit SPARC Only

/platform/platform-name/kernel/sparcv9/unix

Default program to boot system.

x86 Only

/boot

Directory containing boot-related files.

/boot/grub/menu.lst

Menu of bootable operating systems displayed by GRUB.

/platform/i86pc/kernel/unix

32-bit kernel.

64-bit x86 Only

/platform/i86pc/kernel/amd64/unix

64-bit kernel.

kmdb(1), uname(1), bootadm(1M), eeprom(1M), init(1M),

installboot(1M), kernel(1M), monitor(1M), shutdown(1M),

svcadm(1M), svccfg(1M), umountall(1M), zpool(1M), uadmin(2),

bootparams(4), inittab(4), vfstab(4), wanboot.conf(4),

attributes(5), filesystem(5), smf(5) RFC 903, A Reverse Address Resolution Protocol, http://www.ietf.org/rfc/rfc903.txt RFC 2131, Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/rfc2131.txt

SunOS 5.11 Last change: 7 Jun 2010 28

System Administration Commands boot(1M)

RFC 2132, DHCP Options and BOOTP Vendor Extensions, http://www.ietf.org/rfc/rfc2132.txt

RFC 2396, Uniform Resource Identifiers (URI): Generic Syn-

tax, http://www.ietf.org/rfc/rfc2396.txt Sun Hardware Platform Guide OpenBoot Command Reference Manual WARNINGS

The boot utility is unable to determine which files can be

used as bootable programs. If the booting of a file that is

not bootable is requested, the boot utility loads it and

branches to it. What happens after that is unpredictable. NOTES

platform-name can be found using the -i option of uname(1).

hardware-class-name can be found using the -m option of

uname(1). The current release of the Solaris operating system does not

support machines running an UltraSPARC-I CPU.

SunOS 5.11 Last change: 7 Jun 2010 29