The Solaris Operating System (Solaris OS) is designed to run continuously so that electronic mail and network resources are available to users. This chapter provides guidelines for shutting down and booting a system.This is a list of the information in this chapter:What's New in Shutting Down and Booting a System Where to Find Shut Down and Boot Tasks Shut Down and Boot Terminology Guidelines for Shutting Down a System Guidelines for Booting a System When to Shut Down a System When to Boot a System For an overview of all of the boot features and methods that are available in the Solaris release, see Chapter 9, Shutting Down and Booting a System (Overview)For instructions on booting a Solaris system, see Chapter 12, Booting a Solaris System (Tasks). This section describes new boot features in the Solaris release.iSCSI booton the x86 platform x86 boot featuresiSCSI 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 . x86: fast reboot 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 Introducing Fast Reboot. Solaris Express Community Edition, builds 88 and 90: This release includes ZFS 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. 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_archiveFor more information, see Implementation of the findroot 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.The p option must be used with the R option. # bootadm -p platform -R [altroot]The specified platform must be one of the following:i86pc sun4u sun4v For more information, see the bootadm1M man page. 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 OpenBoot 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. 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 boot1M and bootadm1M man pages.For more information in this document, see Understanding the New Solaris SPARC Boot Architecture. 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_archiveThe 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 and System Administration Guide: Virtualization Using the Solaris Operating System extended GRUB support GRUB supportfor directly loading and booting the unix kernel directly loading and booting the unix kernelGRUB support 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. 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.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 Administering the GRUB Bootloader. 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.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 eeprom1M man page. Use these references to find step-by-step instructions for shutting down and booting a system.Shut Down and Boot Task For More Information Shut down a SPARC based system or an x86 based system Chapter 10, Shutting Down a System (Tasks) Modify boot behavior Chapter 11, Modifying Solaris Boot Behavior (Tasks) Boot a SPARC based system or an x86 based system Chapter 12, Booting a Solaris System (Tasks) Manage the Solaris boot archives Chapter 14, Managing the Solaris Boot Archives (Tasks) Troubleshoot boot behavior on a SPARC or an x86 based system Troubleshooting Booting on the SPARC Platform (Task Map) This section describes the terminology that is used in shutting down and booting a system.Run levels and init statesA run level is a letter or digit that represents a system state in which a particular set of system services are available. The system is always running in one of a set of well-defined run levels. Run levels are also referred to as init states because the init process maintains the run level. System administrators use the init command or the svcadm command to initiate a run-level transition. This book refers to init states as run levels. Boot optionsA boot option describes how a system is booted.Different boot options include the following:Interactive boot – You are prompted to provide information about how the system is booted, such as the kernel and device path name. Reconfiguration boot – The system is shutdown and rebooted to add new devices, if the devices are not hot-pluggable.The system is reconfigured to support newly added hardware or new pseudo devices. Recovery boot – The system is hung or an invalid entry is prohibiting the system from booting successfully or from allowing users to log in. For terminology that is specific to GRUB based booting, see GRUB Terminology. shutting downa system, guidelines Keep the following in mind when you shut down a system:Use the init and shutdown commands to shut down a system. Both commands perform a clean system shutdown, which means that all system processes and services are terminated normally.For x86 based systems that are running at least the Solaris 10 6/06 release, you can initiate a clean system shutdown by pressing and releasing the power button. Shutting down an x86 based system in this manner 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 a system shutdown. To use the power button, reconfigure the BIOS. shutdown commandshutting down a serverUse the shutdown command to shut down a server. Logged-in users and systems that mount resources from the server are notified before the server is shut down. Additional notification of system shutdowns by electronic mail is also recommended so that users can prepare for system downtime. You need superuser privileges to use the shutdown or init command to shut down a system. Both shutdown and init commands take a run level as an argument. The three most common run levels are as follows:Run level 3 – All system resources are available and users can log in. By default, booting a system brings it to run level 3, which is used for normal day-to-day operations. This run level is also known as multiuser level with NFS resources shared. Run level 6 – Stops the operating system and reboots to the state that is defined by the initdefault entry in the /etc/inittab file. Run level 0 – The operating system is shut down, and it is safe to turn off power. You need to bring a system to run level 0 whenever you move a system, or add or remove hardware. Run levels are fully described in Chapter 16, Managing Services (Overview). bootinga system, guidelines Keep the following in mind when you boot a system:After a SPARC based system is shut down, it is booted by using the boot command at the PROM level. After an x86 based system is shut down, it is booted by selecting an OS instance in the GRUB menu. In the Solaris 9 release and some Solaris 10 releases, after an x86 based system is shut down, it is booted by using the boot command at the Primary Boot Subsystem menu. A system can be rebooted by turning the power off and then back on.This method is not considered a clean shutdown, unless you have an x86 based system that is running a Solaris release that supports this shutdown method. See Support for Using Power Button to Initiate System Shutdown. Use this shutdown method only as an alternative in emergency situations. Because system services and processes are terminated abruptly, file system damage is likely to occur. The work required to repair this type of damage could be substantial and might require the restoration of various user and system files from backup copies. SPARC and x86 based systems use different hardware components for booting. These differences are described in Chapter 15, GRUB Based Booting (Reference). The following table lists system administration tasks and the type of shutdown that is needed to initiate the task.Reason for System Shutdown Appropriate Run Level For More Information To turn off system power due to anticipated power outage Run level 0, where it is safe to turn off power Chapter 10, Shutting Down a System (Tasks) To change kernel parameters in the /etc/system file Run level 6 (reboot the system) Chapter 10, Shutting Down a System (Tasks) To perform file system maintenance, such as backing up or restoring system data Run level S (single-user level) Chapter 10, Shutting Down a System (Tasks) To repair a system configuration file such as /etc/system See When to Boot a System N/A To add or remove hardware from the system Reconfiguration boot (also to turn off power when adding or removing hardware)Reconfiguration boot (shut down and turn off power when adding or removing devices, if the devices are not hot-pluggable) Adding a Peripheral Device to a System in System Administration Guide: Devices and File Systems To repair an important system file that is causing system boot failure See When to Boot a System N/A To boot the kernel debugger (kmdb) to track down a system problem Run level 0, if possible Chapter 10, Shutting Down a System (Tasks) To recover from a hung system and force a crash dump See When to Boot a System N/A Reboot the system by using the kernel debugger (kmdb), if the debugger can't be loaded at runtime. Run level 6 (reboot the system) For SPARC based systems:How to Boot the System With the Kernel Debugger (kmdb)For x86 based systems:,How to Boot a System With the Kernel Debugger in the GRUB Boot Environment (kmdb) For examples of shutting down a server or a stand-alone system, see Chapter 10, Shutting Down a System (Tasks). The following table lists system administration tasks and the corresponding boot option that is used to complete the task.Reason for System Reboot Appropriate Boot Option Information for SPARC Based Systems Information for x86 Based Systems Turn off system power due to anticipated power outage. Turn system power back on Chapter 10, Shutting Down a System (Tasks) Chapter 10, Shutting Down a System (Tasks) Change kernel parameters in the /etc/system file. Reboot the system to run level 3 (multiuser level with NFS resources shared) How to Boot a System to Run Level 3 (Multiuser Level) How to Boot a System to Run Level 3 (Multiuser) Perform file system maintenance, such as backing up or restoring system data. Press Control-D from run level S to bring the system back to run level 3 How to Boot a System to Run Level S (Single-User Level) How to Boot a System to Run Level S (Single-User Level) Repair a system configuration file such as /etc/system. Interactive boot How to Boot a System Interactively How to Boot a System Interactively Add or remove hardware from the system. Reconfiguration boot (turn on system power after adding or removing devices, if devices are not hot-pluggable) Reconfiguration boot (also to turn on system power after adding or removing hardware) Adding a System Disk or a Secondary Disk (Task Map) in System Administration Guide: Devices and File Systems Adding a System Disk or a Secondary Disk (Task Map) in System Administration Guide: Devices and File Systems Boot the system by using the kernel debugger (kmdb) to track down a system problem. Booting kmdb How to Boot the System With the Kernel Debugger (kmdb) How to Boot a System With the Kernel Debugger in the GRUB Boot Environment (kmdb) Boot the system in failsafe mode to repair an important system file that is causing system boot failure. Booting the failsafe archive How to Boot the Failsafe Archive on a SPARC Based System How to Boot the Failsafe Archive on an x86 Based System by Using GRUB To recover from a hung system and force a crash dump. Recovery boot How to Force a Crash Dump and Reboot of the System How to Force a Crash Dump and Reboot of the System