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.man.txt
+++ new/usr/src/man/man1m/boot.1m.man.txt
1 1 BOOT(1M) Maintenance Commands BOOT(1M)
2 2
3 3
4 4
5 5 NAME
6 6 boot - start the system kernel or a standalone program
7 7
8 8 SYNOPSIS
9 9 SPARC
10 10 boot [OBP names] [file] [-aLV] [-F object] [-D default-file]
11 11 [-Z dataset] [boot-flags]][[client-program-args]
12 12
13 13
14 14 x86
15 15 kernel$ /platform/i86pc/kernel/$ISADIR/unix [boot-args]
16 16 [-B prop=val [,val...]]
17 17
18 18
19 19 DESCRIPTION
20 20 Bootstrapping is the process of loading and executing a standalone
21 21 program. For the purpose of this discussion, bootstrapping means the
22 22 process of loading and executing the bootable operating system.
23 23 Typically, the standalone program is the operating system kernel (see
24 24 kernel(1M)), but any standalone program can be booted instead. On a
25 25 SPARC-based system, the diagnostic monitor for a machine is a good
26 26 example of a standalone program other than the operating system that
27 27 can be booted.
28 28
29 29
30 30 If the standalone is identified as a dynamically-linked executable, boot
31 31 will load the interpreter (linker/loader) as indicated by the
32 32 executable format and then transfer control to the interpreter. If the
33 33 standalone is statically-linked, it will jump directly to the
34 34 standalone.
35 35
36 36
37 37 Once the kernel is loaded, it starts the UNIX system, mounts the
38 38 necessary file systems (see vfstab(4)), and runs /sbin/init to bring
39 39 the system to the "initdefault" state specified in /etc/inittab. See
40 40 inittab(4).
41 41
42 42 SPARC Bootstrap Procedure
43 43 On SPARC based systems, the bootstrap procedure on most machines
44 44 consists of the following basic phases.
45 45
46 46
47 47 After the machine is turned on, the system firmware (in PROM) executes
48 48 power-on self-test (POST). The form and scope of these tests depends on
49 49 the version of the firmware in your system.
50 50
51 51
52 52 After the tests have been completed successfully, the firmware attempts
53 53 to autoboot if the appropriate flag has been set in the non-volatile
54 54 storage area used by the firmware. The name of the file to load, and
55 55 the device to load it from can also be manipulated.
56 56
57 57
58 58 These flags and names can be set using the eeprom(1M) command from the
59 59 shell, or by using PROM commands from the ok prompt after the system
60 60 has been halted.
61 61
62 62
63 63 The second level program is either a fileystem-specific boot block (when
64 64 booting from a disk), or inetboot or wanboot (when booting across the
65 65 network).
66 66
67 67
68 68 Network Booting
69 69
70 70
71 71 Network booting occurs in two steps: the client first obtains an IP
72 72 address and any other parameters necessary to permit it to load the
73 73 second-stage booter. The second-stage booter in turn loads the boot
74 74 archive from the boot device.
75 75
76 76
77 77 An IP address can be obtained in one of three ways: RARP, DHCP, or
78 78 manual configuration, depending on the functions available in and
79 79 configuration of the PROM. Machines of the sun4u and sun4v kernel
80 80 architectures have DHCP-capable PROMs.
81 81
82 82
83 83 The boot command syntax for specifying the two methods of network
84 84 booting are:
85 85
86 86 boot net:rarp
87 87 boot net:dhcp
88 88
89 89
90 90
91 91
92 92 The command:
93 93
94 94 boot net
95 95
96 96
97 97
98 98
99 99 without a rarp or dhcp specifier, invokes the default method for
100 100 network booting over the network interface for which net is an alias.
101 101
102 102
103 103 The sequence of events for network booting using RARP/bootparams is
104 104 described in the following paragraphs. The sequence for DHCP follows
105 105 the RARP/bootparams description.
106 106
107 107
108 108 When booting over the network using RARP/bootparams, the PROM begins by
109 109 broadcasting a reverse ARP request until it receives a reply. When a
110 110 reply is received, the PROM then broadcasts a TFTP request to fetch the
111 111 first block of inetboot. Subsequent requests will be sent to the server
112 112 that initially answered the first block request. After loading,
113 113 inetboot will also use reverse ARP to fetch its IP address, then
114 114 broadcast bootparams RPC calls (see bootparams(4)) to locate
115 115 configuration information and its root file system. inetboot then loads
116 116 the boot archive by means of NFS and transfers control to that archive.
117 117
118 118
119 119 When booting over the network using DHCP, the PROM broadcasts the
120 120 hardware address and kernel architecture and requests an IP address,
121 121 boot parameters, and network configuration information. After a DHCP
122 122 server responds and is selected (from among potentially multiple
123 123 servers), that server sends to the client an IP address and all other
124 124 information needed to boot the client. After receipt of this
125 125 information, the client PROM examines the name of the file to be
126 126 loaded, and will behave in one of two ways, depending on whether the
127 127 file's name appears to be an HTTP URL. If it does not, the PROM
128 128 downloads inetboot, loads that file into memory, and executes it.
129 129 inetboot loads the boot archive, which takes over the machine and
130 130 releases inetboot. Startup scripts then initiate the DHCP agent (see
131 131 dhcpagent(1M)), which implements further DHCP activities.
132 132
133 133
134 134 If the file to be loaded is an HTTP URL, the PROM will use HTTP to load
135 135 the referenced file. If the client has been configured with an HMAC
136 136 SHA-1 key, it will check the integrity of the loaded file before
137 137 proceeding to execute it. The file is expected to be the wanboot
138 138 binary. The WAN boot process can be configured to use either DHCP or
139 139 NVRAM properties to discover the install server and router and the
140 140 proxies needed to connect to it. When wanboot begins executing, it
141 141 determines whether sufficient information is available to it to allow
142 142 it to proceed. If any necessary information is missing, it will either
143 143 exit with an appropriate error or bring up a command interpreter and
144 144 prompt for further configuration information. Once wanboot has obtained
145 145 the necessary information, it loads the boot loader into memory by
146 146 means of HTTP. If an encryption key has been installed on the client,
147 147 wanboot will verify the boot loader's signature and its accompanying
148 148 hash. Presence of an encryption key but no hashing key is an error.
149 149
150 150
151 151 The wanboot boot loader can communicate with the client using either
152 152 HTTP or secure HTTP. If the former, and if the client has been
153 153 configured with an HMAC SHA-1 key, the boot loader will perform an
154 154 integrity check of the root file system. Once the root file system has
155 155 been loaded into memory (and possibly had an integrity check
156 156 performed), the boot archive is transferred from the server. If
157 157 provided with a boot_logger URL by means of the wanboot.conf(4) file,
158 158 wanboot will periodically log its progress.
159 159
160 160
161 161 Not all PROMs are capable of consuming URLs. You can determine whether
162 162 a client is so capable using the list-security-keys OBP command (see
163 163 monitor(1M)).
164 164
165 165
166 166 WAN booting is not currently available on the x86 platform.
167 167
168 168
169 169 The wanboot Command Line
170 170
171 171
172 172 When the client program is wanboot, it accepts client-program-args of the
173 173 form:
174 174
175 175 boot ... -o opt1[,opt2[,...]]
176 176
177 177
178 178
179 179
180 180 where each option may be an action:
181 181
182 182 dhcp
183 183 Require wanboot to obtain configuration parameters by means of
184 184 DHCP.
185 185
186 186
187 187 prompt
188 188 Cause wanboot to enter its command interpreter.
189 189
190 190
191 191 <cmd>
192 192 One of the interpreter commands listed below.
193 193
194 194
195 195
196 196 ...or an assignment, using the interpreter's parameter names listed
197 197 below.
198 198
199 199
200 200 The wanboot Command Interpreter
201 201
202 202
203 203 The wanboot command interpreter is invoked by supplying a client-
204 204 program-args of "-o prompt" when booting. Input consists of single
205 205 commands or assignments, or a comma-separated list of commands or
206 206 assignments. The configuration parameters are:
207 207
208 208 host-ip
209 209 IP address of the client (in dotted-decimal notation)
210 210
211 211
212 212 router-ip
213 213 IP address of the default router (in dotted-decimal notation)
214 214
215 215
216 216 subnet-mask
217 217 subnet mask (in dotted-decimal notation)
218 218
219 219
220 220 client-id
221 221 DHCP client identifier (a quoted ASCII string or hex ASCII)
222 222
223 223
224 224 hostname
225 225 hostname to request in DHCP transactions (ASCII)
226 226
227 227
228 228 http-proxy
229 229 HTTP proxy server specification (IPADDR[:PORT])
230 230
231 231
232 232
233 233 The key names are:
234 234
235 235 3des
236 236 the triple DES encryption key (48 hex ASCII characters)
237 237
238 238
239 239 aes
240 240 the AES encryption key (32 hex ASCII characters)
241 241
242 242
243 243 sha1
244 244 the HMAC SHA-1 signature key (40 hex ASCII characters)
245 245
246 246
247 247
248 248 Finally, the URL or the WAN boot CGI is referred to by means of:
249 249
250 250 bootserver
251 251 URL of WAN boot's CGI (the equivalent of OBP's file parameter)
252 252
253 253
254 254
255 255 The interpreter accepts the following commands:
256 256
257 257 help
258 258 Print a brief description of the available commands
259 259
260 260
261 261 var=val
262 262 Assign val to var, where var is one of the configuration parameter
263 263 names, the key names, or bootserver.
264 264
265 265
266 266 var=
267 267 Unset parameter var.
268 268
269 269
270 270 list
271 271 List all parameters and their values (key values retrieved by means
272 272 of OBP are never shown).
273 273
274 274
275 275 prompt
276 276 Prompt for values for unset parameters. The name of each parameter
277 277 and its current value (if any) is printed, and the user can accept
278 278 this value (press Return) or enter a new value.
279 279
280 280
281 281 go
282 282 Once the user is satisfied that all values have been entered, leave
283 283 the interpreter and continue booting.
284 284
285 285
286 286 exit
287 287 Quit the boot interpreter and return to OBP's ok prompt.
288 288
289 289
290 290
291 291 Any of these assignments or commands can be passed on the command line
292 292 as part of the -o options, subject to the OBP limit of 128 bytes for
293 293 boot arguments. For example, -o list,go would simply list current
294 294 (default) values of the parameters and then continue booting.
295 295
296 296 iSCSI Boot
297 297 iSCSI boot is currently supported only on x86. The host being booted
298 298 must be equipped with NIC(s) capable of iBFT (iSCSI Boot Firmware
299 299 Table) or have the mainboard's BIOS be iBFT-capable. iBFT, defined in
300 300 the Advanced Configuration and Power Interface (ACPI) 3.0b
301 301 specification, specifies a block of information that contains various
302 302 parameters that are useful to the iSCSI Boot process.
303 303
304 304
305 305 Firmware implementing iBFT presents an iSCSI disk in the BIOS during
306 306 startup as a bootable device by establishing the connection to the
307 307 iSCSI target. The rest of the process of iSCSI booting is the same as
308 308 booting from a local disk.
309 309
310 310
311 311 To configure the iBFT properly, users need to refer to the
312 312 documentation from their hardware vendors.
313 313
314 314 Booting from Disk
315 315 When booting from disk, the OpenBoot PROM firmware reads the boot
316 316 blocks from blocks 1 to 15 of the partition specified as the boot
317 317 device. This standalone booter usually contains a file system-specific
318 318 reader capable of reading the boot archive.
319 319
320 320
321 321 If the pathname to the standalone is relative (does not begin with a
322 322 slash), the second level boot will look for the standalone in a
323 323 platform-dependent search path. This path is guaranteed to contain
324 324 /platform/platform-name. Many SPARC platforms next search the platform-
325 325 specific path entry /platform/hardware-class-name. See filesystem(5). If
326 326 the pathname is absolute, boot will use the specified path. The boot
327 327 program then loads the standalone at the appropriate address, and then
328 328 transfers control.
329 329
330 330
331 331 Once the boot archive has been transferred from the boot device,
332 332 Solaris can initialize and take over control of the machine. This
333 333 process is further described in the "Boot Archive Phase," below, and is
334 334 identical on all platforms.
335 335
336 336
337 337 If the filename is not given on the command line or otherwise
338 338 specified, for example, by the boot-file NVRAM variable, boot chooses an
339 339 appropriate default file to load based on what software is installed on
340 340 the system and the capabilities of the hardware and firmware.
341 341
342 342
343 343 The path to the kernel must not contain any whitespace.
344 344
345 345 Booting from ZFS
346 346 Booting from ZFS differs from booting from UFS in that, with ZFS, a
347 347 device specifier identifies a storage pool, not a single root file
348 348 system. A storage pool can contain multiple bootable datasets (that is,
349 349 root file systems). Therefore, when booting from ZFS, it is not
350 350 sufficient to specify a boot device. One must also identify a root file
351 351 system within the pool that was identified by the boot device. By
352 352 default, the dataset selected for booting is the one identified by the
353 353 pool's bootfs property. This default selection can be overridden by
354 354 specifying an alternate bootable dataset with the -Z option.
355 355
356 356 Boot Archive Phase
357 357 The boot archive contains a file system image that is mounted using an
358 358 in-memory disk. The image is self-describing, specifically containing a
359 359 file system reader in the boot block. This file system reader mounts
360 360 and opens the RAM disk image, then reads and executes the kernel
361 361 contained within it. By default, this kernel is in:
362 362
363 363 /platform/`uname -i`/kernel/unix
364 364
365 365
366 366
367 367
368 368 If booting from ZFS, the pathnames of both the archive and the kernel
369 369 file are resolved in the root file system (that is, dataset) selected
370 370 for booting as described in the previous section.
371 371
372 372
373 373 The initialization of the kernel continues by loading necessary drivers
374 374 and modules from the in-memory filesystem until I/O can be turned on and
375 375 the root filesystem mounted. Once the root filesystem is mounted, the
376 376 in-memory filesystem is no longer needed and is discarded.
377 377
378 378 OpenBoot PROM boot Command Behavior
379 379 The OpenBoot boot command takes arguments of the following form:
380 380
381 381 ok boot [device-specifier] [arguments]
382 382
383 383
384 384
385 385
386 386 The default boot command has no arguments:
387 387
388 388 ok boot
389 389
390 390
391 391
392 392
393 393 If no device-specifier is given on the boot command line, OpenBoot
394 394 typically uses the boot-device or diag-device NVRAM variable. If no
395 395 optional arguments are given on the command line, OpenBoot typically
396 396 uses the boot-file or diag-file NVRAM variable as default boot arguments.
397 397 (If the system is in diagnostics mode, diag-device and diag-file are used
398 398 instead of boot-device and boot-file).
399 399
400 400
401 401 arguments may include more than one string. All argument strings are
402 402 passed to the secondary booter; they are not interpreted by OpenBoot.
403 403
404 404
405 405 If any arguments are specified on the boot command line, then neither
406 406 the boot-file nor the diag-file NVRAM variable is used. The contents of
407 407 the NVRAM variables are not merged with command line arguments. For
408 408 example, the command:
409 409
410 410 ok boot -s
411 411
412 412
413 413
414 414
415 415 ignores the settings in both boot-file and diag-file; it interprets the
416 416 string "-s" as arguments. boot will not use the contents of boot-file or
417 417 diag-file.
418 418
419 419
420 420 With older PROMs, the command:
421 421
422 422 ok boot net
423 423
424 424
425 425
426 426
427 427 took no arguments, using instead the settings in boot-file or diag-file
428 428 (if set) as the default file name and arguments to pass to boot. In
429 429 most cases, it is best to allow the boot command to choose an
430 430 appropriate default based upon the system type, system hardware and
431 431 firmware, and upon what is installed on the root file system. Changing
432 432 boot-file or diag-file can generate unexpected results in certain
433 433 circumstances.
434 434
435 435
436 436 This behavior is found on most OpenBoot 2.x and 3.x based systems. Note
437 437 that differences may occur on some platforms.
438 438
439 439
440 440 The command:
441 441
442 442
443 443 ok boot cdrom
444 444
445 445
446 446 ...also normally takes no arguments. Accordingly, if boot-file is set to
447 447 the 64-bit kernel filename and you attempt to boot the installation CD
448 448 or DVD with boot cdrom, boot will fail if the installation media
449 449 contains only a 32-bit kernel.
450 450
451 451
452 452 Because the contents of boot-file or diag-file can be ignored depending
453 453 on the form of the boot command used, reliance upon boot-file should be
454 454 discouraged for most production systems.
455 455
456 456
457 457 When executing a WAN boot from a local (CD or DVD) copy of wanboot, one
458 458 must use:
459 459
460 460
461 461 ok boot cdrom -F wanboot - install
462 462
463 463
464 464 Modern PROMs have enhanced the network boot support package to support
465 465 the following syntax for arguments to be processed by the package:
466 466
467 467
468 468 [protocol,] [key=value,]*
469 469
470 470
471 471 All arguments are optional and can appear in any order. Commas are
472 472 required unless the argument is at the end of the list. If specified,
473 473 an argument takes precedence over any default values, or, if booting
474 474 using DHCP, over configuration information provided by a DHCP server
475 475 for those parameters.
476 476
477 477
478 478 protocol, above, specifies the address discovery protocol to be used.
479 479
480 480
481 481 Configuration parameters, listed below, are specified as key=value
482 482 attribute pairs.
483 483
484 484 tftp-server
485 485 IP address of the TFTP server
486 486
487 487
488 488 file
489 489 file to download using TFTP or URL for WAN boot
490 490
491 491
492 492 host-ip
493 493 IP address of the client (in dotted-decimal notation)
494 494
495 495
496 496 router-ip
497 497 IP address of the default router
498 498
499 499
500 500 subnet-mask
501 501 subnet mask (in dotted-decimal notation)
502 502
503 503
504 504 client-id
505 505 DHCP client identifier
506 506
507 507
508 508 hostname
509 509 hostname to use in DHCP transactions
510 510
511 511
512 512 http-proxy
513 513 HTTP proxy server specification (IPADDR[:PORT])
514 514
515 515
516 516 tftp-retries
517 517 maximum number of TFTP retries
518 518
519 519
520 520 dhcp-retries
521 521 maximum number of DHCP retries
522 522
523 523
524 524
525 525 The list of arguments to be processed by the network boot support
526 526 package is specified in one of two ways:
527 527
528 528 o As arguments passed to the package's open method, or
529 529
530 530 o arguments listed in the NVRAM variable network-boot-arguments.
531 531
532 532
533 533 Arguments specified in network-boot-arguments will be processed only if
534 534 there are no arguments passed to the package's open method.
535 535
536 536
537 537 Argument Values
538 538
539 539
540 540 protocol specifies the address discovery protocol to be used. If
541 541 present, the possible values are rarp or dhcp.
542 542
543 543
544 544 If other configuration parameters are specified in the new syntax and
545 545 style specified by this document, absence of the protocol parameter
546 546 implies manual configuration.
547 547
548 548
549 549 If no other configuration parameters are specified, or if those
550 550 arguments are specified in the positional parameter syntax currently
551 551 supported, the absence of the protocol parameter causes the network
552 552 boot support package to use the platform-specific default address
553 553 discovery protocol.
554 554
555 555
556 556 Manual configuration requires that the client be provided its IP
557 557 address, the name of the boot file, and the address of the server
558 558 providing the boot file image. Depending on the network configuration,
559 559 it might be required that subnet-mask and router-ip also be specified.
560 560
561 561
562 562 If the protocol argument is not specified, the network boot support
563 563 package uses the platform-specific default address discovery protocol.
564 564
565 565
566 566 tftp-server is the IP address (in standard IPv4 dotted-decimal notation)
567 567 of the TFTP server that provides the file to download if using TFTP.
568 568
569 569
570 570 When using DHCP, the value, if specified, overrides the value of the
571 571 TFTP server specified in the DHCP response.
572 572
573 573
574 574 The TFTP RRQ is unicast to the server if one is specified as an
575 575 argument or in the DHCP response. Otherwise, the TFTP RRQ is broadcast.
576 576
577 577
578 578 file specifies the file to be loaded by TFTP from the TFTP server, or
579 579 the URL if using HTTP. The use of HTTP is triggered if the file name is
580 580 a URL, that is, the file name starts with http: (case-insensitive).
581 581
582 582
583 583 When using RARP and TFTP, the default file name is the ASCII
584 584 hexadecimal representation of the IP address of the client, as
585 585 documented in a preceding section of this document.
586 586
587 587
588 588 When using DHCP, this argument, if specified, overrides the name of the
589 589 boot file specified in the DHCP response.
590 590
591 591
592 592 When using DHCP and TFTP, the default file name is constructed from the
593 593 root node's name property, with commas (,) replaced by periods (.).
594 594
595 595
596 596 When specified on the command line, the filename must not contain
597 597 slashes (/).
598 598
599 599
600 600 The format of URLs is described in RFC 2396. The HTTP server must be
601 601 specified as an IP address (in standard IPv4 dotted-decimal notation).
602 602 The optional port number is specified in decimal. If a port is not
603 603 specified, port 80 (decimal) is implied.
604 604
605 605
606 606 The URL presented must be "safe-encoded", that is, the package does not
607 607 apply escape encodings to the URL presented. URLs containing commas
608 608 must be presented as a quoted string. Quoting URLs is optional
609 609 otherwise.
610 610
611 611
612 612 host-ip specifies the IP address (in standard IPv4 dotted-decimal
613 613 notation) of the client, the system being booted. If using RARP as the
614 614 address discovery protocol, specifying this argument makes use of RARP
615 615 unnecessary.
616 616
617 617
618 618 If DHCP is used, specifying the host-ip argument causes the client to
619 619 follow the steps required of a client with an "Externally Configured
620 620 Network Address", as specified in RFC 2131.
621 621
622 622
623 623 router-ip is the IP address (in standard IPv4 dotted-decimal notation) of
624 624 a router on a directly connected network. The router will be used as
625 625 the first hop for communications spanning networks. If this argument is
626 626 supplied, the router specified here takes precedence over the preferred
627 627 router specified in the DHCP response.
628 628
629 629
630 630 subnet-mask (specified in standard IPv4 dotted-decimal notation) is the
631 631 subnet mask on the client's network. If the subnet mask is not provided
632 632 (either by means of this argument or in the DHCP response), the default
633 633 mask appropriate to the network class (Class A, B, or C) of the address
634 634 assigned to the booting client will be assumed.
635 635
636 636
637 637 client-id specifies the unique identifier for the client. The DHCP
638 638 client identifier is derived from this value. Client identifiers can be
639 639 specified as:
640 640
641 641 o The ASCII hexadecimal representation of the identifier, or
642 642
643 643 o a quoted string
644 644
645 645
646 646 Thus, client-id="openboot" and client-id=6f70656e626f6f74 both represent
647 647 a DHCP client identifier of 6F70656E626F6F74.
648 648
649 649
650 650 Identifiers specified on the command line must must not include slash
651 651 (/) or spaces.
652 652
653 653
654 654 The maximum length of the DHCP client identifier is 32 bytes, or 64
655 655 characters representing 32 bytes if using the ASCII hexadecimal form.
656 656 If the latter form is used, the number of characters in the identifier
657 657 must be an even number. Valid characters are 0-9, a-f, and A-F.
658 658
659 659
660 660 For correct identification of clients, the client identifier must be
661 661 unique among the client identifiers used on the subnet to which the
662 662 client is attached. System administrators are responsible for choosing
663 663 identifiers that meet this requirement.
664 664
665 665
666 666 Specifying a client identifier on a command line takes precedence over
667 667 any other DHCP mechanism of specifying identifiers.
668 668
669 669
670 670 hostname (specified as a string) specifies the hostname to be used in
671 671 DHCP transactions. The name might or might not be qualified with the
672 672 local domain name. The maximum length of the hostname is 255
673 673 characters.
674 674
675 675 Note -
676 676
677 677 The hostname parameter can be used in service environments that
678 678 require that the client provide the desired hostname to the DHCP
679 679 server. Clients provide the desired hostname to the DHCP server,
680 680 which can then register the hostname and IP address assigned to the
681 681 client with DNS.
682 682
683 683
684 684 http-proxy is specified in the following standard notation for a host:
685 685
686 686 host [":"" port]
687 687
688 688
689 689
690 690
691 691 ...where host is specified as an IP ddress (in standard IPv4 dotted-
692 692 decimal notation) and the optional port is specified in decimal. If a
693 693 port is not specified, port 8080 (decimal) is implied.
694 694
695 695
696 696 tftp-retries is the maximum number of retries (specified in decimal)
697 697 attempted before the TFTP process is determined to have failed.
698 698 Defaults to using infinite retries.
699 699
700 700
701 701 dhcp-retries is the maximum number of retries (specified in decimal)
702 702 attempted before the DHCP process is determined to have failed.
703 703 Defaults to of using infinite retries.
704 704
705 705 x86 Bootstrap Procedure
706 706 On x86 based systems, the bootstrapping process consists of two
707 707 conceptually distinct phases, kernel loading and kernel initialization.
708 708 Kernel loading is implemented in GRUB (GRand Unified Bootloader) using
709 709 the BIOS ROM on the system board, and BIOS extensions in ROMs on
710 710 peripheral boards. The BIOS loads GRUB, starting with the first
711 711 physical sector from a hard disk, DVD, or CD. If supported by the ROM
712 712 on the network adapter, the BIOS can also download the pxegrub binary
713 713 from a network boot server. Once GRUB is located, it executes a command
714 714 in a menu to load the unix kernel and a pre-constructed boot archive
715 715 containing kernel modules and data.
716 716
717 717
718 718 If the device identified by GRUB as the boot device contains a ZFS
719 719 storage pool, the menu.lst file used to create the GRUB menu will be
720 720 found in the dataset at the root of the pool's dataset hierarchy. This
721 721 is the dataset with the same name as the pool itself. There is always
722 722 exactly one such dataset in a pool, and so this dataset is well-suited
723 723 for pool-wide data such as the menu.lst file. After the system is
724 724 booted, this dataset is mounted at /poolname in the root file system.
725 725
726 726
727 727 There can be multiple bootable datasets (that is, root file systems)
728 728 within a pool. By default, the file system in which file name entries
729 729 in a menu.lst file are resolved is the one identified by the pool's
730 730 bootfs property (see zpool(1M)). However, a menu.lst entry can contain
731 731 a bootfs command, which specifies an alternate dataset in the pool. In
732 732 this way, the menu.lst file can contain entries for multiple root file
733 733 systems within the pool.
734 734
735 735
736 736 Kernel initialization starts when GRUB finishes loading the boot
737 737 archive and hands control over to the unix binary. At this point, GRUB
738 738 becomes inactive and no more I/O occurs with the boot device. The Unix
739 739 operating system initializes, links in the necessary modules from the
740 740 boot archive and mounts the root file system on the real root device.
741 741 At this point, the kernel regains storage I/O, mounts additional file
742 742 systems (see vfstab(4)), and starts various operating system services
743 743 (see smf(5)).
744 744
745 745 Failsafe Mode
746 746 A requirement of booting from a root filesystem image built into a boot
747 747 archive then remounting root onto the actual root device is that the
748 748 contents of the boot archive and the root filesystem must be
749 749 consistent. Otherwise, the proper operation and integrity of the
750 750 machine cannot be guaranteed.
751 751
752 752
753 753 The term "consistent" means that all files and modules in the root
754 754 filesystem are also present in the boot archive and have identical
755 755 contents. Since the boot strategy requires first reading and mounting
756 756 the boot archive as the first-stage root image, all unloadable kernel
757 757 modules and initialization derived from the contents of the boot
758 758 archive are required to match the real root filesystem. Without such
759 759 consistency, it is possible that the system could be running with a
760 760 kernel module or parameter setting applied to the root device before
761 761 reboot, but not yet updated in the root archive. This inconsistency
762 762 could result in system instability or data loss.
763 763
764 764
765 765 Once the root filesystem is mounted, and before relinquishing the in-
766 766 memory filesystem, Solaris performs a consistency verification against
767 767 the two file systems. If an inconsistency is detected, Solaris suspends
768 768 the normal boot sequence and falls back to failsafe mode. Correcting
769 769 this state requires the administrator take one of two steps. The
770 770 recommended procedure is to reboot to the failsafe archive and rebuild
771 771 the boot archive. This ensures that a known kernel is booted and
772 772 functioning for the archive rebuild process. Alternatively, the
773 773 administrator can elect to clear the inconsistent boot archive service
774 774 state and continue system bring-up if the inconsistency is such that
775 775 correct system operation will not be impaired. See svcadm(1M).
776 776
777 777
778 778 If the boot archive service is cleared and system bring-up is continued
779 779 (the second alternative above), the system may be running with
780 780 unloadable kernel drivers or other modules that are out-of-date with
781 781 respect to the root filesystem. As such, correct system operation may
782 782 be compromised.
783 783
784 784
785 785 To ensure that the boot archive is consistent, the normal system
786 786 shutdown process, as initiated by reboot(1M) and shutdown(1M), checks
787 787 for and applies updates to the boot archive at the conclusion of the
788 788 umountall(1M) milestone.
789 789
790 790
791 791 An update to any kernel file, driver, module or driver configuration
792 792 file that needs to be included in the boot archive after the umountall
793 793 service is complete will result in a failed boot archive consistency
794 794 check during the next boot. To avoid this, it is recommended to always
795 795 shut down a machine cleanly.
796 796
797 797
798 798 If an update is required to the kernel after completion of the
799 799 umountall service, the administrator may elect to rebuild the archive
800 800 by invoking:
801 801
802 802 # bootadm update-archive
803 803
804 804
805 805
806 806 Failsafe Boot Archive
807 807 The failsafe archive can be used to boot the machine at any time for
808 808 maintenance or troubleshooting. The failsafe boot archive is installed
809 809 on the machine, sourced from the miniroot archive. Booting the failsafe
810 810 archive causes the machine to boot using the in-memory filesystem as the
811 811 root device.
812 812
813 813 SPARC
814 814 The SPARC failsafe archive is:
815 815
816 816 /platform/`uname -i`/failsafe
817 817
818 818
819 819
820 820
821 821 ...and can be booted as follows:
822 822
823 823 ok boot [device-specifier] -F failsafe
824 824
825 825
826 826
827 827
828 828 If a user wishes to boot a failsafe archive from a particular ZFS
829 829 bootable dataset, this can be done as follows:
830 830
831 831 ok boot [device-specifier] -Z dataset -F failsafe
832 832
833 833
834 834
835 835 x86
836 836 The x86 failsafe archive is:
837 837
838 838 /boot/x86.miniroot-safe
839 839
840 840
841 841
842 842
843 843 ...and can be booted by selecting the Solaris failsafe item from the
844 844 GRUB menu.
845 845
846 846 OPTIONS
847 847 SPARC
848 848 The following SPARC options are supported:
849 849
850 850 -a
851 851 The boot program interprets this flag to mean ask me, and so it
852 852 prompts for the name of the standalone. The '-a' flag is then passed
853 853 to the standalone program.
854 854
855 855
856 856 -D default-file
857 857 Explicitly specify the default-file. On some systems, boot chooses a
858 858 dynamic default file, used when none is otherwise specified. This
859 859 option allows the default-file to be explicitly set and can be
860 860 useful when booting kmdb(1) since, by default, kmdb loads the
861 861 default-file as exported by the boot program.
862 862
863 863
864 864 -F object
865 865 Boot using the named object. The object must be either an ELF
866 866 executable or bootable object containing a boot block. The primary
867 867 use is to boot the failsafe or wanboot boot archive.
868 868
869 869
870 870 -L
871 871 List the bootable datasets within a ZFS pool. You can select one of
872 872 the bootable datasets in the list, after which detailed
873 873 instructions for booting that dataset are displayed. Boot the
874 874 selected dataset by following the instructions. This option is
875 875 supported only when the boot device contains a ZFS storage pool.
876 876
877 877
878 878 -V
879 879 Display verbose debugging information.
880 880
881 881
882 882 boot-flags
883 883 The boot program passes all boot-flags to file. They are not
884 884 interpreted by boot. See the kernel(1M) and kmdb(1) manual pages
885 885 for information about the options available with the default
886 886 standalone program.
887 887
888 888
889 889 client-program-args
890 890 The boot program passes all client-program-args to file. They are not
891 891 interpreted by boot.
892 892
893 893
894 894 file
895 895 Name of a standalone program to boot. If a filename is not
896 896 explicitly specified, either on the boot command line or in the
897 897 boot-file NVRAM variable, boot chooses an appropriate default
898 898 filename.
899 899
900 900
901 901 OBP names
902 902 Specify the open boot prom designations. For example, on Desktop
903 903 SPARC based systems, the designation /sbus/esp@0,800000/sd@3,0:a
904 904 indicates a SCSI disk (sd) at target 3, lun0 on the SCSI bus, with
905 905 the esp host adapter plugged into slot 0.
906 906
907 907
908 908 -Z dataset
909 909 Boot from the root file system in the specified ZFS dataset.
910 910
911 911
912 912 x86
913 913 The following x86 options are supported:
914 914
915 915 -B prop=val...
916 916 One or more property-value pairs to be passed to the kernel.
917 917 Multiple property-value pairs must be separated by a comma. Use of
918 918 this option is the equivalent of the command: eeprom prop=val. See
919 919 eeprom(1M) for available properties and valid values.
920 920
921 921 If the root file system corresponding to this menu entry is a ZFS
922 922 dataset, the menu entry needs the following option added:
923 923
924 924 -B $ZFS-BOOTFS
925 925
926 926
927 927
928 928
929 929 boot-args
930 930 The boot program passes all boot-args to file. They are not
931 931 interpreted by boot. See kernel(1M) and kmdb(1) for information
932 932 about the options available with the kernel.
933 933
934 934
935 935 /platform/i86pc/kernel/$ISADIR/unix
936 936 Name of the kernel to boot. When using the kernel$ token, $ISADIR
937 937 expands to amd64 on 64-bit machines, and a null string on other
938 938 machines. As a result of this dereferencing, this path expands to
939 939 the proper kernel for the machine.
940 940
941 941
942 942 X86 BOOT SEQUENCE DETAILS
|
↓ open down ↓ |
942 lines elided |
↑ open up ↑ |
943 943 After a PC-compatible machine is turned on, the system firmware in the
944 944 BIOS ROM executes a power-on self test (POST), runs BIOS extensions in
945 945 peripheral board ROMs, and invokes software interrupt INT 19h,
946 946 Bootstrap. The INT 19h handler typically performs the standard PC-
947 947 compatible boot, which consists of trying to read the first physical
948 948 sector from the first diskette drive, or, if that fails, from the first
949 949 hard disk. The processor then jumps to the first byte of the sector
950 950 image in memory.
951 951
952 952 X86 PRIMARY BOOT
953 - The first sector on a floppy disk contains the master boot block (GRUB
954 - stage1). The stage 1 is responsible for loading GRUB stage2. Now GRUB
955 - is fully functional. It reads and executes the menu file
956 - /boot/grub/menu.lst. A similar sequence occurs for DVD or CD boot, but
957 - the master boot block location and contents are dictated by the El
958 - Torito specification. The El Torito boot also leads to strap.com, which
959 - in turn loads boot.bin.
960 -
961 -
962 953 The first sector on a hard disk contains the master boot block, which
963 954 contains the master boot program and the FDISK table, named for the PC
964 955 program that maintains it. The master boot finds the active partition
965 956 in the FDISK table, loads its first sector (GRUB stage1), and jumps to
966 957 its first byte in memory. This completes the standard PC-compatible hard
967 958 disk boot sequence. If GRUB stage1 is installed on the master boot
968 959 block (see the -m option of installgrub(1M)), then stage2 is loaded
969 960 directly from the Solaris partition regardless of the active partition.
970 961
971 962
963 + A similar sequence occurs for DVD or CD boot, but the master boot block
964 + location and contents are dictated by the El Torito specification. The
965 + El Torito boot will then continue in the same way as with the hard
966 + disk.
967 +
968 +
969 + Floppy booting is not longer supported. Booting from USB devices
970 + follows the same procedure as with hard disks.
971 +
972 +
972 973 An x86 FDISK partition for the Solaris software begins with a one-
973 974 cylinder boot slice, which contains GRUB stage1 in the first sector,
974 975 the standard Solaris disk label and volume table of contents (VTOC) in
975 976 the second and third sectors, and GRUB stage2 in the fiftieth and
976 977 subsequent sectors. The area from sector 4 to 49 might contain boot
977 978 blocks for older versions of Solaris. This makes it possible for
978 979 multiple Solaris releases on the same FDISK to coexist. When the FDISK
979 980 partition for the Solaris software is the active partition, the master
980 981 boot program (mboot) reads the partition boot program in the first
981 982 sector into memory and jumps to it. It in turn reads GRUB stage2
982 983 program into memory and jumps to it. Once the GRUB menu is displayed,
983 984 the user can choose to boot an operating system on a different
984 985 partition, a different disk, or possibly from the network.
985 986
986 987
987 988 The behavior is slightly different when a disk is using EFI
988 989 partitioning. In that case the GRUB stage1 is always installed in the
989 990 first sector of the disk, and it always loads stage2 from the partition
990 991 specified at GRUB installation time. This only works on partitions
991 992 containing a ZFS root pool.
992 993
993 994
994 995 For network booting, the supported method is Intel's Preboot eXecution
995 996 Environment (PXE) standard. When booting from the network using PXE,
996 997 the system or network adapter BIOS uses DHCP to locate a network
997 998 bootstrap program (pxegrub) on a boot server and reads it using Trivial
998 999 File Transfer Protocol (TFTP). The BIOS executes the pxegrub by jumping
999 1000 to its first byte in memory. The pxegrub program downloads a menu file
1000 1001 and presents the entries to user.
1001 1002
1002 1003 X86 KERNEL STARTUP
1003 1004 The kernel startup process is independent of the kernel loading
1004 1005 process. During kernel startup, console I/O goes to the device
1005 1006 specified by the console property.
1006 1007
1007 1008
1008 1009 When booting from UFS, the root device is specified by the bootpath
1009 1010 property, and the root file system type is specified by the fstype
1010 1011 property. These properties should be setup by the Solaris
1011 1012 Install/Upgrade process in /boot/solaris/bootenv.rc and can be
1012 1013 overridden with the -B option, described above (see the eeprom(1M) man
1013 1014 page).
1014 1015
1015 1016
1016 1017 When booting from ZFS, the root device is specified by a boot parameter
1017 1018 specified by the -B $ZFS-BOOTFS parameter on either the kernel or module
1018 1019 line in the GRUB menu entry. This value (as with all parameters
1019 1020 specified by the -B option) is passed by GRUB to the kernel.
1020 1021
1021 1022
1022 1023 If the console properties are not present, console I/O defaults to
1023 1024 screen and keyboard. The root device defaults to ramdisk and the file
1024 1025 system defaults to ufs.
1025 1026
1026 1027 EXAMPLES
1027 1028 SPARC
1028 1029 Example 1 To Boot the Default Kernel In Single-User Interactive Mode
1029 1030
1030 1031
1031 1032 To boot the default kernel in single-user interactive mode, respond to
1032 1033 the ok prompt with one of the following:
1033 1034
1034 1035
1035 1036 boot -as
1036 1037
1037 1038 boot disk3 -as
1038 1039
1039 1040
1040 1041
1041 1042 Example 2 Network Booting with WAN Boot-Capable PROMs
1042 1043
1043 1044
1044 1045 To illustrate some of the subtle repercussions of various boot command
1045 1046 line invocations, assume that the network-boot-arguments are set and that
1046 1047 net is devaliased as shown in the commands below.
1047 1048
1048 1049
1049 1050
1050 1051 In the following command, device arguments in the device alias are
1051 1052 processed by the device driver. The network boot support package
1052 1053 processes arguments in network-boot-arguments.
1053 1054
1054 1055
1055 1056 boot net
1056 1057
1057 1058
1058 1059
1059 1060
1060 1061 The command below results in no device arguments. The network boot
1061 1062 support package processes arguments in network-boot-arguments.
1062 1063
1063 1064
1064 1065 boot net:
1065 1066
1066 1067
1067 1068
1068 1069
1069 1070 The command below results in no device arguments. rarp is the only
1070 1071 network boot support package argument. network-boot-arguments is ignored.
1071 1072
1072 1073
1073 1074 boot net:rarp
1074 1075
1075 1076
1076 1077
1077 1078
1078 1079 In the command below, the specified device arguments are honored. The
1079 1080 network boot support package processes arguments in network-boot-
1080 1081 arguments.
1081 1082
1082 1083
1083 1084 boot net:speed=100,duplex=full
1084 1085
1085 1086
1086 1087
1087 1088 Example 3 Using wanboot with Older PROMs
1088 1089
1089 1090
1090 1091 The command below results in the wanboot binary being loaded from DVD
1091 1092 or CD, at which time wanboot will perform DHCP and then drop into its
1092 1093 command interpreter to allow the user to enter keys and any other
1093 1094 necessary configuration.
1094 1095
1095 1096
1096 1097 boot cdrom -F wanboot -o dhcp,prompt
1097 1098
1098 1099
1099 1100
1100 1101 x86 (32-bit)
1101 1102 Example 4 To Boot the Default Kernel In 32-bit Single-User Interactive
1102 1103 Mode
1103 1104
1104 1105
1105 1106 To boot the default kernel in single-user interactive mode, edit the
1106 1107 GRUB kernel command line to read:
1107 1108
1108 1109
1109 1110 kernel /platform/i86pc/kernel/unix -as
1110 1111
1111 1112
1112 1113
1113 1114 x86 (64-bit Only)
1114 1115 Example 5 To Boot the Default Kernel In 64-bit Single-User Interactive
1115 1116 Mode
1116 1117
1117 1118
1118 1119 To boot the default kernel in single-user interactive mode, edit the
1119 1120 GRUB kernel command line to read:
1120 1121
1121 1122
1122 1123 kernel /platform/i86pc/kernel/amd64/unix -as
1123 1124
1124 1125
1125 1126
1126 1127 Example 6 Switching Between 32-bit and 64-bit Kernels on 64-bit x86
|
↓ open down ↓ |
145 lines elided |
↑ open up ↑ |
1127 1128 Platform
1128 1129
1129 1130
1130 1131 To be able to boot both 32-bit and 64-bit kernels, add entries for both
1131 1132 kernels to /boot/grub/menu.lst, and use the set-menu subcommand of
1132 1133 bootadm(1M) to switch. See bootadm(1M) for an example of the bootadm
1133 1134 set-menu.
1134 1135
1135 1136
1136 1137 FILES
1137 - /platform/platform-name/ufsboot
1138 - Second-level program to boot from a disk, DVD, or CD
1139 -
1140 -
1141 1138 /etc/inittab
1142 1139 Table in which the initdefault state is specified
1143 1140
1144 1141
1145 1142 /sbin/init
1146 1143 Program that brings the system to the initdefault state
1147 1144
1148 1145
1149 1146 64-bit SPARC Only
1150 1147 /platform/platform-name/kernel/sparcv9/unix
1151 1148 Default program to boot system.
1152 1149
1153 1150
1154 1151 x86 Only
1155 1152 /boot
1156 1153 Directory containing boot-related files.
1157 1154
1158 1155
1159 - /boot/grub/menu.lst
1156 + /rpool/boot/grub/menu.lst
1160 1157 Menu of bootable operating systems displayed by GRUB.
1161 1158
1159 + Note: this file is located on the root ZFS pool. While many
1160 + installs often name their root zpool 'rpool', this is not required
1161 + and the /rpool in the path above should be substituted with the
1162 + name of the root pool of your current system.
1162 1163
1164 +
1163 1165 /platform/i86pc/kernel/unix
1164 1166 32-bit kernel.
1165 1167
1166 1168
1167 1169 64-bit x86 Only
1168 1170 /platform/i86pc/kernel/amd64/unix
1169 1171 64-bit kernel.
1170 1172
1171 1173
1172 1174 SEE ALSO
1173 1175 kmdb(1), uname(1), bootadm(1M), eeprom(1M), init(1M), installboot(1M),
1174 1176 kernel(1M), monitor(1M), shutdown(1M), svcadm(1M), umountall(1M),
1175 1177 zpool(1M), uadmin(2), bootparams(4), inittab(4), vfstab(4),
1176 1178 wanboot.conf(4), filesystem(5)
1177 1179
1178 1180
1179 1181 RFC 903, A Reverse Address Resolution Protocol,
1180 1182 http://www.ietf.org/rfc/rfc903.txt
1181 1183
1182 1184
1183 1185 RFC 2131, Dynamic Host Configuration Protocol,
1184 1186 http://www.ietf.org/rfc/rfc2131.txt
1185 1187
1186 1188
1187 1189 RFC 2132, DHCP Options and BOOTP Vendor Extensions,
1188 1190 http://www.ietf.org/rfc/rfc2132.txt
1189 1191
1190 1192
1191 1193 RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax,
1192 1194 http://www.ietf.org/rfc/rfc2396.txt
1193 1195
1194 1196
1195 1197
1196 1198
1197 1199 Sun Hardware Platform Guide
1198 1200
1199 1201
1200 1202 OpenBoot Command Reference Manual
1201 1203
1202 1204 WARNINGS
1203 1205 The boot utility is unable to determine which files can be used as
1204 1206 bootable programs. If the booting of a file that is not bootable is
1205 1207 requested, the boot utility loads it and branches to it. What happens
1206 1208 after that is unpredictable.
1207 1209
|
↓ open down ↓ |
35 lines elided |
↑ open up ↑ |
1208 1210 NOTES
1209 1211 platform-name can be found using the -i option of uname(1). hardware-
1210 1212 class-name can be found using the -m option of uname(1).
1211 1213
1212 1214
1213 1215 The current release of the Solaris operating system does not support
1214 1216 machines running an UltraSPARC-I CPU.
1215 1217
1216 1218
1217 1219
1218 - January 14, 2015 BOOT(1M)
1220 + June 7, 2015 BOOT(1M)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX