boot man page on Solaris

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
Solaris logo
[printable version]

boot(1M)		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 pro‐
       gram. For the purpose  of  this	discussion,  bootstrapping  means  the
       process	of  loading and executing the bootable operating system. Typi‐
       cally, the standalone program is the operating system kernel (see  ker‐
       nel(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 exe‐
       cutable format and then transfer control to  the	 interpreter.  If  the
       standalone  is  statically-linked,  it will jump directly to the stand‐
       alone.

       Once the kernel is loaded, it starts the UNIX system, mounts the neces‐
       sary  file  systems  (see  vfstab(4)), and runs /sbin/init to bring the
       system to the "initdefault" state specified in /etc/inittab. See	 init‐
       tab(4).

   SPARC Bootstrap Procedure
       On  SPARC  based systems, the bootstrap procedure on most machines con‐
       sists 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 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 ar‐
       chive from the boot device.

       An IP address can be obtained in one of three ways: RARP, DHCP, or man‐
       ual configuration, depending on the functions available in and configu‐
       ration of the PROM. Machines of the sun4u and  sun4v  kernel  architec‐
       tures have DHCP-capable PROMs.

       The boot command syntax for specifying the two methods of network boot‐
       ing are:

	 boot net:rarp
	 boot net:dhcp

       The command:

	 boot net

       without a rarp or dhcp specifier, invokes the default method  for  net‐
       work 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 description.

       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, inet‐
       boot will also use reverse ARP to fetch its IP address, then  broadcast
       bootparams RPC calls (see bootparams(4)) to locate configuration infor‐
       mation 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 hard‐
       ware 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 fur‐
       ther 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 pro‐
       ceeding 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 executing, it determines
       whether sufficient information is available to it to allow it  to  pro‐
       ceed. If any necessary information 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 neces‐
       sary 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 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  config‐
       ured  with an HMAC SHA-1 key, the boot loader will perform an integrity
       check of the root file system. 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, wanboot will
       periodically log its progress.

       Not all PROMs are capable of consuming URLs. You can determine  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.

       <cmd>

	   One of the interpreter commands listed below.

       ...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-pro‐
       gram-args of "-o prompt" when booting. Input consists  of  single  com‐
       mands  or assignments, or a comma-separated list of commands or assign‐
       ments. 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)

       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.

       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.

   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	 plat‐
       form-dependent  search  path. This path is guaranteed to contain /plat‐
       form/platform-name. Many SPARC platforms next search the	 platform-spe‐
       cific  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 speci‐
       fied, 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 sys‐
       tem. A storage pool can contain multiple bootable  datasets  (that  is,
       root  file systems). Therefore, when booting from ZFS, it is not suffi‐
       cient to specify a boot device. One must also identify a root file sys‐
       tem 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 con‐
       tained within it. By default, this kernel is in:

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

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

       The default boot command has no arguments:

	 ok boot

       If no device-specifier is given on the boot command line, OpenBoot typ‐
       ically 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	 argu‐
       ments. (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

       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 appropri‐
       ate  default  based upon the system 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 circumstances.

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

       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 production systems.

       When executing a WAN boot from a local (CD or DVD) copy of wanboot, one
       must use:

       ok boot cdrom -F wanboot - install

       Modern PROMs have enhanced the network boot support package to  support
       the following syntax for arguments to be processed by the package:

       [protocol,] [key=value,]*

       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.

       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

       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 pack‐
       age 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-argu‐
		  ments.

       Arguments specified in network-boot-arguments will be processed 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	 argu‐
       ments  are  specified in the positional parameter syntax currently sup‐
       ported, 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 pro‐
       viding 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	 nota‐
       tion)  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 argu‐
       ment 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 triggered 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  hexadeci‐
       mal  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 (/).

       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	specified in decimal. If a port is not
       specified, port 80 (decimal) is implied.

       The URL presented must be "safe-encoded", that is, the package does not
       apply  escape  encodings	 to  the URL presented. URLs containing commas
       must be presented as a quoted string. Quoting URLs is  optional	other‐
       wise.

       host-ip specifies the IP address (in standard IPv4 dotted-decimal nota‐
       tion) 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 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.

       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 identifier, or

	   o	  a quoted string

       Thus, client-id="openboot" and client-id=6f70656e626f6f74  both	repre‐
       sent 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.

       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 charac‐
       ters.

       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) 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 concep‐
       tually  distinct phases, kernel loading and kernel initialization. Ker‐
       nel 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 network
       adapter, the BIOS can also download the pxegrub binary from  a  network
       boot  server.  Once GRUB is located, it executes a command in a menu to
       load the unix kernel and a pre-constructed boot archive containing ker‐
       nel 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 ar‐
       chive 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, 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	 prop‐
       erty  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  consis‐
       tent. Otherwise, the proper operation and integrity of the machine can‐
       not 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 con‐
       tents. Since the boot strategy requires first reading and mounting  the
       boot  archive as the first-stage root image, all unloadable kernel mod‐
       ules and initialization derived from the contents of the	 boot  archive
       are  required  to  match the real root filesystem. Without such consis‐
       tency, 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  archive.  This  inconsistency	 could
       result in system instability or data loss.

       Once  the  root filesystem is mounted, and before relinquishing the in-
       memory filesystem, Solaris performs a consistency verification  against
       the two file systems. If an inconsistency 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 recom‐
       mended procedure is to reboot to the failsafe archive and  rebuild  the
       boot  archive. This ensures that a known kernel is booted and function‐
       ing for the archive rebuild process. Alternatively,  the	 administrator
       can elect to clear the inconsistent boot archive service state and con‐
       tinue 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  unload‐
       able  kernel drivers or other modules that are out-of-date with respect
       to the root filesystem. As such, correct system operation may  be  com‐
       promised.

       To  ensure that the boot archive is consistent, the normal system shut‐
       down process, as initiated by reboot(1M) and shutdown(1M),  checks  for
       and applies updates to the boot archive at the conclusion of the umoun‐
       tall(1M) milestone.

       An update to any kernel file, driver, module  or	 driver	 configuration
       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	umoun‐
       tall  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 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  particular  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 otherwise specified. This
	   option allows the default-file to be explicitly set and can be use‐
	   ful 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  exe‐
	   cutable or bootable object containing a boot block. The primary use
	   is to boot the failsafe or wanboot 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 instruc‐
	   tions 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 inter‐
	   preted  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  explic‐
	   itly specified, either on the boot command line or in the boot-file
	   NVRAM variable, boot chooses an appropriate default filename.

       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. Multi‐
	   ple property-value pairs must be separated by a comma. Use of  this
	   option  is the equivalent of the command: eeprom prop=val. See eep‐
	   rom(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 inter‐
	   preted 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.

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,	 Boot‐
       strap.  The INT 19h handler typically performs the standard PC-compati‐
       ble 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   executes  the  menu  file
       /boot/grub/menu.lst. 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 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 master 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 partition regardless of the active par‐
       tition.

       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  sub‐
       sequent 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 partition, the master boot  pro‐
       gram  (mboot) reads the partition boot program in the first sector into
       memory and jumps to it. It in turn reads GRUB stage2 program into  mem‐
       ory  and	 jumps	to  it.	 Once the GRUB menu is displayed, the user can
       choose to boot an operating system on a different partition, a  differ‐
       ent disk, or possibly from the network.

       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 boot‐
       strap program (pxegrub) on a boot server and  reads  it	using  Trivial
       File Transfer Protocol (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	speci‐
       fied by the console property.

       When  booting  from  UFS,  the root device is specified by the bootpath
       property, and the root file system type	is  specified  by  the	fstype
       property.   These   properties	should	 be   setup   by  the  Solaris
       Install/Upgrade process in /boot/solaris/bootenv.rc and can be overrid‐
       den 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  mod‐
       ule  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 Interactive 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

       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 pro‐
       cessed 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 network boot sup‐
       port package processes arguments in network-boot-arguments.

	 boot net:

       The command below results in no device arguments. rarp is the only net‐
       work 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 arguments in  network-boot-argu‐
       ments.

	 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 then drop  into  its
       command	interpreter to allow the user to enter keys and any other nec‐
       essary 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

	   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.

SEE ALSO
       kmdb(1), uname(1), bootadm(1M), eeprom(1M), init(1M),  installboot(1M),
       kernel(1M),  monitor(1M),  shutdown(1M), svcadm(1M), svccfg(1M), umoun‐
       tall(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

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

       RFC  2396,  Uniform  Resource  Identifiers   (URI):   Generic   Syntax,
       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.10			  16 May 2011			      boot(1M)
[top]

List of man pages available for Solaris

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net