Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
boot(1M)							      boot(1M)

NAME
       boot - start the	system kernel or a standalone program

SYNOPSIS
   SPARC
       boot  [	OBP  names]  [file]  [-aV] [-D default-file] [boot-flags] [--]
       [client-program-args]

       kernel multiboot	[file] [boot-args] [-B prop=val	[,val...]]

       i

       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 ufsboot (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 ad-
       dress and any other parameters necessary	to permit it to	load the  sec-
       ond-stage  booter.  The second-stage booter in turn loads the UNIX ker-
       nel.

       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  kernel  architecture  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 de-
       scribed 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	kernel via NFS
       and transfers control to	it.

       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 invokes the	kernel,	 which
       loads  the  files  it needs 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 pro-
       ceeding to execute it. The file is expected to be the  wanboot  binary.
       When wanboot begins executing, it will determine	whether	sufficient in-
       formation is available to it to allow it	to proceed. 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 necessary information, it
       will load its boot file system into memory by means of HTTP. If an  en-
       cryption	key has	been installed on the client, wanboot will decrypt the
       file system image and its accompanying hash (presence of	an  encryption
       key  but	 no  hashing  key is an	error),	then verify the	hash. The boot
       file system contains various configuration data needed to allow wanboot
       to set the correct time and proceed to obtain a root file system.

       The  boot  file	system is examined to determine	whether	wanboot	should
       use HTTP	or secure HTTP.	If the former, and if the client has been con-
       figured with an HMAC SHA-1 key, wanboot 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), wanboot loads
       and executes UNIX from it. 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  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 be-
       low.

       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 (de-
       fault) values of	the parameters and then	continue booting.

       Booting from Disk

       When booting from disk (or disk-like device), the bootstrapping process
       consists	 of  two  conceptually	distinct phases, primary boot and sec-
       ondary boot. In the primary boot	phase, the PROM	loads the primary boot
       block  from  blocks  1 to 15 of the disk	partition selected as the boot
       device.

       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.

       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 ap-
       propriate  default  file	to load	based on what software is installed on
       the system and the capabilities of the hardware and firmware.

   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 op-
       tional 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 ex-
       ample, 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  re-
       quired  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  at-
       tribute 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-arguments.

       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 im-
       plies 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  ad-
       dress, the name of the boot file, and the address of the	server provid-
       ing 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  ad-
       dress  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 as-
	       signed 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. De-
       faults 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. De-
       faults to of using infinite retries.

    Bootstrap Procedure
       On  based systems, the bootstrapping process consists of	two  conceptu-
       ally  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	floppy disk, 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 commands in
       a menu to load a	pre-constructed	boot archive containing	kernel program
       and data. GRUB also loads a small program called	"multiboot", which im-
       plements	the kernel side	of the Multiboot Specification.

       Kernel initialization starts when GRUB finishes loading	the  boot  ar-
       chive  and  hands control over to the multiboot program.	At this	point,
       GRUB becomes inactive and no more I/O occurs with the boot device.  The
       multiboot  program assembles the	core kernel modules and	starts the op-
       erating system, links in	the necessary modules from  the	 boot  archive
       and  mounts the root filesystem on the real root	device.	At this	point,
       the kernel regains storage I/O, mounts additional file systems (see vf-
       stab(4)), and starts various operating system services (see smf(5)).

   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.

       -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 in-
	   formation  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.

       The following  options are supported:

       -B prop=val...

	   One or more property-value pairs to be passed to the	multiboot pro-
	   gram.  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.

       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.

       file

	   Name	of a standalone	program	to boot. The default is	to boot	/plat-
	   form/i86pc/kernel/unix  (/platform/i86pc/kernel/amd64/unix  if  the
	   CPU is 64-bit capable) from the root	partition, but you can specify
	   another program on the command line.

       multiboot

	   Name	of the multiboot program loaded	by GRUB. The default  name  is
	   /platform/i86pc/multiboot. This name	should not be changed.

 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.

 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 di-
       rectly from the Solaris FDISK partition regardless of the active	parti-
       tion.

       An  FDISK partition for the Solaris software begins with	a one-cylinder
       boot  slice,  which contains GRUB stage1	in the first sector, the stan-
       dard Solaris disk label and volume table	of contents (VTOC) in the sec-
       ond  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  partition,  the master boot program
       (mboot) reads the partition boot	program	in the first sector into  mem-
       ory  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.

       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.

 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. The root device is	specified by the boot-
       path  property, and the root filesystem type is specified by the	fstype
       property. These properties should be setup by the  Solaris  Install/Up-
       grade  process  in  /boot/solaris/bootenv.rc and	can be overridden with
       the -B option, described	above (see the eeprom(1M) man  page).  If  the
       properties  are	not  present,  console I/O defaults to screen and key-
       board. The root device defaults to ramdisk and the filesystem  defaults
       to ufs.

   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

    (32-bit)
       Example 4: To Boot the Default Kernel In	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/multiboot	kernel/unix -as

    (64-bit Only)
       Example 5: To Boot the Default Kernel In	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/multiboot	kernel/amd64/unix -as

       Example 6: Switching Between 32-bit and 64-bit Kernels on 64-bit	 Plat-
       form

       The default value of  the  boot-file  eeprom(1M)	 variable  is  a  null
       string,	which allows the secondary booter to select the	kernel,	32-bit
       or 64-bit, appropriate for your system's	hardware. If you want to spec-
       ify one kernel or the other, use	the following steps.

       To  specify  the	 32-bit	kernel,	as root	or with	equivalent privileges,
       enter:

       # eeprom	boot-file kernel/unix

       Upon the	next reboot, your system will be running the 32-bit kernel.

       Alternatively, you can specify the 32-bit kernel	in the GRUB menu:

       kernel /platform/i86pc/multiboot	kernel/unix

       To specify the 64-bit kernel, as	root or	 with  equivalent  privileges,
       enter:

       # eeprom	boot-file kernel/amd64/unix

       Upon the	next reboot, your system will be running the 64-bit kernel.

       Alternatively, you can specify the 64-bit kernel	in the GRUB menu:

       kernel /platform/i86pc/multiboot	kernel/amd64/unix

       To  return  the boot-file variable to its default value,	a null string,
       so that the secondary booter selects the	kernel	appropriate  for  your
       system's	hardware, enter:

       # eeprom	boot-file ""

       You  can	 determine  the	 current value of the boot-file	variable, as a
       non-privileged user, by entering:

       % eeprom	boot-file

       See eeprom(1M) for details on that command.

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

    Only
       /boot

	   Directory containing	boot-related files.

       /platform/i86pc/multiboot

	   kernel program implementing the kernel side of the Multiboot	Speci-
	   fication.

       /platform/i86pc/kernel/unix

	   Default program to boot system.

   64-bit  Only
       /platform/i86pc/kernel/amd64/unix

	   Default program to boot system.

       kmdb(1),	 uname(1),  eeprom(1M),	init(1M), installboot(1M), kernel(1M),
       monitor(1M), shutdown(1M), uadmin(2),  bootparams(4),  inittab(4),  vf-
       stab(4),	wanboot.conf(4), filesystem(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 re-
       quested,	the boot utility loads it and branches to it. What happens af-
       ter that	is unpredictable.

       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.

				  24 May 2005			      boot(1M)

NAME | SYNOPSIS | WARNINGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=boot&sektion=1m&manpath=SunOS+5.10>

home | help