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