summaryrefslogtreecommitdiff
path: root/usr/src/man/man1m
diff options
context:
space:
mode:
authorJerry Jelinek <jerry.jelinek@joyent.com>2016-09-26 13:27:55 +0000
committerJerry Jelinek <jerry.jelinek@joyent.com>2016-09-26 13:27:55 +0000
commit0264fb65b613e5b2c44f273fa48b26bebe491074 (patch)
treea375b79dd7543bcf0571578b2189d37168c37c57 /usr/src/man/man1m
parentd21e83058c8edeb1becd9202380d088cb056f0c4 (diff)
parentf76886de6cd6914424d9f6c25bd9d93d87889269 (diff)
downloadillumos-joyent-0264fb65b613e5b2c44f273fa48b26bebe491074.tar.gz
[illumos-gate merge]
commit f76886de6cd6914424d9f6c25bd9d93d87889269 7402 Create tunable to ignore hole_birth feature commit 5bdf86e2a288d6c81a0bcc50a98699f52557bab6 7401 loader.4th is missing newline commit ed4e7a6a5cbc5e8986dc649ad54435210487b102 7340 receive manual origin should override automatic origin commit b021ac0b78f8df3d9c421783d9a323723df84925 7337 inherit_001_pos occasionally times out commit c166b69d29138aed7a415fe7cef698e54c6ae945 7254 ztest failed assertion in ztest_dataset_dirobj_verify: dirobjs + 1 == usedobjs commit 754998c8d410b7b7ddefbfa4de310a030e0c7ce1 7253 ztest failure: dsl_destroy_head(name) == 0 (0x10 == 0x0), file ../ztest.c, line 3235 commit 4220fdc152e5dfec9a1dd51452175295f3684689 7398 zfs test zfs_get_005_neg does not work as expected commit d5f26ad8122c3762fb16413a17bfb497db86a782 5142 libzfs support raidz root pool (loader project) commit c8811bd3e2427dddbac6c05a59cfe117d8fea370 5120 zfs should allow large block/gzip/raidz boot pool (loader project) commit 12e3fba22ec759e9dd8f9564fad79541275b2aa5 6709 manual pages need to be updated for loader (loader project) commit fa0c327afe484fa5ff164fb81ff93715dd6573f8 6706 disable grub menu management in bootadm (loader project) 6707 disable grub menu management in libbe (loader project) commit 9abc7a578aecf9064f46563361e8f856b4bdc35e 6705 halt: replace grub_get_boot_args with be_get_boot_args (loader project) commit a6424c753d6e2f0f04fb65b11e9f9c04445ccbae 6704 svc.startd: replace grub_get_boot_args with be_get_boot_args (loader project) commit c262cbbc8301f7c884fd4800056ee51ba75d931c 6703 update bootadm to support loader configuration (loader project) 6708 update eeprom for loader (loader project) commit ce3cb817f67103796b730fd322174dddefd9a9a8 6702 libbe should support x86 installboot command (loader project) commit 0c946d80993858b7b1314e0b31773e48500e03fb 6701 add installboot to i386 platform (loader project) commit 1386b601c0c7f5c89a9325b8a1e34037304e8119 6700 remove installboot script from i386 platform (loader project) commit f5e5a2c4965aa1013184568ca3140cdcba93e44b 6699 be_get_boot_args interface implementation in libbe (loader project) commit 199767f8919635c4928607450d9e0abb932109ce 5061 freebsd boot loader integration (loader project) commit 0cc5983c8a077e6396dc7c492ee928b40bf0fed1 6698 freebsd btxld port for illumos (loader project) commit afc2ba1deb75b323afde536f2dd18bcafdaa308d 6185 want ficl scripting engine in illumos (loader project) Conflicts: exception_lists/cstyle exception_lists/hdrchk exception_lists/copyright
Diffstat (limited to 'usr/src/man/man1m')
-rw-r--r--usr/src/man/man1m/Makefile1
-rw-r--r--usr/src/man/man1m/beadm.1m11
-rw-r--r--usr/src/man/man1m/boot.1m330
-rw-r--r--usr/src/man/man1m/bootadm.1m159
-rw-r--r--usr/src/man/man1m/eeprom.1m29
-rw-r--r--usr/src/man/man1m/installboot.1m209
-rw-r--r--usr/src/man/man1m/reboot.1m32
7 files changed, 413 insertions, 358 deletions
diff --git a/usr/src/man/man1m/Makefile b/usr/src/man/man1m/Makefile
index 95a6d80172..1cb7503b39 100644
--- a/usr/src/man/man1m/Makefile
+++ b/usr/src/man/man1m/Makefile
@@ -213,6 +213,7 @@ _MANFILES= 6to4relay.1m \
init.1m \
inityp2l.1m \
install.1m \
+ installboot.1m \
installf.1m \
installgrub.1m \
intrd.1m \
diff --git a/usr/src/man/man1m/beadm.1m b/usr/src/man/man1m/beadm.1m
index 0d973c16b4..8e92d8767b 100644
--- a/usr/src/man/man1m/beadm.1m
+++ b/usr/src/man/man1m/beadm.1m
@@ -1,7 +1,7 @@
'\" te
.\" Copyright 2013 Nexenta Systems, Inc. All rights reserved.
-.\" Copyright 2015 Toomas Soome <tsoome@me.com>
-.TH BEADM 1M "Mar 2, 2015"
+.\" Copyright 2016 Toomas Soome <tsoome@me.com>
+.TH BEADM 1M "Feb 21, 2016"
.SH NAME
beadm \- utility for managing zfs boot environments
.SH SYNOPSIS
@@ -176,11 +176,8 @@ provided, the new boot environment will be created as a clone of the
currently
running boot environment. If the \fB-d\fR option is provided then the
description is
-also used as the title for the BE's entry in the GRUB menu for
-x86 systems or
-in the boot menu for SPARC systems. If the \fB-d\fR option is
-not provided, \fIbeName\fR
-will be used as the title.
+also used as the title for the BE's entry in the boot menu. If the \fB-d\fR
+option is not provided, \fIbeName\fR will be used as the title.
.sp
.ne 2
.na
diff --git a/usr/src/man/man1m/boot.1m b/usr/src/man/man1m/boot.1m
index 3c567f126a..2d031006d0 100644
--- a/usr/src/man/man1m/boot.1m
+++ b/usr/src/man/man1m/boot.1m
@@ -5,7 +5,7 @@
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the
.\" fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH BOOT 1M "Jun 13, 2015"
+.TH BOOT 1M "Aug 18, 2016"
.SH NAME
boot \- start the system kernel or a standalone program
.SH SYNOPSIS
@@ -19,8 +19,7 @@ boot \- start the system kernel or a standalone program
.SS "x86"
.LP
.nf
-\fBkernel$\fR \fB/platform/i86pc/kernel/$ISADIR/unix\fR [\fIboot-args\fR]
- [\fB-B\fR \fIprop\fR=\fIval\fR [,\fIval\fR...]]
+\fBboot\fR [\fIboot-flags\fR] [\fB-B\fR \fIprop\fR=\fIval\fR [,\fIval\fR...]]
.fi
.SH DESCRIPTION
@@ -928,154 +927,42 @@ using infinite retries.
.LP
On x86 based systems, the bootstrapping process consists of two conceptually
distinct phases, kernel loading and kernel initialization. Kernel loading is
-implemented in GRUB (GRand Unified Bootloader) using the BIOS ROM on the system
-board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads GRUB,
-starting with the first physical sector from a hard disk, DVD, or CD. If
+implemented in the boot loader using the BIOS ROM on the system
+board, and BIOS extensions in ROMs on peripheral boards. The BIOS loads boot
+loader, starting with the first physical sector from a hard disk, DVD, or CD. If
supported by the ROM on the network adapter, the BIOS can also download the
-\fBpxegrub\fR binary from a network boot server. Once GRUB is located, it
-executes a command in a menu to load the \fBunix\fR kernel and a
-pre-constructed boot archive containing kernel modules and data.
+\fBpxeboot\fR binary from a network boot server. Once the boot loader is
+loaded, it in turn will load the \fBunix\fR kernel, a pre-constructed boot
+archive containing kernel modules and data, and any additional files specified
+in the boot loader configuration. Once specified files are loaded, the boot
+loader will start the kernel to complete boot.
.sp
.LP
-If the device identified by GRUB as the boot device contains a ZFS storage
-pool, the \fBmenu.lst\fR file used to create the GRUB menu will be found in the
-dataset at the root of the pool's dataset hierarchy. This is the dataset with
-the same name as the pool itself. There is always exactly one such dataset in a
-pool, and so this dataset is well-suited for pool-wide data such as the
-\fBmenu.lst\fR file. After the system is booted, this dataset is mounted at
-/\fIpoolname\fR in the root file system.
+If the device identified by the boot loader as the boot device contains a ZFS
+storage pool, the \fBmenu.lst\fR file used to create the Boot Environment menu
+will be found in the dataset at the root of the pool's dataset hierarchy.
+This is the dataset with the same name as the pool itself. There is always
+exactly one such dataset in a pool, and so this dataset is well-suited for
+pool-wide data such as the \fBmenu.lst\fR file. After the system is booted,
+this dataset is mounted at /\fIpoolname\fR in the root file system.
.sp
.LP
There can be multiple bootable datasets (that is, root file systems) within a
-pool. By default, the file system in which file name entries in a
-\fBmenu.lst\fR file are resolved is the one identified by the pool's
-\fBbootfs\fR property (see \fBzpool\fR(1M)). However, a \fBmenu.lst\fR entry
-can contain a \fBbootfs\fR command, which specifies an alternate dataset in the
-pool. In this way, the \fBmenu.lst\fR file can contain entries for multiple
-root file systems within the pool.
-.sp
-.LP
-Kernel initialization starts when GRUB finishes loading the boot archive and
-hands control over to the \fBunix\fR binary. At this point, GRUB becomes
-inactive and no more I/O occurs with the boot device. The Unix operating system
-initializes, links in the necessary modules from the boot archive and mounts
-the root file system on the real root device. At this point, the kernel regains
+pool. The default file system to load the kernel is identified by the boot
+pool \fBbootfs\fR property (see \fBzpool\fR(1M)). All bootable datasets are
+listed in the \fBmenu.lst\fR file, which is used by the boot loader to compose
+the Boot Environment menu, to implement support to load a kernel and boot from
+an alternate Boot Environment.
+.sp
+.LP
+Kernel initialization starts when the boot loader finishes loading the files
+specified in the boot loader configuration and hands control over to the
+\fBunix\fR binary. The Unix operating system initializes, links in the
+necessary modules from the boot archive and mounts the root file system on
+the real root device. At this point, the kernel regains
storage I/O, mounts additional file systems (see \fBvfstab\fR(4)), and starts
various operating system services (see \fBsmf\fR(5)).
-.SS "Failsafe Mode"
-.LP
-A requirement of booting from a root filesystem image built into a boot archive
-then remounting root onto the actual root device is that the contents of the
-boot archive and the root filesystem must be consistent. Otherwise, the proper
-operation and integrity of the machine cannot be guaranteed.
-.sp
-.LP
-The term "consistent" means that all files and modules in the root filesystem
-are also present in the boot archive and have identical contents. Since the
-boot strategy requires first reading and mounting the boot archive as the
-first-stage root image, all unloadable kernel modules and initialization
-derived from the contents of the boot archive are required to match the real
-root filesystem. Without such consistency, it is possible that the system could
-be running with a kernel module or parameter setting applied to the root device
-before reboot, but not yet updated in the root archive. This inconsistency
-could result in system instability or data loss.
-.sp
-.LP
-Once the root filesystem is mounted, and before relinquishing the in-memory
-filesystem, Solaris performs a consistency verification against the two file
-systems. If an inconsistency is detected, Solaris suspends the normal boot
-sequence and falls back to failsafe mode. Correcting this state requires the
-administrator take one of two steps. The recommended procedure is to reboot to
-the failsafe archive and rebuild the boot archive. This ensures that a known
-kernel is booted and functioning for the archive rebuild process.
-Alternatively, the administrator can elect to clear the inconsistent boot
-archive service state and continue system bring-up if the inconsistency is such
-that correct system operation will not be impaired. See \fBsvcadm\fR(1M).
-.sp
-.LP
-If the boot archive service is cleared and system bring-up is continued (the
-second alternative above), the system may be running with unloadable kernel
-drivers or other modules that are out-of-date with respect to the root
-filesystem. As such, correct system operation may be compromised.
-.sp
-.LP
-To ensure that the boot archive is consistent, the normal system shutdown
-process, as initiated by \fBreboot\fR(1M) and \fBshutdown\fR(1M), checks for
-and applies updates to the boot archive at the conclusion of the
-\fBumountall\fR(1M) milestone.
-.sp
-.LP
-An update to any kernel file, driver, module or driver configuration file that
-needs to be included in the boot archive after the \fBumountall\fR service is
-complete will result in a failed boot archive consistency check during the next
-boot. To avoid this, it is recommended to always shut down a machine cleanly.
-.sp
-.LP
-If an update is required to the kernel after completion of the \fBumountall\fR
-service, the administrator may elect to rebuild the archive by invoking:
-.sp
-.in +2
-.nf
-# \fBbootadm update-archive\fR
-.fi
-.in -2
-.sp
-
-.SS "Failsafe Boot Archive"
-.LP
-The failsafe archive can be used to boot the machine at any time for
-maintenance or troubleshooting. The failsafe boot archive is installed on the
-machine, sourced from the miniroot archive. Booting the failsafe archive causes
-the machine to boot using the in-memory filesystem as the root device.
-.SS "SPARC"
-.LP
-The SPARC failsafe archive is:
-.sp
-.in +2
-.nf
-/platform/`uname -i`/failsafe
-.fi
-.in -2
-.sp
-
-.sp
-.LP
-\&...and can be booted as follows:
-.sp
-.in +2
-.nf
-ok \fBboot [\fIdevice-specifier\fR] -F failsafe\fR
-.fi
-.in -2
-.sp
-.sp
-.LP
-If a user wishes to boot a failsafe archive from a particular ZFS bootable
-dataset, this can be done as follows:
-.sp
-.in +2
-.nf
-ok \fBboot [\fIdevice-specifier\fR] -Z \fIdataset\fR -F failsafe\fR
-.fi
-.in -2
-.sp
-
-.SS "x86"
-.LP
-The x86 failsafe archive is:
-.sp
-.in +2
-.nf
-/boot/x86.miniroot-safe
-.fi
-.in -2
-.sp
-
-.sp
-.LP
-\&...and can be booted by selecting the \fBSolaris failsafe\fR item from the
-GRUB menu.
.SH OPTIONS
.SS "SPARC"
.LP
@@ -1215,44 +1102,20 @@ One or more property-value pairs to be passed to the kernel. Multiple
property-value pairs must be separated by a comma. Use of this option is the
equivalent of the command: \fBeeprom\fR \fIprop\fR=\fIval\fR. See
\fBeeprom\fR(1M) for available properties and valid values.
-.sp
-If the root file system corresponding to this menu entry is a ZFS dataset, the
-menu entry needs the following option added:
-.sp
-.in +2
-.nf
--B $ZFS-BOOTFS
-.fi
-.in -2
-.sp
-
.RE
.sp
.ne 2
.na
-\fB\fIboot-args\fR\fR
+\fB\fIboot-flags\fR\fR
.ad
.sp .6
.RS 4n
-The boot program passes all \fIboot-args\fR to \fBfile\fR. They are not
+The boot program passes all \fIboot-flags\fR to \fBfile\fR. They are not
interpreted by \fBboot\fR. See \fBkernel\fR(1M) and \fBkmdb\fR(1) for
information about the options available with the kernel.
.RE
-.sp
-.ne 2
-.na
-\fB\fB/platform/i86pc/kernel/$ISADIR/unix\fR\fR
-.ad
-.sp .6
-.RS 4n
-Name of the kernel to boot. When using the \fBkernel$\fR token, \fB$ISADIR\fR
-expands to \fBamd64\fR on 64-bit machines, and a null string on other machines.
-As a result of this dereferencing, this path expands to the proper kernel for
-the machine.
-.RE
-
.SH X86 BOOT SEQUENCE DETAILS
.LP
After a PC-compatible machine is turned on, the system firmware in the \fBBIOS
@@ -1264,13 +1127,19 @@ drive, or, if that fails, from the first hard disk. The processor then jumps to
the first byte of the sector image in memory.
.SH X86 PRIMARY BOOT
.LP
-The first sector on a hard disk contains the master boot block, which contains
-the master boot program and the \fBFDISK\fR table, named for the \fBPC\fR
-program that maintains it. The master boot finds the active partition in the
-\fBFDISK\fR table, loads its first sector (GRUB \fBstage1\fR), and jumps to its
-first byte in memory. This completes the standard PC-compatible hard disk boot
-sequence. If GRUB \fBstage1\fR is installed on the master boot block (see the
-\fB-m\fR option of \fBinstallgrub\fR(1M)), then \fBstage2\fR is loaded directly
+The first sector on a hard disk contains the master boot block (first stage of
+the boot program), which contains the master boot program and the Master Boot
+Record (\fBMBR\fR) table. The master boot program has recorded the location of
+the secondary stage of the boot program and using this location, master boot
+will load and start the secondary stage of the boot program.
+
+To support booting multiple operating systems, the master boot program is also
+installed as the first sector of the partition with the illumos root file
+system. This will allow configuring third party boot programs to use the
+chainload technique to boot illumos system.
+
+If the first stage is installed on the master boot block (see the \fB-m\fR
+option of \fBinstallboot\fR(1M)), then \fBstage2\fR is loaded directly
from the Solaris partition regardless of the active partition.
.sp
.LP
@@ -1283,34 +1152,54 @@ Floppy booting is not longer supported. Booting from USB devices follows the
same procedure as with hard disks.
.sp
.LP
-An x86 \fBFDISK\fR partition for the Solaris software begins with a
-one-cylinder boot slice, which contains GRUB \fBstage1\fR in the first sector,
-the standard Solaris disk label and volume table of contents (VTOC) in the
-second and third sectors, and GRUB \fBstage2\fR in the fiftieth and subsequent
-sectors. The area from sector 4 to 49 might contain boot blocks for older
-versions of Solaris. This makes it possible for multiple Solaris releases on
-the same FDISK to coexist. When the \fBFDISK\fR partition for the Solaris
-software is the active partition, the master boot program (\fBmboot\fR) reads
-the partition boot program in the first sector into memory and jumps to it. It
-in turn reads GRUB \fBstage2\fR program into memory and jumps to it. Once the
-GRUB menu is displayed, the user can choose to boot an operating system on a
-different partition, a different disk, or possibly from the network.
+An x86 \fBMBR\fR partition for the Solaris software begins with a
+one-cylinder boot slice, which contains the boot loader \fBstage1\fR in the
+first sector, the standard Solaris disk label and volume table of contents
+(VTOC) in the second and third sectors, and in case the UFS file system is
+used for the root file system, \fBstage2\fR in the fiftieth and subsequent
+sectors.
+
+If the zfs boot is used, \fBstage2\fR is always stored in the zfs pool
+boot program area.
.sp
.LP
The behavior is slightly different when a disk is using \fBEFI\fR
-partitioning. In that case the GRUB \fBstage1\fR is always installed
-in the first sector of the disk, and it always loads \fBstage2\fR from
-the partition specified at GRUB installation time. This only works on
-partitions containing a ZFS root pool.
+partitioning.
+
+To support a UFS root file system in the \fBEFI\fR partition, the \fBstage2\fR
+must be stored on separate dedicated partition, as there is no space in UFS
+file system boot program area to store the current \fBstage2\fR. This separate
+dedicated partition is used as raw disk space, and must have enough space
+for both \fBstage1\fR and \fBstage2\fR. The type (tag) of this partition
+must be \fBboot\fR, \fBEFI\fR UUID:
+.sp
+.in +2
+.nf
+\fB6a82cb45-1dd2-11b2-99a6-080020736631\fR
+.fi
+.in -2
+.sp
+For the UUID reference, please see \fB/usr/include/sys/efi_partition.h\fR.
+
+In case of a whole disk zfs pool configuration, the \fBstage1\fR is always
+installed in the first sector of the disk, and it always loads \fBstage2\fR
+from the partition specified at the boot loader installation time.
+.sp
+.LP
+Once \fBstage2\fR is running, it will load and start the third stage boot
+program from root file system. Boot loader supports loading from the ZFS,
+UFS and PCFS file systems. The stage3 boot program defaults to be
+\fB/boot/zfsloader\fR, and implements a user interface to load and boot the
+unix kernel.
.sp
.LP
For network booting, the supported method is Intel's Preboot eXecution
Environment (PXE) standard. When booting from the network using PXE, the system
or network adapter BIOS uses DHCP to locate a network bootstrap program
-(\fBpxegrub\fR) on a boot server and reads it using Trivial File Transfer
-Protocol (TFTP). The BIOS executes the \fBpxegrub\fR by jumping to its first
-byte in memory. The \fBpxegrub\fR program downloads a menu file and presents
-the entries to user.
+(\fBpxeboot\fR) on a boot server and reads it using Trivial File Transfer
+Protocol (TFTP). The BIOS executes the \fBpxeboot\fR by jumping to its first
+byte in memory. The \fBpxeboot\fR program is combined stage2 and stage2 boot
+program and implements user interface to load and boot unix kernel.
.SH X86 KERNEL STARTUP
.LP
The kernel startup process is independent of the kernel loading process. During
@@ -1325,11 +1214,10 @@ process in \fB/boot/solaris/bootenv.rc\fR and can be overridden with the
\fB-B\fR option, described above (see the \fBeeprom\fR(1M) man page).
.sp
.LP
-When booting from ZFS, the root device is specified by a boot parameter
-specified by the \fB-B\fR \fB$ZFS-BOOTFS\fR parameter on either the
-\fBkernel\fR or \fBmodule\fR line in the GRUB menu entry. This value (as with
-all parameters specified by the \fB-B\fR option) is passed by GRUB to the
-kernel.
+When booting from ZFS, the root device is automatically passed by the boot
+loader to the kernel as a boot parameter \fB-B\fR \fBzfs-bootfs\fR. The actual
+value used by the boot loader can be observed with the \fBeeprom bootcmd\fR
+command.
.sp
.LP
If the console properties are not present, console I/O defaults to \fBscreen\fR
@@ -1432,49 +1320,21 @@ configuration.
.in -2
.sp
-.SS "x86 (32-bit)"
-.LP
-\fBExample 4 \fRTo Boot the Default Kernel In 32-bit Single-User Interactive
-Mode
-.sp
-.LP
-To boot the default kernel in single-user interactive mode, edit the GRUB
-kernel command line to read:
-
-.sp
-.in +2
-.nf
-kernel /platform/i86pc/kernel/unix -as
-.fi
-.in -2
-.sp
-
-.SS "x86 (64-bit Only)"
+.SS "x86"
.LP
-\fBExample 5 \fRTo Boot the Default Kernel In 64-bit Single-User Interactive
+\fBExample 4 \fRTo Boot the Default Kernel In 64-bit Single-User Interactive
Mode
.sp
.LP
-To boot the default kernel in single-user interactive mode, edit the GRUB
-kernel command line to read:
+To boot the default kernel in single-user interactive mode, press the ESC key
+to get the boot loader \fBok\fR prompt and enter:
.sp
.in +2
.nf
-kernel /platform/i86pc/kernel/amd64/unix -as
+boot -as
.fi
.in -2
-.sp
-
-.LP
-\fBExample 6 \fRSwitching Between 32-bit and 64-bit Kernels on 64-bit x86
-Platform
-.sp
-.LP
-To be able to boot both 32-bit and 64-bit kernels, add entries for both kernels
-to \fB/boot/grub/menu.lst\fR, and use the \fBset-menu\fR subcommand of
-\fBbootadm\fR(1M) to switch. See \fBbootadm\fR(1M) for an example of the
-\fBbootadm set-menu\fR.
.SH FILES
.ne 2
@@ -1519,11 +1379,11 @@ Directory containing boot-related files.
.sp
.ne 2
.na
-\fB\fB/rpool/boot/grub/menu.lst\fR\fR
+\fB\fB/rpool/boot/menu.lst\fR\fR
.ad
.sp .6
.RS 4n
-Menu of bootable operating systems displayed by GRUB.
+Menu index file of bootable operating systems displayed by the boot loader.
.sp
\fBNote:\fR this file is located on the root ZFS pool. While many installs
often name their root zpool 'rpool', this is not required and the
diff --git a/usr/src/man/man1m/bootadm.1m b/usr/src/man/man1m/bootadm.1m
index 07c8383efd..5276786d82 100644
--- a/usr/src/man/man1m/bootadm.1m
+++ b/usr/src/man/man1m/bootadm.1m
@@ -3,10 +3,10 @@
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.\" Copyright (c) 2015 Toomas Soome <tsoome@me.com>
-.TH BOOTADM 1M "Jul 26, 2015"
+.\" Copyright 2016 Toomas Soome <tsoome@me.com>
+.TH BOOTADM 1M "Aug 18, 2016"
.SH NAME
-bootadm \- manage bootability of GRUB-enabled operating system
+bootadm \- manage bootability of the operating system
.SH SYNOPSIS
.LP
.nf
@@ -35,17 +35,17 @@ bootadm \- manage bootability of GRUB-enabled operating system
.LP
.nf
-\fB/sbin/bootadm\fR list-menu [\fB-R\fR \fIaltroot\fR]
+\fB/sbin/bootadm\fR list-menu [\fB-R\fR \fIaltroot\fR] [\fB-o\fR \fIkey\fR=\fIvalue\fR\fR]
.fi
.SH DESCRIPTION
.LP
The \fBbootadm\fR command manages the boot archive and, with x86 boot
-environments, the GRUB (GRand Unified Bootloader) menu. The
+environments, the boot loader menu. The
\fBupdate-archive\fR option provides a way for user to update the boot archive
as a preventative measure or as part of a recovery procedure. The
\fBset-menu\fR subcommand allows you to switch the \fBauto-boot\fR timeout and
-default boot entry in the GRUB menu.
+default boot entry in the boot menu.
.sp
.LP
The \fBinstall-bootloader\fR subcommand installs the system boot loader on a
@@ -60,16 +60,17 @@ system have been replaced, one should run \fBbootadm install-bootloader\fR to
ensure that all disks in that pool have the system boot loader installed.
.sp
.LP
-The \fBlist-menu\fR subcommand displays the location of the GRUB menu and the
-current GRUB menu entries. While the typical location of the GRUB menu is
-\fB/boot/grub/menu.lst\fR, depending on the install method used the active GRUB
-menu might be located somewhere else. Use the \fBlist-menu\fR subcommand to
-locate the active GRUB menu. See the EXAMPLES section for typical output from
+The \fBlist-menu\fR subcommand displays the location of the boot menu and the
+current boot menu entries. The location of the boot menu list is
+\fB/<boot pool root dataset mountpoint>/boot/menu.lst\fR.
+Use the \fBlist-menu\fR subcommand to
+locate the boot menu. See the EXAMPLES section for typical output from
the \fBlist-menu\fR option.
.sp
.LP
-Note that OpenBoot PROM (OBP)-based machines, such as SPARC systems, do not use
-GRUB and have no boot menu manageable by \fBbootadm\fR.
+Note that OpenBoot PROM (OBP)-based machines, such as SPARC systems, use
+PROM variables to set boot behavior and are managed by the \fBeeprom\fR(1M)
+command.
.sp
.LP
The \fBbootadm\fR command determines dynamically the options supported by the
@@ -129,9 +130,9 @@ option is specified, the \fBMBR\fR of the disk will not updated, as the system
cannot guarantee that the \fBMBR\fR belongs to it. If, for example, the system
was being dual booted, a different initial boot loader may be installed there.
.sp
-When \fBGRUB\fR is being used as the system boot loader (currently on x86), to
-reinstall the boot loader on some or all of the disks, the \fB-f\fR option must
-be passed to the \fBinstall-bootloader\fR subcommand.
+To reinstall the boot loader on some or all of the disks, the \fB-f\fR option
+must be passed to the \fBinstall-bootloader\fR subcommand to override boot
+program version checks.
.RE
.sp
@@ -141,9 +142,10 @@ be passed to the \fBinstall-bootloader\fR subcommand.
.ad
.sp .6
.RS 4n
-Maintain the GRUB menu. The current GRUB menu is \fBboot/grub/menu.lst\fR,
-relative to root. Do not depend on this location, because it is subject to
-change. Applies to x86 platforms only.
+Maintain the menu configuration. The index of menu entries is listed in the
+\fBmenu.lst\fR file, and the actual configuration of the menu entry is located
+in the boot environment \fB/boot\fR directory.
+Applies to x86 platforms only.
.RE
.sp
@@ -153,8 +155,8 @@ change. Applies to x86 platforms only.
.ad
.sp .6
.RS 4n
-Lists the location of the active GRUB menu, as well as the current GRUB menu
-entries. This includes the autoboot-timeout, the default entry number, and the
+Lists the location of the \fBmenu.lst\fR, as well as the current menu
+entries. This listing includes the default entry, dataset name, and the
title of each entry. Applies to x86 platforms only.
.RE
@@ -168,7 +170,7 @@ The \fBbootadm\fR command has the following options:
.ad
.sp .6
.RS 4n
-In an \fBinstall-bootloader\fR operation, override boot loader versioning
+In an \fBinstall-bootloader\fR operation, override the boot loader versioning
constraints.
.RE
@@ -186,6 +188,18 @@ updated.
.sp
.ne 2
.na
+\fB\fB-o\fR\fR \fIkey\fR=\fIvalue\fR
+.ad
+.sp .6
+.RS 4n
+In a \fBlist-menu\fR operation, specify the menu entry for detailed inspection.
+Possible keys are \fBentry\fR and \fBtitle\fR, taking either entry number or
+title name as values.
+.RE
+
+.sp
+.ne 2
+.na
\fB\fB-p\fR \fIplatform\fR\fR
.ad
.sp .6
@@ -275,7 +289,7 @@ Possible values are:
.ad
.sp .6
.RS 4n
-The item number (for example, 0, 1, or 2) in the GRUB menu designating the
+The item number (for example, 0, 1, or 2) in the boot menu designating the
operating system to boot when the timer expires.
.RE
@@ -320,22 +334,21 @@ The following command updates the boot archive on an alternate root:
.in -2
.LP
-\fBExample 3 \fRListing Installed OS Instances
+\fBExample 3 \fRListing Boot Menu Entries and Location of Boot Menu
.sp
.LP
-The following command lists the installed operating system instances in a GRUB
-menu:
+The following command lists the boot environments and the location of the
+\fBmenu.lst\fR:
.sp
.in +2
.nf
# bootadm list-menu
-
-default=0
-timeout=10
-(0) Solaris10
-(1) Solaris10 Failsafe
-(2) Linux
+the location for the active menu is: /raid/boot/menu.lst
+Index Default Dataset Menu
+0 - raid/ROOT/test-182 test-182
+1 - raid/ROOT/test-183 test-183
+2 * raid/ROOT/test-184 test-184
.fi
.in -2
@@ -344,62 +357,55 @@ timeout=10
.sp
.LP
The following command refers to the menu displayed in the previous example. The
-user selects Linux (item 2).
+user selects test-183 (item 1).
.sp
.in +2
.nf
-# bootadm set-menu default=2
+# bootadm set-menu default=1
.fi
.in -2
.LP
-\fBExample 5 \fRListing GRUB Menu Entries and Location of GRUB Menu
+\fBExample 5 \fRDetailed information about menu entry.
.sp
.LP
-The following command lists the GRUB menu entries and the location of the GRUB
-menu:
+The following command lists more detailed information about a boot menu entry:
.sp
.in +2
.nf
-# bootadm list-menu
-The location for the active GRUB menu is: /stubboot/boot/grub/menu.lst
-default 0
-timeout 10
-0 Solaris10
-1 Solaris10 failsafe
-2 Linux
-.fi
-.in -2
-
-.LP
-\fBExample 6 \fRDisplaying Location of GRUB Menu
-.sp
-.LP
-The following command displays the location of the GRUB menu:
+# bootadm list-menu -o entry=2
+the location for the active menu is: /raid/boot/menu.lst
+
+Title: test-184
+Timeout: 10
+Console: text
+Bootfs: raid/ROOT/test-184
+Kernel: /platform/i86pc/kernel/amd64/unix
+Boot-args: "-v"
+
+Modules:
+Name: boot_archive
+Path: /platform/i86pc/${ISADIR}/boot_archive
+Type: rootfs
+Status: Load
+
+Name: boot_archive.hash
+Path: /platform/i86pc/${ISADIR}/boot_archive.hash
+Type: hash
+Status: Load
+
+Name: system
+Path: /boot/modules/etc/system
+Type: file
+Hash: 4f4fe2d2dfae393a2a87ce29e3c71b803938c5fb
+Flags: name=etc/system
+Status: Load
-.sp
-.in +2
-.nf
-# bootadm list-menu
-The location for the active GRUB menu is: /dev/dsk/c0t1d0s0 (not mounted)
-The filesystem type of the menu device is <ufs>
-default 2
-timeout 10
-0 c0t1d0s3
-1 c0t1d0s3 failsafe
-2 Solaris10
-3 Solaris10 failsafe
.fi
.in -2
-.sp
-.LP
-In this example, the active GRUB menu is located on a device which is \fBnot\fR
-mounted. To access the GRUB menu, mount the device and access the GRUB menu at
-\fB\fI<mountpoint>\fR/boot/grub/menu.lst\fR.
-
.SH EXIT STATUS
.LP
The following exit values are returned:
@@ -440,15 +446,4 @@ Interface Stability Committed
.SH SEE ALSO
.LP
-\fBboot\fR(1M), \fBbeadm\fR(1M), \fBinstallgrub\fR(1M), \fBinstallboot\fR(1M),
-\fBattributes\fR(5)
-.sp
-.LP
-Consult the GRUB home page, under:
-.sp
-.in +2
-.nf
-http://www.gnu.org/
-.fi
-.in -2
-
+\fBboot\fR(1M), \fBbeadm\fR(1M), \fBinstallboot\fR(1M), \fBattributes\fR(5)
diff --git a/usr/src/man/man1m/eeprom.1m b/usr/src/man/man1m/eeprom.1m
index a4d0213654..b24478363c 100644
--- a/usr/src/man/man1m/eeprom.1m
+++ b/usr/src/man/man1m/eeprom.1m
@@ -3,7 +3,7 @@
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH EEPROM 1M "Mar 28, 2007"
+.TH EEPROM 1M "Feb 21, 2016"
.SH NAME
eeprom \- EEPROM display and load utility
.SH SYNOPSIS
@@ -13,7 +13,6 @@ eeprom \- EEPROM display and load utility
.fi
.SH DESCRIPTION
-.sp
.LP
\fBeeprom\fR displays or changes the values of parameters in the \fBEEPROM.\fR
It processes parameters in the order given. When processing a \fIparameter\fR
@@ -35,13 +34,11 @@ incorrect.
\fIplatform-name\fR is the name of the platform implementation and can be found
using the \fB-i\fR option of \fBuname\fR(1).
.SS "SPARC"
-.sp
.LP
\fBSPARC\fR based systems implement firmware password protection with
\fBeeprom\fR, using the \fBsecurity-mode\fR, \fBsecurity-password\fR and
\fBsecurity-#badlogins\fR properties.
.SS "x86"
-.sp
.LP
\fBEEPROM\fR storage is simulated using a file residing in the
platform-specific boot area. The \fB/boot/solaris/bootenv.rc\fR file simulates
@@ -55,7 +52,6 @@ program. While it is possible to set the \fBsecurity-mode\fR,
systems, these properties have no special meaning or behavior on x86 based
systems.
.SH OPTIONS
-.sp
.ne 2
.na
\fB\fB-f\fR \fIdevice\fR\fR
@@ -67,7 +63,6 @@ Use \fIdevice\fR as the \fBEEPROM\fR device.
.SH OPERANDS
.SS "x86 Only"
-.sp
.ne 2
.na
\fB\fIacpi-user-options\fR\fR
@@ -107,15 +102,26 @@ and then, if you do not obtain satisfactory results, \fB0x02\fR.
Specifies the console device.
Possible values are \fBttya\fR, \fBttyb\fR, \fBttyc\fR, \fBttyd\fR, and
\fBtext\fR. In \fBtext\fR mode, console output goes to the frame buffer and
-input comes from the keyboard. When this property is not present, the console
-device falls back to the device specified by \fBinput-device\fR and
+input comes from the keyboard. For SPARC, when this property is not present,
+the console device falls back to the device specified by \fBinput-device\fR and
\fBoutput-device\fR. When neither the console property or the
\fBinput-device\fR and \fBoutput-device\fR property pair are present, the
console defaults to the frame buffer and keyboard.
.RE
+.SS "x86 Only"
+.ne 2
+.na
+\fB\fIos_console\fR\fR
+.ad
+.sp .6
+.RS 4n
+While \fBconsole\fR controls both boot loader and kernel console, setting
+\fBos_console\fR allows setting console device only for kernel. Values
+are the same as for \fBconsole\fR.
+.RE
+
.SH NVRAM CONFIGURATION PARAMETERS
-.sp
.LP
Not all OpenBoot systems support all parameters. Defaults vary depending on the
system and the \fBPROM\fR revision. See the output in the "Default Value"
@@ -129,8 +135,7 @@ prompt, to determine the default for your system.
.sp .6
.RS 4n
If \fBtrue\fR, boots automatically after power-on or reset. Defaults to
-\fBtrue\fR. On x86, this parameter is controlled by the grub menu file. See
-\fBinstallgrub\fR(1M).
+\fBtrue\fR.
.RE
.sp
@@ -1270,7 +1275,6 @@ you might use a device other than device \fBa\fR, as shown above. For example,
you could set console to \fBttyb\fR if the second serial port is present.
.SH FILES
-.sp
.ne 2
.na
\fB\fB/boot/solaris/bootenv.rc\fR\fR
@@ -1302,7 +1306,6 @@ Platform-specific version of \fBeeprom\fR. Use \fBuname\fR \fB-i\fR to obtain
.RE
.SH SEE ALSO
-.sp
.LP
\fBpasswd\fR(1), \fBsh\fR(1), \fBsvcs\fR(1), \fBtip\fR(1), \fBuname\fR(1),
\fBboot\fR(1M), \fBkadb\fR(1M), \fBkernel\fR(1M), \fBinit\fR(1M),
diff --git a/usr/src/man/man1m/installboot.1m b/usr/src/man/man1m/installboot.1m
new file mode 100644
index 0000000000..92ff24a277
--- /dev/null
+++ b/usr/src/man/man1m/installboot.1m
@@ -0,0 +1,209 @@
+.\"
+.\" This file and its contents are supplied under the terms of the
+.\" Common Development and Distribution License ("CDDL"), version 1.0.
+.\" You may only use this file in accordance with the terms of version
+.\" 1.0 of the CDDL.
+.\"
+.\" A full copy of the text of the CDDL should have accompanied this
+.\" source. A copy of the CDDL is also available via the Internet at
+.\" http://www.illumos.org/license/CDDL.
+.\"
+.\"
+.\" Copyright 2016 Toomas Soome <tsoome@me.com>
+.\"
+.Dd February 10, 2016
+.Dt INSTALLBOOT 1M
+.Os
+.Sh NAME
+.Nm installboot
+.Nd install bootloader in a disk partition
+.Sh SYNOPSIS
+.Ss SPARC
+.Nm
+.Op Fl fn
+.Op Fl F Sy zfs Ns | Ns Sy ufs Ns | Ns Sy hsfs
+.Op Fl u Ar verstr
+.Ar bootblk raw-device
+.Nm
+.Op Fl enV
+.Fl F Sy zfs
+.Fl i
+.Ar raw-device
+.Nm
+.Op Fl n
+.Fl F Sy zfs
+.Fl M
+.Ar raw-device attach-raw-device
+.Ss x86
+.Nm
+.Op Fl fFmn
+.Op Fl u Ar verstr
+.Ar stage1 stage2 raw-device
+.Nm
+.Op Fl enV
+.Fl i
+.Ar raw-device
+.Nm
+.Op Fl n
+.Fl M
+.Ar raw-device attach-raw-device
+.Sh DESCRIPTION
+The
+.Xr boot 1M
+boot program is loaded from disk and is responsible of loading kernel and its
+support files from specific file system.
+.Pp
+The SPARC systems have one boot loader program file to be installed on the boot
+area of a disk slice. As the SPARC zfs boot loader is too large to fit into
+boot area at the start of the disk slice,
+.Nm
+command will split the zfs boot loader between disk slice boot area, and zfs
+pool boot area.
+.Pp
+The x86 systems have boot loader implemented as three stages:
+.Bl -tag -width Ds
+.It Sy stage1
+.Pa /boot/pmbr
+is used as master boot record
+.Pq MBR
+and partition boot program.
+.It Sy stage2
+.Pa /boot/gptzfsboot
+is responsible for loading files from file system. The
+.Sy stage2
+on x86 systems is always installed to zfs pool boot area, and therefore only zfs
+boot is supported.
+.Nm
+command will record the location of
+.Sy stage2
+to
+.Sy stage1 ,
+which is always installed at least on partition
+.Pq MBR or GPT
+boot area, making it possible to boot via chainload from other boot loaders.
+.Pp
+When
+.Nm
+command is used with the
+.Fl m
+option,
+.Nm
+installs the stage1 file on the master boot sector of the disk as well.
+.It Sy stage3
+.Pa /boot/zfsloader
+is read from file system and executed by
+.Sy stage2
+and will provide boot loader user environment and is responsible of loading
+and starting the operating system kernel.
+.Pp
+In case of GPT partitioning scheme, if the file system to boot from is either
+UFS or PCFS, there must be
+.Sy boot
+partition defined to store stage2 boot program. This is needed because UFS and
+PCFS do not have sufficient space reserved to store boot programs.
+.Pp
+The boot partition must use following GPT UUID:
+.Bd -literal -offset indent
+6a82cb45-1dd2-11b2-99a6-080020736631
+.Ed
+.Pp
+which is provided by
+.Qq boot
+tag in
+.Xr format 1M
+partition menu.
+.El
+.Ss Options
+The
+.Nm
+command accepts the following options:
+.Bl -tag -width Ds
+.It Fl h
+Prints short usage message.
+.It Fl m
+Installs
+.Sy stage1
+on the master boot sector interactively. You must use this option if OS is
+installed on an extended FDISK or an EFI/GPT partition.
+.It Fl f
+Suppresses interaction when overwriting the master boot sector on x86.
+Force update on SPARC.
+.It Fl n
+Dry run session. Will not write to disk.
+.It Fl F
+On SPARC, specify file system type. On x86, inhibit version check and enforce
+boot loader update.
+.It Fl u Ar verstr
+Specify custom version string. Can be used to add version on non-versioned
+boot loader or change built in version string.
+.It Fl i
+Print version string from installed boot loader.
+.It Fl e
+Print version string from installed boot loader without description.
+.It Fl V
+Print version string from installed boot loader with full description.
+.It Fl M
+Mirror boot loader from installed disk partition.
+.El
+.Ss Operands
+The
+.Nm
+command accepts the following operands:
+.Bl -tag -width Ds
+.It Ar bootblk
+The name of the SPARC boot loader code.
+.It Ar stage1
+The name of the loader stage 1 file.
+.It Ar stage2
+The name of the loader stage 2 file.
+.It Ar raw-device
+The name of the device onto which bootloader code is to be installed. It must be
+a character device that is readable and writable and part of boot pool.
+.El
+.Sh FILES
+.Bl -tag -width Ds
+.It Pa /boot
+Directory where x86 loader files reside.
+.It Pa /usr/platform/platform name/lib/fs
+Directory where SPARC boot loader files reside.
+.El
+.Sh EXAMPLES
+.Bl -tag -width Ds
+.It Sy Example 1 No Installing zfs boot loader on SPARC disk slice
+The following command installs zfs boot loader on SPARC system:
+.Bd -literal
+# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk \e
+ /dev/rdsk/c0t0d0s0
+.Ed
+.It Sy Example 2 No Installing boot loader on x86 system
+The following command installs loader stage files and master boot record:
+.Bd -literal
+# installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/c0t0d0s0
+.Ed
+.El
+.Sh INTERFACE STABILITY
+.Sy Uncommitted
+.Sh SEE ALSO
+.Xr boot 1M ,
+.Xr bootadm 1M ,
+.Xr fdisk 1M ,
+.Xr fmthard 1M ,
+.Xr format 1M ,
+.Xr kernel 1M ,
+.Xr attributes 5
+.Sh WARNINGS
+Installing
+.Sy stage1
+on the master boot sector
+.Po
+.Fl m
+option
+.Pc
+overrides any boot loader currently installed on the machine. The system will
+always boot the current OS partition regardless of which fdisk partition is
+active.
+.Pp
+If version string indicates the source boot loader might be more recent,
+.Nm
+will also verify md5 checksums to determine if update is really necessary. If
+checksums match, the install will not be performed.
diff --git a/usr/src/man/man1m/reboot.1m b/usr/src/man/man1m/reboot.1m
index 8eadedf18d..a4bdebd496 100644
--- a/usr/src/man/man1m/reboot.1m
+++ b/usr/src/man/man1m/reboot.1m
@@ -4,7 +4,7 @@
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with
.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH REBOOT 1M "Aug 24, 2009"
+.TH REBOOT 1M "Feb 21, 2016"
.SH NAME
reboot \- restart the operating system
.SH SYNOPSIS
@@ -19,7 +19,6 @@ reboot \- restart the operating system
.fi
.SH DESCRIPTION
-.sp
.LP
The \fBreboot\fR utility restarts the kernel. The kernel is loaded into memory
by the PROM monitor, which transfers control to the loaded kernel.
@@ -49,7 +48,6 @@ options are present.
.LP
Normally, the system reboots itself at power-up or after crashes.
.SH OPTIONS
-.sp
.LP
The following options are supported:
.sp
@@ -148,7 +146,6 @@ Quick. Reboot quickly without halting running zones first.
.RE
.SH OPERANDS
-.sp
.LP
The following operands are supported:
.sp
@@ -211,8 +208,8 @@ be omitted.
.sp
.LP
-The following command reboots to the default entry in the GRUB (see
-\fBgrub\fR(5)) menu file \fBmenu.lst\fR.
+The following command reboots to the default entry in the boot
+menu file \fBmenu.lst\fR.
.sp
.in +2
@@ -326,30 +323,26 @@ example# \fBsvcadm refresh svc:/system/boot-config:default\fR
.sp
.LP
-\fBExample 4 \fRRebooting to a Particular GRUB Menu
+\fBExample 4 \fRRebooting to a Particular Boot Menu Entry
.sp
.LP
-The following commands will reboot to entry \fB2\fR in the GRUB menu.
+The following commands will reboot to entry \fB2\fR in the boot menu.
.sp
.in +2
.nf
example# \fBbootadm list-menu\fR
- the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
- default 0
- timeout 10
- 0 zfsbe1
- 1 zfsbe1 failsafe
- 2 zfsbe2
- 3 zfsbe2 Solaris xVM
- 4 zfsbe2 failsafe
+the location for the active menu is: /rpool/boot/menu.lst
+Index Default Dataset Menu
+0 - rpool/ROOT/test-182 test-182
+1 * rpool/ROOT/test-183 test-183
+2 - rpool/ROOT/test-183 test-183
example# \fBreboot 2\fR
.fi
.in -2
.sp
.SH FILES
-.sp
.ne 2
.na
\fB\fB/var/adm/wtmpx\fR\fR
@@ -360,15 +353,12 @@ login accounting file
.RE
.SH SEE ALSO
-.sp
.LP
\fBmdb\fR(1), \fBboot\fR(1M), \fBdumpadm\fR(1M), \fBfsck\fR(1M),
\fBhalt\fR(1M), \fBinit\fR(1M), \fBkernel\fR(1M), \fBshutdown\fR(1M),
\fBsvcadm\fR(1M), \fBsvccfg\fR(1M), \fBsync\fR(1M), \fBsyslogd\fR(1M),
-\fBsync\fR(2), \fBuadmin\fR(2), \fBreboot\fR(3C), \fBattributes\fR(5),
-\fBgrub\fR(5)
+\fBsync\fR(2), \fBuadmin\fR(2), \fBreboot\fR(3C), \fBattributes\fR(5)
.SH NOTES
-.sp
.LP
The \fBreboot\fR utility does not execute the scripts in
\fB/etc/rc\fInum\fR.d\fR or execute shutdown actions in \fBinittab\fR(4). To