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

FreeBSD Manual Pages

  
 
  

home | help
boot(1M)		System Administration Commands		      boot(1M)

NAME
       boot - start the	system kernel or a standalone program

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

       b [ device [ (c,	u, p)]]	[-afV]	[-D  default-file]  [boot-flags]  [--]
       [client-program-args]

   IA
       b [file]	[-f] [boot-args]

       i

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 filesystems	(see vfstab(4)), and runs /sbin/init to	bring the sys-
       tem 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 (when booting across	the network).

       Network Booting

       Network booting can follow either of two	paths, RARP/bootparams or DHCP
       (Dynamic	 Host  Configuration  Protocol),  depending  on	 the functions
       available in and	configuration of the PROM. Machines of the sun4u  ker-
       nel  architecture have DHCP-capable PROMs and boot from the network us-
       ing RARP/bootparams by default. Whichever network boot path  is	speci-
       fied, RARP or DHCP, is followed all the way through to multi-user mode;
       there is	no mixture of the RARP and DHCP	activities.

       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  makes  a
       reverse ARP request and when it receives	a reply, the PROM broadcasts a
       TFTP request to fetch inetboot over the network from  any  server  that
       responds	 and  executes it. inetboot also makes another reverse ARP re-
       quest, then uses	the bootparams protocol	(see bootparams(4)) to	locate
       its  root filesystem. It	then fetches the kernel	across the network us-
       ing the NFS protocol and	then executes 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 downloads inetboot, loads that file into memory,  and  exe-
       cutes  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	 the further activities	of the
       DHCP.

       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, the capabilities of the hardware and	 firmware,  and	 on  a
       user configurable policy	file (see FILES, below).

   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.

       The commands

       ok boot net

       and

       ok boot cdrom

       have no arguments; they will use	the settings  in  boot-file  or	 diag-
       file,  if they are set, as default filename and arguments and pass them
       to boot.	Accordingly, if	boot-file is set to the	64-bit kernel filename
       and  you	attempt	to boot	the installation CD with boot cdrom, boot will
       fail if the installation	CD contains only a 32-bit kernel.

       Since the contents of boot-file or diag-file may	be  ignored  depending
       on  the	form  of  the  boot  command used, reliance upon the boot-file
       should be discouraged for most production systems.  To  change  the  OS
       policy,	change the policy file.	A significant exception	is when	a pro-
       duction system has both 32-bit and 64-bit packages installed,  but  the
       production system requires use of the 32-bit OS.

       In most cases, it is best to allow the boot command to choose an	appro-
       priate  default	based  upon  the  system  type,	 system	 hardware  and
       firmware,  and upon what	is installed on	the root filesystem. It	is ac-
       cepted practice to augment the boot command's policy by	modifying  the
       policy  file; however, changing boot-file or diag-file may generate un-
       expected	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.

   IA Bootstrap	Procedure
       On  IA based systems, the bootstrapping process consists	of two concep-
       tually distinct phases, primary boot and	secondary  boot.  The  primary
       boot  is	 implemented in	the BIOS ROM on	the system board, and BIOS ex-
       tensions	in ROMs	on peripheral boards. It is distinguished by its abil-
       ity to control the installed peripheral devices and to provide I/O ser-
       vices through software interrupts. It begins  the  booting  process  by
       loading the first physical sector from a	floppy disk, hard disk,	or CD-
       ROM, or,	if supported by	the system or network adapter BIOS, by reading
       a bootstrap program from	a network boot server. The primary boot	is im-
       plemented in IA real-mode code.

       The secondary boot is loaded by the primary boot. It is implemented  in
       32-bit,	paged, protected mode code. It also loads and uses peripheral-
       specific	BIOS extensions	written	in IA real-mode	 code.	The  secondary
       boot  is	 called	 boot.bin and is capable of reading and	booting	from a
       UFS file	system on a hard disk or a CD or by way	of a LAN using the NFS
       protocol.

       The secondary boot is responsible for running the Configuration Assist-
       ant program which determines the	installed devices in the system	 (pos-
       sibly  with  help  from	the  user).  The secondary boot	then reads the
       script in /etc/bootrc, which controls the booting process.   This  file
       contains	boot interpreter commands, which are defined below, and	can be
       modified	to change defaults or to adapt to a specific machine.

       The standard /etc/bootrc	script prompts the user	to enter a b character
       to  boot	 with  specified  options, an i	character to invoke the	inter-
       preter interactively, or	any other character to boot the	 default  ker-
       nel.  Once  the kernel is loaded, it starts the operating system, loads
       the necessary  modules,	mounts	the  necessary	filesystems  (see  vf-
       stab(4)),  and  runs  /sbin/init	 to  bring the system to the ``initde-
       fault'' state specified in /etc/inittab.	See inittab(4).

OPTIONS
   SPARC
       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.

       file  Name  of  a  standalone program to	boot. If a filename is not ex-
	     plicitly specified, either	on the boot command  line  or  in  the
	     boot-file	NVRAM  variable,  boot	chooses	an appropriate default
	     filename. On most systems,	the default  filename  is  the	32-bit
	     kernel.  On  systems  capable  of	supporting both	the 32-bit and
	     64-bit kernels, the 64-bit	kernel will be chosen in preference to
	     the  32-bit  kernel.  boot	chooses	an appropriate default file to
	     boot based	on what	software is installed on the system, the capa-
	     bilities of the hardware and firmware, and	on a user configurable
	     policy file.

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

       -f    When booting an Autoclient	system,	this flag forces the boot pro-
	     gram  to  bypass the client's local cache and read	all files over
	     the network from the client's file	server.	This flag  is  ignored
	     for all non-Autoclient systems. The -f flag is then passed	to the
	     standalone	program.

       -V    Display verbose debugging information.

       -D default-file
	     Explicitly	 specify  the  default-file.  On  some	systems,  boot
	     chooses a dynamic default file, used when none is otherwise spec-
	     ified. This option	allows the default-file	to be  explicitly  set
	     and  can  be useful when booting kadb(1M) since, by default, kadb
	     loads the default-file as exported	by the boot program.

       boot-flags
	     The boot program passes all boot-flags to file. They are not  in-
	     terpreted	by  boot. See the kernel(1M) and kadb(1M) 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.

   IA
       file  Name of a standalone program to boot.  The	 default  is  to  boot
	     /platform/platform-name/kernel/unix  from the root	partition, but
	     you can specify another program on	the command line.

       -f    When booting an Autoclient	system,	this flag forces the boot pro-
	     gram  to  bypass the client's local cache and read	all files over
	     the network from the client's file	server.	This flag  is  ignored
	     for all non-Autoclient systems. The -f flag is then passed	to the
	     standalone	program.

       boot-args
	     The boot program passes all boot-args to file. They are  not  in-
	     terpreted	by  boot.  See kernel(1M) and kadb(1M) for information
	     about the options available with the kernel.

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

IA Primary Boot
       The  first  sector on a floppy disk contains the	master boot block. The
       boot block is responsible for loading the  image	 of  the  boot	loader
       strap.com, which	then loads the secondary boot, boot.bin. A similar se-
       quence occurs for CD-ROM	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, and jumps to	its first byte
       in memory. This completes the standard PC-compatible hard disk boot se-
       quence.

       An IA FDISK partition for the Solaris software begins with a one-cylin-
       der boot	slice, which contains the partition boot  program  (pboot)  in
       the  first  sector, the standard	Solaris	disk label and volume table of
       contents	(VTOC) in the second and third sectors,	and the	 bootblk  pro-
       gram in the fourth and subsequent sectors. 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 the bootblk program  into	memory
       and jumps to it.	Regardless of the type of the active partition,	if the
       drive contains multiple FDISK partitions, the user is given the	oppor-
       tunity to reboot	another	partition.

       bootblk	or  strap.com (depending upon the active partition type) reads
       boot.bin	from the file system in	the Solaris root slice	and  jumps  to
       its first byte in memory.

       For  network booting, you have the choice of the	boot floppy or Intel's
       Preboot eXecution Environment (PXE) standard.  When  booting  from  the
       network	using the boot floppy, you can select which network configura-
       tion strategy you want by editing the  boot  properties,	 changing  the
       setting for net-config-strategy.	By default, net-config-strategy	is set
       to rarp.	It can have two	settings, rarp or dhcp.	When booting from  the
       network	using PXE, the system or network adapter BIOS uses DHCP	to lo-
       cate a network bootstrap	program	(NBP) on  a boot server	and  reads  it
       using Trivial File Transfer Protocol (TFTP). The	BIOS  executes the NBP
       by jumping to its first byte in memory. The NBP uses DHCP to locate the
       secondary bootstrap on a	boot server, reads it using TFTP, and executes
       it.

IA Secondary Boot
       The secondary boot, boot.bin, switches the processor to 32-bit,	paged,
       protected  mode,	 and  performs some limited machine initialization. It
       runs the	Configuration Assistant	program	which  either  auto-boots  the
       system,	or  presents a list of possible	boot devices, depending	on the
       state of	the auto-boot? variable	(see eeprom(1M)).

       Disk target devices (including CDROM drives) are	 expected  to  contain
       UFS  filesystems.  Network devices can be configured to use either DHCP
       or Reverse Address Resolution Protocol (RARP)  and  bootparams  RPC  to
       discover	 the  machine's	 IP  address and which server will provide the
       root file system. The root file system is then mounted using NFS. After
       a  successful root mount, boot.bin invokes a command interpreter, which
       interprets /etc/bootrc.

   Secondary Boot Programming Language for IA
       The wide	range of hardware that must be supported on IA	based  systems
       demands	great  flexibility in the booting process. This	flexibility is
       achieved	in part	by making the secondary	boot  programmable.  The  sec-
       ondary  boot contains an	interpreter that accepts a simple command lan-
       guage similar to	those of sh and	csh. The primary differences are  that
       pipelines,  loops, standard output, and output redirection are not sup-
       ported.

   IA Lexical Structure
       The boot	interpreter splits input lines into words separated by	blanks
       and  tabs.  The	metacharacters	are dollar sign	($), single-quote ('),
       double-quote ("), number	sign (#), new-line, and	 backslash  (\).   The
       special meaning of metacharacters can be	avoided	by preceding them with
       a backslash. A new-line preceded	by a backslash is treated as a	blank.
       A  number  sign	introduces a comment, which continues to the next new-
       line.

       A string	enclosed in a pair of single-quote or double-quote  characters
       forms all or part of a single word. White space and new-line characters
       within a	quoted string become part of the  word.	 Characters  within  a
       quoted  string can be quoted by preceding them with a backslash charac-
       ter; thus a single-quote	character can appear in	a single-quoted	string
       by  preceding  it  with	a  backslash. Two backslashes produce a	single
       backslash, and a	new-line preceded by a backslash produces  a  new-line
       in the string.

   IA Variables
       The  boot  maintains  a	set  of	 variables, each of which has a	string
       value. The first	character of a variable	name must  be  a  letter,  and
       subsequent  characters  can be letters, digits, or underscores. The set
       command creates a variable and/or assigns a value to  it,  or  displays
       the values of variables.	The unset command deletes a variable.

       Variable	 substitution  is  performed when the interpreter encounters a
       dollar-sign that	is not preceded	by a backslash.	The variable name fol-
       lowing  the  dollar  sign is replaced by	the value of the variable, and
       parsing continues at the	beginning of the value.	Variable  substitution
       is  performed  in  double-quoted	 strings,  but	not  in	 single-quoted
       strings.	A variable name	can be enclosed	in braces to separate it  from
       following characters.

   IA Commands
       A  command  is  a sequence of words terminated by a new-line character.
       The first word is the name of the command and subsequent	words are  ar-
       guments	to the command.	All commands are built-in commands. Standalone
       programs	are executed with the run command.

   IA Conditional Execution of Commands
       Commands	can be conditionally executed by surrounding them with the if,
       elseif, else, and endif commands:

       if expr1
	   ...
       elseif expr2
	   ...
       elseif expr3
	   ...
       else
	   ...
       endif

       An if block may be embedded in other if blocks.

   IA Expressions
       The  set,  if, and elseif commands evaluate arithmetic expressions with
       the syntax and semantics	of the C programming language. The ||, &&,  |,
       ^,  &,  ==, !=, <, >, <=, >=, >>, <<, +,	-, *, /, %, ~, and ! operators
       are accepted, as	are (, ), and comma. Signed 32-bit integer  arithmetic
       is performed.

       Expressions  are	 parsed	 after	the full command line has been formed.
       Each token in an	expression must	be a separate argument word, so	blanks
       must separate all tokens	on the command line.

       Before  an  arithmetic operation	is performed on	an operand word, it is
       converted from a	string to a signed 32-bit integer value. After an  op-
       tional  leading sign, a leading 0 produces octal	conversion and a lead-
       ing 0x or 0X produces hexadecimal conversion. Otherwise,	 decimal  con-
       version	is  performed.	 A  string that	is not a legal integer is con-
       verted to zero.

       Several built-in	functions for string manipulation are provided.	Built-
       in function names begin with a dot. String arguments to these functions
       are not converted to integers. To cause an operator, for	example, -, to
       be  treated  as	a string, it must be preceded by a backslash, and that
       backslash must be quoted	with another backslash.	Also be	aware  that  a
       null string can produce a blank argument, and thus an expression	syntax
       error. For example:

       if .strneq ( ${usrarg}X , \- , 1	)

       is the safe way to test whether the variable usrarg starts  with	 a  -,
       even if it could	be null.

   IA I/O
       The  boot  interpreter  takes its input from the	system console or from
       one or more files. The source command causes the	interpreter to read  a
       file  into  memory and begin parsing it.	The console command causes the
       interpreter to take its input from the  system  console.	 Reaching  EOF
       causes  the  interpreter	 to  resume parsing the	previous input source.
       CTRL-D entered at the beginning of console line is treated as EOF.

       The echo	command	writes its arguments to	the display. The read  command
       reads  the system console and assigns word values to its	argument vari-
       ables.

   IA Debugging
       The verbose command turns verbose mode on and off. In verbose mode, the
       interpreter  displays  lines  from the current source file and displays
       the command as actually executed	after variable substitution.

       The singlestep command turns singlestep mode on and off.	In  singlestep
       mode,  the  interpreter displays	step ? before processing the next com-
       mand, and waits for keyboard input, which is discarded. Processing pro-
       ceeds  when  ENTER  is  pressed.	 This allows slow execution in verbose
       mode.

   IA Initialization
       When the	interpreter is first invoked by	the boot, it begins  execution
       of  a compiled-in initialization	string.	This string typically consists
       of "source /etc/bootrc\n" to run	the boot script	in the root file  sys-
       tem.

   IA Communication With Standalone Programs
       The boot	passes information to standalone programs through arguments to
       the run command.	A standalone program can pass information back to  the
       boot  by	 setting  a boot interpreter variable using the	var_ops() boot
       service function. It can	also pass information to the kernel using  the
       setprop() boot service function.	The whoami property is set to the name
       of the standalone program.

   IA Built-in Commands
       console
	     Interpret input from the console until CTRL-D.

       echo arg1 ...
	     Display the arguments separated by	blanks and  terminate  with  a
	     new-line.

       echo -n arg1 ...
	     Display  the  arguments separated by blanks, but do not terminate
	     with a new-line.

       getprop propname	varname
	     Assign the	value of property propname to the variable varname.  A
	     property  value  of  length  zero	produces a null	string.	If the
	     property does not exist, the variable is not set.

       getproplen propname varname
	     Assign the	length in hexadecimal of the value of  property	 prop-
	     name  to the variable varname. Property value lengths include the
	     terminating null. If the property does not	exist, the variable is
	     set to 0xFFFFFFFF (-1).

       if expr
	     If	 the expression	expr is	true, execute instructions to the next
	     elseif, else, or endif. If	expr is	false, do not execute the  in-
	     structions.

       elseif expr
	     If	 the  preceding	if and elseif commands all failed, and expr is
	     true, execute instructions	to the next elseif,  else,  or	endif.
	     Otherwise,	do not execute the instructions.

       else  If	 the  preceding	if and elseif commands all failed, execute in-
	     structions	to the next elseif, else, or endif. Otherwise, do  not
	     execute the instructions.

       endif Revert to the execution mode of the surrounding block.

       help  Display  a	 help  screen that contains summaries of all available
	     boot shell	commands.

       read name1 ...
	     Read a line from the console, break it  into  words,  and	assign
	     them as values to the variables name1, and	so forth.

       readt time ...
	     Same as read, but timeout after time seconds.

       run name	arg1 ...
	     Load and transfer control to the standalone program name, passing
	     it	arg1 and further arguments.

       set   Display all the current variables and their values.

       set name
	     Set the value of the variable name	to the null string.

       set name	word
	     Set the value of the variable name	to word.

       set name	expr
	     Set the value of the variable name	to the	value  of  expr.  expr
	     must  consist  of more than one word. The value is	encoded	in un-
	     signed hexadecimal, so that -1 is represented by 0xFFFFFFFF.

       setcolor
	     Set the text mode display attributes. Allowable colors are	black,
	     blue,  green,  cyan,  red,	 magenta, brown, white,	gray, lt_blue,
	     lt_green, lt_cyan,	lt_red,	lt_magenta, yellow, and	hi_white.

       setprop propname	word
	     Set the value of the property propname to word.

       singlestep or singlestep	on
	     Turn on singlestep	mode, in which the interpreter displays	step ?
	     before  each  command is processed, and waits for keyboard	input.
	     Press ENTER to execute the	next command.

       singlestep off
	     Turn off singlestep mode.

       source name
	     Read the file name	into memory and	begin to interpret it. At EOF,
	     return to the previous source of input.

       unset name
	     Delete the	variable name.

       verbose or verbose on
	     Turn  on verbose mode, which displays lines from source files and
	     commands to be executed.

       verbose off
	     Turn off verbose mode.

   IA Built-in Functions
       The following built-in functions	are accepted within expressions:

       .strcmp(string1,	string2)
	     Returns an	integer	value that is less than, equal to, or  greater
	     than  zero,  as string1 is	lexicographically less than, equal to,
	     or	greater	than string2.

       .strncmp(string1, string2, n)
	     Returns an	integer	value that is less than, equal to, or  greater
	     than  zero,  as string1 is	lexicographically less than, equal to,
	     or	greater	than string2. At most, n characters are	compared.

       .streq (string1,	string2)
	     Returns true if string1 is	equal to string2, and false otherwise.

       .strneq (string1, string2, n)
	     Returns true if string1 is	equal to string2, and false otherwise.
	     At	most, n	characters are compared.

       .strfind	(string, addr, n)
	     Scans n locations in memory starting at addr, looking for the be-
	     ginning of	string.	The string in memory need not  be  null-termi-
	     nated.  Returns  true  if	string	is found, and false otherwise.
	     .strfind can be used to search for	strings	in the	ROM  BIOS  and
	     BIOS  extensions  that identify different machines	and peripheral
	     boards.

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

   32-bit SPARC
       Example	2:  To	Boot  kadb Specifying The 32-Bit Kernel	As The Default
       File

       To boot kadb specifying the 32-bit kernel as the	default	file:

       boot kadb -D kernel/unix

       Example 3: To Boot the 32-Bit Kernel Explicitly

       To boot the 32-bit kernel explicitly, the kernel	file  name  should  be
       specified.  So,	to  boot  the 32-bit kernel in single-user interactive
       mode, respond to	the ok prompt with one of the following:

       boot kernel/unix	-as

       boot disk3 kernel/unix -as

   64-bit SPARC
       Example 4: To Boot the 64-Bit Kernel Explicitly

       To boot the 64-bit kernel explicitly, the kernel	file  name  should  be
       specified.  So,	to  boot  the 64-bit kernel in single-user interactive
       mode, respond to	the ok prompt with one of the following:

       boot kernel/sparcv9/unix	-as

       boot disk3 kernel/sparcv9/unix -as
       Refer to	the NOTES section "Booting UltraSPARC Systems" before  booting
       the 64-bit kernel using an explicit filename.

   IA
       Example 5: To Boot the Default Kernel In	Single-User Interactive	Mode

       To  boot	the default kernel in single-user interactive mode, respond to
       the > prompt with one of	the following:

       b -as

       b kernel/unix -as

FILES
	      /platform/platform-name/ufsboot
		    second level program to boot from a	disk or	CD.

	      /etc/inittab
		    table in which the "initdefault" state is specified.

	      /sbin/init
		    program that brings	the system to the "initdefault"	state.

	      /platform/platform-name/boot.conf

	      /platform/hardware-class-name/boot.conf
		    Primary and	alternate pathnames for	the boot policy	 file.
		    Note  that the policy file is not implemented on all plat-
		    forms.

   32-bit SPARC	and IA
       /platform/platform-name/kernel/unix
	     default program to	boot system.

   64-bit SPARC	only
       /platform/platform-name/kernel/sparcv9/unix
	     default program to	boot system.

	     See NOTES section "Booting	UltraSPARC Systems."

   IA Only
       /etc/bootrc
	     script that controls the booting process.

       /platform/platform-name/boot/solaris/boot.bin
	     second level boot program used on IA systems in place of ufsboot.

       /platform/platform-name/boot
	     directory containing boot-related files.

SEE ALSO
       uname(1), eeprom(1M), init(1M), installboot(1M),	kadb(1M),  kernel(1M),
       shutdown(1M), uadmin(2),	bootparams(4), inittab(4), vfstab(4), filesys-
       tem(5)

       System Administration Guide: Basic Administration

       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.

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

   64-bit SPARC
   Booting UltraSPARC Systems
       Certain platforms may need a firmware upgrade to	run the	64-bit kernel.
       See  the	 Sun Hardware Platform Guide for details. If the 64-bit	kernel
       packages	are installed and boot	detects	 that  the  platform  needs  a
       firmware	 upgrade to run	64-bit,	boot displays a	message	on the console
       and chooses the 32-bit kernel as	the default file instead.

       On systems containing 200MHz or lower UltraSPARC-1  processors,	it  is
       possible	for a user to run a 64-bit program designed to exploit a prob-
       lem that	could cause a processor	to stall. Since	64-bit progams	cannot
       run  on	the  32-bit kernel, the	32-bit kernel is chosen	as the default
       file on these systems.

       The code	sequence that exploits the problem is very unusual and is  not
       likely to be generated by a compiler. Assembler code had	to be specifi-
       cally written to	demonstrate the	problem. It is highly unlikely that  a
       legitimate handwritten assembler	routine	would use this code sequence.

       Users  willing to assume	the risk that a	user might accidentally	or de-
       liberately run a	program	that was designed  to  cause  a	 processor  to
       stall  may choose to run	the 64-bit kernel by modifying the boot	policy
       file. Edit /platform/platform-name/boot.conf so that it contains	an un-
       commented  line	with  the  variable named ALLOW_64BIT_KERNEL_ON_Ultra-
       SPARC_1_CPU set to the value true as shown in the example that follows:

       ALLOW_64BIT_KERNEL_ON_UltraSPARC_1_CPU=true

       For more	information, see the Sun Hardware Platform Guide.

   IA Only
       Because the ``-'' key on	national language keyboards has	been moved, an
       alternate  key  must be used to supply arguments	to the boot command on
       an IA based system using	these keyboards. Use the ``-'' on the  numeric
       keypad. The specific language keyboard and the alternate	key to be used
       in place	of the ``-'' during bootup is shown below.

	      Keyboard
		    Substitute Key

	      Italy '

	      Spain '

	      Sweden
		    +

	      France
		    ?

	      Germany
		    ?

       For example, b -r would be typed	as b +r	on Swedish keyboards, although
       the screen display will show as b -r.

SunOS 5.9			  23 Feb 2001			      boot(1M)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | IA BOOT SEQUENCE DETAILS | IA Primary Boot | IA Secondary Boot | EXAMPLES | FILES | SEE ALSO | WARNINGS | NOTES

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

home | help