System Administration Guide: Basic Administration

Chapter 8 Introduction to Shutting Down and Booting a System

Oracle Solaris 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.

The following is a list of the information that in this chapter:

For an overview of all of the boot features and methods that are available in the Oracle Solaris release, see Chapter 9, Shutting Down and Booting a System (Overview).

For instructions on booting a system, see Chapter 12, Booting an Oracle Solaris System (Tasks).

What's New in Shutting Down and Booting a System

This section describes new boot features in the Oracle Solaris release. For a complete listing of new features and a description of Oracle Solaris releases, see Oracle Solaris 10 9/10 What’s New.

Oracle Solaris Auto Registration Introduced

Oracle Solaris 10 9/10: Oracle Solaris Auto Registration feature is a mechanism whereby newly installed software products are automatically registered with My Oracle Support during the first system reboot after an installation or upgrade, and on subsequent system reboots, if any system configuration changes have occurred. Auto Registration leverages the existing service tag technology that enables products to be discovered on a network and then registered in a local registry.

The Auto Registration feature is managed by an SMF service. This service, which is enabled by default, runs once at boot time to check for newly installed products. If any new products are discovered, service tag information about these products is automatically transmitted to the Oracle Product Registration System by using an Hypertext Transfer Protocol Secure (HTTPS) connection.

The feature has a command-line interface (CLI), usr/sbin/regadm, that can be used by a privileged system administrator to manage the Auto Registration SMF service and to administer product registration, independent of the installation or upgrade process.

For more information, see Chapter 17, Working With the Oracle Solaris Auto Registration regadm Command (Tasks).

Automatic Boot Archive Recovery

Oracle Solaris 10 9/10: Starting with this release, boot archive recovery on the SPARC platform is automatic.

To support auto-recovery of the boot archives on the x86 platform, a new auto-reboot-safe property has been added to the boot configuration service, svc:/system/boot-config:default. By default, the property's value is set to false to ensure that the system does not automatically reboot to an unknown boot device. If the system is configured to automatically point to the BIOS boot device and GRUB menu entry that Oracle Solaris 10 is installed on, you can set the property's value to true. Setting the value to true enables an automatic reboot of the system for the purpose of recovering an out-of-date boot archive.

To set or change this property's value, use the svccfg and svcadm commands. See the svccfg(1M) and svcadm(1M) man pages.

For general information about this enhancement, see the boot(1M) man page.

For step-by-step instructions, see x86: How to Clear Automatic Boot Archive Update Failures by Using the auto-reboot-safe Property.

SPARC Support for Install-Time Updates

Oracle Solaris 10 9/10: Starting with this release, the itu utility has been modified to support booting a SPARC based system with Install-Time Updates (ITUs). Third-party vendors can now deliver driver updates on floppy disk, CD or DVD, and USB storage. In addition, new tools that enable you to modify the Oracle Solaris installation media with new packages and patches have been introduced. These tools can be used to deliver software updates for hardware platforms and to produce customized installation media. For task-related information, see SPARC: How to Boot a System With a Newly Created ITU.

See also the following man pages:

Two-Terabyte Disk Support for Installing and Booting Oracle Solaris 10

Solaris 10 10/09: In previous releases, you could not install and boot the Solaris OS from a disk that was greater than 1 Tbyte in size. Starting with this release, you can install and boot the Oracle Solaris OS from a disk that is up to 2 Tbytes in size. In previous releases, you also had to use an EFI label for a disk that was larger than 1 Tbyte. In this release, you can use the VTOC label on any size disk. However, the addressable space by the VTOC label is limited to 2 Tbytes.

For more information, see What’s New in Disk Management? in System Administration Guide: Devices and File Systems.

Oracle Solaris ZFS Boot Support

Solaris 10 10/08: This release includes Oracle Solaris ZFS installation, as well as ZFS boot support. You can now install and boot from a ZFS root file system. This enhancement applies to both the SPARC and x86 based platforms. Booting, system operations, and installation procedures have been modified to support this change.

For more information, see Booting From an Oracle Solaris ZFS Root File System.

x86: findroot Command

All Oracle 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 Oracle Solaris 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 as follows:


findroot (rootfs0,0,a)
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive

In some Oracle Solaris 10 releases, the entry is as follows:


findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS
module /platform/i86pc/boot_archive

For more information, see x86: Implementation of the findroot Command.

Support for Specifying Platform by Using bootadm Command

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.

Redesign of SPARC Bootstrap Process

The Oracle Solaris SPARC bootstrap process has been redesigned to increase commonality with the x86 boot architecture.

Other enhancements include an improved boot architecture that supports booting a system from additional file system types, for example an Oracle Solaris 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 boot archives and the bootadm command, previously only available on the x86 based platform, are now an integral part of the 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.


Note –

Although the SPARC boot process has changed, no administrative procedures for booting a SPARC based system have been impacted. Boot tasks 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 SPARC Boot Architecture.

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 release, pressing the power button immediately turns off system power without safely shutting it down. This same behavior occurs when you press the power button on systems 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.


Where to Find Shut Down and Boot Tasks

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 or an x86 based system 

Chapter 10, Shutting Down a System (Tasks)

Modify boot behavior 

Chapter 11, Modifying Oracle Solaris Boot Behavior (Tasks)

Boot a SPARC based system or an x86 based system 

Chapter 12, Booting an Oracle Solaris System (Tasks)

Manage the Solaris boot archives 

Chapter 13, Managing the Oracle Solaris Boot Archives (Tasks)

Troubleshoot boot behavior on a SPARC or an x86 based system 

Troubleshooting Booting on the SPARC Platform (Task Map)

Shut Down and Boot Terminology

The following terminology is used when shutting down and booting a system:

Run levels and init states

A 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 options

A 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 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 x86: GRUB Terminology.

Guidelines for Shutting Down a System

Keep the following in mind when you shut down a system:

Guidelines for Booting a System

Keep the following in mind when you boot a system:

When to Shut Down a System

The following table lists system administration tasks and the type of shutdown method that is required to initiate the task.

Table 8–1 Shutting Down a System

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) 

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) 

SPARC: How to Boot the System With the Kernel Debugger (kmdb)

,x86: 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).

When to Boot a System

The following table lists system administration tasks and the corresponding boot option that is used to complete the task.

Table 8–2 Booting a System

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). 

SPARC: How to Boot a System to Run Level 3 (Multiuser Level)

x86: 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. 

SPARC: How to Boot a System to Run Level S (Single-User Level)

x86: How to Boot a System to Run Level S (Single-User Level)

Repair a system configuration file such as /etc/system.

Interactive boot. 

SPARC: How to Boot a System Interactively

x86: How to Boot a System Interactively

Add or remove hardware from the system. 

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 with the kmdb option.

SPARC: How to Boot the System With the Kernel Debugger (kmdb)

x86: 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 a SPARC Based System in Failsafe Mode

How to Boot an x86 Based System in Failsafe Mode

To recover from a hung system and force a crash dump. 

Performing a recovery boot 

SPARC: How to Force a Crash Dump and Reboot of the System

x86: How to Force a Crash Dump and Reboot of the System