|
Hopefully, this page is exactly what you are looking for, but if not, you can always find further assistance on Unix/Linux Forum!
System Administration Commands 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]
x86
kernel multiboot [file] [boot-args] [-B prop=val [,val...]]
i
DESCRIPTION
Bootstrapping is the process of loading and executing a
standalone program. For the purpose of this discussion,
bootstrapping means the process of loading and executing the
bootable operating system. Typically, the standalone program
is the operating system kernel (see kernel(1M)), but any
standalone program can be booted instead. On a SPARC-based
system, the diagnostic monitor for a machine is a good exam-
ple of a standalone program other than the operating system
that can be booted.
If the standalone is identified as a dynamically-linked exe-
cutable, boot will load the interpreter (linker/loader) as
indicated by the executable format and then transfer control
to the interpreter. If the standalone is statically-linked,
it will jump directly to the standalone.
Once the kernel is loaded, it starts the UNIX system, mounts
the necessary file systems (see vfstab(4)), and runs
/sbin/init to bring the system to the "initdefault" state
specified in /etc/inittab. See inittab(4).
SPARC Bootstrap Procedure
On SPARC based systems, the bootstrap procedure on most
machines consists of the following basic phases.
After the machine is turned on, the system firmware (in
PROM) executes power-on self-test (POST). The form and scope
of these tests depends on the version of the firmware in
your system.
After the tests have been completed successfully, the
firmware attempts to autoboot if the appropriate flag has
been set in the non-volatile storage area used by the
firmware. The name of the file to load, and the device to
load it from can also be manipulated.
These flags and names can be set using the eeprom(1M) com-
mand from the shell, or by using PROM commands from the ok
SunOS 5.10 Last change: 24 May 2005 1
System Administration Commands boot(1M)
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 address and any other parameters necessary to
permit it to load the second-stage booter. The second-stage
booter in turn loads the UNIX kernel.
An IP address can be obtained in one of three ways: RARP,
DHCP, or manual configuration, depending on the functions
available in and configuration of the PROM. Machines of the
sun4u kernel architecture have DHCP-capable PROMs.
The boot command syntax for specifying the two methods of
network booting are:
boot net:rarp
boot net:dhcp
The command:
boot net
without a rarp or dhcp specifier, invokes the default method
for network booting over the network interface for which net
is an alias.
The sequence of events for network booting using
RARP/bootparams is described in the following paragraphs.
The sequence for DHCP follows the RARP/bootparams descrip-
tion.
When booting over the network using RARP/bootparams, the
PROM begins by broadcasting a reverse ARP request until it
receives a reply. When a reply is received, the PROM then
broadcasts a TFTP request to fetch the first block of inet-
boot. Subsequent requests will be sent to the server that
initially answered the first block request. After loading,
inetboot will also use reverse ARP to fetch its IP address,
then broadcast bootparams RPC calls (see bootparams(4)) to
locate configuration information and its root file system.
inetboot then loads the kernel via NFS and transfers control
to it.
When booting over the network using DHCP, the PROM broad-
casts the hardware address and kernel architecture and
requests an IP address, boot parameters, and network
SunOS 5.10 Last change: 24 May 2005 2
System Administration Commands boot(1M)
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 proceeding to execute
it. The file is expected to be the wanboot binary. When
wanboot begins executing, it will determine whether suffi-
cient information 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 wan-
boot has obtained the necessary information, it will load
its boot file system into memory by means of HTTP. If an
encryption 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 wan-
boot should use HTTP or secure HTTP. If the former, and if
the client has been configured with an HMAC SHA-1 key, wan-
boot will perform an integrity check of the root file sys-
tem. Once the root file system has been loaded into memory
(and possibly had an integrity check performed), wanboot
loads and executes UNIX from it. If provided with a
boot_logger URL by means of the wanboot.conf(4) file, wan-
boot will periodically log its progress.
Not all PROMs are capable of consuming URLs. You can deter-
mine whether a client is so capable using the list-
security-keys OBP command (see monitor(1M)).
WAN booting is not currently available on the x86 platform.
The wanboot Command Line
When the client program is wanboot, it accepts client-
program-args of the form:
SunOS 5.10 Last change: 24 May 2005 3
System Administration Commands boot(1M)
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-program-args of "-o prompt" when booting. Input con-
sists of single commands or assignments, or a comma-
separated list of commands or assignments. The configuration
parameters are:
host-ip
IP address of the client (in dotted-decimal notation)
router-ip
IP address of the default router (in dotted-decimal
notation)
subnet-mask
subnet mask (in dotted-decimal notation)
SunOS 5.10 Last change: 24 May 2005 4
System Administration Commands boot(1M)
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:
SunOS 5.10 Last change: 24 May 2005 5
System Administration Commands boot(1M)
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
SunOS 5.10 Last change: 24 May 2005 6
System Administration Commands boot(1M)
parameters and then continue booting.
Booting from Disk
When booting from disk (or disk-like device), the bootstrap-
ping process consists of two conceptually distinct phases,
primary boot and secondary 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 platform-dependent search path. This path is
guaranteed to contain /platform/platform-name. Many SPARC
platforms next search the platform-specific path entry
/platform/hardware-class-name. See filesystem(5). If the
pathname is absolute, boot will use the specified path. The
boot program then loads the standalone at the appropriate
address, and then transfers control.
If the filename is not given on the command line or other-
wise specified, for example, by the boot-file NVRAM vari-
able, boot chooses an appropriate default file to load based
on what software is installed on the system and the capabil-
ities of the hardware and firmware.
OpenBoot PROM boot Command Behavior
The OpenBoot boot command takes arguments of the following
form:
ok boot [device-specifier] [arguments]
The default boot command has no arguments:
ok boot
If no device-specifier is given on the boot command line,
OpenBoot typically uses the boot-device or diag-device NVRAM
variable. If no optional arguments are given on the command
line, OpenBoot typically uses the boot-file or diag-file
NVRAM variable as default boot arguments. (If the system is
in diagnostics mode, diag-device and diag-file are used
instead of boot-device and boot-file).
arguments may include more than one string. All argument
strings are passed to the secondary booter; they are not
interpreted by OpenBoot.
If any arguments are specified on the boot command line,
then neither the boot-file nor the diag-file NVRAM variable
SunOS 5.10 Last change: 24 May 2005 7
System Administration Commands boot(1M)
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 appropriate default based upon the sys-
tem type, system hardware and firmware, and upon what is
installed on the root file system. Changing boot-file or
diag-file can generate unexpected results in certain cir-
cumstances.
This behavior is found on most OpenBoot 2.x and 3.x based
systems. Note that differences may occur on some platforms.
The command:
ok boot cdrom
...also normally takes no arguments. Accordingly, if boot-
file is set to the 64-bit kernel filename and you attempt to
boot the installation CD or DVD with boot cdrom, boot will
fail if the installation media contains only a 32-bit ker-
nel.
Because the contents of boot-file or diag-file can be
ignored depending on the form of the boot command used,
reliance upon boot-file should be discouraged for most pro-
duction systems.
When executing a WAN boot from a local (CD or DVD) copy of
wanboot, one must use:
ok boot cdrom -F wanboot - install
Modern PROMs have enhanced the network boot support package
to support the following syntax for arguments to be pro-
cessed by the package:
SunOS 5.10 Last change: 24 May 2005 8
System Administration Commands boot(1M)
[protocol,] [key=value,]*
All arguments are optional and can appear in any order. Com-
mas are required unless the argument is at the end of the
list. If specified, an argument takes precedence over any
default values, or, if booting using DHCP, over configura-
tion information provided by a DHCP server for those parame-
ters.
protocol, above, specifies the address discovery protocol to
be used.
Configuration parameters, listed below, are specified as
key=value attribute pairs.
tftp-server
IP address of the TFTP server
file
file to download using TFTP or URL for WAN boot
host-ip
IP address of the client (in dotted-decimal notation)
router-ip
IP address of the default router
subnet-mask
subnet mask (in dotted-decimal notation)
client-id
DHCP client identifier
SunOS 5.10 Last change: 24 May 2005 9
System Administration Commands boot(1M)
hostname
hostname to use in DHCP transactions
http-proxy
HTTP proxy server specification (IPADDR[:PORT])
tftp-retries
maximum number of TFTP retries
dhcp-retries
maximum number of DHCP retries
The list of arguments to be processed by the network boot
support package is specified in one of two ways:
o As arguments passed to the package's open method, or
o arguments listed in the NVRAM variable network-boot-
arguments.
Arguments specified in network-boot-arguments will be pro-
cessed only if there are no arguments passed to the
package's open method.
Argument Values
protocol specifies the address discovery protocol to be
used. If present, the possible values are rarp or dhcp.
If other configuration parameters are specified in the new
syntax and style specified by this document, absence of the
protocol parameter implies manual configuration.
If no other configuration parameters are specified, or if
those arguments are specified in the positional parameter
syntax currently supported, the absence of the protocol
parameter causes the network boot support package to use the
platform-specific default address discovery protocol.
SunOS 5.10 Last change: 24 May 2005 10
System Administration Commands boot(1M)
Manual configuration requires that the client be provided
its IP address, the name of the boot file, and the address
of the server providing the boot file image. Depending on
the network configuration, it might be required that
subnet-mask and router-ip also be specified.
If the protocol argument is not specified, the network boot
support package uses the platform-specific default address
discovery protocol.
tftp-server is the IP address (in standard IPv4 dotted-
decimal notation) of the TFTP server that provides the file
to download if using TFTP.
When using DHCP, the value, if specified, overrides the
value of the TFTP server specified in the DHCP response.
The TFTP RRQ is unicast to the server if one is specified as
an argument or in the DHCP response. Otherwise, the TFTP RRQ
is broadcast.
file specifies the file to be loaded by TFTP from the TFTP
server, or the URL if using HTTP. The use of HTTP is trig-
gered if the file name is a URL, that is, the file name
starts with http: (case-insensitive).
When using RARP and TFTP, the default file name is the ASCII
hexadecimal representation of the IP address of the client,
as documented in a preceding section of this document.
When using DHCP, this argument, if specified, overrides the
name of the boot file specified in the DHCP response.
When using DHCP and TFTP, the default file name is con-
structed from the root node's name property, with commas (,)
replaced by periods (.).
When specified on the command line, the filename must not
contain slashes (/).
The format of URLs is described in RFC 2396. The HTTP server
must be specified as an IP address (in standard IPv4
dotted-decimal notation). The optional port number is speci-
fied in decimal. If a port is not specified, port 80
(decimal) is implied.
The URL presented must be "safe-encoded", that is, the pack-
age does not apply escape encodings to the URL presented.
URLs containing commas must be presented as a quoted string.
Quoting URLs is optional otherwise.
SunOS 5.10 Last change: 24 May 2005 11
System Administration Commands boot(1M)
host-ip specifies the IP address (in standard IPv4 dotted-
decimal notation) of the client, the system being booted. If
using RARP as the address discovery protocol, specifying
this argument makes use of RARP unnecessary.
If DHCP is used, specifying the host-ip argument causes the
client to follow the steps required of a client with an
"Externally Configured Network Address", as specified in RFC
2131.
router-ip is the IP address (in standard IPv4 dotted-decimal
notation) of a router on a directly connected network. The
router will be used as the first hop for communications
spanning networks. If this argument is supplied, the router
specified here takes precedence over the preferred router
specified in the DHCP response.
subnet-mask (specified in standard IPv4 dotted-decimal nota-
tion) is the subnet mask on the client's network. If the
subnet mask is not provided (either by means of this argu-
ment or in the DHCP response), the default mask appropriate
to the network class (Class A, B, or C) of the address
assigned to the booting client will be assumed.
client-id specifies the unique identifier for the client.
The DHCP client identifier is derived from this value.
Client identifiers can be specified as:
o The ASCII hexadecimal representation of the identifier,
or
o a quoted string
Thus, client-id="openboot" and client-id=6f70656e626f6f74
both represent a DHCP client identifier of 6F70656E626F6F74.
Identifiers specified on the command line must must not
include slash (/) or spaces.
The maximum length of the DHCP client identifier is 32
bytes, or 64 characters representing 32 bytes if using the
ASCII hexadecimal form. If the latter form is used, the
number of characters in the identifier must be an even
number. Valid characters are 0-9, a-f, and A-F.
For correct identification of clients, the client identifier
must be unique among the client identifiers used on the sub-
net to which the client is attached. System administrators
are responsible for choosing identifiers that meet this
requirement.
SunOS 5.10 Last change: 24 May 2005 12
System Administration Commands boot(1M)
Specifying a client identifier on a command line takes pre-
cedence over any other DHCP mechanism of specifying identif-
iers.
hostname (specified as a string) specifies the hostname to
be used in DHCP transactions. The name might or might not be
qualified with the local domain name. The maximum length of
the hostname is 255 characters.
Note - The hostname parameter can be used in service
environments that require that the client provide
the desired hostname to the DHCP server. Clients
provide the desired hostname to the DHCP server,
which can then register the hostname and IP address
assigned to the client with DNS.
http-proxy is specified in the following standard notation
for a host:
host [":"" port]
...where host is specified as an IP ddress (in standard IPv4
dotted-decimal notation) and the optional port is specified
in decimal. If a port is not specified, port 8080 (decimal)
is implied.
tftp-retries is the maximum number of retries (specified in
decimal) attempted before the TFTP process is determined to
have failed. Defaults to using infinite retries.
dhcp-retries is the maximum number of retries (specified in
decimal) attempted before the DHCP process is determined to
have failed. Defaults to of using infinite retries.
x86 Bootstrap Procedure
On x86 based systems, the bootstrapping process consists of
two conceptually distinct phases, kernel loading and kernel
initialization. Kernel loading is implemented in GRUB (GRand
Unified Bootloader) using the BIOS ROM on the system board,
and BIOS extensions in ROMs on peripheral boards. The BIOS
loads GRUB, starting with the first physical sector from a
floppy disk, hard disk, DVD, or CD. If supported by the ROM
on the network adapter, the BIOS can also download the pxe-
grub 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
implements the kernel side of the Multiboot Specification.
Kernel initialization starts when GRUB finishes loading the
boot archive and hands control over to the multiboot
SunOS 5.10 Last change: 24 May 2005 13
System Administration Commands boot(1M)
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 operating
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 addi-
tional file systems (see vfstab(4)), and starts various
operating system services (see smf(5)).
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 useful 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 interpreted by boot. See the kernel(1M) and kmdb(1)
manual pages for information about the options available
with the default standalone program.
client-program-args
The boot program passes all client-program-args to file.
They are not interpreted by boot.
SunOS 5.10 Last change: 24 May 2005 14
System Administration Commands boot(1M)
file
Name of a standalone program to boot. If a filename is
not explicitly specified, either on the boot command
line or in the boot-file NVRAM variable, boot chooses an
appropriate default filename.
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.
x86
The following x86 options are supported:
-B prop=val...
One or more property-value pairs to be passed to the
multiboot program. 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 interpreted 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 /platform/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
SunOS 5.10 Last change: 24 May 2005 15
System Administration Commands boot(1M)
Name of the multiboot program loaded by GRUB. The
default name is /platform/i86pc/multiboot. This name
should not be changed.
x86 BOOT SEQUENCE DETAILS
After a PC-compatible machine is turned on, the system
firmware in the BIOS ROM executes a power-on self test
(POST), runs BIOS extensions in peripheral board ROMs, and
invokes software interrupt INT 19h, Bootstrap. The INT 19h
handler typically performs the standard PC-compatible boot,
which consists of trying to read the first physical sector
from the first diskette drive, or, if that fails, from the
first hard disk. The processor then jumps to the first byte
of the sector image in memory.
x86 Primary Boot
The first sector on a floppy disk contains the master boot
block (GRUB stage1). The stage 1 is responsible for loading
GRUB stage2. Now GRUB is fully functional. It reads and exe-
cutes the menu file /boot/grub/menu.lst. A similar sequence
occurs for DVD or CD boot, but the master boot block loca-
tion and contents are dictated by the El Torito specifica-
tion. The El Torito boot also leads to strap.com, which in
turn loads boot.bin.
The first sector on a hard disk contains the master boot
block, which contains the master boot program and the FDISK
table, named for the PC program that maintains it. The mas-
ter boot finds the active partition in the FDISK table,
loads its first sector (GRUB stage1), and jumps to its first
byte in memory. This completes the standard PC-compatible
hard disk boot sequence. If GRUB stage1 is installed on the
master boot block (see the -m option of installgrub(1M)),
then stage2 is loaded directly from the Solaris FDISK parti-
tion regardless of the active partition.
An x86 FDISK partition for the Solaris software begins with
a one-cylinder boot slice, which contains GRUB stage1 in the
first sector, the standard Solaris disk label and volume
table of contents (VTOC) in the second and third sectors,
and GRUB stage2 in the fiftieth and subsequent sectors. The
area from sector 4 to 49 might contain boot blocks for older
versions of Solaris. This makes it possible for multiple
Solaris releases on the same FDISK to coexist. When the
FDISK partition for the Solaris software is the active par-
tition, the master boot program (mboot) reads the partition
boot program in the first sector into memory and jumps to
it. It in turn reads GRUB stage2 program into memory and
jumps to it. Once the GRUB menu is displayed, the user can
choose to boot an operating system on a different partition,
SunOS 5.10 Last change: 24 May 2005 16
System Administration Commands boot(1M)
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 bootstrap program (pxegrub) on a
boot server and reads it using Trivial File Transfer Proto-
col (TFTP). The BIOS executes the pxegrub by jumping to its
first byte in memory. The pxegrub program downloads a menu
file and presents the entries to user.
x86 Kernel Startup
The kernel startup process is independent of the kernel
loading process. During kernel startup, console I/O goes to
the device specified by the console property. The root dev-
ice is specified by the bootpath property, and the root
filesystem 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 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 keyboard. The root device defaults to
ramdisk and the filesystem 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 processed by the device driver. The network boot
support package processes arguments in network-boot-
arguments.
boot net
The command below results in no device arguments. The net-
work boot support package processes arguments in network-
SunOS 5.10 Last change: 24 May 2005 17
System Administration Commands boot(1M)
boot-arguments.
boot net:
The command below results in no device arguments. rarp is
the only network boot support package argument. network-
boot-arguments is ignored.
boot net:rarp
In the command below, the specified device arguments are
honored. The network boot support package processes argu-
ments in network-boot-arguments.
boot net:speed=100,duplex=full
Example 3: Using wanboot with Older PROMs
The command below results in the wanboot binary being loaded
from DVD or CD, at which time wanboot will perform DHCP and
then drop into its command interpreter to allow the user to
enter keys and any other necessary configuration.
boot cdrom -F wanboot -o dhcp,prompt
x86 (32-bit)
Example 4: To Boot the Default Kernel In 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
x86 (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 x86 Platform
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 specify one kernel or the other,
use the following steps.
SunOS 5.10 Last change: 24 May 2005 18
System Administration Commands boot(1M)
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 vari-
able, as a non-privileged user, by entering:
% eeprom boot-file
See eeprom(1M) for details on that command.
FILES
/platform/platform-name/ufsboot
Second-level program to boot from a disk, DVD, or CD
SunOS 5.10 Last change: 24 May 2005 19
System Administration Commands boot(1M)
/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.
/platform/i86pc/multiboot
kernel program implementing the kernel side of the Mul-
tiboot Specification.
/platform/i86pc/kernel/unix
Default program to boot system.
64-bit x86 Only
/platform/i86pc/kernel/amd64/unix
Default program to boot system.
SEE ALSO
kmdb(1), uname(1), eeprom(1M), init(1M), installboot(1M),
kernel(1M), monitor(1M), shutdown(1M), uadmin(2), boot-
params(4), inittab(4), vfstab(4), wanboot.conf(4), filesys-
tem(5)
SunOS 5.10 Last change: 24 May 2005 20
System Administration Commands boot(1M)
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 Syn-
tax, http://www.ietf.org/rfc/rfc2396.txt
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 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 Last change: 24 May 2005 21
Man(1) output converted with
man2html and wrapped by fishsponge
This page was generated on Wed Sep 12 11:25:47 GMT 2007
|
Your favourite pages:
No pages logged yet... Top 10 most popular pages:
prstat man page (24546 hits)
(Solaris 10 11_06)
netcat man page (17695 hits)
(Suse Linux 10.1)
ssh-socks5-proxy-connect man page (13530 hits)
(Solaris 10 11_06)
signal man page (12550 hits)
(Suse Linux 10.1)
startproc man page (11991 hits)
(Suse Linux 10.1)
raidctl man page (11357 hits)
(Solaris 10 11_06)
adv_cap_autoneg man page (10285 hits)
(Solaris 10 11_06)
sqlite3 man page (9729 hits)
(openSUSE 10.2)
CPAN man page (8947 hits)
(Suse Linux 10.1)
BusyBox man page (7702 hits)
(Suse Linux 10.1)
|
Man Pages 
