Part III Shutting Down and Booting a System
This part provides instructions for shutting down and booting systems running the Solaris 2.x release.
This part contains these chapters.
Chapter 5 Shutting Down and Booting a System (Overview)
This chapter provides guidelines for shutting down and booting a system. The Solaris 2.x 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
Secondary boot programs--ufsboot and inetboot--have been modified
to read CacheFSTM file systems. This new boot feature allows AutoClient systems to
boot more quickly and with less network traffic.
This new feature is enabled automatically and does not require any administration.
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:
-
Both shutdown and init commands take a run level
as an argument. The three most common run levels are:
-
Run level 3 - Means that 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.
Also known as multiuser level with NFS resources shared.
Run levels are fully described in Chapter 6, Run Levels and Boot Files (Tasks).
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
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
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
See Chapter 8, Booting a SPARC System (Tasks), or Chapter 9, Intel: 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 3 is specified in the /etc/inittab file.
Table 6-1 Solaris Run Levels
|
Run Level
|
Init State
|
Type
|
Use This Level ...
|
|
0
|
Power-down
state
|
Power-down
|
To shut down the operating system so that it is safe to turn off power
to the system.
|
|
1
|
Administrative state
|
Single-user
|
To access all available file systems
with user logins allowed. The terminal from which you issue this command becomes the Console.
|
|
2
|
Multiuser state
|
Multiuser
|
For normal operations. Multiple users can access the system and the entire file system.
All daemons are running except for NFS server and syslog.
|
|
3
|
Multiuser with
NFS resources shared
|
Multiuser
|
For normal operations with NFS resource-sharing available.
|
|
4
|
Alternative multiuser state
|
|
This level is currently unavailable.
|
|
5
|
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.
|
|
6
|
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).
|
|
s or S
|
Single-user state
|
Single-user
|
To run as a single user with all file
systems mounted and accessible.
|
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.
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 Oct 26 15:04 3 0 S
$
|
|
run level 3
|
Identifies the current run
level.
|
|
Oct 26 15:04
|
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:
-
The system's default run level
-
What processes to start, monitor, and restart if they terminate
-
What actions to be taken when the system enters a new run level
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
|
The run level, which corresponds
to the command or (script) to be processed
|
|
action
|
How the process specified in
the process field is to be run
|
|
process
|
The name of the process (or
command) to execute
|
Example--Default inittab File
The following example shows an annotated default inittab file:
[STREAMS module initialization] ap::sysinit:/sbin/autopush -f /etc/iu.ap
[Configures transport providers used by sockets. The sock2path file contains
a socket to transport provider map.] ap::sysinit:/sbin/soconfig -f /etc/sock2path
[File system check] fs::sysinit:/sbin/rcS >/dev/console 2>&1 </dev/console
[Default run level] is:3:initdefault:
[Power fail shutdown] p3:s1234:powerfail:/sbin/shutdown -y -i5 -g0 >/dev/console 2>&1 </dev/console
[Run level 0] s0:0:wait:/sbin/rc0 >/dev/console 2>&1 </dev/console
[Run level 2] s1:1:wait:/sbin/shutdown -y -iS -g0 >/dev/console 2>&1 </dev/console
[Run level 3] s2:23:wait:/sbin/rc2 >/dev/console 2>&1 </dev/console
[Run level 1] s3:3:wait:/sbin/rc3 >/dev/console 2>&1 </dev/console
[Run level 5] s5:5:wait:/sbin/rc5 >/dev/console 2>&1 </dev/console
[Run level 6] s6:6:wait:/sbin/rc6 >/dev/console 2>&1 </dev/console
[Firmware] fw:0:wait:/sbin/uadmin 2 0 >/dev/console 2>&1 </dev/console
[Off] of:5:wait:/sbin/uadmin 2 6 >/dev/console 2>&1 </dev/console
[Reboot] rb:6:wait:/sbin/uadmin 2 1 >/dev/console 2>&1
[Service access controller initialization] sc:234:respawn:/usr/lib/saf/sac -t 300
[Console initialization] co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: "
-T terminal_type -d /dev/console -l console -m ldterm,ttcompat
|
What Happens When the System Is Brought to Run Level 3
-
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.
-
Then init reads the inittab file
to do the following:
-
Identify the initdefault entry, which defines the default run level
(3).
-
Execute any process entries that have sysinit in the action
field so that any special initializations can take place before users login.
-
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/rc2
|
Sets up the time zone, then 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:
-
rc0
-
rc1
-
rc2
-
rc3
-
rc5
-
rc6
-
rcS
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:
[K,S][0-9][0-9][A-Z][0-99]
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/rc*.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
-
Become superuser.
-
Turn off functionality.
# /etc/init.d/filename stop
|
-
Restart functionality.
# /etc/init.d/filename start
|
-
Use the ps and grep commands to verify whether the service
has been stopped or started.
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
# ps -ef | grep nfs
#
|
Restart the NFS services by typing:
# /etc/init.d/nfs.server start
# ps -ef | grep nfs
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
root 1324 1318 11 13:29:52 pts/0 0:00 grep nfs
|
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 rc*.d directory you want
the service to start and stop.
See the README file in each /etc/rc*.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
-
Become superuser.
-
Add the script to the /etc/init.d directory.
# cp filename /etc/init.d
|
-
Create links to the appropriate rc*.d directory.
# cd /etc/init.d
# ln filename /etc/rc2.d/Snnfilename
# ln filename /etc/rcn.d/Knnfilename
|
-
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
-
Become superuser.
-
Rename the script by adding a dot (.) to the beginning of the new file.
# cd /etc/rcn.d
# cp filename .filename
|
-
Verify the script has been renamed.
Example--Disabling a Run Control Script
The following example changes the K00ANNOUNCE script name but saves the original
script.
# cd /etc/rc0.d
# cp K00ANNOUNCE .K00ANNOUNCE
|
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
-
Rebuilds device entries for reconfiguration boots
-
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 ncsd (name service cache daemon)
-
Starts automount, cron, LP, 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 nfsds
-
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 Script
|
Script Name
|
Description
|
|
/sbin/rc5
|
Runs the /etc/rc0.d scripts to perform the following tasks:
|
|
-
Kills the printer and syslog daemons
-
Unmounts local and remote file systems
-
Stops NFS server and client services
-
Stops NIS, RPC, and cron services
-
Kills all active processes and initiates an interactive boot
|
| |
Table 6-10 The
/sbin/rc6 Script
|
Script Name
|
Description
|
|
/sbin/rc6
|
Performs the following tasks:
|
|
-
Runs the /etc/rc0.d/K* scripts to stop system processes
-
Kills all active processes
-
Unmounts the file systems
-
Runs the initdefault entries in the /etc/inittab file
|
Table 6-11 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:
-
Adding or removing hardware
-
Preparing for an expected power outage
-
Performing file system maintenance, such as a backup
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, Intel: Booting a System (Tasks), for instructions on system recovery techniques.
Note -
There is no clean way to bring a system to run level 2 or S from run level 3 (multiuser state with
NFS resources shared). The best way to bring a system to an intermediate run level is to bring the system
to run level 0, and then boot the system to run level S.
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 {0, 1, 2, 3, 6, S, s}
|
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 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
-
Log into the system to be shut down.
-
Display logged-in users with the who command.
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
-
Become superuser.
-
Find out if users are logged into the system.
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.
-
Shut down the system by using the shutdown 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.
|
-
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.
-
Type the superuser password, if prompted.
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): xxx
|
-
After you have finished the system administration tasks, press Control-d to return to the default
run system level.
-
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
In the following example, the shutdown and boot commands are
used to bring a SPARC system to run level S (single-user state) in 3 minutes.
# who
root console May 7 08:35
# shutdown -i0 -g180 -y
Shutdown started. Wed May 7 08:39:17 MDT 1997
Broadcast Message from root (console) on mars Wed May 7 08:39:18
The system will be shut down in 1 minute
Broadcast Message from root (console) on mars Wed May 7 08:39:50
The system will be shut down in 30 seconds
.
.
.
INIT: New run level: 0
The system is coming down. Please wait.
syncing file systems... [7] [7] [5] done
Program terminated
ok boot -s
Booting from: sd(0,0,0) -s
SunOS Release 5.6 Version generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, 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
Entering System Maintenance Mode
#
|
Example--Bringing a SPARC System to Run Level 0
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 May 7 08:28
rimmer pts/1 May 7 08:29 (starbug)
pmorph pts/2 May 7 08:30 (bluemidget)
Send mail message to logged-in users
# shutdown -i0 -g300 -y
Shutdown started. Wed May 7 09:49:01 PDT 1997
Broadcast Message from root (console) on pluto Wed May 7 09:46:58
The system will be shut down in 3 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
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 May 7 08:40
rimmer pts/1 May 7 08:45 (starbug)
pmorph pts/2 May 7 08:50 (bluemidget)
Send mail message to logged-in users
# shutdown -i6 -g120 -y
Shutdown started. Wed May 7 09:52:06 PDT 1997
Broadcast Message from root (console) on pluto Wed May 7 09:46:58
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, Intel: Booting a System (Tasks), for instructions on bringing a system back to a multiuser state.
How to Shut Down a Standalone System
-
Become superuser.
-
Shut down the system by using the init command.
|
run-level
|
Identifies the new run level.
|
-
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 resource shared)
|
hostname console login:
|
hostname console login:
|
Example--Bringing an x86 System to Run Level 0
In the following example, the init command is used to bring an x86 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
In the following example, the init and boot commands are used
to bring a SPARC system to run level S (single-user state).
# init 0
#
INIT: New run level: 0
The system is coming down. Please wait.
.
.
.
syncing file systems... [7] [7] [5] done
Program terminated
ok boot -s
Booting from: sd(0,0,0) -s
SunOS Release 5.6 Version generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: venus
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, Intel: Booting a System (Tasks), for instructions on bringing a system back to a multiuser state.
How to Turn Off Power to All Devices
-
Use the following table to determine which procedure to use for shutting down the system.
-
Turn off power to all devices after the system is shutdown. If necessary, also unplug the power
cables.
-
After power can be restored, use the following steps to turn on the system and devices.
-
Plug in the power cables.
-
Turn on the monitor.
-
Turn on disk drives, tape drives, and printers.
-
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 OpenBoot(TM) 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.
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.
-
Become superuser.
-
Halt the system by using the init command.
The > PROM prompt is displayed.
-
If the > PROM prompt is displayed, type n and press Return.
The ok PROM prompt is displayed.
-
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.
-
Verify the default boot device change by using the printenv command.
-
Save the new boot-device value by using the reset command.
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 IPC, No Keyboard
ROM Rev. 2.9, 12 MB memory installed, Serial #32522.
Ethernet address 8:0:20:b:40:e9, Host ID: 52007f0a.
Testing 1 megs of memory. Still to go 0
Boot device: /sbus/esp@0,800000/sd@3,0 File and args:
.
.
.
pluto console login:
|
SPARC: How to Reset the System
Run the reset command from the ok prompt.
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
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)
-
Boot to run level 3 by using the boot command.
The automatic boot procedure displays a series of startup messages, and brings the system to run
level 3.
-
Verify the system boots to run level 3.
The login prompt is displayed when the boot process has finished successfully.
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 8:0:20:1f:21:be, Host ID: number.
Rebooting with command:
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0
File and args:
SunOS Release 5.6 Version [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: venus
The system is coming up. Please wait.
checking ufs filesystems
/dev/rdsk/c0t3d0s7: is clean.
/dev/rdsk/c0t3d0s5: is clean.
NIS domainname is solar.com
starting rpc services: rpcbind keyserv nis_cachemgr kerbd 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.
volume management starting.
The system is ready.
venus console login:
|
SPARC: How to Boot a System to Run Level S
(Single-User State)
-
Boot the system to run level S by using the boot -s command.
-
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
|
-
Use the who -r command to verify that the system is at run level S.
# who -r
. run-level S May 2 07:39 3 0 S
|
-
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.6 Version [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, 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.6 August 1997
# who -r
. run-level S June 2 07:45 S 0 ?
(Perform some maintenance task)
# Press <Control-d>
|
SPARC: How to Boot a System Interactively
-
Boot the system interactively by using the boot -a command.
-
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.
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.
|
-
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 /kernel /usr/kernel]:
Return
SunOS Release 5.6 Version [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1997, 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).
-
Follow the instructions below depending on whether you are booting from the Solaris 2.x installation
CD or the network.
|
If
You Are Booting From ...
|
Then ...
|
|
Solaris 2.x installation CD
|
1. Insert the Solaris 2.x 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
|
-
Mount the file system that has the file with an invalid entry.
# mount /dev/dsk/device-name /a
|
-
Change to the newly mounted directory.
-
Set the terminal type.
-
Remove the invalid entry from the file using an editor.
-
Change to the root (/) directory.
-
Unmount the /a directory.
-
Reboot the system.
-
Verify the system boots to run level 3.
The login prompt is displayed when the boot process has finished successfully.
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.
-
Type the abort key sequence for your system.
The monitor displays the ok PROM prompt.
-
Use the sync command to synchronize the disks.
-
When you see the syncing file systems... message, press the abort key sequence
for your system again.
-
Type the appropriate boot command to start the boot process.
-
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 command is used to enable this feature. It can be turned on automatically
by editing the /etc/init.d/sysetup script.
The savecore feature and how to set it up is described in Chapter 69, Generating and Saving System Crash Information.
This section only describes how to reboot the system if the savecore feature is enabled.
SPARC: How to Force a Crash Dump and Reboot
the System
-
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.
-
Use the sync command at the ok prompt to synchronize the disk
and write the crash dump.
After the crash dump is written to disk, the system will continue to reboot.
-
Verify the system boots to run level 3.
The login prompt is displayed when the boot process has finished successfully.
SPARC: Example--Forcing a Crash Dump and Rebooting the System
SPARC: How to Boot the System Using the Kernel
Debugger (kadb)
-
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.
-
Use the sync command at the ok prompt to synchronize the disk
and write the crash dump.
-
When you see the syncing file systems... message, press the abort key sequence
for your system again.
-
Boot the system using the kernel debugger.
-
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 Intel: 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: Example--Forcing a Crash Dump and Rebooting 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)
-
Press any key to reboot the system if the system displays the type any key to reboot
prompt. Or, use the reset button to restart the system if the system is shut down.
The Solaris boot option screen is displayed after a few minutes.
-
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.
-
Verify the system boots to run level 3.
The login prompt is displayed when the boot process has finished successfully.
x86: Example--Booting a System to Run Level 3 (Multiuser
State)
type any key to reboot
.
.
.
<<< Current Boot Parameters >>>
Boot path: /isa/ata@1f0,0/cmdk@0,0:a
Boot args:
Type b [file-name] [boot-flags] to boot with options
or i to enter boot interpreter
or 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)
-
Press any key to reboot the system if the system displays the type any key to reboot
prompt. Or, use the reset button to restart the system if the system is shutdown.
The Solaris boot option screen is displayed after a few minutes.
-
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.
-
Type the superuser password, if prompted.
-
Verify the system is at run level S by using the who -r.
# who -r
. run-level S Nov 10 13:59 S 0 3
|
-
Perform the maintenance task that needed the run level change to S.
-
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: /isa/ata@1f0,0/cmdk@0,0:a
Boot args:
Type b [file-name] [boot-flags] to boot with options
or i to enter boot interpreter
or 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
# 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
-
Press any key to reboot the system if the system displays the type any key to reboot
prompt. Or, use the reset button to restart the system if the system is shutdown.
The Solaris Boot Option screen is displayed after a few minutes.
-
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.
-
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, or use the reset button to
restart the system.
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 default boot slice is selected automatically.
|
|
Select (b)oot or (i)nterpreter:
|
Type b -a and press Return.
|
|
Enter filename [kernel/unix]:
|
Provide the name of another kernel to use for booting and press
Return.
Or, press Return to use the default kernel (/platform/i86pc/kernel/unix).
|
|
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.
|
|
Name of 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.
|
|
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.
|
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: /isa/ata@1f0,0/cmdk@0,0:a
Boot args:
Type b [file-name] [boot-flags] to boot with options
or i to enter boot interpreter
or to boot with defaults
<<< timeout in 5 seconds >>>
Select (b)oot or (i)nterpreter: b -a
(Copyright notice)
Enter filename [kernel/unix]:Return
Name of system file [/etc/system]:Return
Name of default directory for modules [platform/i86pc/kernel
/kernel/usr/kernel]:> Return
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.x installation
CD or the network.
-
Boot from the Solaris 2.x 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.
-
Insert the Solaris 2.x installation CD into the CD caddy.
-
Insert the CD caddy into the CD-ROM drive.
-
Insert the Configuration Assistant/Boot Diskette into the primary diskette drive (DOS drive A).
-
Press any key to reboot the system if the system displays the type any key to reboot
prompt. Or, use the reset button to restart the system if the system is shutdown.
The Boot Solaris screen is displayed after a few minutes.
-
Press the F2 key (F2_Continue) at the Solaris Device Configuration Assistant screen.
The identified devices are displayed in the next screen.
-
Press the F2 key (F2_Continue) at the Identified Devices screen.
-
Select the CD-ROM drive or net(work) as the boot device from the Boot Solaris screen. Then press
the F2 key (F2_Boot Solaris).
The Solaris boot option screen is displayed.
-
Type b -s at the Select the type of installation: prompt.
After a few minutes, the single-user mode # prompt is displayed.
-
Mount the root (/) file system that has the invalid passwd
file.
# mount /dev/dsk/devicename /a
|
-
Change to the newly mounted etc directory.
-
Set the terminal type.
# TERM=AT386
# export TERM
|
-
Make the necessary change to the passwd file using an editor.
-
Change to the root (/) directory.
-
Unmount the /a directory.
-
Reboot the system.
-
Verify the system boots to run level 3.
The login prompt is displayed when the boot process has finished successfully.
x86: Example--Booting a System for Recovery Purposes
type any key to reboot
Running Configuration Assistant...
Solaris Device Configuration Assistant
.
.
.
Boot Solaris
Select one of the identified devices to boot Solaris.
> To make a selection, use the arrow keys, then press Enter to mark it [X].
Boot Solaris
--------------------------------------------------------------------
[ ] DISK: IDE(ATA) QUANTUM FIREBALL1080A
target: 0; port: 1F0-1F7, 3F6-3F7; irq: 14
[ ] NET : Intel EtherExpress network card
port: 300-30F; irq: 5
FF2_Boot Solaris F3_Back F4_Boot Tasks F6_Help
<<< Current Boot Parameters >>>
Boot path: /isa/ata@1f0,0/cmdk@0,0:a
Boot args:
Type b [file-name] [boot-flags] to boot with options
or i to enter boot interpreter
or to boot with defaults
<<< timeout in 5 seconds >>>
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
The specific stop key sequence depends on your system type. For example, press the reset button
to stop the system. If your system doesn't have a reset button, turn the power off and back on again.
x86: Forcing a Crash Dump and Rebooting the System
Saving core dumps of the operating system is sometimes necessary for troubleshooting purposes. The savecore command is used to enable this feature. It can be turned on automatically by editing
the /etc/init.d/sysetup script.
The savecore feature and how to set it up is described in Chapter 69, Generating and Saving System Crash Information.
This section only describes how to reboot the system if the savecore feature is enabled.
x86: How to Force a Crash Dump and Reboot the
System
-
Press Control-Alt-d.
The kadb> prompt is displayed.
-
Type 0:c at the kadb> prompt.
-
Type :c at the kadb> prompt.
After the crash dump is written to disk, the system will continue to reboot.
-
Verify the system has rebooted by logging in at the console login prompt.
x86: Example--Forcing a Crash Dump and Rebooting the System
Press <C
ontrol-Alt-d>
kadb> 0:c
kadb> :c
|
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, Intel: 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 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.
|
|
| |
| | | | | | |
|
init Phase
| |
The kernel starts the init process.
| |
| | |
The init process starts the run controls scripts.
|
|
| |
| | |
|
| |
SPARC: The Boot Process Details
Table 10-2 describes the SPARC boot process
illustrated on the previous page.
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.
|
|
init
|
6. The kernel creates a user process and
starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.
|
|
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
Booting an x86 system uses a Solaris Boot Options screen to specify the way in which a system should
be booted.
Additionally, identifying attached devices or booting from the network or a local CD-ROM drive uses
the Configuration Assistant/Boot Diskette.
Table 10-3 describes both interfaces used to
boot all levels on an x86 system.
Table 10-3 x86: x86 Boot Subsystems
|
Boot Subsystem
|
This Subsystem Menu Displays ...
|
|
Configuration Assistant/Boot Diskette
|
Solaris Device Configuration Assistant, identifies device attaches
to the system.
Solaris Boot Screen, presents a list of bootable devices such as disk, network,
or CD-ROM.
|
|
Solaris Boot Option Screen
|
A list of boot options. The system automatically
boots to run level 3 if you don't select an option (after a five-second time out) from this menu. The
other options enable you to specify boot options or enter the boot interpreter (see boot(1M)).
|
During the boot process, the boot subsystem menus display different device and booting options.
If the system receives no response after several time-out periods, it continues to boot automatically
using default selections. You can stop the boot process when the boot subsystem menus are displayed or
let it continue automatically.
The following section provides examples of each subsystem screen. Screen displays will vary based
on system configurations.
x86: Configuration Assistant/Boot Diskette
During the Configuration Assistant phase, the system:
During the Boot phase, the system:
Examples of device configuration during each phase are provided below. Device output will vary based
on each system configuration.
Configuration Assistant Phase
During this phase, the Configuration Assistant attempts to identify devices on the system.
Solaris Device Configuration Assistant
The Solaris(TM) 2.6 (Intel Platform Edition) Device Configuration
Assistant scans to identify the devices on the system, lists
identified devices, and enables you to boot the Solaris software
from a specified device. This program must be used whenever you
install the Solaris operating environment or change the hardware
on the system.
> To perform a full scan and identify all the devices on the system,
choose Continue.
> To perform a partial scan and identify only the automatically
detected devices, choose Partial Scan. (Choose Partial Scan if a
full scan has previously failed.)
F2_Continue F4_Partial Scan F6_Help
|
Scanning Devices Phase
During this phase, all devices connected to the system are scanned.
Scanning Devices
The system is being scanned to identify all devices on the system.
If the scanning stalls, press the system's reset button. When the
system reboots, choose Partial Scan or Help.
Building driver list --
| | | | | |
0 20 40 60 80 100 Please wait ...
|
Identifying Devices Phase
During this phase, all devices connected to the system are identified in this example.
Identified Devices
The following devices have been identified in this system. To
identify devices that on not in this list, choose Device Tasks.
ISA: Bidirectional parallel port
ISA: Floppy disk controller
ISA: IDE controller
ISA: Intel EtherExpress network card
ISA: Motherboard
ISA: PS/2 mouse
ISA: Serial controller
ISA: Serial controller
ISA: System keyboard
ISA: VGA Compatible Display Adapter
F2_Continue F3_Back F4_Device Tasks F5_Boot Solaris
|
Solaris Boot Phase
During this phase, you can select a device from which to boot. Select the Boot Tasks option to change
the default boot device.
Select one of the identified devices to boot Solaris.
> To make a selection, use the arrow keys, then press Enter to mark
it [X].
Boot Solaris
------------------------------------------------------------------
[ ] DISK: IDE(ATA) QUANTUM FIREBALL1080A
target: 0; port: 1F0-1F7, 3F6-3F7; irq: 14
[ ] NET : Intel EtherExpress network card
port: 300-30F; irq: 5
Esc-2_Boot Solaris Esc-3_Back Esc-4_Boot Tasks Esc-6_Help
|
Solaris Boot Options Phase
During this phase, you can boot the system with a specific option or let it boot to run level 3
by default.
<<< Current Boot Parameters >>>
Boot path: /isa/ata@1f0,0/cmdk@0,0:a
Boot args:
Type b [file-name] [boot-flags] to boot with options
or i to enter boot interpreter
or to boot with defaults
<<< timeout in 5 seconds >>>
Select (b)oot or (i)nterpreter:
|
x86: The Boot Process
Table 10-4 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.
|
|
| |
|
bootblk loads ufsboot, the secondary
boot program.
|
| | |
ufsboot reads the /etc/bootrc
script, which 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.
|
|
| |
| | |
|
| |
x86: The Boot Process Details
Table 10-5 describes the x86 boot process illustrated
on the previous page.
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. This step only occurs if there is more than one bootable partition present on
the system.
|
|
6. bootblk finds and executes ufsboot,
the secondary boot program in the root file system.
|
|
7. 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.
|
|
Kernel Initialization
|
8. 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 fsboot
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.
|