| blob | 2d031006d0a9b1d1383998f81de8c4227c3f2cab |
1 '\" te
2 .\" Copyright 2015 Nexenta Systems Inc.
3 .\" Copyright (c) 2008 Sun Microsystems, Inc. All Rights Reserved
4 .\" Copyright 1989 AT&T
5 .\" 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.
6 .\" 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
7 .\" fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
8 .TH BOOT 1M "Aug 18, 2016"
9 .SH NAME
10 boot \- start the system kernel or a standalone program
11 .SH SYNOPSIS
12 .SS "SPARC"
13 .LP
14 .nf
15 \fBboot\fR [\fIOBP\fR \fInames\fR] [\fIfile\fR] [\fB-aLV\fR] [\fB-F\fR \fIobject\fR] [\fB-D\fR \fIdefault-file\fR]
16 [\fB-Z\fR \fIdataset\fR] [\fIboot-flags\fR] [\fB\(mi\(mi\fR] [\fIclient-program-args\fR]
17 .fi
19 .SS "x86"
20 .LP
21 .nf
22 \fBboot\fR [\fIboot-flags\fR] [\fB-B\fR \fIprop\fR=\fIval\fR [,\fIval\fR...]]
23 .fi
25 .SH DESCRIPTION
26 .LP
27 Bootstrapping is the process of loading and executing a standalone program. For
28 the purpose of this discussion, bootstrapping means the process of loading and
29 executing the bootable operating system. Typically, the standalone program is
30 the operating system kernel (see \fBkernel\fR(1M)), but any standalone program
31 can be booted instead. On a SPARC-based system, the diagnostic monitor for a
32 machine is a good example of a standalone program other than the operating
33 system that can be booted.
34 .sp
35 .LP
36 If the standalone is identified as a dynamically-linked executable, \fBboot\fR
37 will load the interpreter (linker/loader) as indicated by the executable format
38 and then transfer control to the interpreter. If the standalone is
39 statically-linked, it will jump directly to the standalone.
40 .sp
41 .LP
42 Once the kernel is loaded, it starts the UNIX system, mounts the necessary file
43 systems (see \fBvfstab\fR(4)), and runs \fB/sbin/init\fR to bring the system to
44 the "initdefault" state specified in \fB/etc/inittab\fR. See \fBinittab\fR(4).
45 .SS "SPARC Bootstrap Procedure"
46 .LP
47 On SPARC based systems, the bootstrap procedure on most machines consists of
48 the following basic phases.
49 .sp
50 .LP
51 After the machine is turned on, the system firmware (in PROM) executes power-on
52 self-test (POST). The form and scope of these tests depends on the version of
53 the firmware in your system.
54 .sp
55 .LP
56 After the tests have been completed successfully, the firmware attempts to
57 autoboot if the appropriate flag has been set in the non-volatile storage area
58 used by the firmware. The name of the file to load, and the device to load it
59 from can also be manipulated.
60 .sp
61 .LP
62 These flags and names can be set using the \fBeeprom\fR(1M) command from the
63 shell, or by using \fBPROM\fR commands from the \fBok\fR prompt after the
64 system has been halted.
65 .sp
66 .LP
67 The second level program is either a fileystem-specific boot block (when
68 booting from a disk), or \fBinetboot\fR or \fBwanboot\fR (when booting across
69 the network).
70 .sp
71 .LP
72 Network Booting
73 .sp
74 .LP
75 Network booting occurs in two steps: the client first obtains an IP address and
76 any other parameters necessary to permit it to load the second-stage booter.
77 The second-stage booter in turn loads the boot archive from the boot device.
78 .sp
79 .LP
80 An IP address can be obtained in one of three ways: RARP, DHCP, or manual
81 configuration, depending on the functions available in and configuration of the
82 PROM. Machines of the \fBsun4u\fR and \fBsun4v\fR kernel architectures have
83 DHCP-capable PROMs.
84 .sp
85 .LP
86 The boot command syntax for specifying the two methods of network booting are:
87 .sp
88 .in +2
89 .nf
90 boot net:rarp
91 boot net:dhcp
92 .fi
93 .in -2
94 .sp
96 .sp
97 .LP
98 The command:
99 .sp
100 .in +2
101 .nf
102 boot net
103 .fi
104 .in -2
105 .sp
107 .sp
108 .LP
109 without a \fBrarp\fR or \fBdhcp\fR specifier, invokes the default method for
110 network booting over the network interface for which \fBnet\fR is an alias.
111 .sp
112 .LP
113 The sequence of events for network booting using RARP/\fBbootparams\fR is
114 described in the following paragraphs. The sequence for DHCP follows the
115 RARP/\fBbootparams\fR description.
116 .sp
117 .LP
118 When booting over the network using RARP/\fBbootparams\fR, the PROM begins by
119 broadcasting a reverse ARP request until it receives a reply. When a reply is
120 received, the PROM then broadcasts a TFTP request to fetch the first block of
121 \fBinetboot\fR. Subsequent requests will be sent to the server that initially
122 answered the first block request. After loading, \fBinetboot\fR will also use
123 reverse ARP to fetch its IP address, then broadcast \fBbootparams\fR RPC calls
124 (see \fBbootparams\fR(4)) to locate configuration information and its root file
125 system. \fBinetboot\fR then loads the boot archive by means of NFS and
126 transfers control to that archive.
127 .sp
128 .LP
129 When booting over the network using DHCP, the PROM broadcasts the hardware
130 address and kernel architecture and requests an IP address, boot parameters,
131 and network configuration information. After a DHCP server responds and is
132 selected (from among potentially multiple servers), that server sends to the
133 client an IP address and all other information needed to boot the client. After
134 receipt of this information, the client PROM examines the name of the file to
135 be loaded, and will behave in one of two ways, depending on whether the file's
136 name appears to be an HTTP URL. If it does not, 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(1M)), which implements further DHCP activities.
141 .sp
142 .LP
143 If the file to be loaded is an HTTP URL, the PROM will use HTTP to load the
144 referenced file. If the client has been configured with an HMAC SHA-1 key, it
145 will check the integrity of the loaded file before proceeding to execute it.
146 The file is expected to be the \fBwanboot\fR binary. The WAN boot process can
147 be configured to use either DHCP or NVRAM properties to discover the install
148 server and router and the proxies needed to connect to it. When \fBwanboot\fR
149 begins executing, it determines whether sufficient information is available to
150 it to allow it to proceed. If any necessary information is missing, it will
151 either exit with an appropriate error or bring up a command interpreter and
152 prompt for further configuration information. Once \fBwanboot\fR has obtained
153 the necessary information, it loads the boot loader into memory by means of
154 HTTP. If an encryption key has been installed on the client, \fBwanboot\fR will
155 verify the boot loader's signature and its accompanying hash. Presence of an
156 encryption key but no hashing key is an error.
157 .sp
158 .LP
159 The \fBwanboot\fR boot loader can communicate with the client using either HTTP
160 or secure HTTP. If the former, and if the client has been configured with an
161 HMAC SHA-1 key, the boot loader will perform an integrity check of the root
162 file system. Once the root file system has been loaded into memory (and
163 possibly had an integrity check performed), the boot archive is transferred
164 from the server. If provided with a \fBboot_logger\fR URL by means of the
165 \fBwanboot.conf\fR(4) file, \fBwanboot\fR will periodically log its progress.
166 .sp
167 .LP
168 Not all PROMs are capable of consuming URLs. You can determine whether a client
169 is so capable using the \fBlist-security-keys\fR OBP command (see
170 \fBmonitor\fR(1M)).
171 .sp
172 .LP
173 WAN booting is not currently available on the x86 platform.
174 .sp
175 .LP
176 The \fBwanboot\fR Command Line
177 .sp
178 .LP
179 When the client program is \fBwanboot\fR, it accepts \fBclient-program-args\fR
180 of the form:
181 .sp
182 .in +2
183 .nf
184 boot ... -o \fIopt1\fR[,\fIopt2\fR[,...]]
185 .fi
186 .in -2
187 .sp
189 .sp
190 .LP
191 where each option may be an action:
192 .sp
193 .ne 2
194 .na
195 \fB\fBdhcp\fR\fR
196 .ad
197 .sp .6
198 .RS 4n
199 Require \fBwanboot\fR to obtain configuration parameters by means of DHCP.
200 .RE
202 .sp
203 .ne 2
204 .na
205 \fB\fBprompt\fR\fR
206 .ad
207 .sp .6
208 .RS 4n
209 Cause \fBwanboot\fR to enter its command interpreter.
210 .RE
212 .sp
213 .ne 2
214 .na
215 \fB\fI<cmd>\fR\fR
216 .ad
217 .sp .6
218 .RS 4n
219 One of the interpreter commands listed below.
220 .RE
222 .sp
223 .LP
224 \&...or an assignment, using the interpreter's parameter names listed below.
225 .sp
226 .LP
227 The \fBwanboot\fR Command Interpreter
228 .sp
229 .LP
230 The \fBwanboot\fR command interpreter is invoked by supplying a
231 \fBclient-program-args\fR of "\fB-o prompt\fR" when booting. Input consists of
232 single commands or assignments, or a comma-separated list of commands or
233 assignments. The configuration parameters are:
234 .sp
235 .ne 2
236 .na
237 \fB\fBhost-ip\fR\fR
238 .ad
239 .sp .6
240 .RS 4n
241 IP address of the client (in dotted-decimal notation)
242 .RE
244 .sp
245 .ne 2
246 .na
247 \fB\fBrouter-ip\fR\fR
248 .ad
249 .sp .6
250 .RS 4n
251 IP address of the default router (in dotted-decimal notation)
252 .RE
254 .sp
255 .ne 2
256 .na
257 \fB\fBsubnet-mask\fR\fR
258 .ad
259 .sp .6
260 .RS 4n
261 subnet mask (in dotted-decimal notation)
262 .RE
264 .sp
265 .ne 2
266 .na
267 \fB\fBclient-id\fR\fR
268 .ad
269 .sp .6
270 .RS 4n
271 DHCP client identifier (a quoted ASCII string or hex ASCII)
272 .RE
274 .sp
275 .ne 2
276 .na
277 \fB\fBhostname\fR\fR
278 .ad
279 .sp .6
280 .RS 4n
281 hostname to request in DHCP transactions (ASCII)
282 .RE
284 .sp
285 .ne 2
286 .na
287 \fB\fBhttp-proxy\fR\fR
288 .ad
289 .sp .6
290 .RS 4n
291 HTTP proxy server specification (IPADDR[:PORT])
292 .RE
294 .sp
295 .LP
296 The key names are:
297 .sp
298 .ne 2
299 .na
300 \fB\fB3des\fR\fR
301 .ad
302 .sp .6
303 .RS 4n
304 the triple DES encryption key (48 hex ASCII characters)
305 .RE
307 .sp
308 .ne 2
309 .na
310 \fB\fBaes\fR\fR
311 .ad
312 .sp .6
313 .RS 4n
314 the AES encryption key (32 hex ASCII characters)
315 .RE
317 .sp
318 .ne 2
319 .na
320 \fB\fBsha1\fR\fR
321 .ad
322 .sp .6
323 .RS 4n
324 the HMAC SHA-1 signature key (40 hex ASCII characters)
325 .RE
327 .sp
328 .LP
329 Finally, the URL or the WAN boot CGI is referred to by means of:
330 .sp
331 .ne 2
332 .na
333 \fB\fBbootserver\fR\fR
334 .ad
335 .sp .6
336 .RS 4n
337 URL of WAN boot's CGI (the equivalent of OBP's \fBfile\fR parameter)
338 .RE
340 .sp
341 .LP
342 The interpreter accepts the following commands:
343 .sp
344 .ne 2
345 .na
346 \fB\fBhelp\fR\fR
347 .ad
348 .sp .6
349 .RS 4n
350 Print a brief description of the available commands
351 .RE
353 .sp
354 .ne 2
355 .na
356 \fB\fB\fIvar\fR=\fIval\fR\fR\fR
357 .ad
358 .sp .6
359 .RS 4n
360 Assign \fIval\fR to \fIvar\fR, where \fIvar\fR is one of the configuration
361 parameter names, the key names, or \fBbootserver\fR.
362 .RE
364 .sp
365 .ne 2
366 .na
367 \fB\fB\fIvar\fR=\fR\fR
368 .ad
369 .sp .6
370 .RS 4n
371 Unset parameter \fIvar\fR.
372 .RE
374 .sp
375 .ne 2
376 .na
377 \fB\fBlist\fR\fR
378 .ad
379 .sp .6
380 .RS 4n
381 List all parameters and their values (key values retrieved by means of OBP are
382 never shown).
383 .RE
385 .sp
386 .ne 2
387 .na
388 \fB\fBprompt\fR\fR
389 .ad
390 .sp .6
391 .RS 4n
392 Prompt for values for unset parameters. The name of each parameter and its
393 current value (if any) is printed, and the user can accept this value (press
394 Return) or enter a new value.
395 .RE
397 .sp
398 .ne 2
399 .na
400 \fB\fBgo\fR\fR
401 .ad
402 .sp .6
403 .RS 4n
404 Once the user is satisfied that all values have been entered, leave the
405 interpreter and continue booting.
406 .RE
408 .sp
409 .ne 2
410 .na
411 \fB\fBexit\fR\fR
412 .ad
413 .sp .6
414 .RS 4n
415 Quit the boot interpreter and return to OBP's \fBok\fR prompt.
416 .RE
418 .sp
419 .LP
420 Any of these assignments or commands can be passed on the command line as part
421 of the \fB-o\fR options, subject to the OBP limit of 128 bytes for boot
422 arguments. For example, \fB-o\fR \fBlist,go\fR would simply list current
423 (default) values of the parameters and then continue booting.
424 .SS "iSCSI Boot"
425 .LP
426 iSCSI boot is currently supported only on x86. The host being booted must be
427 equipped with NIC(s) capable of iBFT (iSCSI Boot Firmware Table) or have the
428 mainboard's BIOS be iBFT-capable. iBFT, defined in the Advanced Configuration
429 and Power Interface (ACPI) 3.0b specification, specifies a block of information
430 that contains various parameters that are useful to the iSCSI Boot process.
431 .sp
432 .LP
433 Firmware implementing iBFT presents an iSCSI disk in the BIOS during startup as
434 a bootable device by establishing the connection to the iSCSI target. The rest
435 of the process of iSCSI booting is the same as booting from a local disk.
436 .sp
437 .LP
438 To configure the iBFT properly, users need to refer to the documentation from
439 their hardware vendors.
440 .SS "Booting from Disk"
441 .LP
442 When booting from disk, the OpenBoot PROM firmware reads the boot blocks from
443 blocks 1 to 15 of the partition specified as the boot device. This standalone
444 booter usually contains a file system-specific reader capable of reading the
445 boot archive.
446 .sp
447 .LP
448 If the pathname to the standalone is relative (does not begin with a slash),
449 the second level boot will look for the standalone in a platform-dependent
450 search path. This path is guaranteed to contain
451 \fB/platform/\fR\fIplatform-name\fR. Many SPARC platforms next search the
452 platform-specific path entry \fB/platform/\fR\fIhardware-class-name\fR. See
453 \fBfilesystem\fR(5). If the pathname is absolute, \fBboot\fR will use the
454 specified path. The \fBboot\fR program then loads the standalone at the
455 appropriate address, and then transfers control.
456 .sp
457 .LP
458 Once the boot archive has been transferred from the boot device, Solaris can
459 initialize and take over control of the machine. This process is further
460 described in the "Boot Archive Phase," below, and is identical on all
461 platforms.
462 .sp
463 .LP
464 If the filename is not given on the command line or otherwise specified, for
465 example, by the \fBboot-file\fR NVRAM variable, \fBboot\fR chooses an
466 appropriate default file to load based on what software is installed on the
467 system and the capabilities of the hardware and firmware.
468 .sp
469 .LP
470 The path to the kernel must not contain any whitespace.
471 .SS "Booting from ZFS"
472 .LP
473 Booting from ZFS differs from booting from UFS in that, with ZFS, a device
474 specifier identifies a storage pool, not a single root file system. A storage
475 pool can contain multiple bootable datasets (that is, root file systems).
476 Therefore, when booting from ZFS, it is not sufficient to specify a boot
477 device. One must also identify a root file system within the pool that was
478 identified by the boot device. By default, the dataset selected for booting is
479 the one identified by the pool's \fBbootfs\fR property. This default selection
480 can be overridden by specifying an alternate bootable dataset with the \fB-Z\fR
481 option.
482 .SS "Boot Archive Phase"
483 .LP
484 The boot archive contains a file system image that is mounted using an
485 in-memory disk. The image is self-describing, specifically containing a file
486 system reader in the boot block. This file system reader mounts and opens the
487 RAM disk image, then reads and executes the kernel contained within it. By
488 default, this kernel is in:
489 .sp
490 .in +2
491 .nf
492 /platform/`uname -i`/kernel/unix
493 .fi
494 .in -2
495 .sp
497 .sp
498 .LP
499 If booting from ZFS, the pathnames of both the archive and the kernel file are
500 resolved in the root file system (that is, dataset) selected for booting as
501 described in the previous section.
502 .sp
503 .LP
504 The initialization of the kernel continues by loading necessary drivers and
505 modules from the in-memory filesystem until I/O can be turned on and the root
506 filesystem mounted. Once the root filesystem is mounted, the in-memory
507 filesystem is no longer needed and is discarded.
508 .SS "OpenBoot PROM \fBboot\fR Command Behavior"
509 .LP
510 The OpenBoot \fBboot\fR command takes arguments of the following form:
511 .sp
512 .in +2
513 .nf
514 ok boot [\fIdevice-specifier\fR] [\fIarguments\fR]
515 .fi
516 .in -2
517 .sp
519 .sp
520 .LP
521 The default \fBboot\fR command has no arguments:
522 .sp
523 .in +2
524 .nf
525 ok boot
526 .fi
527 .in -2
528 .sp
530 .sp
531 .LP
532 If no \fIdevice-specifier\fR is given on the \fBboot\fR command line, OpenBoot
533 typically uses the \fIboot-device\fR or \fIdiag-device\fR \fBNVRAM\fR variable.
534 If no optional \fIarguments\fR are given on the command line, OpenBoot
535 typically uses the \fIboot-file\fR or \fIdiag-file\fR \fBNVRAM\fR variable as
536 default \fBboot\fR arguments. (If the system is in diagnostics mode,
537 \fIdiag-device\fR and \fIdiag-file\fR are used instead of \fIboot-device\fR and
538 \fIboot-file\fR).
539 .sp
540 .LP
541 \fIarguments\fR may include more than one string. All \fIargument\fR strings
542 are passed to the secondary booter; they are not interpreted by OpenBoot.
543 .sp
544 .LP
545 If any \fIarguments\fR are specified on the \fBboot\fR command line, then
546 neither the \fIboot-file\fR nor the \fIdiag-file\fR \fBNVRAM\fR variable is
547 used. The contents of the \fBNVRAM\fR variables are not merged with command
548 line arguments. For example, the command:
549 .sp
550 .in +2
551 .nf
552 ok \fBboot\fR \fB-s\fR
553 .fi
554 .in -2
555 .sp
557 .sp
558 .LP
559 ignores the settings in both \fIboot-file\fR and \fIdiag-file\fR; it interprets
560 the string \fB"-s"\fR as \fIarguments\fR. \fBboot\fR will not use the contents
561 of \fIboot-file\fR or \fIdiag-file\fR.
562 .sp
563 .LP
564 With older PROMs, the command:
565 .sp
566 .in +2
567 .nf
568 ok \fBboot net\fR
569 .fi
570 .in -2
571 .sp
573 .sp
574 .LP
575 took no arguments, using instead the settings in \fIboot-file\fR or
576 \fIdiag-file\fR (if set) as the default file name and arguments to pass to
577 boot. In most cases, it is best to allow the \fBboot\fR command to choose an
578 appropriate default based upon the system type, system hardware and firmware,
579 and upon what is installed on the root file system. Changing \fIboot-file\fR or
580 \fIdiag-file\fR can generate unexpected results in certain circumstances.
581 .sp
582 .LP
583 This behavior is found on most OpenBoot 2.x and 3.x based systems. Note that
584 differences may occur on some platforms.
585 .sp
586 .LP
587 The command:
588 .sp
589 .LP
590 ok \fBboot cdrom\fR
591 .sp
592 .LP
593 \&...also normally takes no arguments. Accordingly, if \fIboot-file\fR is set
594 to the 64-bit kernel filename and you attempt to boot the installation CD or
595 DVD with \fBboot cdrom\fR, boot will fail if the installation media contains
596 only a 32-bit kernel.
597 .sp
598 .LP
599 Because the contents of \fIboot-file\fR or \fIdiag-file\fR can be ignored
600 depending on the form of the \fBboot\fR command used, reliance upon
601 \fIboot-file\fR should be discouraged for most production systems.
602 .sp
603 .LP
604 When executing a WAN boot from a local (CD or DVD) copy of wanboot, one must
605 use:
606 .sp
607 .LP
608 ok \fBboot cdrom -F wanboot - install\fR
609 .sp
610 .LP
611 Modern PROMs have enhanced the network boot support package to support the
612 following syntax for arguments to be processed by the package:
613 .sp
614 .LP
615 [\fIprotocol\fR,] [\fIkey\fR=\fIvalue\fR,]*
616 .sp
617 .LP
618 All arguments are optional and can appear in any order. Commas are required
619 unless the argument is at the end of the list. If specified, an argument takes
620 precedence over any default values, or, if booting using DHCP, over
621 configuration information provided by a DHCP server for those parameters.
622 .sp
623 .LP
624 \fIprotocol\fR, above, specifies the address discovery protocol to be used.
625 .sp
626 .LP
627 Configuration parameters, listed below, are specified as \fIkey\fR=\fIvalue\fR
628 attribute pairs.
629 .sp
630 .ne 2
631 .na
632 \fB\fBtftp-server\fR\fR
633 .ad
634 .sp .6
635 .RS 4n
636 IP address of the TFTP server
637 .RE
639 .sp
640 .ne 2
641 .na
642 \fB\fBfile\fR\fR
643 .ad
644 .sp .6
645 .RS 4n
646 file to download using TFTP or URL for WAN boot
647 .RE
649 .sp
650 .ne 2
651 .na
652 \fB\fBhost-ip\fR\fR
653 .ad
654 .sp .6
655 .RS 4n
656 IP address of the client (in dotted-decimal notation)
657 .RE
659 .sp
660 .ne 2
661 .na
662 \fB\fBrouter-ip\fR\fR
663 .ad
664 .sp .6
665 .RS 4n
666 IP address of the default router
667 .RE
669 .sp
670 .ne 2
671 .na
672 \fB\fBsubnet-mask\fR\fR
673 .ad
674 .sp .6
675 .RS 4n
676 subnet mask (in dotted-decimal notation)
677 .RE
679 .sp
680 .ne 2
681 .na
682 \fB\fBclient-id\fR\fR
683 .ad
684 .sp .6
685 .RS 4n
686 DHCP client identifier
687 .RE
689 .sp
690 .ne 2
691 .na
692 \fB\fBhostname\fR\fR
693 .ad
694 .sp .6
695 .RS 4n
696 hostname to use in DHCP transactions
697 .RE
699 .sp
700 .ne 2
701 .na
702 \fB\fBhttp-proxy\fR\fR
703 .ad
704 .sp .6
705 .RS 4n
706 HTTP proxy server specification (IPADDR[:PORT])
707 .RE
709 .sp
710 .ne 2
711 .na
712 \fB\fBtftp-retries\fR\fR
713 .ad
714 .sp .6
715 .RS 4n
716 maximum number of TFTP retries
717 .RE
719 .sp
720 .ne 2
721 .na
722 \fB\fBdhcp-retries\fR\fR
723 .ad
724 .sp .6
725 .RS 4n
726 maximum number of DHCP retries
727 .RE
729 .sp
730 .LP
731 The list of arguments to be processed by the network boot support package is
732 specified in one of two ways:
733 .RS +4
734 .TP
735 .ie t \(bu
736 .el o
737 As arguments passed to the package's \fBopen\fR method, or
738 .RE
739 .RS +4
740 .TP
741 .ie t \(bu
742 .el o
743 arguments listed in the NVRAM variable \fBnetwork-boot-arguments\fR.
744 .RE
745 .sp
746 .LP
747 Arguments specified in \fBnetwork-boot-arguments\fR will be processed only if
748 there are no arguments passed to the package's \fBopen\fR method.
749 .sp
750 .LP
751 Argument Values
752 .sp
753 .LP
754 \fIprotocol\fR specifies the address discovery protocol to be used. If present,
755 the possible values are \fBrarp\fR or \fBdhcp\fR.
756 .sp
757 .LP
758 If other configuration parameters are specified in the new syntax and style
759 specified by this document, absence of the \fIprotocol\fR parameter implies
760 manual configuration.
761 .sp
762 .LP
763 If no other configuration parameters are specified, or if those arguments are
764 specified in the positional parameter syntax currently supported, the absence
765 of the \fIprotocol\fR parameter causes the network boot support package to use
766 the platform-specific default address discovery protocol.
767 .sp
768 .LP
769 Manual configuration requires that the client be provided its IP address, the
770 name of the boot file, and the address of the server providing the boot file
771 image. Depending on the network configuration, it might be required that
772 \fBsubnet-mask\fR and \fBrouter-ip\fR also be specified.
773 .sp
774 .LP
775 If the \fIprotocol\fR argument is not specified, the network boot support
776 package uses the platform-specific default address discovery protocol.
777 .sp
778 .LP
779 \fBtftp-server\fR is the IP address (in standard IPv4 dotted-decimal notation)
780 of the TFTP server that provides the file to download if using TFTP.
781 .sp
782 .LP
783 When using DHCP, the value, if specified, overrides the value of the TFTP
784 server specified in the DHCP response.
785 .sp
786 .LP
787 The TFTP RRQ is unicast to the server if one is specified as an argument or in
788 the DHCP response. Otherwise, the TFTP RRQ is broadcast.
789 .sp
790 .LP
791 \fIfile\fR specifies the file to be loaded by TFTP from the TFTP server, or the
792 URL if using HTTP. The use of HTTP is triggered if the file name is a URL, that
793 is, the file name starts with \fBhttp:\fR (case-insensitive).
794 .sp
795 .LP
796 When using RARP and TFTP, the default file name is the ASCII hexadecimal
797 representation of the IP address of the client, as documented in a preceding
798 section of this document.
799 .sp
800 .LP
801 When using DHCP, this argument, if specified, overrides the name of the boot
802 file specified in the DHCP response.
803 .sp
804 .LP
805 When using DHCP and TFTP, the default file name is constructed from the root
806 node's \fBname\fR property, with commas (,) replaced by periods (.).
807 .sp
808 .LP
809 When specified on the command line, the filename must not contain slashes
810 (\fB/\fR).
811 .sp
812 .LP
813 The format of URLs is described in RFC 2396. The HTTP server must be specified
814 as an IP address (in standard IPv4 dotted-decimal notation). The optional port
815 number is specified in decimal. If a port is not specified, port 80 (decimal)
816 is implied.
817 .sp
818 .LP
819 The URL presented must be "safe-encoded", that is, the package does not apply
820 escape encodings to the URL presented. URLs containing commas must be presented
821 as a quoted string. Quoting URLs is optional otherwise.
822 .sp
823 .LP
824 \fBhost-ip\fR specifies the IP address (in standard IPv4 dotted-decimal
825 notation) of the client, the system being booted. If using RARP as the address
826 discovery protocol, specifying this argument makes use of RARP unnecessary.
827 .sp
828 .LP
829 If DHCP is used, specifying the \fBhost-ip\fR argument causes the client to
830 follow the steps required of a client with an "Externally Configured Network
831 Address", as specified in RFC 2131.
832 .sp
833 .LP
834 \fBrouter-ip\fR is the IP address (in standard IPv4 dotted-decimal notation) of
835 a router on a directly connected network. The router will be used as the first
836 hop for communications spanning networks. If this argument is supplied, the
837 router specified here takes precedence over the preferred router specified in
838 the DHCP response.
839 .sp
840 .LP
841 \fBsubnet-mask\fR (specified in standard IPv4 dotted-decimal notation) is the
842 subnet mask on the client's network. If the subnet mask is not provided (either
843 by means of this argument or in the DHCP response), the default mask
844 appropriate to the network class (Class A, B, or C) of the address assigned to
845 the booting client will be assumed.
846 .sp
847 .LP
848 \fBclient-id\fR specifies the unique identifier for the client. The DHCP client
849 identifier is derived from this value. Client identifiers can be specified as:
850 .RS +4
851 .TP
852 .ie t \(bu
853 .el o
854 The ASCII hexadecimal representation of the identifier, or
855 .RE
856 .RS +4
857 .TP
858 .ie t \(bu
859 .el o
860 a quoted string
861 .RE
862 .sp
863 .LP
864 Thus, \fBclient-id="openboot"\fR and \fBclient-id=6f70656e626f6f74\fR both
865 represent a DHCP client identifier of 6F70656E626F6F74.
866 .sp
867 .LP
868 Identifiers specified on the command line must must not include slash (\fB/\fR)
869 or spaces.
870 .sp
871 .LP
872 The maximum length of the DHCP client identifier is 32 bytes, or 64 characters
873 representing 32 bytes if using the ASCII hexadecimal form. If the latter form
874 is used, the number of characters in the identifier must be an even number.
875 Valid characters are 0-9, a-f, and A-F.
876 .sp
877 .LP
878 For correct identification of clients, the client identifier must be unique
879 among the client identifiers used on the subnet to which the client is
880 attached. System administrators are responsible for choosing identifiers that
881 meet this requirement.
882 .sp
883 .LP
884 Specifying a client identifier on a command line takes precedence over any
885 other DHCP mechanism of specifying identifiers.
886 .sp
887 .LP
888 \fBhostname\fR (specified as a string) specifies the hostname to be used in
889 DHCP transactions. The name might or might not be qualified with the local
890 domain name. The maximum length of the hostname is 255 characters.
891 .LP
892 Note -
893 .sp
894 .RS 2
895 The \fBhostname\fR parameter can be used in service environments that require
896 that the client provide the desired hostname to the DHCP server. Clients
897 provide the desired hostname to the DHCP server, which can then register the
898 hostname and IP address assigned to the client with DNS.
899 .RE
900 .sp
901 .LP
902 \fBhttp-proxy\fR is specified in the following standard notation for a host:
903 .sp
904 .in +2
905 .nf
906 \fIhost\fR [":"" \fIport\fR]
907 .fi
908 .in -2
909 .sp
911 .sp
912 .LP
913 \&...where \fIhost\fR is specified as an IP ddress (in standard IPv4
914 dotted-decimal notation) and the optional \fIport\fR is specified in decimal.
915 If a port is not specified, port 8080 (decimal) is implied.
916 .sp
917 .LP
918 \fBtftp-retries\fR is the maximum number of retries (specified in decimal)
919 attempted before the TFTP process is determined to have failed. Defaults to
920 using infinite retries.
921 .sp
922 .LP
923 \fBdhcp-retries\fR is the maximum number of retries (specified in decimal)
924 attempted before the DHCP process is determined to have failed. Defaults to of
925 using infinite retries.
926 .SS "x86 Bootstrap Procedure"
927 .LP
928 On x86 based systems, the bootstrapping process consists of two conceptually
929 distinct phases, kernel loading and kernel initialization. Kernel loading is
930 implemented in the boot loader using the BIOS ROM on the system
931 board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads boot
932 loader, starting with the first physical sector from a hard disk, DVD, or CD. If
933 supported by the ROM on the network adapter, the BIOS can also download the
934 \fBpxeboot\fR binary from a network boot server. Once the boot loader is
935 loaded, it in turn will load the \fBunix\fR kernel, a pre-constructed boot
936 archive containing kernel modules and data, and any additional files specified
937 in the boot loader configuration. Once specified files are loaded, the boot
938 loader will start the kernel to complete boot.
939 .sp
940 .LP
941 If the device identified by the boot loader as the boot device contains a ZFS
942 storage pool, the \fBmenu.lst\fR file used to create the Boot Environment menu
943 will be found in the dataset at the root of the pool's dataset hierarchy.
944 This is the dataset with the same name as the pool itself. There is always
945 exactly one such dataset in a pool, and so this dataset is well-suited for
946 pool-wide data such as the \fBmenu.lst\fR file. After the system is booted,
947 this dataset is mounted at /\fIpoolname\fR in the root file system.
948 .sp
949 .LP
950 There can be multiple bootable datasets (that is, root file systems) within a
951 pool. The default file system to load the kernel is identified by the boot
952 pool \fBbootfs\fR property (see \fBzpool\fR(1M)). All bootable datasets are
953 listed in the \fBmenu.lst\fR file, which is used by the boot loader to compose
954 the Boot Environment menu, to implement support to load a kernel and boot from
955 an alternate Boot Environment.
956 .sp
957 .LP
958 Kernel initialization starts when the boot loader finishes loading the files
959 specified in the boot loader configuration and hands control over to the
960 \fBunix\fR binary. The Unix operating system initializes, links in the
961 necessary modules from the boot archive and mounts the root file system on
962 the real root device. At this point, the kernel regains
963 storage I/O, mounts additional file systems (see \fBvfstab\fR(4)), and starts
964 various operating system services (see \fBsmf\fR(5)).
966 .SH OPTIONS
967 .SS "SPARC"
968 .LP
969 The following SPARC options are supported:
970 .sp
971 .ne 2
972 .na
973 \fB\fB-a\fR\fR
974 .ad
975 .sp .6
976 .RS 4n
977 The boot program interprets this flag to mean \fBask me\fR, and so it prompts
978 for the name of the standalone. The \fB\&'\fR\fB-a\fR\fB\&'\fR flag is then
979 passed to the standalone program.
980 .RE
982 .sp
983 .ne 2
984 .na
985 \fB\fB-D\fR \fIdefault-file\fR\fR
986 .ad
987 .sp .6
988 .RS 4n
989 Explicitly specify the \fIdefault-file\fR. On some systems, \fBboot\fR chooses
990 a dynamic default file, used when none is otherwise specified. This option
991 allows the \fIdefault-file\fR to be explicitly set and can be useful when
992 booting \fBkmdb\fR(1) since, by default, \fBkmdb\fR loads the default-file as
993 exported by the \fBboot\fR program.
994 .RE
996 .sp
997 .ne 2
998 .na
999 \fB\fB-F\fR \fIobject\fR\fR
1000 .ad
1001 .sp .6
1002 .RS 4n
1003 Boot using the named object. The object must be either an ELF executable or
1004 bootable object containing a boot block. The primary use is to boot the
1005 failsafe or \fBwanboot\fR boot archive.
1006 .RE
1008 .sp
1009 .ne 2
1010 .na
1011 \fB\fB-L\fR\fR
1012 .ad
1013 .sp .6
1014 .RS 4n
1015 List the bootable datasets within a ZFS pool. You can select one of the
1016 bootable datasets in the list, after which detailed instructions for booting
1017 that dataset are displayed. Boot the selected dataset by following the
1018 instructions. This option is supported only when the boot device contains a ZFS
1019 storage pool.
1020 .RE
1022 .sp
1023 .ne 2
1024 .na
1025 \fB\fB-V\fR\fR
1026 .ad
1027 .sp .6
1028 .RS 4n
1029 Display verbose debugging information.
1030 .RE
1032 .sp
1033 .ne 2
1034 .na
1035 \fB\fIboot-flags\fR\fR
1036 .ad
1037 .sp .6
1038 .RS 4n
1039 The boot program passes all \fIboot-flags\fR to \fBfile\fR. They are not
1040 interpreted by \fBboot\fR. See the \fBkernel\fR(1M) and \fBkmdb\fR(1) manual
1041 pages for information about the options available with the default standalone
1042 program.
1043 .RE
1045 .sp
1046 .ne 2
1047 .na
1048 \fB\fIclient-program-args\fR\fR
1049 .ad
1050 .sp .6
1051 .RS 4n
1052 The \fBboot\fR program passes all \fIclient-program-args\fR to \fIfile\fR. They
1053 are not interpreted by \fBboot\fR.
1054 .RE
1056 .sp
1057 .ne 2
1058 .na
1059 \fB\fIfile\fR\fR
1060 .ad
1061 .sp .6
1062 .RS 4n
1063 Name of a standalone program to \fBboot\fR. If a filename is not explicitly
1064 specified, either on the \fBboot\fR command line or in the \fIboot-file\fR
1065 NVRAM variable, \fBboot\fR chooses an appropriate default filename.
1066 .RE
1068 .sp
1069 .ne 2
1070 .na
1071 \fB\fIOBP\fR \fInames\fR\fR
1072 .ad
1073 .sp .6
1074 .RS 4n
1075 Specify the open boot prom designations. For example, on Desktop SPARC based
1076 systems, the designation \fB/sbus/esp@0,800000/sd@3,0:a\fR indicates a
1077 \fBSCSI\fR disk (sd) at target 3, lun0 on the \fBSCSI\fR bus, with the esp host
1078 adapter plugged into slot 0.
1079 .RE
1081 .sp
1082 .ne 2
1083 .na
1084 \fB\fB-Z\fR \fIdataset\fR\fR
1085 .ad
1086 .sp .6
1087 .RS 4n
1088 Boot from the root file system in the specified ZFS dataset.
1089 .RE
1091 .SS "x86"
1092 .LP
1093 The following x86 options are supported:
1094 .sp
1095 .ne 2
1096 .na
1097 \fB\fB-B\fR \fIprop\fR=\fIval\fR...\fR
1098 .ad
1099 .sp .6
1100 .RS 4n
1101 One or more property-value pairs to be passed to the kernel. Multiple
1102 property-value pairs must be separated by a comma. Use of this option is the
1103 equivalent of the command: \fBeeprom\fR \fIprop\fR=\fIval\fR. See
1104 \fBeeprom\fR(1M) for available properties and valid values.
1105 .RE
1107 .sp
1108 .ne 2
1109 .na
1110 \fB\fIboot-flags\fR\fR
1111 .ad
1112 .sp .6
1113 .RS 4n
1114 The boot program passes all \fIboot-flags\fR to \fBfile\fR. They are not
1115 interpreted by \fBboot\fR. See \fBkernel\fR(1M) and \fBkmdb\fR(1) for
1116 information about the options available with the kernel.
1117 .RE
1119 .SH X86 BOOT SEQUENCE DETAILS
1120 .LP
1121 After a PC-compatible machine is turned on, the system firmware in the \fBBIOS
1122 ROM\fR executes a power-on self test (POST), runs \fBBIOS\fR extensions in
1123 peripheral board \fBROMs,\fR and invokes software interrupt INT 19h, Bootstrap.
1124 The INT 19h handler typically performs the standard PC-compatible boot, which
1125 consists of trying to read the first physical sector from the first diskette
1126 drive, or, if that fails, from the first hard disk. The processor then jumps to
1127 the first byte of the sector image in memory.
1128 .SH X86 PRIMARY BOOT
1129 .LP
1130 The first sector on a hard disk contains the master boot block (first stage of
1131 the boot program), which contains the master boot program and the Master Boot
1132 Record (\fBMBR\fR) table. The master boot program has recorded the location of
1133 the secondary stage of the boot program and using this location, master boot
1134 will load and start the secondary stage of the boot program.
1136 To support booting multiple operating systems, the master boot program is also
1137 installed as the first sector of the partition with the illumos root file
1138 system. This will allow configuring third party boot programs to use the
1139 chainload technique to boot illumos system.
1141 If the first stage is installed on the master boot block (see the \fB-m\fR
1142 option of \fBinstallboot\fR(1M)), then \fBstage2\fR is loaded directly
1143 from the Solaris partition regardless of the active partition.
1144 .sp
1145 .LP
1146 A similar sequence occurs for DVD or CD boot, but the master boot block location
1147 and contents are dictated by the El Torito specification. The El Torito boot
1148 will then continue in the same way as with the hard disk.
1149 .sp
1150 .LP
1151 Floppy booting is not longer supported. Booting from USB devices follows the
1152 same procedure as with hard disks.
1153 .sp
1154 .LP
1155 An x86 \fBMBR\fR partition for the Solaris software begins with a
1156 one-cylinder boot slice, which contains the boot loader \fBstage1\fR in the
1157 first sector, the standard Solaris disk label and volume table of contents
1158 (VTOC) in the second and third sectors, and in case the UFS file system is
1159 used for the root file system, \fBstage2\fR in the fiftieth and subsequent
1160 sectors.
1162 If the zfs boot is used, \fBstage2\fR is always stored in the zfs pool
1163 boot program area.
1164 .sp
1165 .LP
1166 The behavior is slightly different when a disk is using \fBEFI\fR
1167 partitioning.
1169 To support a UFS root file system in the \fBEFI\fR partition, the \fBstage2\fR
1170 must be stored on separate dedicated partition, as there is no space in UFS
1171 file system boot program area to store the current \fBstage2\fR. This separate
1172 dedicated partition is used as raw disk space, and must have enough space
1173 for both \fBstage1\fR and \fBstage2\fR. The type (tag) of this partition
1174 must be \fBboot\fR, \fBEFI\fR UUID:
1175 .sp
1176 .in +2
1177 .nf
1178 \fB6a82cb45-1dd2-11b2-99a6-080020736631\fR
1179 .fi
1180 .in -2
1181 .sp
1182 For the UUID reference, please see \fB/usr/include/sys/efi_partition.h\fR.
1184 In case of a whole disk zfs pool configuration, the \fBstage1\fR is always
1185 installed in the first sector of the disk, and it always loads \fBstage2\fR
1186 from the partition specified at the boot loader installation time.
1187 .sp
1188 .LP
1189 Once \fBstage2\fR is running, it will load and start the third stage boot
1190 program from root file system. Boot loader supports loading from the ZFS,
1191 UFS and PCFS file systems. The stage3 boot program defaults to be
1192 \fB/boot/zfsloader\fR, and implements a user interface to load and boot the
1193 unix kernel.
1194 .sp
1195 .LP
1196 For network booting, the supported method is Intel's Preboot eXecution
1197 Environment (PXE) standard. When booting from the network using PXE, the system
1198 or network adapter BIOS uses DHCP to locate a network bootstrap program
1199 (\fBpxeboot\fR) on a boot server and reads it using Trivial File Transfer
1200 Protocol (TFTP). The BIOS executes the \fBpxeboot\fR by jumping to its first
1201 byte in memory. The \fBpxeboot\fR program is combined stage2 and stage2 boot
1202 program and implements user interface to load and boot unix kernel.
1203 .SH X86 KERNEL STARTUP
1204 .LP
1205 The kernel startup process is independent of the kernel loading process. During
1206 kernel startup, console I/O goes to the device specified by the \fBconsole\fR
1207 property.
1208 .sp
1209 .LP
1210 When booting from UFS, the root device is specified by the \fBbootpath\fR
1211 property, and the root file system type is specified by the \fBfstype\fR
1212 property. These properties should be setup by the Solaris Install/Upgrade
1213 process in \fB/boot/solaris/bootenv.rc\fR and can be overridden with the
1214 \fB-B\fR option, described above (see the \fBeeprom\fR(1M) man page).
1215 .sp
1216 .LP
1217 When booting from ZFS, the root device is automatically passed by the boot
1218 loader to the kernel as a boot parameter \fB-B\fR \fBzfs-bootfs\fR. The actual
1219 value used by the boot loader can be observed with the \fBeeprom bootcmd\fR
1220 command.
1221 .sp
1222 .LP
1223 If the console properties are not present, console I/O defaults to \fBscreen\fR
1224 and \fBkeyboard\fR. The root device defaults to \fBramdisk\fR and the file
1225 system defaults to \fBufs\fR.
1226 .SH EXAMPLES
1227 .SS "SPARC"
1228 .LP
1229 \fBExample 1 \fRTo Boot the Default Kernel In Single-User Interactive Mode
1230 .sp
1231 .LP
1232 To boot the default kernel in single-user interactive mode, respond to the
1233 \fBok\fR prompt with one of the following:
1235 .sp
1236 .in +2
1237 .nf
1238 \fBboot\fR \fB\fR\fB-as\fR
1240 \fBboot\fR \fBdisk3\fR \fB-as\fR
1241 .fi
1242 .in -2
1243 .sp
1245 .LP
1246 \fBExample 2 \fRNetwork Booting with WAN Boot-Capable PROMs
1247 .sp
1248 .LP
1249 To illustrate some of the subtle repercussions of various boot command line
1250 invocations, assume that the \fBnetwork-boot-arguments\fR are set and that
1251 \fBnet\fR is devaliased as shown in the commands below.
1253 .sp
1254 .LP
1255 In the following command, device arguments in the device alias are processed by
1256 the device driver. The network boot support package processes arguments in
1257 \fBnetwork-boot-arguments\fR.
1259 .sp
1260 .in +2
1261 .nf
1262 \fBboot net\fR
1263 .fi
1264 .in -2
1265 .sp
1267 .sp
1268 .LP
1269 The command below results in no device arguments. The network boot support
1270 package processes arguments in \fBnetwork-boot-arguments\fR.
1272 .sp
1273 .in +2
1274 .nf
1275 \fBboot net:\fR
1276 .fi
1277 .in -2
1278 .sp
1280 .sp
1281 .LP
1282 The command below results in no device arguments. \fBrarp\fR is the only
1283 network boot support package argument. \fBnetwork-boot-arguments\fR is ignored.
1285 .sp
1286 .in +2
1287 .nf
1288 \fBboot net:rarp\fR
1289 .fi
1290 .in -2
1291 .sp
1293 .sp
1294 .LP
1295 In the command below, the specified device arguments are honored. The network
1296 boot support package processes arguments in \fBnetwork-boot-arguments\fR.
1298 .sp
1299 .in +2
1300 .nf
1301 \fBboot net:speed=100,duplex=full\fR
1302 .fi
1303 .in -2
1304 .sp
1306 .LP
1307 \fBExample 3 \fRUsing \fBwanboot\fR with Older PROMs
1308 .sp
1309 .LP
1310 The command below results in the \fBwanboot\fR binary being loaded from DVD or
1311 CD, at which time \fBwanboot\fR will perform DHCP and then drop into its
1312 command interpreter to allow the user to enter keys and any other necessary
1313 configuration.
1315 .sp
1316 .in +2
1317 .nf
1318 \fBboot cdrom -F wanboot -o dhcp,prompt\fR
1319 .fi
1320 .in -2
1321 .sp
1323 .SS "x86"
1324 .LP
1325 \fBExample 4 \fRTo Boot the Default Kernel In 64-bit Single-User Interactive
1326 Mode
1327 .sp
1328 .LP
1329 To boot the default kernel in single-user interactive mode, press the ESC key
1330 to get the boot loader \fBok\fR prompt and enter:
1332 .sp
1333 .in +2
1334 .nf
1335 boot -as
1336 .fi
1337 .in -2
1339 .SH FILES
1340 .ne 2
1341 .na
1342 \fB\fB/etc/inittab\fR\fR
1343 .ad
1344 .sp .6
1345 .RS 4n
1346 Table in which the \fBinitdefault\fR state is specified
1347 .RE
1349 .sp
1350 .ne 2
1351 .na
1352 \fB\fB/sbin/init\fR\fR
1353 .ad
1354 .sp .6
1355 .RS 4n
1356 Program that brings the system to the \fBinitdefault\fR state
1357 .RE
1359 .SS "64-bit SPARC Only"
1360 .ne 2
1361 .na
1362 \fB\fB/platform/\fR\fIplatform-name\fR\fB/kernel/sparcv9/unix\fR\fR
1363 .ad
1364 .sp .6
1365 .RS 4n
1366 Default program to boot system.
1367 .RE
1369 .SS "x86 Only"
1370 .ne 2
1371 .na
1372 \fB\fB/boot\fR\fR
1373 .ad
1374 .sp .6
1375 .RS 4n
1376 Directory containing boot-related files.
1377 .RE
1379 .sp
1380 .ne 2
1381 .na
1382 \fB\fB/rpool/boot/menu.lst\fR\fR
1383 .ad
1384 .sp .6
1385 .RS 4n
1386 Menu index file of bootable operating systems displayed by the boot loader.
1387 .sp
1388 \fBNote:\fR this file is located on the root ZFS pool. While many installs
1389 often name their root zpool 'rpool', this is not required and the
1390 /rpool in the path above should be substituted with the name of
1391 the root pool of your current system.
1392 .RE
1394 .sp
1395 .ne 2
1396 .na
1397 \fB\fB/platform/i86pc/kernel/unix\fR\fR
1398 .ad
1399 .sp .6
1400 .RS 4n
1401 32-bit kernel.
1402 .RE
1404 .SS "64-bit x86 Only"
1405 .ne 2
1406 .na
1407 \fB\fB/platform/i86pc/kernel/amd64/unix\fR\fR
1408 .ad
1409 .sp .6
1410 .RS 4n
1411 64-bit kernel.
1412 .RE
1414 .SH SEE ALSO
1415 .LP
1416 \fBkmdb\fR(1), \fBuname\fR(1), \fBbootadm\fR(1M), \fBeeprom\fR(1M),
1417 \fBinit\fR(1M), \fBinstallboot\fR(1M), \fBkernel\fR(1M), \fBmonitor\fR(1M),
1418 \fBshutdown\fR(1M), \fBsvcadm\fR(1M), \fBumountall\fR(1M), \fBzpool\fR(1M),
1419 \fBuadmin\fR(2), \fBbootparams\fR(4), \fBinittab\fR(4), \fBvfstab\fR(4),
1420 \fBwanboot.conf\fR(4), \fBfilesystem\fR(5)
1421 .sp
1422 .LP
1423 RFC 903, \fIA Reverse Address Resolution Protocol\fR,
1424 \fBhttp://www.ietf.org/rfc/rfc903.txt\fR
1425 .sp
1426 .LP
1427 RFC 2131, \fIDynamic Host Configuration Protocol\fR,
1428 \fBhttp://www.ietf.org/rfc/rfc2131.txt\fR
1429 .sp
1430 .LP
1431 RFC 2132, \fIDHCP Options and BOOTP Vendor Extensions\fR,
1432 \fBhttp://www.ietf.org/rfc/rfc2132.txt\fR
1433 .sp
1434 .LP
1435 RFC 2396, \fIUniform Resource Identifiers (URI): Generic Syntax\fR,
1436 \fBhttp://www.ietf.org/rfc/rfc2396.txt\fR
1437 .sp
1438 .LP
1439 \fI\fR
1440 .sp
1441 .LP
1442 \fISun Hardware Platform Guide\fR
1443 .sp
1444 .LP
1445 \fIOpenBoot Command Reference Manual\fR
1446 .SH WARNINGS
1447 .LP
1448 The \fBboot\fR utility is unable to determine which files can be used as
1449 bootable programs. If the booting of a file that is not bootable is requested,
1450 the \fBboot\fR utility loads it and branches to it. What happens after that is
1451 unpredictable.
1452 .SH NOTES
1453 .LP
1454 \fIplatform-name\fR can be found using the \fB-i\fR option of \fBuname\fR(1).
1455 \fIhardware-class-name\fR can be found using the \fB-m\fR option of
1456 \fBuname\fR(1).
1457 .sp
1458 .LP
1459 The current release of the Solaris operating system does not support machines
1460 running an UltraSPARC-I CPU.