What's New in Shutting Down and Booting a System
This section describes new boot features in the Solaris release.
x86: iSCSI Boot
Solaris Express Community Edition, build 104: The iSCSI Boot feature enables you to initialize an operating system over
the network from a remote location, such as a storage disk array. This
version of iSCSI Boot supports booting from x86 based systems. iSCSI Boot is
typically loaded onto an initiator or a diskless client, while the hard disk
resides on a SCSI target that is attached to the network. Because the
feature uses a standard Ethernet-based infrastructure, data, storage, and networking traffic can be consolidated
on a standard network. More information about iSCSI Boot can be found
at https://wikis.sun.com/display/OpenSolarisInfo/iSCSI+Boot.
Fast Reboot on the x86 Platform
Solaris Express Community Edition, build 100, and the OpenSolaris 2008.11 release: The Fast Reboot feature enables you to reboot an x86 based system,
bypassing the firmware and boot loader processes. Fast Reboot implements an in-kernel
boot loader that loads the kernel into memory and then switches to that
kernel, so that the reboot process occurs within seconds. This feature is implemented
on both 32-bit and 64-bit kernels.
For more information about this feature, see x86: Introducing Fast Reboot.
ZFS Boot Support
Solaris Express Community Edition, builds 88 and 90: This release includes ZFS TM installation and boot support. Systems can now
be installed and booted from a ZFS root file system. This implementation applies
to both SPARC and x86 based systems. Booting, system operations, and installation procedures
have been modified to support this change.
For more information, see Booting From a ZFS Root File System.
x86: New findroot Command
Solaris Express Community Edition, build 88: All Solaris installation methods, including Solaris Live Upgrade, now use the findroot
command for specifying which disk slice on an x86 based system to boot.
This implementation supports booting systems with ZFS roots, as well as UFS roots.
Previously, the root command, root (hd0.0.a), was used to explicitly specify which disk
slice to boot. This information is located in the menu.lst file that is
used by GRUB.
The most common form of the GRUB menu.lst entry is now:
findroot (rootfs0,0,a)
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive
For more information, see x86: Implementation of the findroot Command.
Support for Specifying Platform by Using bootadm Command
Solaris Express Community Edition, build 87: A new -p option has been added to the bootadm command.
This option enables you to specify the platform or machine hardware class of
a client system in situations where the client platform differs from the server
platform, for example when administering diskless clients.
Note - The -p option must be used with the -R option.
# bootadm -p platform -R [altroot]
The specified platform must be one of the following:
For more information, see the bootadm(1M) man page.
Solaris SPARC Bootstrap Process Redesigned
Solaris Express Community Edition, build 80: The Solaris SPARC bootstrap process has been redesigned to increase commonality with
the Solaris x86 boot architecture.
Other enhancements include an improved boot architecture that supports booting a system from
additional file system types, for example a ZFS file system or a single
miniroot for installation, as well as booting from DVD, NFS, or HTTP. These
enhancements increase flexibility and reduce maintenance requirements on SPARC based systems.
As part of this redesign, the Solaris boot archives and the bootadm
command, previously only available on the Solaris x86 based platform, are now an
integral part of the Solaris SPARC boot architecture.
The primary difference between the SPARC and x86 boot architectures is how the
boot device and file are selected at boot time. The SPARC based platform
continues to use the OpenBootTM PROM (OBP) as the primary administrative interface, with
boot options selected by using OBP commands. On x86 based systems, these options
are selected through the BIOS and the GRand Unified Bootloader (GRUB) menu.
Note - Although the implementation of the Solaris SPARC boot has changed, no
administrative procedures for booting a SPARC based system have been impacted. Boot tasks
that are performed by the system administrator remain the same as they were
prior to the boot architecture redesign.
For more information, see the boot(1M) and bootadm(1M) man pages.
For more information in this document, see Understanding the New Solaris SPARC Boot Architecture.
x86: Support for Booting the Solaris OS as a Virtualized Control Domain
Solaris Express Community Edition, build 75: In this release, the GRUB boot loader is capable of booting a
Solaris release that runs with hypervisor technology. The hypervisor can securely execute multiple
virtual machines simultaneously, each running its own operating system, on a single physical
system. You can decide at boot time whether to run the Solaris OS
as a virtualized domain0, also called a dom0, or as a stand-alone operating
system.
You can run the Solaris OS as a virtualized dom0. Whether to
run the Solaris OS as a virtualized dom0 or as a stand-alone operating
system is a decision you can make at boot time. To run the
Solaris OS as a virtualized dom0, there must first be an entry in
the menu.lst file that specifies the hypervisor. The entry can be the default
boot entry, or it can be an option that you select manually at
boot time. Note that when you upgrade your system to a Solaris release
that includes this capability, the bootadm command automatically adds a menu entry for the
hypervisor to the menu.lst file.
The bootadm command installs a default boot entry in the menu.lst file that
is similar to the following:
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive
Note - The format for entries that are used in the menu.lst file for booting
the Solaris OS as a control domain differs slightly from the format that
is used for other menu.lst entries. The kernel$ line must identify the
hypervisor binary to use and includes any options that are accepted by the
hypervisor. The first module$ line in the file identifies the Solaris kernel to
use, for example unix, and include any options the unix kernel accepts. Due
to an implementation detail that exists in this version of GRUB, the specified
unix kernel must be named twice on the first module$ line. The second
module$ line identifies the boot archive to use.
For more information, see Description of a menu.lst File That Supports Hypervisor Technology.
For more information about administering Solaris systems that support the hypervisor, see https://www.opensolaris.org/os/community/xen/docs/
and System Administration Guide: Virtualization Using the Solaris Operating System
x86: GRUB Support for Directly Loading and Booting the unix Kernel
Solaris Express Community Edition, build 57: This release includes changes to the GRUB based boot environment to enable
the boot loader to directly load and boot the unix kernel.
Note - The GRUB multiboot module is no longer used.
This implementation integrates the previous multiboot functionality directly into the platform-specific unix kernel
module. These changes reduce the time, as well as memory requirements, that are
needed to boot the Solaris OS on x86 based systems.
Two new keywords, kernel$ and module$, have been added to GRUB to assist
in creating menu.lst entries that work with either 32-bit or 64-bit systems. In
addition, the bootadm command that manages the menu.lst file has been modified to
create file entries for the platform-specific unix module that is loaded by GRUB.
During an upgrade, the bootadm command converts any existing multiboot menu.lst entries to
unix entries.
The kernel$ and module$ keywords are identical to the kernel and module commands that
are used in the GRUB multiboot implementation, with the addition of the
$ISADIR keyword. This keyword provides the capability to expand to amd64 on 64-bit
capable hardware. If the x86 based system is not 64-bit capable, the $ISADIR
keyword is a null value (""). In this case, the system boots the
32-bit kernel.
Note - These changes do not prevent you from booting a newer Solaris kernel with
an older implementation of GRUB. Nor do the changes prevent you from booting
an older Solaris kernel with a newer implementation of GRUB.
For information about booting an x86 based system with GRUB, see x86: Administering the GRUB Bootloader.
x86: Support for Using Power Button to Initiate System Shutdown
Pressing and releasing the power button on x86 based systems initiates a clean
system shutdown and turns the system off. This functionality is equivalent to using
the init 5 command to shut down a system. On some x86 based
systems, the BIOS configuration might prevent the power button from initiating shutdown. To
enable use of the power button to perform a clean system shutdown, reconfigure
the BIOS.
Note - On certain x86 based systems that were manufactured before 1999 and are running
an older Solaris release, pressing the power button immediately turns off system power
without safely shutting down the system. This same behavior occurs when pressing the
power button on systems that are running with ACPI support that is disabled
through the use of acpi-user-options.
For more information about acpi-user-options, see the eeprom(1M) man page.
