System Administration Guide, Volume I

Part III Shutting Down and Booting a System

This part provides instructions for shutting down and booting systems running the Solaris release. This part contains these chapters.

Chapter 5, Shutting Down and Booting a System (Overview)

Provides an overview and guidelines for shutting down and booting a system.  

Chapter 6, Run Levels and Boot Files (Tasks)

Provides information about run levels and boot files.  

Chapter 7, Shutting Down a System (Tasks)

Provides step-by-step procedures for shutting down a system.  

Chapter 8, Booting a SPARC System (Tasks)

Provides step-by-step procedures for booting a SPARC system.  

Chapter 9, x86: Booting a System (Tasks)

Provides step-by-step procedures for booting an x86 system.  

Chapter 10, The Boot Process (Reference)

Provides a high-level overview of the boot process including a description of the platform-specific hardware used to boot SPARC and x86 systems.  

Chapter 5 Shutting Down and Booting a System (Overview)

This chapter provides guidelines for shutting down and booting a system. The Solaris software environment is designed to run continuously so that electronic mail and network resources are available to users. Occasionally, it is necessary to shut down or reboot a system because of a system configuration change, a scheduled maintenance event, or a power outage.

This is a list of overview information in this chapter.

What's New in Shutting Down and Booting a System?

This section describes new features related to shutting down and booting a system in the Solaris 7 release.

Bringing a System to Run Level S (Single-User Mode)

Bug ID 1154696 has been fixed in the Solaris 7 release. This means that you can cleanly bring your system down to run level S (or single-user mode) by using the shutdown -s or the init -s command. The inittab file and the rc scripts in the /etc/init.d directory and the /etc/rcn.d directories have been modified to ensure system run level transitions are made cleanly and efficiently.

Booting a System Running the 32-bit or 64-bit Solaris 7 Operating Environment

See "Troubleshooting 64-bit Solaris Boot Problems" for information on booting a system running the 32-bit or 64-bit Solaris 7 operating environment.

Where to Find Shutting Down and Booting Tasks

Use these references to find step-by-step instructions for shutting down and booting a system.

Terminology

This section describes the terminology used in shutting down and booting a system.

Guidelines for Shutting Down a System

Keep the following in mind when shutting down a system:

Guidelines for Booting a System

Keep the following in mind when booting a system:

Performing a Reconfiguration Boot

Perform a reconfiguration boot when adding new hardware to the system or configuring support for pseudo devices, such as increasing the number of pseudo devices (ptys). Table 5-1 to determine which reconfiguration procedure to use.

Table 5-1 Reconfiguration Procedures

If You Are Reconfiguring the System To ... 

See ... 

Add a secondary disk 

Chapter 23, SPARC: Adding a Disk (Tasks) or Chapter 24, x86: Adding a Disk (Tasks)

Add some other peripheral device 

"How to Add a Peripheral Device"

Change the number of pseudo devices 

"Examining and Changing System Information (Tasks)" in System Administration Guide, Volume II

When to Shut Down a System

Table 5-2 provides a list of system administration tasks and the type of shut down needed to initiate the task.

Table 5-2 Shutting Down a System

If You Are ...  

Change to This Run Level ... 

See ... 

Turning off system power due to anticipated power outage 

Run level 0, where it is safe to turn off power 

Chapter 7, Shutting Down a System (Tasks)

Changing kernel parameters in the /etc/system file

Run level 6 (reboot the system) 

Chapter 7, Shutting Down a System (Tasks)

Performing file system maintenance, such as backing up or restoring system data 

Run level S (single-user mode) 

Chapter 7, Shutting Down a System (Tasks)

Repairing a system configuration file such as /etc/system

See "When to Boot a System"

N/A 

Changing pseudo device parameters in the /etc/system file

Reconfiguration boot 

"Tuning Kernel Parameters (Tasks)" in System Administration Guide, Volume II

Adding or removing hardware from the system 

Reconfiguration boot (plus turning off power when adding or removing hardware) 

"SPARC: How to Connect a Secondary Disk and Boot"

Repairing an important system file which is causing system boot failure 

See "When to Boot a System"

N/A 

Booting the kernel debugger (kadb) to track down a system problem

Run level 0, if possible 

Chapter 7, Shutting Down a System (Tasks)

Recovering from a hung system and you want to force a crash dump 

See "When to Boot a System"

N/A 

See Chapter 7, Shutting Down a System (Tasks) for examples of shutting down a server or standalone system.

When to Boot a System

Table 5-3 provides a list of system administration tasks and the corresponding boot type used to complete the task.

Table 5-3 Booting a System

If You Are Rebooting the System After ...  

Use This Boot Type ... 

See SPARC Procedure ... 

See x86 Procedure ... 

Turning off system power due to anticipated power outage 

Turn system power back on 

Chapter 7, Shutting Down a System (Tasks)

Chapter 7, Shutting Down a System (Tasks)

Changing kernel parameters in the /etc/system file

Reboot the system to run level 3 (multiuser mode with NFS resources shared) 

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

"x86: How to Boot a System to Run Level 3 (Multiuser State)"

Performing file system maintenance, such as performing a backup or restoring system data 

Use 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 State)"

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

Repairing a system configuration file such as /etc/system

Interactive boot 

"SPARC: How to Boot a System Interactively"

"x86: How to Boot a System Interactively"

Changing pseudo device parameters in the /etc/system file

Reconfiguration boot 

"Tuning Kernel Parameters (Tasks)" in System Administration Guide, Volume II

"Tuning Kernel Parameters (Tasks)" in System Administration Guide, Volume II

Adding or removing hardware from the system 

Reconfiguration boot (plus turning on system power after adding or removing hardware) 

"SPARC: How to Connect a Secondary Disk and Boot"

Chapter 24, x86: Adding a Disk (Tasks)

Booting the kernel debugger (kadb) to track down a system problem

Booting kabd

"SPARC: How to Boot the System Using the Kernel Debugger (kadb)"

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

Repairing an important system file which is causing system boot failure 

Recovery boot 

"x86: How to Boot a System for Recovery Purposes"

"x86: How to Boot a System for Recovery Purposes"

Recovering from a hung system and you want to force a crash dump 

Recovery boot 

See example on "x86: How to Force a Crash Dump and Reboot the System"

See example on "x86: How to Force a Crash Dump and Reboot the System"

See Chapter 8, Booting a SPARC System (Tasks) or Chapter 9, x86: Booting a System (Tasks) for examples of booting a system.

Chapter 6 Run Levels and Boot Files (Tasks)

This chapter provides guidelines for shutting down and booting a system and information about run levels and boot files.

This is a list of the step-by-step instructions in this chapter.

This is a list of overview information in this chapter.

Run Levels

A system's run level (also known as an init state) defines what services and resources are available to users. A system can be in only one run level at a time.

The Solaris software environment has eight run levels, which are described in Table 6-1. The default run level is specified in the /etc/inittab file as run level 3.

Table 6-1 Solaris Run Levels

Run Level 

Init State 

Type 

Use This Level ... 

Power-down state 

Power-down 

 

To shut down the operating system so that it is safe to turn off power to the system.

s or S

Single-user state

Single-user 

To run as a single user with all file systems mounted and accessible.  

Administrative state 

Single-user 

To access all available file systems with user logins allowed.

Multiuser state 

Multiuser 

For normal operations. Multiple users can access the system and the entire file system. All daemons are running except for the NFS server daemons.

Multiuser with NFS resources shared

Multiuser 

For normal operations with NFS resource-sharing available.

Alternative multiuser state 

 

This level is currently unavailable. 

Power-down state 

Power-down 

To shut down the operating system so that it is safe to turn off power to the system. If possible, automatically turn off system power on systems that support this feature. 

Reboot state 

Reboot 

To shut down the system to run level 0, and then reboot to multiuser state (or whatever level is the default in the inittab file).

How to Determine a System's Run Level

Display run level information by using the who -r command to determine a system's run level.


$ who -r

Use the who -r command to determine a system's current run level for any level except run level 0.

Example--Determining a System's Run Level


$ who -r
 .       run-level 3  Jun 10 09:56     3      0  S
$

run level 3

Identifies the current run level. 

Jun 10 09:56

Identifies the date of last run level change. 

3

Is the current run level. 

0

Identifies the number of times at this run level since the last reboot. 

S

Identifies the previous run level. 

The /etc/inittab File

When you boot the system or change run levels with the init or shutdown command, the init daemon starts processes by reading information from the /etc/inittab file. This file defines three important items for the init process:

Each entry in the /etc/inittab file has the following fields:

id:rstate:action:process

Table 6-2 describes the fields in an inittab entry.

Table 6-2 Fields in the inittab File

Field 

Description 

id

A unique identifier for the entry. 

rstate

A list of run levels to which this entry applies. 

action

How the process specified in the process field is to be run. Possible values include: initdefault, sysinit, boot, bootwait, wait, and respawn.

process

The command to execute. 

Example--Default inittab File

The following example shows a default inittab file:


ap::sysinit:/sbin/autopush -f /etc/iu.ap
ap::sysinit:/sbin/soconfig -f /etc/sock2path
fs::sysinit:/sbin/rcS sysinit      >/dev/console 2<>/dev/console </dev/console
is:3:initdefault:
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/console 2<>/dev/console
sS:s:wait:/sbin/rcS                >/dev/console 2<>/dev/console </dev/console
s0:0:wait:/sbin/rc0                >/dev/console 2<>/dev/console </dev/console
s1:1:respawn:/sbin/rc1             >/dev/console 2<>/dev/console </dev/console
s2:23:wait:/sbin/rc2               >/dev/console 2<>/dev/console </dev/console
s3:3:wait:/sbin/rc3                >/dev/console 2<>/dev/console </dev/console
s5:5:wait:/sbin/rc5                >/dev/console 2<>/dev/console </dev/console
s6:6:wait:/sbin/rc6                >/dev/console 2<>/dev/console </dev/console
fw:0:wait:/sbin/uadmin 2 0         >/dev/console 2<>/dev/console </dev/console
of:5:wait:/sbin/uadmin 2 6         >/dev/console 2<>/dev/console </dev/console
rb:6:wait:/sbin/uadmin 2 1         >/dev/console 2<>/dev/console </dev/console
sc:234:respawn:/usr/lib/saf/sac -t 300
co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T sun 
-d /dev/console -l console -m ldterm,ttcompat  

What Happens When the System Is Brought to Run Level 3

  1. The init process is started and reads the /etc/default/init file to set any environment variables. By default, only the TIMEZONE variable is set.

  2. Then init reads the inittab file to do the following:

    1. Identify the initdefault entry, which defines the default run level (3).

    2. Execute any process entries that have sysinit in the action field so that any special initializations can take place before users login.

    3. Execute any process entries that have 3 in the rstate field, which matches the default run level, 3.

      See init(1M) for a detailed description of how the init process uses the inittab file.

      Table 6-3 describes the key words used for run level 3's action field.

      Table 6-3 Run Level 3 Action Key Word Descriptions

      Key Word 

      Starts the Specified Process ... 

      powerfail

      Only when the system receives a power fail signal. 

      wait

      And waits for its termination. 

      respawn

      If it does not exist. If the process already exists, continue scanning the inittab file.

Table 6-4 describes the processes (or commands) executed at run level 3.

Table 6-4 Run Level 3 Command Descriptions

Command or Script Name 

Description 

/usr/sbin/shutdown

Shuts down the system. The init process runs the shutdown command only if the system has received a powerfail signal.

/sbin/rcS

Mounts and checks root (/), /usr, /var, and /var/adm file systems.

/sbin/rc2

Starts the standard system processes, bringing the system up into run level 2 (multiuser mode). 

/sbin/rc3

Starts NFS resource sharing for run level 3. 

/usr/lib/saf/sac -t 30

Starts the port monitors and network access for UUCP. This process is restarted if it fails. 

/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T terminal_type -d /dev/console -l console

Starts the ttymon process that monitors the console for login requests. This process is restarted if it fails.

The terminal_type on a SPARC system is sun

The terminal_type on a x86 system is AT386

Run Control Scripts

The Solaris software environment provides a detailed series of run control (rc) scripts to control run level changes. Each run level has an associated rc script located in the /sbin directory:

For each rc script in the /sbin directory, there is a corresponding directory named /etc/rcn.d that contains scripts to perform various actions for that run level. For example, /etc/rc2.d contains files used to start and stop processes for run level 2.


# ls /etc/rc2.d
K20spc@             S70uucp*            S80lp*
K60nfs.server*      S71rpc*             S80spc@
K76snmpdx*          S71sysid.sys*       S85power*
K77dmi*             S72autoinstall*     S88sendmail*
README              S72inetsvc*         S88utmpd*
S01MOUNTFSYS*       S73nfs.client*      S89bdconfig@
S05RMTMPFILES*      S74autofs*          S91leoconfig*
S20sysetup*         S74syslog*          S92rtvc-config*
S21perf*            S74xntpd*           S92volmgt*
S30sysid.net*       S75cron*            S93cacheos.finish*
S47asppp*           S76nscd*            S99audit*
S69inet*            S80PRESERVE*        S99dtlogin*

The /etc/rcn.d scripts are always run in ASCII sort order. The scripts have names of the form:

[KS][0-9][0-9]*

Files beginning with K are run to terminate (kill) a system process. Files beginning with S are run to start a system process.

Run control scripts are also located in the /etc/init.d directory. These files are linked to corresponding run control scripts in the /etc/rcn.d directories.

The actions of each run control script are summarized in Table 6-5.

Using a Run Control Script to Stop or Start Services

One advantage of having individual scripts for each run level is that you can run scripts in the /etc/init.d directory individually to turn off functionality without changing a system's run level.

How to Use a Run Control Script to Stop or Start a Service

  1. Become superuser.

  2. Turn off functionality.


    # /etc/init.d/filename stop
    
  3. Restart functionality.


    # /etc/init.d/filename start
    
  4. Use the pgrep command to verify whether the service has been stopped or started.


    # pgrep -f service
    

Example--Using a Run Control Script to Stop or Start a Service

Turn off NFS server functionality by typing:


# /etc/init.d/nfs.server stop
# pgrep -f nfs
#

Restart the NFS services by typing:


# /etc/init.d/nfs.server start
# pgrep -f nfs
141
143
245
247
# pgrep -f nfs -d, | xargs ps -fp
root   141     1 40   Jul 31 ?     0:00 /usr/lib/nfs/statd
root   143     1 80   Jul 31 ?     0:01 /usr/lib/nfs/lockd
root   245     1 34   Jul 31 ?     0:00 /usr/lib/nfs/nfsd -a 16
root   247     1 80   Jul 31 ?     0:02 /usr/lib/nfs/mountd

Adding a Run Control Script

If you want to add a run control script to start and stop a service, copy the script into the /etc/init.d directory and create links in the rcn.d directory you want the service to start and stop.

See the README file in each /etc/rcn.d directory for more information on naming run control scripts. The procedure below describes how to add a run control script.

How to Add a Run Control Script

  1. Become superuser.

  2. Add the script to the /etc/init.d directory.


    # cp filename /etc/init.d
    # chmod 0744 /etc/init.d/filename
    # chown root:sys /etc/init.d/filename
    
  3. Create links to the appropriate rcn.d directory.


    # cd /etc/init.d
    # ln filename /etc/rc2.d/Snnfilename
    # ln filename /etc/rcn.d/Knnfilename
    
  4. Use the ls command to verify that the script has links in the specified directories.


    # ls /etc/init.d/ /etc/rc2.d/ /etc/rcn.d/
    

Example--Adding a Run Control Script


# cp xyz /etc/init.d
# cd /etc/init.d
# ln xyz /etc/rc2.d/S100xyz
# ln xyz /etc/rc0.d/K100xyz
# ls /etc/init.d /etc/rc2.d /etc/rc0.d

Disabling a Run Control Script

Disable a run control script by renaming it with a dot (.) at the beginning of the new file name. Files that begin with a dot are not executed. If you copy a file by adding a suffix to it, both files will be run.

How to Disable a Run Control Script

  1. Become superuser.

  2. Rename the script by adding an underscore (_) to the beginning of the new file.


    # cd /etc/rcn.d
    # mv filename _filename
    
  3. Verify the script has been renamed.


    # ls
    # _filename
    

Example--Disabling a Run Control Script

The following example changes the S100datainit script name but saves the original script.


# cd /etc/rc2.d
# mv S100datainit _S100datainit

Run Control Script Summaries

Table 6-5 The /sbin/rc0 Script

Script Name 

Description 

/sbin/rc0

Performs the following tasks: 

 

  • Stops system services and daemons

  • Terminates all running processes

  • Unmounts all file systems

Table 6-6 The /sbin/rc1 Script

Script Name 

Description 

/sbin/rc1

Runs the /etc/rc1.d scripts to perform the following tasks:

 

  • Stops system services and daemons

  • Terminates all running processes

  • Unmounts all file systems

  • Brings the system up in single-user mode

Table 6-7 The /sbin/rc2 Script

Script Name 

Description 

/sbin/rc2

Runs the /etc/rc2.d scripts to perform the following tasks:

 
  • Mounts all local file systems

  • Enables disk quotas if at least one file system was mounted with the quota option

  • Saves editor temporary files in /usr/preserve

  • Removes any files in the /tmp directory

  • Configures system accounting

  • Configures default router

  • Sets NIS domain and ifconfig netmask

  • Reboots the system from the installation media or a boot server if either /.PREINSTALL or /AUTOINSTALL exists

  • Starts inetd and rpcbind and named, if appropriate

  • Starts Kerberos client-side daemon, kerbd

  • Starts NIS daemons (ypbind) and NIS+ daemons (rpc.nisd), depending on whether the system is configured for NIS or NIS+, and whether the system is a client or a server

  • Starts keyserv, statd, lockd, xntpd, and utmpd

  • Mounts all NFS entries

  • Starts nscd (name service cache daemon)

  • Starts automount, cron, LP print service, sendmail, utmpd, and vold daemons


Note -

Many of the system services and applications that are started at run level 2 depend on what software is installed on the system.


Table 6-8 The /sbin/rc3 Script

Script Name 

Description 

/sbin/rc3

Runs the /etc/rc3.d scripts to perform the following tasks:

 
  • Cleans up sharetab

  • Starts nfsd

  • Starts mountd

  • If the system is a boot server, starts rarpd, rpc.bootparamd, and rpld

  • Starts snmpdx (SolsticeTM EnterpriseTM AgentTM process ).

Table 6-9 The /sbin/rc5 and /sbin/rc6 Scripts

Script Name 

Description 

/sbin/rc5 and /sbin/rc6

Runs the /etc/rc0.d/K* scripts to perform the following tasks:

 
  • Kills all active processes

  • Unmounts the file systems

  

Table 6-10 The /sbin/rcS Script

Script Name 

Description 

/sbin/rcS

Runs the /etc/rcS.d scripts to bring the system up to run level S. The following tasks are performed from these scripts:

 
  • Establishes a minimal network

  • Mounts /usr, if necessary

  • Sets the system name

  • Checks the root (/) and /usr file systems

  • Mounts pseudo file systems (/proc and /dev/fd)

  • Rebuilds the device entries for reconfiguration boots

  • Checks and mounts other file systems to be mounted in single-user mode

Chapter 7 Shutting Down a System (Tasks)

This chapter describes the procedures for shutting down systems. This is a list of the step-by-step instructions in this chapter.

This is a list of the overview information in this chapter.

For overview information about the available run levels, see Chapter 6, Run Levels and Boot Files (Tasks).

When to Shut Down the System

The Solaris system software is designed to be left running continuously so that the electronic mail and network software can work correctly. However, some system administration tasks and emergency situations require that the system is shut down to a level where it is safe to remove power or brought to an intermediate level, where not all system services are available, such as:

See Chapter 5, Shutting Down and Booting a System (Overview) for a complete list of system administration tasks requiring a system shutdown.

How to Shut Down a System

Using the init and shutdown commands are the primary ways to shut down a system. Both commands perform a clean shutdown of the system, which means all file system changes are written to the disk, and all system services, processes, and the operating system are terminated normally.

Using a system's stop key sequence or turning a system off and then on are not clean shutdowns because system services are terminated abruptly. However, is it sometimes necessary to use these actions in emergency situations. See Chapter 8, Booting a SPARC System (Tasks) or Chapter 9, x86: Booting a System (Tasks) for instructions on system recovery techniques.

Table 7-1 describes the various shutdown commands and provides recommendations for using them.

Table 7-1 Shutdown Commands

Command 

Description 

This Command Is ... 

shutdown

An executable shell script that calls the init program to shutdown the system. The system is brought to run level S by default.

Recommended for servers running at run level 3 because users are notified of the impending shut down as are the systems that are mounting resources from the server being shut down.  

init

An executable that kills all active process and syncs the disks before changing run levels.

Recommended for standalone systems when other users will not be affected. It provides a faster system shutdown because users are not notified of the impending shutdown. 

reboot

An executable that syncs the disks and passes booting instructions to the uadmin system call, which, in turn, stops the processor.

Not recommended; use the init command instead.

halt

An executable that syncs the disks and stops the processor.

Not recommended because it doesn't execute the /etc/rc0 script, which stops all processes, syncs the disks, and unmounts any remaining file systems.


Note -

The /usr/sbin/shutdown command, not the /usr/ucb/shutdown command, is used in this chapter and throughout this book.


When to Turn Off Power to Devices

Turning off power to all system devices is necessary when you need to:

All system devices include the CPU, the monitor, and external devices such as disks, tapes, and printers.

The steps for turning off power to all devices are performed in addition to shutting down the system.

Notifying Users of System Down Time

When the shutdown command is initiated, it will notify all logged-in users and all systems that are mounting resources from it of the impending shutdown with a warning and then a final message.

This is why the shutdown command is recommended over the init command when used on a server. When using either command, you may want to give users more notice by sending a mail message about any scheduled system shutdown.

Use the who(1) command to determine which users on the system need to be notified. This command is also useful for determining a system's current run level, which is described on "How to Determine a System's Run Level".

How to Determine Who Is Logged in to a System

  1. Log into the system to be shut down.

  2. Display logged-in users with the who command.


    $ who
    

Example--Determining Who Is Logged in to a System

The following example displays the output of the who command.


$ who
 [Identifies the username of the logged-in user. ] holly [Identifies the terminal line of the logged-in user. ]           console  May  7 07:30
 [Identifies the date and time the user logged in. ] kryten    pts/0    May  7 07:35	(starbug)
 [(Optional) Identifies the host name if a user is logged in from a remote system.  ] lister    pts/1    May  7 07:40	(bluemidget)

How to Shut Down a Server

  1. Become superuser.

  2. Find out if users are logged into the system.


    # who
    

    A list of all logged-in users is displayed. You may want to send mail or broadcast a message to let users know that the system is being shut down.

  3. Shut down the system by using the shutdown(1M) command.


    # shutdown -iinit-state -ggrace-period -y 
    

    -iinit-state

    Brings the system to an init state different from the default of S. The choices are 0, 1, 2, 5, and 6. 

    -ggrace-period

    Indicates a time (in seconds) before the system is shut down. The default is 60 seconds. 

    -y

    Continues to shut down the system without intervention; otherwise, you are prompted to continue the shutdown process after 60 seconds. 

  4. If you are asked for confirmation, type y.


    Do you want to continue? (y or n): y
    

    If you used the shutdown -y command, you will not be prompted to continue.

  5. Type the superuser password, if prompted.


    Type Ctrl-d to proceed with normal startup,
    (or give root password for system maintenance): xxx
    
  6. After you have finished the system administration tasks, press Control-d to return to the default run system level.

  7. Use the following table to verify the system is at the run level specified in the shutdown command.

    If the System Was Brought To ... 

    The SPARC System Prompt Should Be ... 

    The x86 System Prompt Should Be ... 

    Run level S (single-user state) 

    Run level 0 (power-down state) 

    ok or >

    type any key to continue

    Run level 3 (multiuser state with remote resources shared) 

    hostname console login:

    hostname console login:

Example--Bringing a SPARC System to Run Level S (Server)

In the following example, the shutdown is used to bring a SPARC system to run level S (single-user state) in 3 minutes.


# who
root       console      Jun 10 14:15 
# shutdown -g180 -y
 
Shutdown started.    Wed Jun 10 14:15:25 MDT 1998
 
Broadcast Message from root (console) on mars Wed Jun 10 14:15:26...
The system mars will be shut down in 3 minutes 
.
.
.
Broadcast Message from root (console) on mars Wed Jun 10 14:17:58...
The system mars will be shut down in 30 seconds
.
.
.
INIT: New run level: S
The system is coming down for administration.  Please wait.
Unmounting remote filesystems: /vol nfs done.
Print services stopped.
syslogd: going down on signal 15
Killing user processes: done.
 
INIT: SINGLE USER MODE
 
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): xxx
Entering System Maintenance Mode ...
# 

Example--Bringing a SPARC System to Run Level 0 (Server)

In the following example, the shutdown command is used to bring a SPARC system to run level 0 in 5 minutes without requiring additional confirmation.


# who
kryten     console      Jun 10 14:22
rimmer     pts/1        Jun 10 14:23    (starbug)
pmorph     pts/2        Jun 10 14:24    (bluemidget)
Send mail message to logged-in users
# shutdown -i0 -g300 -y
Shutdown started.    Wed Jun 10 14:30:32 MDT 1998
Broadcast Message from root (console) on pluto Wed Jun 10 14:30:32...
The system will be shut down in 5 minutes
.
.
.
INIT: New run level: 0
The system is coming down.  Please wait.
.
.
.
The system is down.
syncing file systems... [11] [9] [5] done
Program terminated
Type  help  for more information
ok 

See "How to Turn Off Power to All Devices" if you are bringing the system to run level 0 to turn off power to all devices.

Example--Rebooting a SPARC System to Run Level 3 (Server)

In the following example, the shutdown command is used to reboot a SPARC system to run level 3 in 2 minutes without requiring additional confirmation.


# who
kryten     console      Jun 10 14:35
rimmer     pts/1        Jun 10 14:40    (starbug)
pmorph     pts/2        Jun 10 14:45    (bluemidget)
Send mail message to logged-in users
# shutdown -i6 -g120 -y
Shutdown started.    Wed Jun 10 14:34:26 MDT 1998
Broadcast Message from root (console) on pluto Wed Jun 10 14:34:26 MDT 1998
The system will be shut down in 1 minute
Changing to init state 6 - please wait
#
INIT: New run level: 6
The system is coming down.  Please wait.
.
.
.
The system is down.
syncing file systems... [11] [9] [5] done
rebooting...
.
.
.
 
pluto console login:

Where to Go From Here

Regardless of the reason for shutting down the system, you'll probably want to return to run level 3 where all file resources are available and users can log in. See Chapter 8, Booting a SPARC System (Tasks) or Chapter 9, x86: Booting a System (Tasks) for instructions on bringing a system back to a multiuser state.

How to Shut Down a Standalone System

  1. Become superuser.

  2. Shut down the system by using the init(1M) command.


    # init run-level
    

    run-level

    Identifies the new run level. 

  3. Use the following table to verify the system is at the run level specified in the init command.

    If the System Was Brought To ... 

    The SPARC System Prompt Should Be ... 

    The x86 System Prompt Should Be ... 

    Run level S (single-user state) 

    ##

    Run level 2 (multiuser state) 

    ##

    Run level 0 (power-down state) 

    ok or >type any key to continue

    Run level 3 (multiuser state with remote resources shared) 

    hostname console login:

    hostname console login:

Example--Bringing an x86 System to Run Level 0 (Standalone)

In the following example, the init command is used to bring an x86 standalone system to the level where it is safe to turn off power.


# init 0
#
INIT: New run level: 0
The system is coming down.  Please wait.
.
 
.
 
.
The system is down.
syncing file systems... [11] [10] [3] done
Type any key to continue

See "How to Turn Off Power to All Devices" if you are bringing the system to run level 0 to turn off power to all devices.

Example--Bringing a SPARC System to Run Level S (Standalone)

In the following example, the init is used to bring a SPARC standalone system to run level S (single-user state).


# init s
#
INIT: New run level: S
The system is coming down for administration.  Please wait.
Unmounting remote filesystems: /vol nfs done.
Print services stopped.
syslogd: going down on signal 15
Killing user processes: done. 
INIT: SINGLE USER MODE
 
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): xxx
Entering System Maintenance Mode
 
# 

Where to Go From Here

Regardless of the reason for shutting down the system, you'll probably want to return to run level 3 where all file resources are available and users can log in. See Chapter 8, Booting a SPARC System (Tasks) or Chapter 9, x86: Booting a System (Tasks) for instructions on bringing a system back to a multiuser state.

How to Turn Off Power to All Devices

  1. Use the following table to determine which procedure to use for shutting down the system.

    If You Are Shutting Down a Server ... 

    If You Are Shutting Down a Standalone System ... 

    See "How to Shut Down a Server".

    See "How to Shut Down a Standalone System".

  2. Turn off power to all devices after the system is shutdown. If necessary, also unplug the power cables.

  3. After power can be restored, use the following steps to turn on the system and devices.

    1. Plug in the power cables.

    2. Turn on the monitor.

    3. Turn on disk drives, tape drives, and printers.

    4. Turn on the CPU.

      The system brought to run level 3 after the CPU is turned on.

Chapter 8 Booting a SPARC System (Tasks)

This chapter describes procedures for using the OpenBootTM PROM monitor and procedures for booting a SPARC system to different run levels.

This is a list of the step-by-step instructions in this chapter.

For overview information about the boot process, see Chapter 10, The Boot Process (Reference).

SPARC: Using the Boot PROM

System administrators typically use the PROM level to boot a system but occasionally may need to change the way the system works, such as setting which device to boot from or running hardware diagnostics, before the system is brought to a multiuser state.

Changing the default boot device is necessary when you want to add a new drive to the system either permanently or temporarily, or if you convert a standalone system to a diskless client that needs to boot from the network.

See monitor(1M) or eeprom(1M) for a complete list of PROM commands.

SPARC: How to Switch to the ok Prompt

When the system is halted, the PROM monitor prompt is either the greater than sign (>) or ok.

Switch from the > prompt to the ok prompt on SPARC systems by typing the following command.


> n
ok

All examples in this section use the ok prompt.

SPARC: How to Find the PROM Release for a System

Display a system's PROM release level with the banner command.


ok banner
SPARCstation 2, Type 4 Keyboard
ROM Rev. 2.2, 16 MB memory installed, Serial #nnnnnn
Ethernet address 8:0:20:f:fd:6c HostID nnnnnnnn

Hardware configuration information, including the release number of the PROM, is displayed. The PROM release level is indicated by the ROM Rev. number.

SPARC: How to Change the Default Boot Device

Use this procedure when you need to change the default boot device.

  1. Become superuser.

  2. Halt the system by using the init(1M) command.


    # init 0
    

    The > PROM prompt is displayed.

  3. If the > PROM prompt is displayed, type n and press Return.


    > n
    ok

    The ok PROM prompt is displayed.

  4. Change the boot-device setting by using the setenv command.


    ok setenv boot-device disk[n]

    boot-device

    Identifies the parameter for setting the device from which to boot. 

    disk[n]

    Identifies the boot-device value and in this case, n is the disk number.

    Use the probe-scsi-all command if you need help identifying the disk number.

  5. Verify the default boot device change by using the printenv command.


    ok printenv boot-device
    
  6. Save the new boot-device value by using the reset command.


    ok reset
    

    The boot-device setting is written to the PROM.

SPARC: Example--Changing the Default Boot Device


# init 0
# 
INIT: New run level: 0
.
.
.
The system is down.
syncing file systems... [11] [10] [5] done
Program terminated
Type  help  for more information
ok setenv boot-device disk
boot-device =         disk
ok printenv boot-device
boot-device           disk                    disk
ok reset
SPARCstation 10 (1 X 390Z50), No Keyboard
ROM Rev. 2.14, 32 MB memory installed, Serial #3383708.
Ethernet address 8:0:20:1f:33:9f, Host ID: 7233a19e.
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0  File and args: kadb -v
.
.
.
pluto console login:

SPARC: How to Reset the System

Run the reset command from the ok prompt.


ok reset

The self-test program, which runs diagnostic tests on the hardware, is executed and the system is rebooted.

Booting a SPARC System

Table 8-1 describes the boot scenarios covered in this chapter.

Table 8-1 SPARC: Boot Type Descriptions

Booting the System ... 

Is Usually Done ... 

See ... 

To run level 3 (multiuser state with NFS resources shared) 

After halting the system or performing some system hardware maintenance task. This is the default boot level where all resources are available and users can log into the system. 

"Example--Booting a System to Run Level 3 (Multiuser State)"

To run level S (single-user state) 

After performing some system maintenance task such as backing up a file system. At this level only local file systems are mounted and users cannot log into the system. 

"SPARC: Example--Booting a System to Run Level S (Single-User State)"

Interactively 

After making temporary changes to a system file or the kernel for testing purposes. This type of boot allows you to recover easily if there are problems with the system file or kernel by supplying an alternative pathname to these files when prompted. Use the default settings for the other system prompts. 

"SPARC: Example--Booting a System Interactively"

From local CD-ROM or the network for recovery purposes 

To repair an important system file that is preventing the system from booting successfully. This type of boot is also used for installing (or upgrading) a new release of the operating system. 

"SPARC: Example--Booting a System for Recovery Purposes"

Using kadb

To troubleshoot system problems by running the kernel debugger. 

"SPARC: Example--Booting the System Using the Kernel Debugger (kadb)"

If a system is turned off, turning it on starts the multiuser boot sequence. The following procedures show how to boot to different run levels from the ok PROM prompt.

Use the who -r command to verify that the system is brought to the specified run level.

See Chapter 6, Run Levels and Boot Files (Tasks) for a description of run levels.

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

  1. Boot to run level 3 by using the boot(1M) command.


    ok boot
    

    The automatic boot procedure displays a series of startup messages, and brings the system to run level 3.

  2. Verify the system boots to run level 3.

    The login prompt is displayed when the boot process has finished successfully.


    hostname console login:

Example--Booting a System to Run Level 3 (Multiuser State)

The following example displays the messages from booting a system to run level 3.


ok boot
Resetting ...
SPARCstation 10 (1 X 390Z50), Keyboard Present
ROM Rev. 2.14, 32 MB memory installed, Serial #number.
Ethernet address #number, Host ID: number.

Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0  
File and args: 
SunOS Release 5.7 Version generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1998, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: venus
The system is coming up.  Please wait.
add net default: gateway 129.152.75.248
NIS domainname is solar.com
starting rpc services: rpcbind keyserv ypbind done.
Setting netmask of le0 to 255.255.255.0
Setting default interface for multicast: add net 224.0.0.0: gateway venus
syslog service starting.
Print services started.
volume management starting.
The system is ready.

venus console login: 

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

  1. Boot the system to run level S by using the boot -s command.


    ok boot -s
    
  2. Enter the superuser password when the following message is displayed.


    INIT: SINGLE USER MODE
    Type Ctrl-d to proceed with normal startup,
     
    (or give root password for system maintenance):  xxx
    
  3. Use the who -r command to verify that the system is at run level S.


    # who -r
    .       run-level 3  Jun 10 15:27     3      0 
  4. To bring the system up to multiuser state after the system maintenance task is performed, press Control-d.

SPARC: Example--Booting a System to Run Level S (Single-User State)

The following example displays a system booted to run level S.


ok boot -s
.
.
.
SunOS Release 5.7 Version [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1998, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: mars
INIT: SINGLE USER MODE
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): xxx
Sun Microsystems Inc.   SunOS 5.7 August 1998
# who -r
  .       run-level S  Jun 10 15:34     S      0  ?
(Perform some maintenance task)
# Press <Control-d>

SPARC: How to Boot a System Interactively

  1. Boot the system interactively by using the boot -a command.


    ok boot -a
    
  2. Answer the system prompts as described in Table 8-2.

    Table 8-2 SPARC: Interactive Boot Procedure Steps

    If the System Displays ... 

    Do the Following ... 

    Enter filename [kernel/unix]:

    Provide the name of another kernel to use for booting. 

    Or, press Return to use the default kernel (/platform/`uname -m`/kernel/unix).

    Name of default directory for modules [/platform/`uname -m`/kernel /kernel /usr/kernel]:

    Provide an alternate path for the modules directory and press Return. 

    Or, press Return to use the default modules directory path. 

    Name of system file [/etc/system]:

    Provide the name of an alternate system file and press Return. Enter /dev/null as the file if your /etc/system file has been damaged.

    Or, press Return to use the default /etc/system file.

    root filesystem type [ufs]:

    Press Return to use the default root file system type: UFS for local disk booting or NFS for diskless clients. 

    Enter physical name of root device

    [physical_device_name]:

    Provide an alternate device name and press Return. 

    Or, press Return to use the default physical name of the root device.  

  3. If you are not prompted to answer the questions in Table 8-2, verify that you entered the boot -a command correctly.

SPARC: Example--Booting a System Interactively

In the following example, the default choices shown in square brackets [] are accepted.


ok boot -a
.
.
.
Resetting ...
Rebooting with command: -a                                           
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 
File and args: -a
Enter filename [kernel/unix]: Return
Enter default directory for modules
[/platform/SUNW,SPARCstation-10/kernel /platform/sun4m/kernel /kernel /usr/kernel]:
Return
SunOS Release 5.7 Version generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1998, Sun Microsystems, Inc.
Name of system file [etc/system]:  Return
root filesystem type [ufs]: Return
Enter physical name of root device
[/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000
/sd@3,0:a]: Return
configuring network interfaces: le0.
Hostname: earth
The system is coming up.  Please wait.
.
.
.
The system is ready.
earth console login:

SPARC: How to Boot a System for Recovery Purposes

This procedure is needed when an important file, such as /etc/passwd, has an invalid entry and is causing the boot process to fail.

If you need help identifying a system's device names, refer to Chapter 20, Accessing Devices (Overview).

  1. Follow the instructions below depending on whether you are booting from the Solaris installation CD or the network.

    If You Are Booting From ... 

    Then ... 

    Solaris installation CD 

    1. Insert the Solaris installation CD into the CD caddy. 

    2. Insert the CD caddy into the CD-ROM drive. 

    3. Boot from the installation CD in single-user mode: 

    ok boot cdrom -s

    The network and an installation server or remote CD drive are available 

    Use the following command: 

    ok boot net -s

  2. Mount the file system that has the file with an invalid entry.


    # mount /dev/dsk/device-name /a
    
  3. Change to the newly mounted directory.


    # cd /a/directory
    
  4. Set the terminal type.


    # TERM=sun
    # export TERM
    
  5. Remove the invalid entry from the file using an editor.


    # vi filename
    
  6. Change to the root (/) directory.


    # cd /
    
  7. Unmount the /a directory.


    # umount /a
    
  8. Reboot the system.


    # init 6
    
  9. Verify the system boots to run level 3.

    The login prompt is displayed when the boot process has finished successfully.


    hostname console login:

SPARC: Example--Booting a System for Recovery Purposes

The following example shows how to repair an important system file (in this case, /etc/passwd) after booting from a local CD-ROM.


ok boot cdrom -s
# mount /dev/dsk/c0t3d0s0 /a
# cd /a/etc
# TERM=sun
# export TERM
# vi passwd
(Remove invalid entry)
# cd /
# umount /a
# init 6

SPARC: How to Stop the System for Recovery Purposes

The specific stop key sequence depends on your keyboard type. For example, you can press Stop-a or L1-a. On terminals, press the Break key.

  1. Type the abort key sequence for your system.

    The monitor displays the ok PROM prompt.


    ok
  2. Use the sync command to synchronize the disks.


    ok sync
    
  3. When you see the syncing file systems... message, press the abort key sequence for your system again.

  4. Type the appropriate boot(1M) command to start the boot process.

  5. Verify the system is booted to the specified run level.


    # who -r
     .       run-level 3  May  2 07:39     3      0  S 

SPARC: Example--Stopping the System for Recovery Purposes


Press <Stop-a>
ok sync
syncing file systems...
Press <Stop-a>
ok boot

SPARC: Forcing a Crash Dump and Rebooting the System

Saving crash dumps of the operating system is sometimes necessary for troubleshooting purposes. The savecore feature and how it is set up is described in "Managing System Crash Information" in System Administration Guide, Volume II. This section only describes how to reboot the system when the savecore feature is enabled.

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

  1. Type the stop key sequence for your system. The specific stop key sequence depends on your keyboard type. For example, you can press Stop-a or L1-a. On terminals, press the Break key.

    The monitor displays the ok PROM prompt.

  2. Use the sync command at the ok prompt to synchronize the disk and write the crash dump.


    > n
    ok sync
    

    After the crash dump is written to disk, the system will continue to reboot.

  3. Verify the system boots to run level 3.

    The login prompt is displayed when the boot process has finished successfully.


    hostname console login:

SPARC: Example--Forcing a Crash Dump and Rebooting the System


Press <Stop-a>
ok sync

SPARC: How to Boot the System Using the Kernel Debugger (kadb)

  1. Type the stop key sequence for your system. The specific stop key sequence depends on your keyboard type. For example, you can press Stop-A or L1-A. On terminals, press the Break key.

    The monitor displays the ok PROM prompt.

  2. Use the sync command at the ok prompt to synchronize the disk and write the crash dump.


    > n
    ok sync
    
  3. When you see the syncing file systems... message, press the abort key sequence for your system again.

  4. Boot the system using the kernel debugger.


    ok boot kadb
    
  5. Identify kadb booting messages to verify the system is booted using the kernel debugger.


    Rebooting with command: kadb
    Boot device: /iommu/sbus/espdma@4,800000/esp@4,8800000/sd@3,0
    .
    .
    .

SPARC: Example--Booting the System Using the Kernel Debugger (kadb)


Press <Stop-a>
ok sync
syncing file systems...
Press <Stop-a>
ok boot kadb

Chapter 9 x86: Booting a System (Tasks)

This chapter describes the procedures for booting an x86 system.

This is a list of the step-by-step instructions in this chapter.

For overview information about the boot process, see Chapter 10, The Boot Process (Reference).

Booting an x86 System

Table 9-1 describes the boot types covered in this chapter.

Table 9-1 x86: Boot Type Descriptions

Booting the System ... 

Is Usually Done ... 

See an Example On ... 

To run level 3 (multiuser state) 

After shutting down the system or performing some system hardware maintenance task. This is the default boot level where all resources are available and users can log into the system. 

"x86: Example--Booting a System to Run Level 3 (Multiuser State)"

To run level S (single-user state) 

After performing some system maintenance task such as backing up a file system. At this level only some file systems are mounted and users cannot log into the system. 

"x86: Example--Booting a System to Run Level S (Single-User State)"

Interactively 

After making temporary changes to the system file or the kernel for testing purposes. This type of boot allows you to recover easily if there are problems with the system file or kernel by supplying an alternative pathname to these files when prompted. Use the default settings for the other system prompts. 

"x86: Example--Booting a System Interactively"

From local CD-ROM or the network for recovery purposes 

To repair an important system file that is preventing the system from booting successfully. This type of boot is also used for installing (or upgrading) a new release of the operating system. 

"x86: Example--Booting a System for Recovery Purposes"

Using kadb

To troubleshoot system problems by using the kernel debugger and saving core dumps of the operating system. 

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

The following procedures use the reset button to restart the system. If your system does not have a reset button, use the on/off switch to restart the system. You might be able to press the Control-Alt-Del keys to interrupt system operation, depending upon the state of the system.

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

  1. Press any key to reboot the system if the system displays the Type any key to reboot prompt. You can also use the reset button at this prompt. If the system is shut down, turn the system on with the power (on/off) switch.

    The Current Boot Parameters menu is displayed after a few minutes.

  2. Type b to boot the system to run level 3. Press Return.

    If you do not make a selection within 5 seconds, the system is automatically booted to run level 3. See

  3. Verify the system boots to run level 3.

    The login prompt is displayed when the boot process has finished successfully.


    hostname console login:

x86: Example--Booting a System to Run Level 3 (Multiuser State)


Type any key to reboot
           .
           .
           .
 
                     <<< Current Boot Parameters >>>
Boot path: /eisa/eha@1,4000/sd@0,0:a
Boot args: 
 
Type    b [file-name] [boot-flags] <ENTER>      to boot with options
or      i <ENTER>                               to enter boot interpreter
or      <ENTER>                                 to boot with defaults
 
 
                     <<< timeout in 5 seconds >>>
 
Select (b)oot or (i)nterpreter: b 
             .
             .
             .
venus console login:

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

  1. Press any key to reboot the system if the system displays the Type any key to reboot prompt. You can also use the reset button at this prompt. If the system is shut down, turn the system on with the power (on/off) switch.

    The Current Boot Parameters menu is displayed after a few minutes.

  2. Type b -s to boot the system to run level S. Press Return.

    If you do not make a selection within 5 seconds, the system is automatically booted to run level 3.

  3. Type the superuser password, if prompted.

  4. Verify the system is at run level S by using the who -r command.


    # who -r
       .         run-level S  Nov 10 13:59     S    0  3
  5. Perform the maintenance task that needed the run level change to S.

  6. Press Control-d to bring the system back to run level 3.

x86: Example--Booting a System to Run Level S (Single-User State)


Type any key to reboot
            .
            .
            .
 
                     <<< Current Boot Parameters >>>
Boot path: /eisa/eha@1,4000/sd@0,0:a
Boot args: 
 
Type    b [file-name] [boot-flags] <ENTER>      to boot with options
or      i <ENTER>                               to enter boot interpreter
or      <ENTER>                                 to boot with defaults
 
 
                     <<< timeout in 5 seconds >>>
 
Select (b)oot or (i)nterpreter: b -s
              .
              .
              .
INIT: SINGLE USER MODE
 
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance):  xxx
Entering System Maintenance Mode
              .
              .
              .
# who -r
.       run-level S  Aug  4 13:11     S      0  3
(Perform some maintenance task)
# Press <Control-d>

x86: How to Boot a System Interactively

  1. Press any key to reboot the system if the system displays the Type any key to reboot prompt. You can also use the reset button at this prompt. If the system is shut down, turn the system on with the power (on/off) switch.

    The Current Boot Parameters menu is displayed after a few minutes.

  2. Type b -a to boot the system interactively.

    If you do not make a selection within 5 seconds, the system is automatically booted to run level 3.

  3. Answer the system prompts as described in Table 9-2.

    Table 9-2 x86: Interactive Boot Procedure Steps

    If the System Displays ... 

    Do the Following ... 

    Type any key to reboot

    Press any key to reboot the system if the system displays the Type any key to reboot prompt. You can also use the reset button at this prompt. If the system is shut down, turn the system on with the power (on/off) switch.

    The Primary Boot Subsystem menu is displayed after a few minutes. 

    The Primary Boot Subsystem menu 

    Select the Active Solaris slice as the boot device. Press Return. If you do not make a selection within 30 seconds, the active boot slice is selected automatically. 

    Select (b)oot or (i)nterpreter:

    Type b -a and press Return.

    Enter default directory for modules: [/platform/i86pc/kernel /kernel /usr/kernel]:

    Provide an alternate path for the modules directory and press Return, or press Return to use the default modules directory path.

    Name of system file [etc/system]:

    Provide the name of an alternate system file and press Return, or press Return to use the default /etc/system file. Enter

    /dev/null as the file if your /etc/system file has been damaged.

    root filesystem type [ufs]:

    Press Return to use the default root file system type: UFS for local disk booting or NFS for diskless clients. 

    Enter physical name of root device [physical_device_name]:

    Provide an alternate device name and press Return, or press Return to use the default physical name of the root device bootpath.

x86: Example--Booting a System Interactively

In the following example, the default choices (shown in square brackets []) are accepted.


Type any key to reboot
            .
            .
            .
 
                     <<< Current Boot Parameters >>>
Boot path: /eisa/eha@1,4000/sd@0,0:a
Boot args: 
 
Type    b [file-name] [boot-flags] <ENTER>      to boot with options
or      i  <ENTER>                              to enter boot interpreter
or      <ENTER>                                 to boot with defaults
 
 
                     <<< timeout in 5 seconds >>>>
Select (b)oot or (i)nterpreter: b -a
Enter default directory for modules [/platform/i86pc/kernel 
/kernel /usr/kernel]: Return
Name of system file [etc/system]:Return
(Copyright notice)
root filesystem type [ufs]: Return
Enter physical name of root device
[/eisa/dpt@5c88,0/cmdk@0,0:a]: Return
Configuring network interfaces:  smc0
Hostname: venus
(fsck messages)
The system is coming up.  Please wait
(More messages)
venus console login:

x86: How to Boot a System for Recovery Purposes

Recovering from a invalid /etc/passwd file is used as an example of how to boot a system for recovery purposes.

Substitute the device name of the file system to be repaired for the devicename variable identified in the procedures below. If you need help identifying a system's device names, refer to Chapter 20, Accessing Devices (Overview).

Follow the instructions below depending on whether you are booting from the Solaris 2 installation CD or the network.

  1. Boot from the Solaris 2 installation CD (or the network) to single-user mode using steps a-f.

    If you are booting from the network, skip steps a and b.

    1. Insert the Solaris 2 installation CD into the CD caddy.

    2. Insert the CD caddy into the CD-ROM drive.

    3. (Optional) Insert the Configuration Assistant/Boot Diskette into the primary diskette drive (DOS drive A) if the disk you are booting from doesn't contain the Solaris 2.6 Intel Platform Edition or compatible versions.

    4. Press any key to reboot the system if the system displays the Type any key to reboot prompt. You can also use the reset button at this prompt. If the system is shut down, turn the system on with the power (on/off) switch.

    5. Press the F2 key (F2_Continue) at the Solaris Device Configuration Assistant screen.

      Device identification is performed and a screen that displays the identified devices appears.

    6. Press the F2 key (F2_Continue) at the Identified Devices screen.

      Bootable drivers are loaded.

    7. Select the CD-ROM drive or net(work) as the boot device from the Boot Solaris screen. Then press the F2 key (F2_Continue).

      The Solaris boot option screen is displayed.

    8. Type b -s at the Select the type of installation: prompt.

      After a few minutes, the single-user mode # prompt is displayed.

  2. Mount the root (/) file system that has the invalid passwd file.


    # mount /dev/dsk/devicename /a
    
  3. Change to the newly mounted etc directory.


    # cd /a/etc
    
  4. Set the terminal type.


    # TERM=AT386
    # export TERM
    
  5. Make the necessary change to the passwd file using an editor.


    # vi passwd
    
  6. Change to the root (/) directory.


    # cd /
    
  7. Unmount the /a directory.


    # umount /a
    
  8. Reboot the system.


    # init 6
    
  9. Verify the system boots to run level 3.

    The login prompt is displayed when the boot process has finished successfully.


    hostname console login:

x86: Example--Booting a System for Recovery Purposes


Type any key to reboot
 
SunOS Secondary Boot version 3.00
 
 
		Solaris Intel Platform Edition Booting System
 
 
Running Configuration Assistant...
Autobooting from bootpath: /eisa/eha@1,4000/sd@0,0:a
 
If the system hardware has changed, or to boot from a different
device, interrupt the autoboot process by pressing ESC.
 
Press ESCape to interrupt autoboot in 5 seconds.
      .
      .
      .
Boot Solaris
 
Select one of the identified devices to boot the Solaris kernel and
choose Continue.
 
To perform optional features, such as modifying the autoboot and property
settings, choose Boot Tasks.
 
An asterisk (*) indicates the current default boot device.
 
> To make a selection use the arrow keys, and press Enter to mark it [X].
 
  [ ] DISK: Target 0, IMPRIMIS 94241-7			0888
	    on Adaptec 1740/1742 SCSI controller in EISA Slot 4
  [ ] CD  : Target 2, TOSHIBA  CD-ROM XM-3501TA 3054
	    on Adaptec 1740/1742 SCSI controller in EISA Slot 4
  [ ] NET : SMC EtherCard Elite32C Ethernet adapter
	    in EISA Slot 6
 
 
F2_Continue		F3_Back		F4_Boot Tasks		F6_Help
      .
      .
      .
                     <<< Current Boot Parameters >>>
Boot path: /eisa/smceu@0,0
Boot args: kernel/unix -r
 
 
 
Select the type of installation you want to perform:
 
	1 Solaris Interactive
	2 Custom JumpStart
	3 Solaris Web Start
 
Enter the number of your choice followed by <ENTER> the key.
 
If you enter anything else, or if you wait for 30 seconds,
an interactive installation will be started.
 
Select type of installation:  
Select (b)oot or (i)nterpreter: b -s
# mount /dev/dsk/c0t3d0s0 /a
# cd /a/etc
# TERM=AT386
# export TERM
# vi passwd
(Remove invalid entry)
# cd /
# umount /a
# init 6

x86: How to Stop the System for Recovery Purposes

If possible, attempt to stop the system by using one of the following commands:

If the system doesn't respond to any input from the mouse or keyboard, press the reset key, if it exists, to reboot the system. Or, use the power (on/off) switch to reboot the system.

x86: Forcing a Crash Dump and Rebooting the System

Saving core dumps of the operating system is sometimes necessary for troubleshooting purposes. The savecore feature and how it is set up is described in "Managing System Crash Information" in System Administration Guide, Volume II. This section only describes how to reboot the system when the savecore feature is enabled.

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

The system must be booted with the kernel debugger option, kadb, to get to the kadb[0]: prompt and force the crash dump.


x86 only -

You must be in text mode to enter the kernel debugger (kadb), so exit any window system (CDE or Open Windows) first.


  1. Press Control-Alt-d.


    kadb[0]:

    The kadb[0]: prompt is displayed.

  2. Type the following commands at the kadb[0]: prompt.


    Press <Control-Alt-d>
    kadb[0]: vfs_syncall/W ffffffff
    kadb[0]: 0>eip
    kadb[0]: :c
    kadb[0]: :c
    kadb[0]: :c
    

    After the first :c is typed, the system panics, so you need to type :c again. The system panics again, so type :c a third time to force the crash dump and reboot the system.

    After the crash dump is written to disk, the system will continue to reboot.

  3. Verify the system has rebooted by logging in at the console login prompt.

Chapter 10 The Boot Process (Reference)

This chapter describes the hardware used for booting on SPARC and x86 systems and a conceptual overview of the boot process on each platform.

This is a list of overview information in this chapter.

For instructions on booting a system, see Chapter 8, Booting a SPARC System (Tasks) or Chapter 9, x86: Booting a System (Tasks).

SPARC: The Boot PROM

Each SPARC system has a PROM (programmable read-only memory) chip with a program called the monitor. The monitor controls the operation of the system before the kernel is available. When a system is turned on, the monitor runs a quick self-test procedure that checks things such as the hardware and memory on the system. If no errors are found, the system begins the automatic boot process.


SPARC only -

Some older systems may require PROM upgrades before they will work with the Solaris system software. Contact your local service provider for more information.


SPARC: The Boot Process

Table 10-1 SPARC: The Boot Process
      
 

Boot PROM Phase 

 

The boot PROM runs self-test diagnostics. 

 
   

The boot PROM loads the bootblock program.

     
       
 

Boot Programs Phase 

 

The boot block program loads the ufsboot program.

 
   

After the ufsboot program is loaded, it loads the kernel.

     
       
 

Kernel Initialization Phase 

 

The kernel initializes itself and loads the modules needed to mount the root (/) file system.

  
   

The kernel starts the init process.

     
       
 

init Phase

 

The init process starts the run control scripts.

  
         

SPARC: The Boot Process Details

Table 10-2 describes the SPARC boot process illustrated above.

Table 10-2 SPARC: Description of SPARC Boot Process

Boot Phase 

Description 

Boot PROM 

1. The PROM displays system identification information and then runs self-test diagnostics to verify the system's hardware and memory. 

 

2. Then the PROM loads the primary boot program, bootblk, whose purpose is to load the secondary boot program located in the ufs file system from the default boot device.

Boot Programs 

3. The bootblk program finds and executes the secondary boot program, ufsboot, and loads it into memory.

 

4. After ufsboot program is loaded, the ufsboot program loads the kernel.

Kernel Initialization 

5. The kernel initializes itself and begins loading modules, using ufsboot to read the files. When the kernel has loaded enough modules to mount the root file system, it unmaps the ufsboot program and continues, using its own resources.

 

6. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.

init

7. The /sbin/init process starts the run control (rc) scripts, which execute a series of other scripts. These scripts (/sbin/rc*) check and mount file systems, start various processes, and perform system maintenance tasks.

x86: The PC BIOS

Before the kernel is started, the system is controlled by the read-only-memory (ROM) Basic Input/Output System (BIOS), the firmware interface on a PC.

Hardware adapters can have an onboard BIOS that displays the physical characteristics of the device and can be used to access the device.

During the startup sequence, the PC BIOS checks for the presence of any adapter BIOS and if found, loads and executes each one. Each individual adapter's BIOS runs self-test diagnostics and displays device information.

x86: Boot Subsystems

At three times during the Solaris boot process, you can make the following choices about a booting system:

Table 10-3 summarizes the purpose of the primary x86 boot interfaces. See the sections that follow for a detailed description and example of each boot subsystem.

Table 10-3 x86: Boot Subsystems

Boot Subsystem 

Purpose 

Primary Boot Subsystem 

This menu appears if the disk you are booting from contains more than one fdisk partition, in addition to the Solaris fdisk partition.

Secondary Boot Subsystem 

This menu appears each time you boot the Solaris release. The Solaris release is booted automatically unless you choose to run the Solaris Device Configuration Asisstant by interrupting the autoboot process. 

Solaris Device Configuration Assistant/Boot Diskette 

There are two ways to access the Solaris Device Configuration Assistant menus:  

  1. Use the Solaris Device Configuration Assistant Boot Diskette to boot the system.

  2. Interrupt the autoboot process when booting Solaris from an installed disk.

Current Boot Parameters Menu 

This menu appears when you boot from a disk with the Solaris operating environment installed or if you want to install the Solaris release from the Solaris installation CD or the network. In either case, this menu presents a list of boot options. 

During the boot process, the boot subsystem menus allow you to customize boot choices. If the system receives no response during the time-out periods, it continues to boot automatically using default selections. You can stop the boot process when each boot subsystem menu is displayed or you can let it continue automatically.

The following section provides examples of each subsystem screen.

x86: Booting Solaris

During the device identification phase, the Configuration Assistant:

During the Boot phase, the system:

Examples of device identification during each phase are provided below. Device output varies based on your system configuration.

x86: Menus Displayed During the Device Identification Phase

Several menus are displayed as the Configuration Assistant attempts to identify devices on the system.

x86: Configuration Assistant Menu

This menu appears each time you run the Configuration Assistant.


Solaris Device Configuration Assistant 
 
The Solaris(TM) (Intel Platform Edition) Device Configuration Assistant
scans to identify system hardware, lists identified devices, and can
boot the Solaris software from a specified device. This program must be
used to install the Solaris operating environment, add a Driver Update,
or change the hardware on the system.
 
> To perform a full scan to identify all system hardware, choose Continue.
 
> To diagnose possible full scan failures, choose Specific Scan.
 
> To add new or updated device drivers, choose Driver Update.
 
About navigation...
    - The mouse cannot be used.
    - If the keyboard does not have function keys or they do not respond, 
      press ESC. The legend at the bottom of the screen will change to 
      show the ESC keys to use for navigation.
    - The F2 key performs the default action.
 
F2_Continue		F3_Specific Scan		F4_Driver Update		F6_Help

x86: Bus Enumeration Menu

The Bus Enumeration menu appears briefly while the Configuration Assistant gathers hardware configuration data for devices that can be detected automatically.


Bus Enumeration
 
 
 
Determining bus types and gathering hardware configuration data ...
 
 
 
Please wait ...

x86: Scanning Devices Menu

The Scanning Devices menu appears while the Configuration Assistant manually scans for devices that can only be detected with special drivers.


Scanning Devices
 
The system is being scanned to identify system hardware.
 
If the scanning stalls, press the system's reset button. When the
system reboots, choose Specific Scan or Help.
 
 
			Scanning: Flpppy disk controller
 
   #######################
			|         |        |         |         |         |
			0	 		 20       40        60	       80       100
 
 
 
Please wait ...

x86: Identified Devices Menu

The Identified Devices menu displays which devices have been identified on the system. From here, you can continue to the "Boot Solaris" menu or perform optional tasks, such as set a keyboard configuration, view and edit devices, set up a serial console, and save and delete configurations.


Identified Devices
 
The following devices have been identified on this system. To identify
devices not on this list or to modify device characteristics, such as
keyboard configuration, choose Device Tasks. Platform types may be
included in this list.
 
	EISA: Adaptec 1740/1742 SCSI controller
	EISA: Motherboard
	EISA: SMC EtherCard Elite32C Ethernet adapter
	ISA: Floppy disk controller
	ISA: Game port (Joy stick)
	ISA: PCMCIA controller
	ISA: Parallel port
	ISA: Serial port
	ISA: System keyboard (US-English)
	ISA: VGA w/ 8514/A compatible graphics adapter
 
 
 
F2_Continue		F3_Back			F4_Device Tasks			F6_Help
 

x86: Menus Displayed During the Boot Phase

During this phase, you can determine the way in which the system is booted.

x86: Boot Solaris Menu

The Boot Solaris menu allows you to select the device from which to boot the Solaris release. You can also perform optional tasks, such as view and edit autoboot and property settings. Once a boot device is selected and you choose Continue, the Solaris kernel will begin to boot.


Boot Solaris
 
Select one of the identified devices to boot the Solaris kernel and
choose Continue.
 
To perform optional features, such as modifying the autoboot and property
settings, choose Boot Tasks.
 
An asterisk (*) indicates the current default boot device.
 
> To make a selection use the arrow keys, and press Enter to mark it [X].
 
  [ ] DISK: Target 0, IMPRIMIS 94241-7			0888
	    			on Adaptec 1740/1742 SCSI controller in EISA Slot 4
  [ ] CD  : Target 2, TOSHIBA  CD-ROM XM-3501TA 3054
	    			on Adaptec 1740/1742 SCSI controller in EISA Slot 4
  [ ] NET : SMC EtherCard Elite32C Ethernet adapter
	    			in EISA Slot 6
 
 
 
 
F2_Continue		F3_Back			F4_Boot Tasks			F6_Help

x86: Solaris Boot Options Menu

This menu appears each time you boot Solaris from the local disk. Let the five-second timeout elapse if you want to boot the default Solaris kernel. If you want to boot with different options, select an appropriate option before the timeout period elapses.


                     <<< Current Boot Parameters >>>
Boot path: /eisa/eha@1,4000/sd@0,0:a
Boot args: 
 
Type    b [file-name] [boot-flags] <ENTER>       to boot with options
or      i <ENTER>                                to enter boot interpreter
or      <ENTER>                                  to boot with defaults
 
 
                     <<< timeout in 5 seconds >>>
 
Select (b)oot or (i)nterpreter: 

x86: The Boot Process

Table 10-4 x86: The Boot Process
      
 

BIOS Phase 

 

The PC BIOS loads and executes any hardware device's BIOS. 

 
   

The BIOS boot program loads and executes the master boot record, mboot.

     
       
 

Boot Programs Phase 

 

mboot loads pboot, the Solaris boot partition, boot program.

 
   

pboot loads bootblk, the primary boot program.

  
   

bootblk reads the fdisk table to locate the default boot partition. The Primary Boot Subsystem menu is displayed at this time.

  
   

bootblk loads the secondary boot program, boot.bin or ufsboot. You can press the ESC key to enter the Configuration Assistant Menu at this point.

  
   

The secondary boot program, boot.bin or ufsboot, reads the /etc/bootrc script, which loads the kernel. The Solaris Boot options menu is displayed at this time.

     
       
 

Kernel Initialization Phase 

 

The kernel initializes itself and loads the modules needed to mount the root (/) file system.

  
   

The kernel starts the init process.

     
       
 

init Phase

 

The init process starts the run control scripts.

  
         

x86: The Boot Process Details

Table 10-5 describes the x86 boot process illustrated above.

Table 10-5 x86: Description of x86 Boot Process

Boot Phase 

Description 

BIOS 

1. When the system is turned on, the PC BIOS runs self-test diagnostics to verify the system's hardware and memory. The system begins to boot automatically if no errors are found. If errors are found, error messages are displayed describing recovery options. 

Additional hardware devices' BIOS are run at this time. 

 

2. The BIOS boot program tries to read the first physical sector from the boot device--either a diskette or hard drive. This first disk sector on the boot device contains the master boot record mboot, which is loaded and executed. If no mboot file is found, an error message is displayed.

Boot Programs 

3. mboot, which contains disk information needed to find the active partition and the location of the Solaris boot program, pboot, loads and executes pboot.

 

4. pboot loads bootblk, the primary boot program, whose purpose is to load the secondary boot program located in the ufs file system.

 

5. If there is more than one bootable partition, bootblk reads the fdisk table to locate the default boot partition, and builds and displays a menu of available partitions. You have a 30-second timeout interval to select an alternate partition from which to boot. This step only occurs if there is more than one bootable partition present on the system.

 

6. bootblk finds and executes the secondary boot program, boot.bin or ufsboot, in the root file system. You have a 5-second timeout interval to interrupt the autoboot to start the Configuration Assistant.

 

7. The secondary boot program, boot.bin or ufsboot, starts a command interpreter that executes the /etc/bootrc script, which provides a menu of choices for booting the system. The default action is to load and execute the kernel. You have a 5-second timeout interval to specify a boot option or start the boot interpreter.

Kernel Initialization 

8. The kernel initializes itself and begins loading modules, using the secondary boot program (boot.binor ufsboot) to read the files. When the kernel has loaded enough modules to mount the root file system, it unmaps the secondary boot program and continues, using its own resources.

 

9. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.

init

10. The /sbin/init process starts the run control (rc) scripts, which execute a series of other scripts. These scripts (/sbin/rc*) check and mount file systems, start various processes, and perform system maintenance tasks.