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