| blob | 512be7a2cb59b6a3b1faedfe64023a53d1db5a7a |
1 '\" te
2 .\" Copyright 2018 OmniOS Community Edition (OmniOSce) Association.
3 .\" Copyright 2015 Nexenta Systems Inc.
4 .\" Copyright 2014 Garrett D'Amore <garrett@damore.org>
5 .\" Copyright (c) 2008 Sun Microsystems, Inc. All Rights Reserved
6 .\" Copyright 1989 AT&T
7 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
8 .\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the
9 .\" fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
10 .TH BOOT 8 "Jul 20, 2018"
11 .SH NAME
12 boot \- start the system kernel or a standalone program
13 .SH SYNOPSIS
14 .SS "SPARC"
15 .LP
16 .nf
17 \fBboot\fR [\fIOBP\fR \fInames\fR] [\fIfile\fR] [\fB-aLV\fR] [\fB-F\fR \fIobject\fR] [\fB-D\fR \fIdefault-file\fR]
18 [\fB-Z\fR \fIdataset\fR] [\fIboot-flags\fR] [\fB\(mi\(mi\fR] [\fIclient-program-args\fR]
19 .fi
21 .SS "x86"
22 .LP
23 .nf
24 \fBboot\fR [\fIboot-flags\fR] [\fB-B\fR \fIprop\fR=\fIval\fR [,\fIval\fR...]]
25 .fi
27 .SH DESCRIPTION
28 .LP
29 Bootstrapping is the process of loading and executing a standalone program. For
30 the purpose of this discussion, bootstrapping means the process of loading and
31 executing the bootable operating system. Typically, the standalone program is
32 the operating system kernel (see \fBkernel\fR(8)), but any standalone program
33 can be booted instead. On a SPARC-based system, the diagnostic monitor for a
34 machine is a good example of a standalone program other than the operating
35 system that can be booted.
36 .sp
37 .LP
38 If the standalone is identified as a dynamically-linked executable, \fBboot\fR
39 will load the interpreter (linker/loader) as indicated by the executable format
40 and then transfer control to the interpreter. If the standalone is
41 statically-linked, it will jump directly to the standalone.
42 .sp
43 .LP
44 Once the kernel is loaded, it starts the UNIX system, mounts the necessary file
45 systems (see \fBvfstab\fR(4)), and runs \fB/sbin/init\fR to bring the system to
46 the "initdefault" state specified in \fB/etc/inittab\fR. See \fBinittab\fR(4).
47 .SS "SPARC Bootstrap Procedure"
48 .LP
49 On SPARC based systems, the bootstrap procedure on most machines consists of
50 the following basic phases.
51 .sp
52 .LP
53 After the machine is turned on, the system firmware (in PROM) executes power-on
54 self-test (POST). The form and scope of these tests depends on the version of
55 the firmware in your system.
56 .sp
57 .LP
58 After the tests have been completed successfully, the firmware attempts to
59 autoboot if the appropriate flag has been set in the non-volatile storage area
60 used by the firmware. The name of the file to load, and the device to load it
61 from can also be manipulated.
62 .sp
63 .LP
64 These flags and names can be set using the \fBeeprom\fR(8) command from the
65 shell, or by using \fBPROM\fR commands from the \fBok\fR prompt after the
66 system has been halted.
67 .sp
68 .LP
69 The second level program is either a filesystem-specific boot block (when
70 booting from a disk), or \fBinetboot\fR (when booting across
71 the network).
72 .sp
73 .LP
74 Network Booting
75 .sp
76 .LP
77 Network booting occurs in two steps: the client first obtains an IP address and
78 any other parameters necessary to permit it to load the second-stage booter.
79 The second-stage booter in turn loads the boot archive from the boot device.
80 .sp
81 .LP
82 An IP address can be obtained in one of three ways: RARP, DHCP, or manual
83 configuration, depending on the functions available in and configuration of the
84 PROM. Machines of the \fBsun4u\fR and \fBsun4v\fR kernel architectures have
85 DHCP-capable PROMs.
86 .sp
87 .LP
88 The boot command syntax for specifying the two methods of network booting are:
89 .sp
90 .in +2
91 .nf
92 boot net:rarp
93 boot net:dhcp
94 .fi
95 .in -2
96 .sp
98 .sp
99 .LP
100 The command:
101 .sp
102 .in +2
103 .nf
104 boot net
105 .fi
106 .in -2
107 .sp
109 .sp
110 .LP
111 without a \fBrarp\fR or \fBdhcp\fR specifier, invokes the default method for
112 network booting over the network interface for which \fBnet\fR is an alias.
113 .sp
114 .LP
115 The sequence of events for network booting using RARP/\fBbootparams\fR is
116 described in the following paragraphs. The sequence for DHCP follows the
117 RARP/\fBbootparams\fR description.
118 .sp
119 .LP
120 When booting over the network using RARP/\fBbootparams\fR, the PROM begins by
121 broadcasting a reverse ARP request until it receives a reply. When a reply is
122 received, the PROM then broadcasts a TFTP request to fetch the first block of
123 \fBinetboot\fR. Subsequent requests will be sent to the server that initially
124 answered the first block request. After loading, \fBinetboot\fR will also use
125 reverse ARP to fetch its IP address, then broadcast \fBbootparams\fR RPC calls
126 (see \fBbootparams\fR(4)) to locate configuration information and its root file
127 system. \fBinetboot\fR then loads the boot archive by means of NFS and
128 transfers control to that archive.
129 .sp
130 .LP
131 When booting over the network using DHCP, the PROM broadcasts the hardware
132 address and kernel architecture and requests an IP address, boot parameters,
133 and network configuration information. After a DHCP server responds and is
134 selected (from among potentially multiple servers), that server sends to the
135 client an IP address and all other information needed to boot the client.
136 Next, the PROM downloads
137 \fBinetboot\fR, loads that file into memory, and executes it. \fBinetboot\fR
138 loads the boot archive, which takes over the machine and releases
139 \fBinetboot\fR. Startup scripts then initiate the DHCP agent (see
140 \fBdhcpagent\fR(8)), which implements further DHCP activities.
142 .SS "iSCSI Boot"
143 .LP
144 iSCSI boot is currently supported only on x86. The host being booted must be
145 equipped with NIC(s) capable of iBFT (iSCSI Boot Firmware Table) or have the
146 mainboard's BIOS be iBFT-capable. iBFT, defined in the Advanced Configuration
147 and Power Interface (ACPI) 3.0b specification, specifies a block of information
148 that contains various parameters that are useful to the iSCSI Boot process.
149 .sp
150 .LP
151 Firmware implementing iBFT presents an iSCSI disk in the BIOS during startup as
152 a bootable device by establishing the connection to the iSCSI target. The rest
153 of the process of iSCSI booting is the same as booting from a local disk.
154 .sp
155 .LP
156 To configure the iBFT properly, users need to refer to the documentation from
157 their hardware vendors.
158 .SS "Booting from Disk"
159 .LP
160 When booting from disk, the OpenBoot PROM firmware reads the boot blocks from
161 blocks 1 to 15 of the partition specified as the boot device. This standalone
162 booter usually contains a file system-specific reader capable of reading the
163 boot archive.
164 .sp
165 .LP
166 If the pathname to the standalone is relative (does not begin with a slash),
167 the second level boot will look for the standalone in a platform-dependent
168 search path. This path is guaranteed to contain
169 \fB/platform/\fR\fIplatform-name\fR. Many SPARC platforms next search the
170 platform-specific path entry \fB/platform/\fR\fIhardware-class-name\fR. See
171 \fBfilesystem\fR(5). If the pathname is absolute, \fBboot\fR will use the
172 specified path. The \fBboot\fR program then loads the standalone at the
173 appropriate address, and then transfers control.
174 .sp
175 .LP
176 Once the boot archive has been transferred from the boot device, Solaris can
177 initialize and take over control of the machine. This process is further
178 described in the "Boot Archive Phase," below, and is identical on all
179 platforms.
180 .sp
181 .LP
182 If the filename is not given on the command line or otherwise specified, for
183 example, by the \fBboot-file\fR NVRAM variable, \fBboot\fR chooses an
184 appropriate default file to load based on what software is installed on the
185 system and the capabilities of the hardware and firmware.
186 .sp
187 .LP
188 The path to the kernel must not contain any whitespace.
189 .SS "Booting from ZFS"
190 .LP
191 Booting from ZFS differs from booting from UFS in that, with ZFS, a device
192 specifier identifies a storage pool, not a single root file system. A storage
193 pool can contain multiple bootable datasets (that is, root file systems).
194 Therefore, when booting from ZFS, it is not sufficient to specify a boot
195 device. One must also identify a root file system within the pool that was
196 identified by the boot device. By default, the dataset selected for booting is
197 the one identified by the pool's \fBbootfs\fR property. This default selection
198 can be overridden by specifying an alternate bootable dataset with the \fB-Z\fR
199 option.
200 .SS "Boot Archive Phase"
201 .LP
202 The boot archive contains a file system image that is mounted using an
203 in-memory disk. The image is self-describing, specifically containing a file
204 system reader in the boot block. This file system reader mounts and opens the
205 RAM disk image, then reads and executes the kernel contained within it. By
206 default, this kernel is in:
207 .sp
208 .in +2
209 .nf
210 /platform/`uname -i`/kernel/unix
211 .fi
212 .in -2
213 .sp
215 .sp
216 .LP
217 If booting from ZFS, the pathnames of both the archive and the kernel file are
218 resolved in the root file system (that is, dataset) selected for booting as
219 described in the previous section.
220 .sp
221 .LP
222 The initialization of the kernel continues by loading necessary drivers and
223 modules from the in-memory filesystem until I/O can be turned on and the root
224 filesystem mounted. Once the root filesystem is mounted, the in-memory
225 filesystem is no longer needed and is discarded.
226 .SS "OpenBoot PROM \fBboot\fR Command Behavior"
227 .LP
228 The OpenBoot \fBboot\fR command takes arguments of the following form:
229 .sp
230 .in +2
231 .nf
232 ok boot [\fIdevice-specifier\fR] [\fIarguments\fR]
233 .fi
234 .in -2
235 .sp
237 .sp
238 .LP
239 The default \fBboot\fR command has no arguments:
240 .sp
241 .in +2
242 .nf
243 ok boot
244 .fi
245 .in -2
246 .sp
248 .sp
249 .LP
250 If no \fIdevice-specifier\fR is given on the \fBboot\fR command line, OpenBoot
251 typically uses the \fIboot-device\fR or \fIdiag-device\fR \fBNVRAM\fR variable.
252 If no optional \fIarguments\fR are given on the command line, OpenBoot
253 typically uses the \fIboot-file\fR or \fIdiag-file\fR \fBNVRAM\fR variable as
254 default \fBboot\fR arguments. (If the system is in diagnostics mode,
255 \fIdiag-device\fR and \fIdiag-file\fR are used instead of \fIboot-device\fR and
256 \fIboot-file\fR).
257 .sp
258 .LP
259 \fIarguments\fR may include more than one string. All \fIargument\fR strings
260 are passed to the secondary booter; they are not interpreted by OpenBoot.
261 .sp
262 .LP
263 If any \fIarguments\fR are specified on the \fBboot\fR command line, then
264 neither the \fIboot-file\fR nor the \fIdiag-file\fR \fBNVRAM\fR variable is
265 used. The contents of the \fBNVRAM\fR variables are not merged with command
266 line arguments. For example, the command:
267 .sp
268 .in +2
269 .nf
270 ok \fBboot\fR \fB-s\fR
271 .fi
272 .in -2
273 .sp
275 .sp
276 .LP
277 ignores the settings in both \fIboot-file\fR and \fIdiag-file\fR; it interprets
278 the string \fB"-s"\fR as \fIarguments\fR. \fBboot\fR will not use the contents
279 of \fIboot-file\fR or \fIdiag-file\fR.
280 .sp
281 .LP
282 With older PROMs, the command:
283 .sp
284 .in +2
285 .nf
286 ok \fBboot net\fR
287 .fi
288 .in -2
289 .sp
291 .sp
292 .LP
293 took no arguments, using instead the settings in \fIboot-file\fR or
294 \fIdiag-file\fR (if set) as the default file name and arguments to pass to
295 boot. In most cases, it is best to allow the \fBboot\fR command to choose an
296 appropriate default based upon the system type, system hardware and firmware,
297 and upon what is installed on the root file system. Changing \fIboot-file\fR or
298 \fIdiag-file\fR can generate unexpected results in certain circumstances.
299 .sp
300 .LP
301 This behavior is found on most OpenBoot 2.x and 3.x based systems. Note that
302 differences may occur on some platforms.
303 .sp
304 .LP
305 The command:
306 .sp
307 .LP
308 ok \fBboot cdrom\fR
309 .sp
310 .LP
311 \&...also normally takes no arguments. Accordingly, if \fIboot-file\fR is set
312 to the 64-bit kernel filename and you attempt to boot the installation CD or
313 DVD with \fBboot cdrom\fR, boot will fail if the installation media contains
314 only a 32-bit kernel.
315 .sp
316 .LP
317 Because the contents of \fIboot-file\fR or \fIdiag-file\fR can be ignored
318 depending on the form of the \fBboot\fR command used, reliance upon
319 \fIboot-file\fR should be discouraged for most production systems.
320 .sp
321 .LP
322 Modern PROMs have enhanced the network boot support package to support the
323 following syntax for arguments to be processed by the package:
324 .sp
325 .LP
326 [\fIprotocol\fR,] [\fIkey\fR=\fIvalue\fR,]*
327 .sp
328 .LP
329 All arguments are optional and can appear in any order. Commas are required
330 unless the argument is at the end of the list. If specified, an argument takes
331 precedence over any default values, or, if booting using DHCP, over
332 configuration information provided by a DHCP server for those parameters.
333 .sp
334 .LP
335 \fIprotocol\fR, above, specifies the address discovery protocol to be used.
336 .sp
337 .LP
338 Configuration parameters, listed below, are specified as \fIkey\fR=\fIvalue\fR
339 attribute pairs.
340 .sp
341 .ne 2
342 .na
343 \fB\fBtftp-server\fR\fR
344 .ad
345 .sp .6
346 .RS 4n
347 IP address of the TFTP server
348 .RE
350 .sp
351 .ne 2
352 .na
353 \fB\fBfile\fR\fR
354 .ad
355 .sp .6
356 .RS 4n
357 file to download using TFTP
358 .RE
360 .sp
361 .ne 2
362 .na
363 \fB\fBhost-ip\fR\fR
364 .ad
365 .sp .6
366 .RS 4n
367 IP address of the client (in dotted-decimal notation)
368 .RE
370 .sp
371 .ne 2
372 .na
373 \fB\fBrouter-ip\fR\fR
374 .ad
375 .sp .6
376 .RS 4n
377 IP address of the default router
378 .RE
380 .sp
381 .ne 2
382 .na
383 \fB\fBsubnet-mask\fR\fR
384 .ad
385 .sp .6
386 .RS 4n
387 subnet mask (in dotted-decimal notation)
388 .RE
390 .sp
391 .ne 2
392 .na
393 \fB\fBclient-id\fR\fR
394 .ad
395 .sp .6
396 .RS 4n
397 DHCP client identifier
398 .RE
400 .sp
401 .ne 2
402 .na
403 \fB\fBhostname\fR\fR
404 .ad
405 .sp .6
406 .RS 4n
407 hostname to use in DHCP transactions
408 .RE
410 .sp
411 .ne 2
412 .na
413 \fB\fBtftp-retries\fR\fR
414 .ad
415 .sp .6
416 .RS 4n
417 maximum number of TFTP retries
418 .RE
420 .sp
421 .ne 2
422 .na
423 \fB\fBdhcp-retries\fR\fR
424 .ad
425 .sp .6
426 .RS 4n
427 maximum number of DHCP retries
428 .RE
430 .sp
431 .LP
432 The list of arguments to be processed by the network boot support package is
433 specified in one of two ways:
434 .RS +4
435 .TP
436 .ie t \(bu
437 .el o
438 As arguments passed to the package's \fBopen\fR method, or
439 .RE
440 .RS +4
441 .TP
442 .ie t \(bu
443 .el o
444 arguments listed in the NVRAM variable \fBnetwork-boot-arguments\fR.
445 .RE
446 .sp
447 .LP
448 Arguments specified in \fBnetwork-boot-arguments\fR will be processed only if
449 there are no arguments passed to the package's \fBopen\fR method.
450 .sp
451 .LP
452 Argument Values
453 .sp
454 .LP
455 \fIprotocol\fR specifies the address discovery protocol to be used. If present,
456 the possible values are \fBrarp\fR or \fBdhcp\fR.
457 .sp
458 .LP
459 If other configuration parameters are specified in the new syntax and style
460 specified by this document, absence of the \fIprotocol\fR parameter implies
461 manual configuration.
462 .sp
463 .LP
464 If no other configuration parameters are specified, or if those arguments are
465 specified in the positional parameter syntax currently supported, the absence
466 of the \fIprotocol\fR parameter causes the network boot support package to use
467 the platform-specific default address discovery protocol.
468 .sp
469 .LP
470 Manual configuration requires that the client be provided its IP address, the
471 name of the boot file, and the address of the server providing the boot file
472 image. Depending on the network configuration, it might be required that
473 \fBsubnet-mask\fR and \fBrouter-ip\fR also be specified.
474 .sp
475 .LP
476 If the \fIprotocol\fR argument is not specified, the network boot support
477 package uses the platform-specific default address discovery protocol.
478 .sp
479 .LP
480 \fBtftp-server\fR is the IP address (in standard IPv4 dotted-decimal notation)
481 of the TFTP server that provides the file to download if using TFTP.
482 .sp
483 .LP
484 When using DHCP, the value, if specified, overrides the value of the TFTP
485 server specified in the DHCP response.
486 .sp
487 .LP
488 The TFTP RRQ is unicast to the server if one is specified as an argument or in
489 the DHCP response. Otherwise, the TFTP RRQ is broadcast.
490 .sp
491 .LP
492 \fIfile\fR specifies the file to be loaded by TFTP from the TFTP server.
493 .sp
494 .LP
495 When using RARP and TFTP, the default file name is the ASCII hexadecimal
496 representation of the IP address of the client, as documented in a preceding
497 section of this document.
498 .sp
499 .LP
500 When using DHCP, this argument, if specified, overrides the name of the boot
501 file specified in the DHCP response.
502 .sp
503 .LP
504 When using DHCP and TFTP, the default file name is constructed from the root
505 node's \fBname\fR property, with commas (,) replaced by periods (.).
506 .sp
507 .LP
508 When specified on the command line, the filename must not contain slashes
509 (\fB/\fR).
510 .sp
511 .LP
512 \fBhost-ip\fR specifies the IP address (in standard IPv4 dotted-decimal
513 notation) of the client, the system being booted. If using RARP as the address
514 discovery protocol, specifying this argument makes use of RARP unnecessary.
515 .sp
516 .LP
517 If DHCP is used, specifying the \fBhost-ip\fR argument causes the client to
518 follow the steps required of a client with an "Externally Configured Network
519 Address", as specified in RFC 2131.
520 .sp
521 .LP
522 \fBrouter-ip\fR is the IP address (in standard IPv4 dotted-decimal notation) of
523 a router on a directly connected network. The router will be used as the first
524 hop for communications spanning networks. If this argument is supplied, the
525 router specified here takes precedence over the preferred router specified in
526 the DHCP response.
527 .sp
528 .LP
529 \fBsubnet-mask\fR (specified in standard IPv4 dotted-decimal notation) is the
530 subnet mask on the client's network. If the subnet mask is not provided (either
531 by means of this argument or in the DHCP response), the default mask
532 appropriate to the network class (Class A, B, or C) of the address assigned to
533 the booting client will be assumed.
534 .sp
535 .LP
536 \fBclient-id\fR specifies the unique identifier for the client. The DHCP client
537 identifier is derived from this value. Client identifiers can be specified as:
538 .RS +4
539 .TP
540 .ie t \(bu
541 .el o
542 The ASCII hexadecimal representation of the identifier, or
543 .RE
544 .RS +4
545 .TP
546 .ie t \(bu
547 .el o
548 a quoted string
549 .RE
550 .sp
551 .LP
552 Thus, \fBclient-id="openboot"\fR and \fBclient-id=6f70656e626f6f74\fR both
553 represent a DHCP client identifier of 6F70656E626F6F74.
554 .sp
555 .LP
556 Identifiers specified on the command line must must not include slash (\fB/\fR)
557 or spaces.
558 .sp
559 .LP
560 The maximum length of the DHCP client identifier is 32 bytes, or 64 characters
561 representing 32 bytes if using the ASCII hexadecimal form. If the latter form
562 is used, the number of characters in the identifier must be an even number.
563 Valid characters are 0-9, a-f, and A-F.
564 .sp
565 .LP
566 For correct identification of clients, the client identifier must be unique
567 among the client identifiers used on the subnet to which the client is
568 attached. System administrators are responsible for choosing identifiers that
569 meet this requirement.
570 .sp
571 .LP
572 Specifying a client identifier on a command line takes precedence over any
573 other DHCP mechanism of specifying identifiers.
574 .sp
575 .LP
576 \fBhostname\fR (specified as a string) specifies the hostname to be used in
577 DHCP transactions. The name might or might not be qualified with the local
578 domain name. The maximum length of the hostname is 255 characters.
579 .LP
580 Note -
581 .sp
582 .RS 2
583 The \fBhostname\fR parameter can be used in service environments that require
584 that the client provide the desired hostname to the DHCP server. Clients
585 provide the desired hostname to the DHCP server, which can then register the
586 hostname and IP address assigned to the client with DNS.
587 .RE
588 .sp
589 .LP
591 \fBtftp-retries\fR is the maximum number of retries (specified in decimal)
592 attempted before the TFTP process is determined to have failed. Defaults to
593 using infinite retries.
594 .sp
595 .LP
596 \fBdhcp-retries\fR is the maximum number of retries (specified in decimal)
597 attempted before the DHCP process is determined to have failed. Defaults to of
598 using infinite retries.
599 .SS "x86 Bootstrap Procedure"
600 .LP
601 On x86 based systems, the bootstrapping process consists of two conceptually
602 distinct phases, kernel loading and kernel initialization. Kernel loading is
603 implemented in the boot loader using the BIOS ROM on the system
604 board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads boot
605 loader, starting with the first physical sector from a hard disk, DVD, or CD. If
606 supported by the ROM on the network adapter, the BIOS can also download the
607 \fBpxeboot\fR binary from a network boot server. Once the boot loader is
608 loaded, it in turn will load the \fBunix\fR kernel, a pre-constructed boot
609 archive containing kernel modules and data, and any additional files specified
610 in the boot loader configuration. Once specified files are loaded, the boot
611 loader will start the kernel to complete boot.
612 .sp
613 .LP
614 If the device identified by the boot loader as the boot device contains a ZFS
615 storage pool, the \fBmenu.lst\fR file used to create the Boot Environment menu
616 will be found in the dataset at the root of the pool's dataset hierarchy.
617 This is the dataset with the same name as the pool itself. There is always
618 exactly one such dataset in a pool, and so this dataset is well-suited for
619 pool-wide data such as the \fBmenu.lst\fR file. After the system is booted,
620 this dataset is mounted at /\fIpoolname\fR in the root file system.
621 .sp
622 .LP
623 There can be multiple bootable datasets (that is, root file systems) within a
624 pool. The default file system to load the kernel is identified by the boot
625 pool \fBbootfs\fR property (see \fBzpool\fR(8)). All bootable datasets are
626 listed in the \fBmenu.lst\fR file, which is used by the boot loader to compose
627 the Boot Environment menu, to implement support to load a kernel and boot from
628 an alternate Boot Environment.
629 .sp
630 .LP
631 Kernel initialization starts when the boot loader finishes loading the files
632 specified in the boot loader configuration and hands control over to the
633 \fBunix\fR binary. The Unix operating system initializes, links in the
634 necessary modules from the boot archive and mounts the root file system on
635 the real root device. At this point, the kernel regains
636 storage I/O, mounts additional file systems (see \fBvfstab\fR(4)), and starts
637 various operating system services (see \fBsmf\fR(5)).
639 .SH OPTIONS
640 .SS "SPARC"
641 .LP
642 The following SPARC options are supported:
643 .sp
644 .ne 2
645 .na
646 \fB\fB-a\fR\fR
647 .ad
648 .sp .6
649 .RS 4n
650 The boot program interprets this flag to mean \fBask me\fR, and so it prompts
651 for the name of the standalone. The \fB\&'\fR\fB-a\fR\fB\&'\fR flag is then
652 passed to the standalone program.
653 .RE
655 .sp
656 .ne 2
657 .na
658 \fB\fB-D\fR \fIdefault-file\fR\fR
659 .ad
660 .sp .6
661 .RS 4n
662 Explicitly specify the \fIdefault-file\fR. On some systems, \fBboot\fR chooses
663 a dynamic default file, used when none is otherwise specified. This option
664 allows the \fIdefault-file\fR to be explicitly set and can be useful when
665 booting \fBkmdb\fR(1) since, by default, \fBkmdb\fR loads the default-file as
666 exported by the \fBboot\fR program.
667 .RE
669 .sp
670 .ne 2
671 .na
672 \fB\fB-F\fR \fIobject\fR\fR
673 .ad
674 .sp .6
675 .RS 4n
676 Boot using the named object. The object must be either an ELF executable or
677 bootable object containing a boot block. The primary use is to boot the
678 failsafe boot archive.
679 .RE
681 .sp
682 .ne 2
683 .na
684 \fB\fB-L\fR\fR
685 .ad
686 .sp .6
687 .RS 4n
688 List the bootable datasets within a ZFS pool. You can select one of the
689 bootable datasets in the list, after which detailed instructions for booting
690 that dataset are displayed. Boot the selected dataset by following the
691 instructions. This option is supported only when the boot device contains a ZFS
692 storage pool.
693 .RE
695 .sp
696 .ne 2
697 .na
698 \fB\fB-V\fR\fR
699 .ad
700 .sp .6
701 .RS 4n
702 Display verbose debugging information.
703 .RE
705 .sp
706 .ne 2
707 .na
708 \fB\fIboot-flags\fR\fR
709 .ad
710 .sp .6
711 .RS 4n
712 The boot program passes all \fIboot-flags\fR to \fBfile\fR. They are not
713 interpreted by \fBboot\fR. See the \fBkernel\fR(8) and \fBkmdb\fR(1) manual
714 pages for information about the options available with the default standalone
715 program.
716 .RE
718 .sp
719 .ne 2
720 .na
721 \fB\fIclient-program-args\fR\fR
722 .ad
723 .sp .6
724 .RS 4n
725 The \fBboot\fR program passes all \fIclient-program-args\fR to \fIfile\fR. They
726 are not interpreted by \fBboot\fR.
727 .RE
729 .sp
730 .ne 2
731 .na
732 \fB\fIfile\fR\fR
733 .ad
734 .sp .6
735 .RS 4n
736 Name of a standalone program to \fBboot\fR. If a filename is not explicitly
737 specified, either on the \fBboot\fR command line or in the \fIboot-file\fR
738 NVRAM variable, \fBboot\fR chooses an appropriate default filename.
739 .RE
741 .sp
742 .ne 2
743 .na
744 \fB\fIOBP\fR \fInames\fR\fR
745 .ad
746 .sp .6
747 .RS 4n
748 Specify the open boot prom designations. For example, on Desktop SPARC based
749 systems, the designation \fB/sbus/esp@0,800000/sd@3,0:a\fR indicates a
750 \fBSCSI\fR disk (sd) at target 3, lun0 on the \fBSCSI\fR bus, with the esp host
751 adapter plugged into slot 0.
752 .RE
754 .sp
755 .ne 2
756 .na
757 \fB\fB-Z\fR \fIdataset\fR\fR
758 .ad
759 .sp .6
760 .RS 4n
761 Boot from the root file system in the specified ZFS dataset.
762 .RE
764 .SS "x86"
765 .LP
766 The following x86 options are supported:
767 .sp
768 .ne 2
769 .na
770 \fB\fB-B\fR \fIprop\fR=\fIval\fR...\fR
771 .ad
772 .sp .6
773 .RS 4n
774 One or more property-value pairs to be passed to the kernel. Multiple
775 property-value pairs must be separated by a comma. Use of this option is the
776 equivalent of the command: \fBeeprom\fR \fIprop\fR=\fIval\fR. See
777 \fBeeprom\fR(8) for available properties and valid values.
778 .RE
780 .sp
781 .ne 2
782 .na
783 \fB\fIboot-flags\fR\fR
784 .ad
785 .sp .6
786 .RS 4n
787 The boot program passes all \fIboot-flags\fR to \fBfile\fR. They are not
788 interpreted by \fBboot\fR. See \fBkernel\fR(8) and \fBkmdb\fR(1) for
789 information about the options available with the kernel.
790 .RE
792 .SH X86 BOOT SEQUENCE DETAILS
793 .LP
794 After a PC-compatible machine is turned on, the system firmware in the \fBBIOS
795 ROM\fR executes a power-on self test (POST), runs \fBBIOS\fR extensions in
796 peripheral board \fBROMs,\fR and invokes software interrupt INT 19h, Bootstrap.
797 The INT 19h handler typically performs the standard PC-compatible boot, which
798 consists of trying to read the first physical sector from the first diskette
799 drive, or, if that fails, from the first hard disk. The processor then jumps to
800 the first byte of the sector image in memory.
801 .SH X86 PRIMARY BOOT
802 .LP
803 The first sector on a hard disk contains the master boot block (first stage of
804 the boot program), which contains the master boot program and the Master Boot
805 Record (\fBMBR\fR) table. The master boot program has recorded the location of
806 the secondary stage of the boot program and using this location, master boot
807 will load and start the secondary stage of the boot program.
809 To support booting multiple operating systems, the master boot program is also
810 installed as the first sector of the partition with the illumos root file
811 system. This will allow configuring third party boot programs to use the
812 chainload technique to boot illumos system.
814 If the first stage is installed on the master boot block (see the \fB-m\fR
815 option of \fBinstallboot\fR(8)), then \fBstage2\fR is loaded directly
816 from the Solaris partition regardless of the active partition.
817 .sp
818 .LP
819 A similar sequence occurs for DVD or CD boot, but the master boot block location
820 and contents are dictated by the El Torito specification. The El Torito boot
821 will then continue in the same way as with the hard disk.
822 .sp
823 .LP
824 Floppy booting is not longer supported. Booting from USB devices follows the
825 same procedure as with hard disks.
826 .sp
827 .LP
828 An x86 \fBMBR\fR partition for the Solaris software begins with a
829 one-cylinder boot slice, which contains the boot loader \fBstage1\fR in the
830 first sector, the standard Solaris disk label and volume table of contents
831 (VTOC) in the second and third sectors, and in case the UFS file system is
832 used for the root file system, \fBstage2\fR in the fiftieth and subsequent
833 sectors.
835 If the zfs boot is used, \fBstage2\fR is always stored in the zfs pool
836 boot program area.
837 .sp
838 .LP
839 The behavior is slightly different when a disk is using \fBEFI\fR
840 partitioning.
842 To support a UFS root file system in the \fBEFI\fR partition, the \fBstage2\fR
843 must be stored on separate dedicated partition, as there is no space in UFS
844 file system boot program area to store the current \fBstage2\fR. This separate
845 dedicated partition is used as raw disk space, and must have enough space
846 for both \fBstage1\fR and \fBstage2\fR. The type (tag) of this partition
847 must be \fBboot\fR, \fBEFI\fR UUID:
848 .sp
849 .in +2
850 .nf
851 \fB6a82cb45-1dd2-11b2-99a6-080020736631\fR
852 .fi
853 .in -2
854 .sp
855 For the UUID reference, please see \fB/usr/include/sys/efi_partition.h\fR.
857 In case of a whole disk zfs pool configuration, the \fBstage1\fR is always
858 installed in the first sector of the disk, and it always loads \fBstage2\fR
859 from the partition specified at the boot loader installation time.
860 .sp
861 .LP
862 Once \fBstage2\fR is running, it will load and start the third stage boot
863 program from root file system. Boot loader supports loading from the ZFS,
864 UFS and PCFS file systems. The stage3 boot program defaults to be
865 \fB/boot/loader\fR, and implements a user interface to load and boot the
866 unix kernel.
867 .sp
868 .LP
869 For network booting, the supported method is Intel's Preboot eXecution
870 Environment (PXE) standard. When booting from the network using PXE, the system
871 or network adapter BIOS uses DHCP to locate a network bootstrap program
872 (\fBpxeboot\fR) on a boot server and reads it using Trivial File Transfer
873 Protocol (TFTP). The BIOS executes the \fBpxeboot\fR by jumping to its first
874 byte in memory. The \fBpxeboot\fR program is combined stage2 and stage2 boot
875 program and implements user interface to load and boot unix kernel.
876 .SH X86 KERNEL STARTUP
877 .LP
878 The kernel startup process is independent of the kernel loading process. During
879 kernel startup, console I/O goes to the device specified by the \fBconsole\fR
880 property.
881 .sp
882 .LP
883 When booting from UFS, the root device is specified by the \fBbootpath\fR
884 property, and the root file system type is specified by the \fBfstype\fR
885 property. These properties should be setup by the Solaris Install/Upgrade
886 process in \fB/boot/solaris/bootenv.rc\fR and can be overridden with the
887 \fB-B\fR option, described above (see the \fBeeprom\fR(8) man page).
888 .sp
889 .LP
890 When booting from ZFS, the root device is automatically passed by the boot
891 loader to the kernel as a boot parameter \fB-B\fR \fBzfs-bootfs\fR. The actual
892 value used by the boot loader can be observed with the \fBeeprom bootcmd\fR
893 command.
894 .sp
895 .LP
896 If the console properties are not present, console I/O defaults to \fBscreen\fR
897 and \fBkeyboard\fR. The root device defaults to \fBramdisk\fR and the file
898 system defaults to \fBufs\fR.
899 .SH EXAMPLES
900 .SS "SPARC"
901 .LP
902 \fBExample 1 \fRTo Boot the Default Kernel In Single-User Interactive Mode
903 .sp
904 .LP
905 To boot the default kernel in single-user interactive mode, respond to the
906 \fBok\fR prompt with one of the following:
908 .sp
909 .in +2
910 .nf
911 \fBboot\fR \fB\fR\fB-as\fR
913 \fBboot\fR \fBdisk3\fR \fB-as\fR
914 .fi
915 .in -2
916 .sp
918 .LP
919 \fBExample 2 \fRNetwork Booting
920 .sp
921 .LP
922 To illustrate some of the subtle repercussions of various boot command line
923 invocations, assume that the \fBnetwork-boot-arguments\fR are set and that
924 \fBnet\fR is devaliased as shown in the commands below.
926 .sp
927 .LP
928 In the following command, device arguments in the device alias are processed by
929 the device driver. The network boot support package processes arguments in
930 \fBnetwork-boot-arguments\fR.
932 .sp
933 .in +2
934 .nf
935 \fBboot net\fR
936 .fi
937 .in -2
938 .sp
940 .sp
941 .LP
942 The command below results in no device arguments. The network boot support
943 package processes arguments in \fBnetwork-boot-arguments\fR.
945 .sp
946 .in +2
947 .nf
948 \fBboot net:\fR
949 .fi
950 .in -2
951 .sp
953 .sp
954 .LP
955 The command below results in no device arguments. \fBrarp\fR is the only
956 network boot support package argument. \fBnetwork-boot-arguments\fR is ignored.
958 .sp
959 .in +2
960 .nf
961 \fBboot net:rarp\fR
962 .fi
963 .in -2
964 .sp
966 .sp
967 .LP
968 In the command below, the specified device arguments are honored. The network
969 boot support package processes arguments in \fBnetwork-boot-arguments\fR.
971 .sp
972 .in +2
973 .nf
974 \fBboot net:speed=100,duplex=full\fR
975 .fi
976 .in -2
977 .sp
979 .SS "x86"
980 .LP
981 \fBExample 3 \fRTo Boot the Default Kernel In 64-bit Single-User Interactive
982 Mode
983 .sp
984 .LP
985 To boot the default kernel in single-user interactive mode, press the ESC key
986 to get the boot loader \fBok\fR prompt and enter:
988 .sp
989 .in +2
990 .nf
991 boot -as
992 .fi
993 .in -2
995 .SH FILES
996 .ne 2
997 .na
998 \fB\fB/etc/inittab\fR\fR
999 .ad
1000 .sp .6
1001 .RS 4n
1002 Table in which the \fBinitdefault\fR state is specified
1003 .RE
1005 .sp
1006 .ne 2
1007 .na
1008 \fB\fB/sbin/init\fR\fR
1009 .ad
1010 .sp .6
1011 .RS 4n
1012 Program that brings the system to the \fBinitdefault\fR state
1013 .RE
1015 .SS "64-bit SPARC Only"
1016 .ne 2
1017 .na
1018 \fB\fB/platform/\fR\fIplatform-name\fR\fB/kernel/sparcv9/unix\fR\fR
1019 .ad
1020 .sp .6
1021 .RS 4n
1022 Default program to boot system.
1023 .RE
1025 .SS "x86 Only"
1026 .ne 2
1027 .na
1028 \fB\fB/boot\fR\fR
1029 .ad
1030 .sp .6
1031 .RS 4n
1032 Directory containing boot-related files.
1033 .RE
1035 .sp
1036 .ne 2
1037 .na
1038 \fB\fB/rpool/boot/menu.lst\fR\fR
1039 .ad
1040 .sp .6
1041 .RS 4n
1042 Menu index file of bootable operating systems displayed by the boot loader.
1043 .sp
1044 \fBNote:\fR this file is located on the root ZFS pool. While many installs
1045 often name their root zpool 'rpool', this is not required and the
1046 /rpool in the path above should be substituted with the name of
1047 the root pool of your current system.
1048 .RE
1050 .sp
1051 .ne 2
1052 .na
1053 \fB\fB/platform/kernel/unix\fR\fR
1054 .ad
1055 .sp .6
1056 .RS 4n
1057 32-bit kernel.
1058 .RE
1060 .SS "64-bit x86 Only"
1061 .ne 2
1062 .na
1063 \fB\fB/platform/kernel/amd64/unix\fR\fR
1064 .ad
1065 .sp .6
1066 .RS 4n
1067 64-bit kernel.
1068 .RE
1070 .SH SEE ALSO
1071 .LP
1072 \fBkmdb\fR(1), \fBuname\fR(1), \fBbootadm\fR(8), \fBeeprom\fR(8),
1073 \fBinit\fR(8), \fBinstallboot\fR(8), \fBkernel\fR(8), \fBmonitor\fR(8),
1074 \fBshutdown\fR(8), \fBsvcadm\fR(8), \fBumountall\fR(8), \fBzpool\fR(8),
1075 \fBuadmin\fR(2), \fBbootparams\fR(4), \fBinittab\fR(4), \fBvfstab\fR(4),
1076 \fBfilesystem\fR(5)
1077 .sp
1078 .LP
1079 RFC 903, \fIA Reverse Address Resolution Protocol\fR,
1080 \fBhttp://www.ietf.org/rfc/rfc903.txt\fR
1081 .sp
1082 .LP
1083 RFC 2131, \fIDynamic Host Configuration Protocol\fR,
1084 \fBhttp://www.ietf.org/rfc/rfc2131.txt\fR
1085 .sp
1086 .LP
1087 RFC 2132, \fIDHCP Options and BOOTP Vendor Extensions\fR,
1088 \fBhttp://www.ietf.org/rfc/rfc2132.txt\fR
1089 .sp
1090 .LP
1091 \fI\fR
1092 .sp
1093 .LP
1094 \fISun Hardware Platform Guide\fR
1095 .sp
1096 .LP
1097 \fIOpenBoot Command Reference Manual\fR
1098 .SH WARNINGS
1099 .LP
1100 The \fBboot\fR utility is unable to determine which files can be used as
1101 bootable programs. If the booting of a file that is not bootable is requested,
1102 the \fBboot\fR utility loads it and branches to it. What happens after that is
1103 unpredictable.
1104 .SH NOTES
1105 .LP
1106 \fIplatform-name\fR can be found using the \fB-i\fR option of \fBuname\fR(1).
1107 \fIhardware-class-name\fR can be found using the \fB-m\fR option of
1108 \fBuname\fR(1).
1109 .sp
1110 .LP
1111 The current release of the Solaris operating system does not support machines
1112 running an UltraSPARC-I CPU.