Print this page
10067 Miscellaneous man page typos
Reviewed by: Robert Mustacchi <rm@joyent.com>
Reviewed by: Andy Fiddaman <andy@omniosce.org>
Reviewed by: Volker A. Brandt <vab@bb-c.de>
| 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 boot [boot-flags] [-B prop=val [,val...]]
16 16
17 17
18 18 DESCRIPTION
19 19 Bootstrapping is the process of loading and executing a standalone
20 20 program. For the purpose of this discussion, bootstrapping means the
21 21 process of loading and executing the bootable operating system.
22 22 Typically, the standalone program is the operating system kernel (see
23 23 kernel(1M)), but any standalone program can be booted instead. On a
24 24 SPARC-based system, the diagnostic monitor for a machine is a good
25 25 example of a standalone program other than the operating system that
26 26 can be booted.
27 27
28 28
29 29 If the standalone is identified as a dynamically-linked executable,
30 30 boot will load the interpreter (linker/loader) as indicated by the
31 31 executable format and then transfer control to the interpreter. If the
32 32 standalone is statically-linked, it will jump directly to the
33 33 standalone.
34 34
35 35
36 36 Once the kernel is loaded, it starts the UNIX system, mounts the
37 37 necessary file systems (see vfstab(4)), and runs /sbin/init to bring
38 38 the system to the "initdefault" state specified in /etc/inittab. See
39 39 inittab(4).
40 40
41 41 SPARC Bootstrap Procedure
42 42 On SPARC based systems, the bootstrap procedure on most machines
43 43 consists of the following basic phases.
44 44
45 45
46 46 After the machine is turned on, the system firmware (in PROM) executes
47 47 power-on self-test (POST). The form and scope of these tests depends on
48 48 the version of the firmware in your system.
49 49
50 50
51 51 After the tests have been completed successfully, the firmware attempts
|
↓ open down ↓ |
51 lines elided |
↑ open up ↑ |
52 52 to autoboot if the appropriate flag has been set in the non-volatile
53 53 storage area used by the firmware. The name of the file to load, and
54 54 the device to load it from can also be manipulated.
55 55
56 56
57 57 These flags and names can be set using the eeprom(1M) command from the
58 58 shell, or by using PROM commands from the ok prompt after the system
59 59 has been halted.
60 60
61 61
62 - The second level program is either a fileystem-specific boot block
62 + The second level program is either a filesystem-specific boot block
63 63 (when booting from a disk), or inetboot (when booting across the
64 64 network).
65 65
66 66
67 67 Network Booting
68 68
69 69
70 70 Network booting occurs in two steps: the client first obtains an IP
71 71 address and any other parameters necessary to permit it to load the
72 72 second-stage booter. The second-stage booter in turn loads the boot
73 73 archive from the boot device.
74 74
75 75
76 76 An IP address can be obtained in one of three ways: RARP, DHCP, or
77 77 manual configuration, depending on the functions available in and
78 78 configuration of the PROM. Machines of the sun4u and sun4v kernel
79 79 architectures have DHCP-capable PROMs.
80 80
81 81
82 82 The boot command syntax for specifying the two methods of network
83 83 booting are:
84 84
85 85 boot net:rarp
86 86 boot net:dhcp
87 87
88 88
89 89
90 90
91 91 The command:
92 92
93 93 boot net
94 94
95 95
96 96
97 97
98 98 without a rarp or dhcp specifier, invokes the default method for
99 99 network booting over the network interface for which net is an alias.
100 100
101 101
102 102 The sequence of events for network booting using RARP/bootparams is
103 103 described in the following paragraphs. The sequence for DHCP follows
104 104 the RARP/bootparams description.
105 105
106 106
107 107 When booting over the network using RARP/bootparams, the PROM begins by
108 108 broadcasting a reverse ARP request until it receives a reply. When a
109 109 reply is received, the PROM then broadcasts a TFTP request to fetch the
110 110 first block of inetboot. Subsequent requests will be sent to the server
111 111 that initially answered the first block request. After loading,
112 112 inetboot will also use reverse ARP to fetch its IP address, then
113 113 broadcast bootparams RPC calls (see bootparams(4)) to locate
114 114 configuration information and its root file system. inetboot then loads
115 115 the boot archive by means of NFS and transfers control to that archive.
116 116
117 117
118 118 When booting over the network using DHCP, the PROM broadcasts the
119 119 hardware address and kernel architecture and requests an IP address,
120 120 boot parameters, and network configuration information. After a DHCP
121 121 server responds and is selected (from among potentially multiple
122 122 servers), that server sends to the client an IP address and all other
123 123 information needed to boot the client. After receipt of this
124 124 information, the client PROM examines the name of the file to be
125 125 loaded, and will behave in one of two ways, depending on whether the
126 126 file's name appears to be an HTTP URL. If it does not, the PROM
127 127 downloads inetboot, loads that file into memory, and executes it.
128 128 inetboot loads the boot archive, which takes over the machine and
129 129 releases inetboot. Startup scripts then initiate the DHCP agent (see
130 130 dhcpagent(1M)), which implements further DHCP activities.
131 131
132 132
133 133 iSCSI Boot
134 134 iSCSI boot is currently supported only on x86. The host being booted
135 135 must be equipped with NIC(s) capable of iBFT (iSCSI Boot Firmware
136 136 Table) or have the mainboard's BIOS be iBFT-capable. iBFT, defined in
137 137 the Advanced Configuration and Power Interface (ACPI) 3.0b
138 138 specification, specifies a block of information that contains various
139 139 parameters that are useful to the iSCSI Boot process.
140 140
141 141
142 142 Firmware implementing iBFT presents an iSCSI disk in the BIOS during
143 143 startup as a bootable device by establishing the connection to the
144 144 iSCSI target. The rest of the process of iSCSI booting is the same as
145 145 booting from a local disk.
146 146
147 147
148 148 To configure the iBFT properly, users need to refer to the
149 149 documentation from their hardware vendors.
150 150
151 151 Booting from Disk
152 152 When booting from disk, the OpenBoot PROM firmware reads the boot
153 153 blocks from blocks 1 to 15 of the partition specified as the boot
154 154 device. This standalone booter usually contains a file system-specific
155 155 reader capable of reading the boot archive.
156 156
157 157
158 158 If the pathname to the standalone is relative (does not begin with a
159 159 slash), the second level boot will look for the standalone in a
160 160 platform-dependent search path. This path is guaranteed to contain
161 161 /platform/platform-name. Many SPARC platforms next search the platform-
162 162 specific path entry /platform/hardware-class-name. See filesystem(5).
163 163 If the pathname is absolute, boot will use the specified path. The boot
164 164 program then loads the standalone at the appropriate address, and then
165 165 transfers control.
166 166
167 167
168 168 Once the boot archive has been transferred from the boot device,
169 169 Solaris can initialize and take over control of the machine. This
170 170 process is further described in the "Boot Archive Phase," below, and is
171 171 identical on all platforms.
172 172
173 173
174 174 If the filename is not given on the command line or otherwise
175 175 specified, for example, by the boot-file NVRAM variable, boot chooses
176 176 an appropriate default file to load based on what software is installed
177 177 on the system and the capabilities of the hardware and firmware.
178 178
179 179
180 180 The path to the kernel must not contain any whitespace.
181 181
182 182 Booting from ZFS
183 183 Booting from ZFS differs from booting from UFS in that, with ZFS, a
184 184 device specifier identifies a storage pool, not a single root file
185 185 system. A storage pool can contain multiple bootable datasets (that is,
186 186 root file systems). Therefore, when booting from ZFS, it is not
187 187 sufficient to specify a boot device. One must also identify a root file
188 188 system within the pool that was identified by the boot device. By
189 189 default, the dataset selected for booting is the one identified by the
190 190 pool's bootfs property. This default selection can be overridden by
191 191 specifying an alternate bootable dataset with the -Z option.
192 192
193 193 Boot Archive Phase
194 194 The boot archive contains a file system image that is mounted using an
195 195 in-memory disk. The image is self-describing, specifically containing a
196 196 file system reader in the boot block. This file system reader mounts
197 197 and opens the RAM disk image, then reads and executes the kernel
198 198 contained within it. By default, this kernel is in:
199 199
200 200 /platform/`uname -i`/kernel/unix
201 201
202 202
203 203
204 204
205 205 If booting from ZFS, the pathnames of both the archive and the kernel
206 206 file are resolved in the root file system (that is, dataset) selected
207 207 for booting as described in the previous section.
208 208
209 209
210 210 The initialization of the kernel continues by loading necessary drivers
211 211 and modules from the in-memory filesystem until I/O can be turned on
212 212 and the root filesystem mounted. Once the root filesystem is mounted,
213 213 the in-memory filesystem is no longer needed and is discarded.
214 214
215 215 OpenBoot PROM boot Command Behavior
216 216 The OpenBoot boot command takes arguments of the following form:
217 217
218 218 ok boot [device-specifier] [arguments]
219 219
220 220
221 221
222 222
223 223 The default boot command has no arguments:
224 224
225 225 ok boot
226 226
227 227
228 228
229 229
230 230 If no device-specifier is given on the boot command line, OpenBoot
231 231 typically uses the boot-device or diag-device NVRAM variable. If no
232 232 optional arguments are given on the command line, OpenBoot typically
233 233 uses the boot-file or diag-file NVRAM variable as default boot
234 234 arguments. (If the system is in diagnostics mode, diag-device and diag-
235 235 file are used instead of boot-device and boot-file).
236 236
237 237
238 238 arguments may include more than one string. All argument strings are
239 239 passed to the secondary booter; they are not interpreted by OpenBoot.
240 240
241 241
242 242 If any arguments are specified on the boot command line, then neither
243 243 the boot-file nor the diag-file NVRAM variable is used. The contents of
244 244 the NVRAM variables are not merged with command line arguments. For
245 245 example, the command:
246 246
247 247 ok boot -s
248 248
249 249
250 250
251 251
252 252 ignores the settings in both boot-file and diag-file; it interprets the
253 253 string "-s" as arguments. boot will not use the contents of boot-file
254 254 or diag-file.
255 255
256 256
257 257 With older PROMs, the command:
258 258
259 259 ok boot net
260 260
261 261
262 262
263 263
264 264 took no arguments, using instead the settings in boot-file or diag-file
265 265 (if set) as the default file name and arguments to pass to boot. In
266 266 most cases, it is best to allow the boot command to choose an
267 267 appropriate default based upon the system type, system hardware and
268 268 firmware, and upon what is installed on the root file system. Changing
269 269 boot-file or diag-file can generate unexpected results in certain
270 270 circumstances.
271 271
272 272
273 273 This behavior is found on most OpenBoot 2.x and 3.x based systems. Note
274 274 that differences may occur on some platforms.
275 275
276 276
277 277 The command:
278 278
279 279
280 280 ok boot cdrom
281 281
282 282
283 283 ...also normally takes no arguments. Accordingly, if boot-file is set
284 284 to the 64-bit kernel filename and you attempt to boot the installation
285 285 CD or DVD with boot cdrom, boot will fail if the installation media
286 286 contains only a 32-bit kernel.
287 287
288 288
289 289 Because the contents of boot-file or diag-file can be ignored depending
290 290 on the form of the boot command used, reliance upon boot-file should be
291 291 discouraged for most production systems.
292 292
293 293
294 294 Modern PROMs have enhanced the network boot support package to support
295 295 the following syntax for arguments to be processed by the package:
296 296
297 297
298 298 [protocol,] [key=value,]*
299 299
300 300
301 301 All arguments are optional and can appear in any order. Commas are
302 302 required unless the argument is at the end of the list. If specified,
303 303 an argument takes precedence over any default values, or, if booting
304 304 using DHCP, over configuration information provided by a DHCP server
305 305 for those parameters.
306 306
307 307
308 308 protocol, above, specifies the address discovery protocol to be used.
309 309
310 310
311 311 Configuration parameters, listed below, are specified as key=value
312 312 attribute pairs.
313 313
314 314 tftp-server
315 315
316 316 IP address of the TFTP server
317 317
318 318
319 319 file
320 320
321 321 file to download using TFTP
322 322
323 323
324 324 host-ip
325 325
326 326 IP address of the client (in dotted-decimal notation)
327 327
328 328
329 329 router-ip
330 330
331 331 IP address of the default router
332 332
333 333
334 334 subnet-mask
335 335
336 336 subnet mask (in dotted-decimal notation)
337 337
338 338
339 339 client-id
340 340
341 341 DHCP client identifier
342 342
343 343
344 344 hostname
345 345
346 346 hostname to use in DHCP transactions
347 347
348 348
349 349 http-proxy
350 350
351 351 HTTP proxy server specification (IPADDR[:PORT])
352 352
353 353
354 354 tftp-retries
355 355
356 356 maximum number of TFTP retries
357 357
358 358
359 359 dhcp-retries
360 360
361 361 maximum number of DHCP retries
362 362
363 363
364 364
365 365 The list of arguments to be processed by the network boot support
366 366 package is specified in one of two ways:
367 367
368 368 o As arguments passed to the package's open method, or
369 369
370 370 o arguments listed in the NVRAM variable network-boot-
371 371 arguments.
372 372
373 373
374 374 Arguments specified in network-boot-arguments will be processed only if
375 375 there are no arguments passed to the package's open method.
376 376
377 377
378 378 Argument Values
379 379
380 380
381 381 protocol specifies the address discovery protocol to be used. If
382 382 present, the possible values are rarp or dhcp.
383 383
384 384
385 385 If other configuration parameters are specified in the new syntax and
386 386 style specified by this document, absence of the protocol parameter
387 387 implies manual configuration.
388 388
389 389
390 390 If no other configuration parameters are specified, or if those
391 391 arguments are specified in the positional parameter syntax currently
392 392 supported, the absence of the protocol parameter causes the network
393 393 boot support package to use the platform-specific default address
394 394 discovery protocol.
395 395
396 396
397 397 Manual configuration requires that the client be provided its IP
398 398 address, the name of the boot file, and the address of the server
399 399 providing the boot file image. Depending on the network configuration,
400 400 it might be required that subnet-mask and router-ip also be specified.
401 401
402 402
403 403 If the protocol argument is not specified, the network boot support
404 404 package uses the platform-specific default address discovery protocol.
405 405
406 406
407 407 tftp-server is the IP address (in standard IPv4 dotted-decimal
408 408 notation) of the TFTP server that provides the file to download if
409 409 using TFTP.
410 410
411 411
412 412 When using DHCP, the value, if specified, overrides the value of the
413 413 TFTP server specified in the DHCP response.
414 414
415 415
416 416 The TFTP RRQ is unicast to the server if one is specified as an
417 417 argument or in the DHCP response. Otherwise, the TFTP RRQ is broadcast.
418 418
419 419
420 420 file specifies the file to be loaded by TFTP from the TFTP server.
421 421
422 422
423 423 When using RARP and TFTP, the default file name is the ASCII
424 424 hexadecimal representation of the IP address of the client, as
425 425 documented in a preceding section of this document.
426 426
427 427
428 428 When using DHCP, this argument, if specified, overrides the name of the
429 429 boot file specified in the DHCP response.
430 430
431 431
432 432 When using DHCP and TFTP, the default file name is constructed from the
433 433 root node's name property, with commas (,) replaced by periods (.).
434 434
435 435
436 436 When specified on the command line, the filename must not contain
437 437 slashes (/).
438 438
439 439
440 440 host-ip specifies the IP address (in standard IPv4 dotted-decimal
441 441 notation) of the client, the system being booted. If using RARP as the
442 442 address discovery protocol, specifying this argument makes use of RARP
443 443 unnecessary.
444 444
445 445
446 446 If DHCP is used, specifying the host-ip argument causes the client to
447 447 follow the steps required of a client with an "Externally Configured
448 448 Network Address", as specified in RFC 2131.
449 449
450 450
451 451 router-ip is the IP address (in standard IPv4 dotted-decimal notation)
452 452 of a router on a directly connected network. The router will be used as
453 453 the first hop for communications spanning networks. If this argument is
454 454 supplied, the router specified here takes precedence over the preferred
455 455 router specified in the DHCP response.
456 456
457 457
458 458 subnet-mask (specified in standard IPv4 dotted-decimal notation) is the
459 459 subnet mask on the client's network. If the subnet mask is not provided
460 460 (either by means of this argument or in the DHCP response), the default
461 461 mask appropriate to the network class (Class A, B, or C) of the address
462 462 assigned to the booting client will be assumed.
463 463
464 464
465 465 client-id specifies the unique identifier for the client. The DHCP
466 466 client identifier is derived from this value. Client identifiers can be
467 467 specified as:
468 468
469 469 o The ASCII hexadecimal representation of the identifier, or
470 470
471 471 o a quoted string
472 472
473 473
474 474 Thus, client-id="openboot" and client-id=6f70656e626f6f74 both
475 475 represent a DHCP client identifier of 6F70656E626F6F74.
476 476
477 477
478 478 Identifiers specified on the command line must must not include slash
479 479 (/) or spaces.
480 480
481 481
482 482 The maximum length of the DHCP client identifier is 32 bytes, or 64
483 483 characters representing 32 bytes if using the ASCII hexadecimal form.
484 484 If the latter form is used, the number of characters in the identifier
485 485 must be an even number. Valid characters are 0-9, a-f, and A-F.
486 486
487 487
488 488 For correct identification of clients, the client identifier must be
489 489 unique among the client identifiers used on the subnet to which the
490 490 client is attached. System administrators are responsible for choosing
491 491 identifiers that meet this requirement.
492 492
493 493
494 494 Specifying a client identifier on a command line takes precedence over
495 495 any other DHCP mechanism of specifying identifiers.
496 496
497 497
498 498 hostname (specified as a string) specifies the hostname to be used in
499 499 DHCP transactions. The name might or might not be qualified with the
500 500 local domain name. The maximum length of the hostname is 255
501 501 characters.
502 502
503 503 Note -
504 504
505 505 The hostname parameter can be used in service environments that
506 506 require that the client provide the desired hostname to the DHCP
507 507 server. Clients provide the desired hostname to the DHCP server,
508 508 which can then register the hostname and IP address assigned to the
509 509 client with DNS.
510 510
511 511
512 512 http-proxy is specified in the following standard notation for a host:
513 513
514 514 host [":"" port]
515 515
516 516
517 517
518 518
519 519 ...where host is specified as an IP ddress (in standard IPv4 dotted-
520 520 decimal notation) and the optional port is specified in decimal. If a
521 521 port is not specified, port 8080 (decimal) is implied.
522 522
523 523
524 524 tftp-retries is the maximum number of retries (specified in decimal)
525 525 attempted before the TFTP process is determined to have failed.
526 526 Defaults to using infinite retries.
527 527
528 528
529 529 dhcp-retries is the maximum number of retries (specified in decimal)
530 530 attempted before the DHCP process is determined to have failed.
531 531 Defaults to of using infinite retries.
532 532
533 533 x86 Bootstrap Procedure
534 534 On x86 based systems, the bootstrapping process consists of two
535 535 conceptually distinct phases, kernel loading and kernel initialization.
536 536 Kernel loading is implemented in the boot loader using the BIOS ROM on
537 537 the system board, and BIOS extensions in ROMs on peripheral boards. The
538 538 BIOS loads boot loader, starting with the first physical sector from a
539 539 hard disk, DVD, or CD. If supported by the ROM on the network adapter,
540 540 the BIOS can also download the pxeboot binary from a network boot
541 541 server. Once the boot loader is loaded, it in turn will load the unix
542 542 kernel, a pre-constructed boot archive containing kernel modules and
543 543 data, and any additional files specified in the boot loader
544 544 configuration. Once specified files are loaded, the boot loader will
545 545 start the kernel to complete boot.
546 546
547 547
548 548 If the device identified by the boot loader as the boot device contains
549 549 a ZFS storage pool, the menu.lst file used to create the Boot
550 550 Environment menu will be found in the dataset at the root of the pool's
551 551 dataset hierarchy. This is the dataset with the same name as the pool
552 552 itself. There is always exactly one such dataset in a pool, and so this
553 553 dataset is well-suited for pool-wide data such as the menu.lst file.
554 554 After the system is booted, this dataset is mounted at /poolname in the
555 555 root file system.
556 556
557 557
558 558 There can be multiple bootable datasets (that is, root file systems)
559 559 within a pool. The default file system to load the kernel is identified
560 560 by the boot pool bootfs property (see zpool(1M)). All bootable datasets
561 561 are listed in the menu.lst file, which is used by the boot loader to
562 562 compose the Boot Environment menu, to implement support to load a
563 563 kernel and boot from an alternate Boot Environment.
564 564
565 565
566 566 Kernel initialization starts when the boot loader finishes loading the
567 567 files specified in the boot loader configuration and hands control over
568 568 to the unix binary. The Unix operating system initializes, links in the
569 569 necessary modules from the boot archive and mounts the root file system
570 570 on the real root device. At this point, the kernel regains storage I/O,
571 571 mounts additional file systems (see vfstab(4)), and starts various
572 572 operating system services (see smf(5)).
573 573
574 574
575 575 OPTIONS
576 576 SPARC
577 577 The following SPARC options are supported:
578 578
579 579 -a
580 580
581 581 The boot program interprets this flag to mean ask me, and so it
582 582 prompts for the name of the standalone. The '-a' flag is then
583 583 passed to the standalone program.
584 584
585 585
586 586 -D default-file
587 587
588 588 Explicitly specify the default-file. On some systems, boot chooses
589 589 a dynamic default file, used when none is otherwise specified. This
590 590 option allows the default-file to be explicitly set and can be
591 591 useful when booting kmdb(1) since, by default, kmdb loads the
592 592 default-file as exported by the boot program.
593 593
594 594
595 595 -F object
596 596
597 597 Boot using the named object. The object must be either an ELF
598 598 executable or bootable object containing a boot block. The primary
599 599 use is to boot the failsafe boot archive.
600 600
601 601
602 602 -L
603 603
604 604 List the bootable datasets within a ZFS pool. You can select one of
605 605 the bootable datasets in the list, after which detailed
606 606 instructions for booting that dataset are displayed. Boot the
607 607 selected dataset by following the instructions. This option is
608 608 supported only when the boot device contains a ZFS storage pool.
609 609
610 610
611 611 -V
612 612
613 613 Display verbose debugging information.
614 614
615 615
616 616 boot-flags
617 617
618 618 The boot program passes all boot-flags to file. They are not
619 619 interpreted by boot. See the kernel(1M) and kmdb(1) manual pages
620 620 for information about the options available with the default
621 621 standalone program.
622 622
623 623
624 624 client-program-args
625 625
626 626 The boot program passes all client-program-args to file. They are
627 627 not interpreted by boot.
628 628
629 629
630 630 file
631 631
632 632 Name of a standalone program to boot. If a filename is not
633 633 explicitly specified, either on the boot command line or in the
634 634 boot-file NVRAM variable, boot chooses an appropriate default
635 635 filename.
636 636
637 637
638 638 OBP names
639 639
640 640 Specify the open boot prom designations. For example, on Desktop
641 641 SPARC based systems, the designation /sbus/esp@0,800000/sd@3,0:a
642 642 indicates a SCSI disk (sd) at target 3, lun0 on the SCSI bus, with
643 643 the esp host adapter plugged into slot 0.
644 644
645 645
646 646 -Z dataset
647 647
648 648 Boot from the root file system in the specified ZFS dataset.
649 649
650 650
651 651 x86
652 652 The following x86 options are supported:
653 653
654 654 -B prop=val...
655 655
656 656 One or more property-value pairs to be passed to the kernel.
657 657 Multiple property-value pairs must be separated by a comma. Use of
658 658 this option is the equivalent of the command: eeprom prop=val. See
659 659 eeprom(1M) for available properties and valid values.
660 660
661 661
662 662 boot-flags
663 663
664 664 The boot program passes all boot-flags to file. They are not
665 665 interpreted by boot. See kernel(1M) and kmdb(1) for information
666 666 about the options available with the kernel.
667 667
668 668
669 669 X86 BOOT SEQUENCE DETAILS
670 670 After a PC-compatible machine is turned on, the system firmware in the
671 671 BIOS ROM executes a power-on self test (POST), runs BIOS extensions in
672 672 peripheral board ROMs, and invokes software interrupt INT 19h,
673 673 Bootstrap. The INT 19h handler typically performs the standard PC-
674 674 compatible boot, which consists of trying to read the first physical
675 675 sector from the first diskette drive, or, if that fails, from the first
676 676 hard disk. The processor then jumps to the first byte of the sector
677 677 image in memory.
678 678
679 679 X86 PRIMARY BOOT
680 680 The first sector on a hard disk contains the master boot block (first
681 681 stage of the boot program), which contains the master boot program and
682 682 the Master Boot Record (MBR) table. The master boot program has
683 683 recorded the location of the secondary stage of the boot program and
684 684 using this location, master boot will load and start the secondary
685 685 stage of the boot program.
686 686
687 687 To support booting multiple operating systems, the master boot program
688 688 is also installed as the first sector of the partition with the illumos
689 689 root file system. This will allow configuring third party boot programs
690 690 to use the chainload technique to boot illumos system.
691 691
692 692 If the first stage is installed on the master boot block (see the -m
693 693 option of installboot(1M)), then stage2 is loaded directly from the
694 694 Solaris partition regardless of the active partition.
695 695
696 696
697 697 A similar sequence occurs for DVD or CD boot, but the master boot block
698 698 location and contents are dictated by the El Torito specification. The
699 699 El Torito boot will then continue in the same way as with the hard
700 700 disk.
701 701
702 702
703 703 Floppy booting is not longer supported. Booting from USB devices
704 704 follows the same procedure as with hard disks.
705 705
706 706
707 707 An x86 MBR partition for the Solaris software begins with a one-
708 708 cylinder boot slice, which contains the boot loader stage1 in the first
709 709 sector, the standard Solaris disk label and volume table of contents
710 710 (VTOC) in the second and third sectors, and in case the UFS file system
711 711 is used for the root file system, stage2 in the fiftieth and subsequent
712 712 sectors.
713 713
714 714 If the zfs boot is used, stage2 is always stored in the zfs pool boot
715 715 program area.
716 716
717 717
718 718 The behavior is slightly different when a disk is using EFI
719 719 partitioning.
720 720
721 721 To support a UFS root file system in the EFI partition, the stage2 must
722 722 be stored on separate dedicated partition, as there is no space in UFS
723 723 file system boot program area to store the current stage2. This
724 724 separate dedicated partition is used as raw disk space, and must have
725 725 enough space for both stage1 and stage2. The type (tag) of this
726 726 partition must be boot, EFI UUID:
727 727
728 728 6a82cb45-1dd2-11b2-99a6-080020736631
729 729
730 730 For the UUID reference, please see /usr/include/sys/efi_partition.h.
731 731
732 732 In case of a whole disk zfs pool configuration, the stage1 is always
733 733 installed in the first sector of the disk, and it always loads stage2
734 734 from the partition specified at the boot loader installation time.
735 735
736 736
737 737 Once stage2 is running, it will load and start the third stage boot
738 738 program from root file system. Boot loader supports loading from the
739 739 ZFS, UFS and PCFS file systems. The stage3 boot program defaults to be
740 740 /boot/loader, and implements a user interface to load and boot the unix
741 741 kernel.
742 742
743 743
744 744 For network booting, the supported method is Intel's Preboot eXecution
745 745 Environment (PXE) standard. When booting from the network using PXE,
746 746 the system or network adapter BIOS uses DHCP to locate a network
747 747 bootstrap program (pxeboot) on a boot server and reads it using Trivial
748 748 File Transfer Protocol (TFTP). The BIOS executes the pxeboot by jumping
749 749 to its first byte in memory. The pxeboot program is combined stage2 and
750 750 stage2 boot program and implements user interface to load and boot unix
751 751 kernel.
752 752
753 753 X86 KERNEL STARTUP
754 754 The kernel startup process is independent of the kernel loading
755 755 process. During kernel startup, console I/O goes to the device
756 756 specified by the console property.
757 757
758 758
759 759 When booting from UFS, the root device is specified by the bootpath
760 760 property, and the root file system type is specified by the fstype
761 761 property. These properties should be setup by the Solaris
762 762 Install/Upgrade process in /boot/solaris/bootenv.rc and can be
763 763 overridden with the -B option, described above (see the eeprom(1M) man
764 764 page).
765 765
766 766
767 767 When booting from ZFS, the root device is automatically passed by the
768 768 boot loader to the kernel as a boot parameter -B zfs-bootfs. The actual
769 769 value used by the boot loader can be observed with the eeprom bootcmd
770 770 command.
771 771
772 772
773 773 If the console properties are not present, console I/O defaults to
774 774 screen and keyboard. The root device defaults to ramdisk and the file
775 775 system defaults to ufs.
776 776
777 777 EXAMPLES
778 778 SPARC
779 779 Example 1 To Boot the Default Kernel In Single-User Interactive Mode
780 780
781 781
782 782 To boot the default kernel in single-user interactive mode, respond to
783 783 the ok prompt with one of the following:
784 784
785 785
786 786 boot -as
787 787
788 788 boot disk3 -as
789 789
790 790
791 791
792 792 Example 2 Network Booting
793 793
794 794
795 795 To illustrate some of the subtle repercussions of various boot command
796 796 line invocations, assume that the network-boot-arguments are set and
797 797 that net is devaliased as shown in the commands below.
798 798
799 799
800 800
801 801 In the following command, device arguments in the device alias are
802 802 processed by the device driver. The network boot support package
803 803 processes arguments in network-boot-arguments.
804 804
805 805
806 806 boot net
807 807
808 808
809 809
810 810
811 811 The command below results in no device arguments. The network boot
812 812 support package processes arguments in network-boot-arguments.
813 813
814 814
815 815 boot net:
816 816
817 817
818 818
819 819
820 820 The command below results in no device arguments. rarp is the only
821 821 network boot support package argument. network-boot-arguments is
822 822 ignored.
823 823
824 824
825 825 boot net:rarp
826 826
827 827
828 828
829 829
830 830 In the command below, the specified device arguments are honored. The
831 831 network boot support package processes arguments in network-boot-
832 832 arguments.
833 833
834 834
835 835 boot net:speed=100,duplex=full
836 836
837 837
838 838
839 839 x86
840 840 Example 3 To Boot the Default Kernel In 64-bit Single-User Interactive
841 841 Mode
842 842
843 843
844 844 To boot the default kernel in single-user interactive mode, press the
845 845 ESC key to get the boot loader ok prompt and enter:
846 846
847 847
848 848 boot -as
849 849
850 850
851 851 FILES
852 852 /etc/inittab
853 853
854 854 Table in which the initdefault state is specified
855 855
856 856
857 857 /sbin/init
858 858
859 859 Program that brings the system to the initdefault state
860 860
861 861
862 862 64-bit SPARC Only
863 863 /platform/platform-name/kernel/sparcv9/unix
864 864
865 865 Default program to boot system.
866 866
867 867
868 868 x86 Only
869 869 /boot
870 870
871 871 Directory containing boot-related files.
872 872
873 873
874 874 /rpool/boot/menu.lst
875 875
876 876 Menu index file of bootable operating systems displayed by the boot
877 877 loader.
878 878
879 879 Note: this file is located on the root ZFS pool. While many
880 880 installs often name their root zpool 'rpool', this is not required
881 881 and the /rpool in the path above should be substituted with the
882 882 name of the root pool of your current system.
883 883
884 884
885 885 /platform/i86pc/kernel/unix
886 886
887 887 32-bit kernel.
888 888
889 889
890 890 64-bit x86 Only
891 891 /platform/i86pc/kernel/amd64/unix
892 892
893 893 64-bit kernel.
894 894
895 895
896 896 SEE ALSO
897 897 kmdb(1), uname(1), bootadm(1M), eeprom(1M), init(1M), installboot(1M),
898 898 kernel(1M), monitor(1M), shutdown(1M), svcadm(1M), umountall(1M),
899 899 zpool(1M), uadmin(2), bootparams(4), inittab(4), vfstab(4),
900 900 filesystem(5)
901 901
902 902
903 903 RFC 903, A Reverse Address Resolution Protocol,
904 904 http://www.ietf.org/rfc/rfc903.txt
905 905
906 906
907 907 RFC 2131, Dynamic Host Configuration Protocol,
908 908 http://www.ietf.org/rfc/rfc2131.txt
909 909
910 910
911 911 RFC 2132, DHCP Options and BOOTP Vendor Extensions,
912 912 http://www.ietf.org/rfc/rfc2132.txt
913 913
914 914
915 915 RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax,
916 916 http://www.ietf.org/rfc/rfc2396.txt
917 917
918 918
919 919
920 920
921 921 Sun Hardware Platform Guide
922 922
923 923
924 924 OpenBoot Command Reference Manual
925 925
926 926 WARNINGS
927 927 The boot utility is unable to determine which files can be used as
928 928 bootable programs. If the booting of a file that is not bootable is
929 929 requested, the boot utility loads it and branches to it. What happens
930 930 after that is unpredictable.
931 931
932 932 NOTES
933 933 platform-name can be found using the -i option of uname(1). hardware-
934 934 class-name can be found using the -m option of uname(1).
935 935
936 936
937 937 The current release of the Solaris operating system does not support
938 938 machines running an UltraSPARC-I CPU.
939 939
940 940
941 941
942 942 July 20, 2018 BOOT(1M)
|
↓ open down ↓ |
870 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX