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>
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 fileystem-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)
--- EOF ---