Starting Up Systems

Starting up systems is an integral part of performing system administration tasks. This section describes procedures for routinely starting up systems. If a system does not start up gracefully, see your system documentation for information on how to diagnose booting problems.

Choosing an Init State

The init state (also called run level) determines what programs are started or initialized when a system is booted. A system can be in only one init state at a time. The Solaris Operating Environment has eight init states; the default init state for each system is specified in the /etc/inittab file. The default init state for the Solaris Operating Environment is run level 3. Table 1 shows the available run levels and the state of the system at each level.

Table 1. System Init States

Init State	Function
0	Firmware state.
S, or s	Single-user state. All file systems mounted.
1	Administrative state. All file systems mounted and user logins allowed.
2	Multiuser state (resources not exported). All daemons are running except the NFS server daemons.
3	Multiuser state. NFS resource-sharing available.
4	Alternative multiuser state (currently unused).
5	Power-down state. Shut down the operating system so that it is safe to turn off power to the system. If possible, turn off power on systems that support this feature.
6	Reboot. Shut down the system to init state 0 and then reboot to the multiuser state defined in the inittab file.

The /sbin/init command is responsible for keeping the system running correctly and is the command you use to change init states. You can also use the init states (with the -i option) as arguments to the shutdown command. The four types of system states are described below.

• Power-down (run level 5).

• Single-user (run levels 1 and s or S).

• Multiuser (run levels 2 and 3).

• Reboot (run level 6).

When preparing to do a system administration task, you need to determine which init state is appropriate for the system and the task at hand.

The /etc/inittab File

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

• The default run level for the system.

• The processes to start, monitor, and restart if they terminate.

• Actions to take when the system enters a new run level.

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

id: rstate: action: process

Table 2 describes the fields in the /etc/inittab file.

Table 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 are listed below.
	respawn	If the process does not exist, start the process. Do not wait for its termination (continue to scan the inittab file), and when the process dies, restart it. If the process currently exists, do nothing and continue scanning the inittab file.
	wait	When init enters the run level that matches the rstate for the entry, start the process and wait for its termination. Ignore all subsequent reads of the inittab file while init is at the same run level.
	once	When init enters a run level that matches the rstate for the entry, start the process and do not wait for its termination. When the process dies, do not restart it. If init enters a new run level and the process is still running from a previous run-level change, do not restart the program.
	boot	Process the entry only at init's boot-time read of the inittab file. init starts the process and does not wait for its termination. When the process dies, init does not restart it. For this instruction to be meaningful, the rstate should either be the default or match init's run level at boot time. This action is useful for an initialization function following a hardware reboot.
	bootwait	Process the entry the first time init goes from single-user to multiuser state after the system is booted. If initdefault is set to 2, run the process right after the boot. init starts the process, waits for its termination, and when it dies, does not restart it.
	powerfail	Execute the process associated with this entry only when init receives a power fail signal, SIGPWR. (See signal(3C).)
	powerwait	Execute the process associated with this entry only when init receives a power fail signal, SIGPWR, and wait until it terminates before continuing any processing of inittab.
	off	When the process associated with this entry is currently running, send the warning signal SIGTERM and wait five seconds before forcibly terminating the process with the kill signal, SIGKILL. If the process is nonexistent, ignore the entry.
	ondemand	A synonym for the respawn action. The functionality is identical to respawn but it has a different keyword to divorce its association from run levels. Use this instruction only with a, b, or c values in the rstate field.
	initdefault	Scan an entry with this action only when init is initially invoked. init uses this entry to determine the initial run level. It takes the highest run level specified in the rstate field and uses that as its initial state. If the rstate field is empty, the value is interpreted as 0123456 and init enters run level 6. This interpretation loops the system (it goes to firmware and reboot continuously). In addition, if init does not find an initdefault entry in inittab, it requests an initial run level from the user at reboot.
	sysinit	Execute entry before init accesses the console (before the Console Login: prompt). Use this entry only to initialize devices that init might try to ask the run-level question. These entries are executed, and init waits for them to complete before continuing.
process	The command to execute.

The following example shows a default /etc/inittab file.

ap::sysinit:/sbin/autopush -f /etc/iu.ap
ap::sysinit:/sbin/soconfig -f /etc/sock2path
fs::sysinit:/sbin/rcS sysinit           >/dev/msglog 2<>/dev/msglog </dev/console
is:3:initdefault:
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/msglog
sS:s:wait:/sbin/rcS                     >/dev/msglog 2<>/dev/msglog </dev/console
s0:0:wait:/sbin/rc0                     >/dev/msglog 2<>/dev/msglog </dev/console
s1:1:respawn:/sbin/rc1                  >/dev/msglog 2<>/dev/msglog </dev/console
s2:23:wait:/sbin/rc2                    >/dev/msglog 2<>/dev/msglog </dev/console
s3:3:wait:/sbin/rc3                     >/dev/msglog 2<>/dev/msglog </dev/console
s5:5:wait:/sbin/rc5                     >/dev/msglog 2<>/dev/msglog </dev/console
s6:6:wait:/sbin/rc6                     >/dev/msglog 2<>/dev/msglog </dev/console
fw:0:wait:/sbin/uadmin 2 0              >/dev/msglog 2<>/dev/msglog </dev/console
of:5:wait:/sbin/uadmin 2 6              >/dev/msglog 2<>/dev/msglog </dev/console
rb:6:wait:/sbin/uadmin 2 1              >/dev/msglog 2<>/dev/msglog </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

Run Control Scripts

The init command uses a different script for each run level instead of grouping all of the run levels together. The files named by a run level are located in the /sbin directory.

The following listing shows the default run control scripts in the /sbin directory.

mopoke% ls -l /sbin/rc*
-rwxr--r--   3 root     sys          2792 Nov 8 2001 /sbin/rc0
-rwxr--r--   1 root     sys          3177 Nov 8 2001 /sbin/rc1
-rwxr--r--   1 root     sys          2922 Nov 8 2001 /sbin/rc2
-rwxr--r--   1 root     sys          2403 Nov 8 2001 /sbin/rc3
-rwxr--r--   3 root     sys          2792 Nov 8 2001 /sbin/rc5
-rwxr--r--   3 root     sys          2792 Nov 8 2001 /sbin/rc6
-rwxr--r--   1 root     sys          9934 Nov 8 2001 /sbin/rcS
mopoke%

Run control files are located in the /etc/init.d directory. These files are linked to corresponding run control files in the /etc/rc*.d directories. The files in the /etc directory define the sequence in which the scripts are performed within each run level. For example, the /etc/rc2.d directory contains files, listed below, that start and stop processes for run level 2.

mopoke% ls /etc/rc2.d
K03samba           S21perf            S73nfs.client       S90wbem
K03sshd            S30sysid.net       S74autofs           S91afbinit
K06mipagent        S40llc2            S74syslog           S91gfbinit
K07dmi             S42ncakmod         S74xntpd            S91ifbinit
K07snmpdx          S47pppd            S75cron             S92volmgt
K16apache          S69inet            S75flashprom        S93cacheos.finish
K21dhcp            S70sckm            S75savecore         S94ncalogd
K27boot.server     S70uucp            S76nscd             S95IIim
K28kdc             S71ldap.client     S77sf880dr          S95svm.sync
K28kdc.master      S71rpc             S80lp               S96ab2mgr
K28nfs.server      S71sysid.sys       S80spc              S98efcode
README             S72autoinstall     S85power            S99audit
S01MOUNTFSYS       S72directory       S88sendmail         S99dtlogin
S05RMTMPFILES      S72inetsvc         S88utmpd
S10lu              S72slpd            S89bdconfig
S20sysetup         S73cachefs.daemon  S89PRESERVE
mopoke%

The scripts are always run in ASCII sort order. The names of the scripts have the form [K, S][0 - 9][A - Z][0 - 99]. Files beginning with K are run to terminate (kill) some system process. Files beginning with S are run to start a system process. The actions of each run-level control script are summarized in the following sections.

The /sbin/rc0 Script

The /sbin/rc0 script performs the following tasks.

• Stop system services and daemons.

• Terminate all running processes.

• Unmount all file systems.

The /sbin/rc1 Script

The /sbin/rc1 script runs the /etc/rc1.d scripts to perform the following tasks.

• Stop system services and daemons.

• Terminate all running processes.

• Unmount all file systems.

• Bring the system up in single-user mode.

The /sbin/rc2 Script

The /sbin/rc2 script runs the /etc/rc2.d scripts to perform the following tasks.

Local system-related tasks:

• Mount all local file systems.

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

• Save editor temporary files in /usr/preserve.

• Remove any files in the /tmp directory.

• Start system activity data collecting, system accounting, and system auditing if configured.

• Start the system logging daemon (syslogd), set the default dump device, and rotate the /var/adm/messages file.

• Set the default scheduling class if the /etc/dispadmin.conf file exists.

• Start LP print service (lpsched) if a local printer is configured and clean up the print queue.

• Configure power management if appropriate.

• Start the utmpd daemon.

• Start cron and vold daemons.

• Configure serial device stream.

• Configure WBEM services.

• Synchronize volumes if required and start the mdmonitord daemon to monitor the physical components of the volumes.

• Start the CDE desktop login process, dtlogin, if appropriate.

Network service and security-related tasks:

• Configure the network interfaces, set ifconfig netmask, and configure network routing if appropriate.

• Start network service (inetd and rpcbind) daemons.

• Set the nameservice domain name, start various nameservice daemons, depending on whether the system is configured for a nameservice and whether the system is a client or a server.

• Start keyserv, statd, lockd, and xntpd daemons if appropriate.

• Start the logical link controller (llc2) if configured.

• Mount all NFS entries.

• Configure the Solaris Network Cache and Accelerator (NCA) and NCA logging if appropriate.

• Start the Solaris PPP server or client daemons (pppoed or pppd) if configured.

• Start LDAP cache manager (ldap_cachemgr) if configured.

• Start directory server (slapd) daemon if configured.

• Start DNS (in.named) daemon if configured.

• Start Service Location Protocol (slpd) daemon if configured.

• Configure system resource controls and system pools if the /etc/rctladm.conf and /etc/pooladm.conf files exist.

• Start the cachefsd, automount, and sendmail daemons if appropriate.

• Start the htt_server process.

Install-related tasks:

• Configure the boot environment for the Live Upgrade software on system startup or system shutdown.

• Check for the presence of the /etc/.UNCONFIGURE file to determine whether to reconfigure the system.

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

Hardware-related tasks:

• Start the Sun Fire 150000 key management daemon (sckmd) if appropriate.

• Start the Sun Fire 880 Dynamic Reconfiguration daemon (sf880drd) if appropriate.

• Run the flash PROM update script.

• Configure any graphic frame buffers or graphic accelerators.

• Run the FCode interpreter daemon (efdaemon) if necessary.

Transition the following services between run-level changes:

• Apache (tomcat).

• Boot server (in.rarpd, rpc.bootparamd, or rpld).

• DHCP (in.dhcpd).

• Kerberos KDC (krb5dc) and Kerberos administration (kadmind).

• Mobile IP (mipagent).

• NFS server (nfsd, mountd, nfslogd).

• Samba (smdb and nmdb).

• Secure shell (sshd).

• Solstice Enterprise Agents (dmispd and snmpXdmid).

The /sbin/rc3 Script

The /sbin/rc3 script runs the /etc/rc3.d scripts to perform the following tasks.

• Start the Apache server daemon (tomcat) if configured.

• Start the DHCP daemon (in.dhcpd) if appropriate.

• Start Kerberos KDC (krb5dc) and Kerberos administration (kadmind) daemons if configured.

• Start Mobile IP daemon (mipagent) if configured.

• Start the Samba daemons (smdb and nmdb) if configured.

• Start the secure shell daemon (sshd) if appropriate.

• Start the Solstice Enterprise Agents (dmispd and snmpXdmid).

• Clean up the /etc/dfs/sharetab file.

• Start the NFS server daemons nfsd, mountd, and nfslogd if appropriate.

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

The /sbin/rc5 and /sbin/rc6 Scripts

The /sbin/rc5 and /sbin/rc6 scripts run the /etc/rc0.d/K* and S* scripts (in that order) to perform the following tasks.

• Kill all active processes.

• Unmount the file systems.

The /sbin/rcS Script

The /sbin/rcS script runs the /etc/rcS.d scripts to bring the system to run level S and perform the following tasks.

• Establish a minimal network.

• Mount /usr if necessary.

• Set the system name.

• Check the root and /usr file systems.

• Mount pseudofile systems (/proc and /dev/fd).

• Rebuild the device entries for reconfiguration boots.

• Check and mount other file systems to be mounted in single-user mode.

Finding the Run Level for a System

To find the run level for a system, type who -r and press Return. The run level, date and time of the last run-level change, process termination status, process exit status, number of times at this run level since the last reboot, and previous run level are displayed.

In the following example, the system named paperbark is at the default multiuser run level (3), the date and time of the last run-level change is May 2 08:34, the process exit status is 3, the number of times at this run level since the last reboot is 0, and the previous run level is S.

paperbark% who -r
   .       run-level 3  May  2 08:34      3      0  S
paperbark%

The next sections describe how you might use each init state.

Using OpenBoot PROM State, Run Level 0

Use run level 0 to shut down the operating system and put the system into OpenBoot PROM (on SPARC systems only).

Using Single-User State, Run Level s and S

Use run level s or S when performing administrative tasks that require you to be the only user on the system with all file systems mounted and accessible. The terminal from which you issue the init s command becomes the console. No other users are logged in.

Using Administrative State, Run Level 1

Use run level 1 as a single user to access all available file systems with no user logins allowed.

Using Multiuser State, Run Level 2

Use run level 2 for normal operations. Multiple users can access the system and the entire file system. All daemons are running except for NFS server and syslog.

Using Remote Resource-Sharing State, Run Level 3

Use run level 3 for normal operations with NFS resource-sharing available.

Using Alternative Multiuser State, Run Level 4

Run level 4 is an alternative multiuser state, currently not used.

Using Power-Down State, Run Level 5

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

Using Reboot State, Run Level 6

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

Changing Run Levels

Use either the telinit or init command to change run levels. The telinit command takes a one-character argument that tells init what run level to use. Although you can use the init command directly, telinit is the preferred command to use to change system run states.

Use the following steps to change run levels.

The following example shuts down the system and places the focus at the OpenBoot PROM prompt (on SPARC systems only).

oak% su
Password:
# telinit 0

The following example changes the system to single-user state.

oak% su
Password:
# telinit 1

The following example changes to multiuser state, with no NFS server daemons running.

oak% su
Password:
# telinit 2

The following example changes to multiuser state, with NFS server daemons running.

oak% su
Password:
# telinit 3

The following example shuts down and reboots a system.

oak% su
Password:
# telinit 6

Using Platform-Specific Booting Protocols

The OpenBoot PROM and Interface (SPARC Platforms)

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

The boot process consists of the boot PROM, boot programs, kernel initialization, and system initialization phases. These phases are summarized in Table 3.

Table 3. Description of the SPARC Boot Process

Boot Phase	Description
OpenBoot PROM	The OpenBoot PROM displays system identification information and then runs self-test diagnostics to verify the hardware and memory of the system. Then, the OpenBoot PROM loads the bootblk primary boot program, which loads the secondary boot program from the default boot device located in the UFS file system.
Boot programs	The bootblk program finds and executes the ufsboot secondary boot program and loads it into memory. After the ufsboot program is loaded, ufsboot loads the kernel.
Kernel initialization	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 terminates the ufsboot program and continues by using its own resources.
	The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.
init	The /sbin/init process starts the run control (/sbin/rc*) scripts, which execute a series of other scripts (/etc/rc*.d/S*). These scripts check and mount file systems, start various processes, and perform system maintenance tasks.

The OpenBoot firmware on the SPARC PROM not only initiates the boot process but also provides a command-line interface. OpenBoot provides two modes. The restricted monitor mode, which displays the > prompt, provides only three commands. These commands enable you to boot the operating system (b specifiers), resume the execution of a halted program (c), or enter the Forth Monitor (n).

The Forth Monitor, also referred to as new command mode, is the default mode of the OpenBoot firmware. The Forth Monitor displays the ok prompt. This monitor enables you to access an extensive set of diagnostic commands for hardware and software. Anyone who has access to the system console can access these functions. To access the restricted monitor, at the ok PROM prompt, type old-mode and press Return.

Displaying the PROM Release for a System

To display the PROM release for a system, at the ok PROM prompt, type banner and press Return. Hardware configuration information, including the release number of the PROM is displayed, as shown in the following example.

ok banner
     Sun Blade 100 (UltraSPARC-IIe, Keyboard Present
     Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
     OpenBoot 4.5, 128 MB memory, installed, Serial #50640486.
     Ethernet address 0:23:ba:4:b6:66, Host ID 8304b666

OpenBoot Configuration Information

OpenBoot configuration parameters are listed in Table 4.

Table 4. Boot Configuration Parameters

auto-boot?	If true, boot automatically after power-on or reset. Default is true.
boot-command
	If auto-boot? is true, execute command. Default is boot.
boot-device
	Device from which to boot. boot-device can contain zero or more device specifiers separated by spaces. Each device specifier can be either a PROM device alias or a PROM device path. The boot PROM tries to open each successive device specifier in the list, beginning with the first device specifier. The first device specifier that opens successfully is used as the device to boot from. Default is disk net.
boot-file	File to boot (an empty string lets the secondary booter choose default). Default is an empty string.
diag-device
	Diagnostic boot source device. Default is net.
diag-file	File from which to boot in diagnostic mode. Default is an empty string.
diag-level	Diagnostics level. Values include min and max. The default value is min. The values off and menus are no longer available.
diag-switch?
	If true, run in diagnostic mode. Default is false.
fcode-debug?
	If true, include name parameter for plug-in device FCodes. Default is false.
input-device
	Input device used at power-on (usually keyboard, ttya, or ttyb). Default is keyboard.
keyboard-click?
	If true, enable keyboard click. Default is false.
keymap	Keymap for custom keyboard. There is no default.
nvramrc	NVRAM startup script. Default is an empty string.
oem-banner	Custom OEM banner (enabled by setting oem-banner? to true). Default is an empty string.
oem-banner?
	If true, use custom OEM banner. Default is false.
output-device
	Output device used at power-on (usually screen, ttya, or ttyb). Default is screen.
sbus-probe-list
	Which SBus slots are probed and in what order. Default system-specific because different SBus systems have different numbers of SBus slots. Newer Sun systems have a PCI bus instead of an SBus.
scsi-initiator-id
	SCSI bus address of host adapter, range 0–7. Default is 7.
security-mode
	Firmware security level (options: none, command, or full). If set to command or full, system prompts for PROM security password. Default is none.
security-password
	Firmware security password (never displayed). Can be set only when security mode is set to command or full.
ttya-mode	TTYA (baud rate, #bits, parity, #stop, handshake). Default is 9600, 8, n, 1, -.
	Fields, in left-to-right order, are described below.
	baud rate	110, 300, 1200, 4800, 9600...
	data bits	5, 6, 7, 8
	parity	n (none), e (even), o (odd), m (mark), s (space)
	stop bits	1, 1.5, 2
	handshake	- (none), h (hardware: rts/cts), s (software: xon/xoff)
ttyb-mode	TTYB (baud rate, #bits, parity, #stop, handshake). Default is 9600, 8, n, 1, -.
	Fields, in left-to-right order, are described below.
	baud rate	110, 300, 1200, 4800, 9600...
	data bits	5, 6, 7, 8
	stop bits	1, 1.5, 2
	parity	n (none), e (even), o (odd), m (mark), s (space)
	handshake	- (none), h (hardware: rts/cts), s (software: xon/xoff)
ttya-ignore-cd
	If true, operating system ignores carrier-detect on TTYA. Default is true.
ttyb-ignore-cd
	If true, operating system ignores carrier-detect on TTYB. Default is true.
ttya-rts-dtr-off
	If true, operating system does not assert DTR and RTS on TTYA. Default is false.
ttyb-rts-dtr-off
	If true, operating system does not assert DTR and RTS on TTYB. Default is false.
use-nvramrc?
	If true, execute commands in nvramrc during system start-up. Default is false.
version2?	If true, hybrid (1.x/2.x) PROM comes up in version 2.x. Default is true.
watchdog-reboot?
	If true, reboot after watchdog reset. Default is false.

You can display and set the list of OpenBoot commands from Solaris by using the eeprom command or display the list at the ok PROM prompt by typing printenv and pressing Return.

The following example uses the eeprom command without arguments to display the current settings.

mopoke% eeprom
test-args: data not available.
diag-passes=1
pci-probe-list=7,c,3,8,d,13,5
local-mac-address?=false
fcode-debug?=false
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
silent-mode?=false
scsi-initiator-id=7
oem-logo: data not available.
oem-logo?=false
oem-banner: data not available.
oem-banner?=false
ansi-terminal?=true
screen-#columns=80
screen-#rows=34
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
output-device=screen
input-device=keyboard
load-base=16384
auto-boot?=true
boot-command=boot
diag-file: data not available.
diag-device=disk net
boot-file: data not available.
boot-device=disk:a disk net
use-nvramrc?=false
nvramrc: data not available.
security-mode=none
security-password: data not available.
security-#badlogins=0
diag-script=none
diag-level=max
diag-switch?=false
error-reset-recovery=boot
mopoke%

The following example sets the method for setting the auto-boot? parameter to true. You may need to enclose the command in double quotation marks to prevent the shell from interpreting the question mark.

# eeprom "auto-boot?"=true
#

Alternatively, you can precede the question mark with an escape character (\) to prevent the shell from interpreting the question mark.

Commands Used to View or Modify Configuration Variables

Table 5 describes the commands you can use from the ok PROM prompt to view or modify the OpenBoot configuration variables.

Table 5. Commands to View or Modify OpenBoot Configuration Variables

Command	Description
help [category]	Display a list of help categories. Help for an individual category is displayed if you specify a category argument.
printenv [variable]	Display the variable, the current value, and the default value. If you specify a variable, the values for that variable are displayed.
setenv variable value	Set variable to the specified numeric or text value. Changes are permanent but often do not take effect until after you reset or reboot the system.
set-default variable	Reset the value of the variable to the factory default.
set-defaults	Reset all variable values to the factory defaults.
password	Set security password.

OpenBoot Firmware Security Levels

The OpenBoot firmware provides three levels of system security: none, command, and full.

For the none security level, no password is required. Users can change all OpenBoot settings, including the boot disk partition and execute any command. By default, Sun systems are shipped with the OpenBoot security level set to none.

For the command security level, a password is required for all commands except boot and go (continue system operation after a Stop-A, L1-A, or Break sequence).

For the full security level, a password is required for all OpenBoot commands except go.

You can set the OpenBoot security level either while running Solaris or from the ok PROM prompt.

Use the following steps to set the OpenBoot security level from Solaris.

In the following example, the security level is set to command.

paperbark% su
Password:
# eeprom security-mode=command

To set the OpenBoot security level, at the ok PROM prompt, type security-mode=level and press Return.

In the following example, the security level is set to full.

ok security-mode=full

For more information, refer to the eeprom(1M) manual page or to the OpenBoot documentation available from Sun Microsystems.

The PC BIOS (IA Platforms)

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

Hardware adapters can have an onboard BIOS that displays the physical characteristics of the device and that can be used to access the device. During the startup sequence, the PC BIOS checks for the presence of an adapter BIOS and, if it finds one or more, loads and executes each one. The BIOS for each individual adapter runs self-test diagnostics and displays device information.

Boot Subsystems

You can make the choices about booting a system at three times during the Solaris IA boot process, as described below.

• Primary Boot Subsystem (Partition Boot Menu)— This first menu is displayed if multiple bootable fdisk partitions exist on the disk. The menu enables you to boot from one of the fdisk partitions. By default, the active partition is booted if you take no action. Note that if you boot a non-Solaris partition, the next two menus are never displayed.

• Interrupt the Autoboot Process— If you interrupt the autoboot process, you can access the Configuration Assistant, which enables you to boot the Solaris Operating Environment from a different boot device, configure new or misconfigured hardware, or perform other device- or boot-related tasks.

• Current Boot Parameters Menu— This menu has two forms, one for a normal Solaris boot and one for a Solaris installation boot.

  • The normal Current Boot Parameters menu enables you to boot the Solaris system with options or to enter the boot interpreter.

  • The install Current Boot Parameters menu enables you to choose the type of installation to be performed or to customize the boot.

Table 6 describes the IA Platform boot subsystems.

Table 6. IA Platform Boot Subsystems

Boot Subsystem	Description
Primary Boot Subsystem	This menu is displayed 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 is displayed each time you boot the Solaris Operating Environment. The Solaris Operating Environment is booted automatically unless you interrupt it to run the Solaris Device Configuration Assistant.
Solaris Device Configuration Assistant/Boot Diskette	You can access the Solaris Device Configuration Assistant menu by using the Solaris Device Configuration Assistant Boot Diskette to boot the system or by interrupting the autoboot process when booting the Solaris Operating Environment from an installed disk.
Current Boot Parameters Menu	This menu is displayed 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.

When booting an IA platform, the Configuration Assistant performs the following tasks during the device identification phase.

• Scans for devices installed on the system.

• Displays the identified devices.

• Enables you to perform optional tasks such as choosing a keyboard type and editing devices and their resources.

During the boot phase, the system displays a list of devices from which to boot. The asterisk (*) marks the default boot device. You can perform optional tasks, such as editing autoboot and property settings.

The boot process consists of the BIOS, boot programs, kernel initialization, and system initialization phases. These phases are summarized in Table 7.

Table 7. Description of the IA Boot Process

Boot Phase	Description
BIOS	When the system is turned on, the PC BIOS runs self-test diagnostics to verify the hardware and memory on the system. If the BIOS finds no errors, the system begins to boot automatically. If errors are found, error messages are displayed describing recovery options. BIOS for additional hardware devices are run. The BIOS boot program tries to read the first physical sector from the boot diskette or hard drive. This first disk sector contains the mboot master boot record, which is loaded and executed. If BIOS finds no mboot program, an error message is displayed.
Boot programs	The mboot program contains disk information needed to find the active partition and the location of the pboot Solaris boot program. mboot loads and executes pboot. pboot loads bootblk, which is the primary boot program. bootblk loads the secondary boot program located in the UFS file system. If the disk has 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 during which you can choose an alternative partition from which to boot. This step occurs only if more than one bootable partition is present on the system. bootblk finds and executes either the boot.bin or ufsboot secondary boot program in the root file system. At this point, you have a 5-second timeout interval during which you can interrupt the autoboot to start the Configuration Assistant. 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 during which you can specify a boot option or start the boot interpreter.
Kernel initialization	The kernel initializes itself and begins loading modules, using boot.bin or ufsboot to read the files. When the kernel has loaded enough modules to mount the root file system, it terminates the secondary boot program and continues by using its own resources. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.
init	The /sbin/init process starts the run control (/sbin/rc*) scripts, which execute a series of other scripts (/etc/rc*.d/S*). These scripts check and mount file systems, start various processes, and perform system maintenance tasks.

Booting a System

If a system is powered off, turning it on starts the multiuser boot sequence. The following procedures tell you how to boot in different states from the ok PROM prompt. If the PROM prompt is >, type n to display the ok prompt, and then follow the appropriate steps.

Table 8 describes commands for booting a system for different reboot reasons.

Table 8. Commands for Booting a System

Reboot Reason	Boot Instructions
Turning off system power because of anticipated power outage.	Turn on system power.
Changing kernel parameters in the /etc/system file.	Reboot to run level 3 (multiuser mode with NFS resources shared) (boot). See "Booting in Multiuser State" on page 34 for more information.
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.
Repairing a system configuration file such as /etc/system.	Interactive boot (boot -a). See "Booting Interactively" on page 34 for more information.
Changing pseudodevice parameters in the /etc/system file.	Reconfiguration boot (boot -r). See "Booting After Adding New Hardware" on page 36 for more information.
Adding or removing hardware from the system.	Reconfiguration boot (boot -r) plus turning on system power after adding or removing hardware. See "Booting After Adding New Hardware" on page 36 for more information.
Booting the kernel debugger to track down a system problem.	Boot kadb. See "Booting the System with the Kernel Debugger" on page 38.
Repairing an important system file that is causing system boot failure.	Recovery boot (SPARC platform, sync; IA platform, kadb). See "Booting a System for Recovery Purposes (SPARC Platform) and "Booting a System for Recovery Purposes (IA Platform)" on page 39.
Recovering from a hung system and forcing a crash dump.	Recovery boot (SPARC platform, sync; IA platform, kadb). See "Booting a System for Recovery Purposes (SPARC Platform)" on page 38 and "Booting a System for Recovery Purposes (IA Platform)" on page 39.

Booting in Multiuser State

To boot in multiuser state, at the ok PROM prompt, type boot and press Return. The automatic boot procedure starts on the default drive, displaying a series of start-up messages. The system is brought up in multiuser state.

Booting in Single-User State

To boot in single-user state, at the ok PROM prompt, type boot -s and press Return. The system boots to single-user state and prompts you for the root password.

ok boot -s

INIT: SINGLE USER MODE
Type Ctrl-d to proceed with normal start-up,
(or give root password for system maintenance)
Type the root password and press Return.

Booting Interactively

You may boot interactively if you want to make a temporary change to the system file or the kernel. In this way, you can test your changes and recover easily if you have any problems.

In the following example, the user accepted the default choices (shown in square brackets []) by pressing Return.

ok boot -a
(Hardware configuration messages)
rebooting from -a
Boot device: /sbus/esp@0,800000/sd@0,0 File and args: -a
Enter filename [/kernel/unix]:
Enter default directory for modules [/platform/SUNW,Ultra-2/kernel
 /platform/sun4u/kernel /kernel /usr/kernel]:
Name of system file [/etc/system]:
(Copyright notice)
root filesystem type [ufs]
Enter physical name of root device
[/sbus@if,0/SUNW,fas@e,8800000/sd@0.0:a]:
Swap filesystem type [swapfs]
Configuring IPv4 interfaces:  le0
Hostname: paperbark
The system is coming up. Please wait.
(fsck messages)
(Startup messages)
paperbark login:

Looking at the Boot Messages

The most recent boot messages are stored in the /var/adm/messages file. To see these messages after you have booted the system, type more/var/adm/messages and press Return. The /usr/sbin/dmesg command is obsolete; however, you can still use it to display boot messages.

Because the /var/adm/messages file is maintained in chronological order, the most current boot messages are at the end of the file. The following example shows the last 30 lines of the /var/adm/messages file.

paperbark% tail -30 /var/adm/messages
Mar  7 18:11:15 paperbark swapgeneric: [ID 308332 kern.info] root on
 /sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a fstype ufs
Mar  7 18:11:16 paperbark sbus: [ID 349649 kern.info] zs0 at sbus0: SBus0 slot
 0xf offset 0x1100000 Onboard device sparc9 ipl 12
Mar  7 18:11:16 paperbark genunix: [ID 936769 kern.info]  zs0 is
 /sbus@1f,0/zs@f,1100000
Mar  7 18:11:16 paperbark sbus: [ID 349649 kern.info] zs1 at sbus0: SBus0 slot
 0xf offset 0x1000000 Onboard device sparc9 ipl 12
Mar  7 18:11:16 paperbark genunix: [ID 936769 kern.info] zs1 is
 /sbus@1f,0/zs@f,1000000
Mar  7 18:11:19 paperbark rootnex: [ID 349649 kern.info] ffb0 at root: UPA
 0x1e 0x0
Mar  7 18:11:19 paperbark genunix: [ID 936769 kern.info] ffb0 is
 /SUNW,ffb@1e,0
Mar  7 18:11:19 paperbark unix: [ID 987524 kern.info] cpu0: SUNW,UltraSPARC
 (upaid 0 impl 0x10 ver 0x22 clock 168 MHz)
Mar  7 18:11:22 paperbark hme: [ID 517527 kern.info] SUNW,hme0 : Sbus (Rev Id 
 = 22) Found
Mar  7 18:11:22 paperbark sbus: [ID 349649 kern.info] hme0 at sbus0: SBus0
 slot 0xe offset 0x8c00000 and slot 0xe offset 0x8c02000 and slot 0xe offset
 0x8c04000 and slot 0xe offset 0x8c06000 and slot 0xe offset 0x8c07000
 Onboard device sparc9 ipl 6
Mar  7 18:11:22 paperbark genunix: [ID 936769 kern.info] hme0 is
 /sbus@1f,0/SUNW,hme@e,8c00000
Mar  7 18:11:24 paperbark genunix: [ID 454863 kern.info] dump on
 /dev/dsk/c0t0d0s1 size 512 MB
Mar  7 18:11:26 paperbark hme: [ID 517527 kern.info] SUNW,hme0 : Internal
 Transceiver Selected.
Mar  7 18:11:26 paperbark hme: [ID 517527 kern.info] SUNW,hme0 :
 Auto-Negotiated   10 Mbps Half-Duplex Link Up
Mar  7 18:12:01 paperbark pseudo: [ID 129642 kern.info] pseudo-device: pm0
Mar  7 18:12:01 paperbark genunix: [ID 936769 kern.info] pm0 is /pseudo/pm@0
Mar  7 18:12:01 paperbark pseudo: [ID 129642 kern.info] pseudo-device: tod0
Mar  7 18:12:01 paperbark genunix: [ID 936769 kern.info] tod0 is /pseudo/tod@0
Mar  7 18:12:02 paperbark sendmail[250]: [ID 702911 mail.crit] My unqualified
 host name (paperbark) unknown; sleeping for retry
Mar  7 18:12:03 paperbark pseudo: [ID 129642 kern.info] pseudo-device:
 devinfo0
Mar  7 18:12:03 paperbark genunix: [ID 936769 kern.info] devinfo0 is
 /pseudo/devinfo@0
Mar  7 18:12:06 paperbark sws.smc[290]: [ID 987397 daemon.notice] [1 admin.195
 0 (SW) NOTICE]: Running with SWS Configuration file
 "/etc/ehttp/server.conf".
Mar  7 18:12:10 paperbark sws.smc[290]: [ID 409041 daemon.error] [1
 servlet.353 0 (SW) ERR]: Servlet smc load error.
Mar  7 18:12:10 paperbark sws.smc[290]: [ID 420037 daemon.notice] [1
 servlet.919 0 (SW) NOTICE]: Servlet Engine (with JSDK2.0) started.
Mar  7 18:12:10 paperbark sws.smc[290]: [ID 111395 daemon.notice] [1 httpd.105
 0 (SW) NOTICE]: Sun_WebServer/2.1 server started.
Mar  7 18:12:15 paperbark sws.smc[290]: [ID 329940 daemon.notice] [1 httpd.135
 0 (SW) NOTICE]: Shutting down server.
Mar  7 18:12:18 paperbark sws.smc[368]: [ID 987397 daemon.notice] [1 admin.195
 0 (SW) NOTICE]: Running with SWS Configuration file
 "/etc/ehttp/server.conf".
Mar  7 18:12:19 paperbark sws.smc[368]: [ID 420037 daemon.notice] [1
 servlet.919 0 (SW) NOTICE]: Servlet Engine (with JSDK2.0) started.
Mar  7 18:12:19 paperbark sws.smc[368]: [ID 111395 daemon.notice] [1 httpd.105
 0 (SW) NOTICE]: Sun_WebServer/2.1 server started.
Mar  7 18:13:02 paperbark sendmail[250]: [ID 702911 mail.alert] unable to
 qualify my own domain name (paperbark) -- using short name
paperbark%

Booting After Adding New Hardware

A reconfiguration boot tells the system to probe for all connected devices and build the names for them in the /devices and /dev directories. Adding new devices to a system formerly required a complete reconfiguration boot.

With the Solaris 8 release, the devfsadm command manages the special device files in the /dev and /devices directories. The new devfsadmd daemon handles both processing of reconfiguration boot and updating of the /dev and /devices directories and responds to dynamic reconfiguration events. Because devfsadmd automatically detects device configuration changes generated by any reconfiguration event, you no longer need to perform a reconfiguration boot (boot -r) when you add most new hardware to a system. Some device addition and removal scenarios may still require you to perform a reconfiguration boot. For example, adding a USB Zip Drive requires a boot -r before the system can recognize the device. See Chapter 8, "Administering Devices," for more information.

With the OpenBoot PROM, you can use the -r option to the boot command so that the operating system knows to look for new device drivers and incorporate them as part of the boot process.

Alternatively, if you add another device with the driver already installed, you can use the following commands to tell the system to recognize the new device.

# touch /reconfigure
# _INIT_RECONFIG=YES /etc/init.d/drvconfig
# _INIT_RECONFIG=YES /etc/init.d/devlinks

Forcing a Crash Dump and Rebooting the System

Sometimes you need to save crash dumps of the operating system. Starting with the Solaris 7 Operating Environment, saving crash dumps is enabled by default.

Starting with the Solaris 8 Operating Environment, the halt command provides a -d option that enables you to force a crash dump before stopping the system.

dumping to /dev/dsk/c1t0d0s1 offset 107479040, content: kernel.
100% done: 11207 pages dumped, compression ratio 2.95, dump succeeded
Program terminated

Dumps are compressed to improve performance and to fit more information into existing swap partitions.

Typing the dumpadm command with no arguments shows the current settings, as shown in the following example.

mopoke% su
Password:
# dumpadm
      Dump content: kernel pages
       Dump device: /dev/dsk/c1t0d0s1 (swap)
Savecore directory: /var/crash/mopoke
  Savecore enabled: yes
#

Refer to the dumpadm(1M) manual page for more information.

The savecore(1M) command works with alternative kernels. In the past, the symbol table was generated from the currently installed kernel. The symbol table is now part of the dump. Before this change, if you patched the Solaris kernel and then crashed before you rebooted the system, the crash dump was useless because the symbol table generated was from the patched kernel, not the running kernel.

savecore supports large files because the file it writes can be greater than 2 Gbytes.

Administering Crash Dumps

You can administer the crash dump facility with the dumpadm(1M) command, which provides the following capabilities.

• Turn on or off saving crash dumps.

• Set up a dedicated dump device (raw partition) or swap entry. The default is the best swap partition.

• Change directory where savecore(1M) puts its files. The default is /var/crash/hostname.

• Dump all memory or only kernel pages. The default is kernel.

Booting the System with the Kernel Debugger

Use the following steps to boot the system by using the kernel debugger.

Refer to the kadb(1M) manual page for information about how to use the kernel debugger.

Booting a System for Recovery Purposes (SPARC Platform)

Use the following procedure on SPARC platforms when the boot process fails. The boot process can fail, for example, when an important file such as /etc/passwd has an invalid entry.

The following example shows how to repair the /etc/passwd file after booting from a local CD-ROM.

ok boot cdrom -s
(Boot messages are displayed here)
# mount /dev/dsk/c0t3d0s0 /a
# cd /a/etc
# TERM=sun;export TERM
# vi passwd
(Remove or edit invalid entry)
# cd /
# umount /a
# init 6

Booting a System for Recovery Purposes (IA Platform)

Use the following procedure on IA platforms when the boot process fails. The boot process can fail, for example, when an important file such as /etc/passwd has an invalid entry.

The following example shows how to repair the /etc/passwd file after you boot from a local CD-ROM.

Type any key to reboot
SunOS Secondary Boot version 3.00
Solaris Intel Platform Edition Booting System
Running Configuration Assistant...
Autobooting from Boot path: /pci@0,0/pci-ide@7,1/ide@0/cmdk@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].
[ ]  NET : DEC 21142/21143 Fast Ethernet
on Board PCI at Dev 3
[ ]  DISK: (*) Target 0, QUANTUM  FIREBALL1280A
on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1
[ ]  DISK: Target 1:ST5660A
on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1
[ ]  DISK: Target 0:Maxtor 9 0680D4
on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1
[ ] CD : Target 1:TOSHIBA CD-ROM XM-5602B 1546
on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1
F2_Continue F3_Back F4_Boot Tasks F6_Help
      .
      .
      .
             <<< Current Boot Parameters >>>
Boot path: /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0:a
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: b -s
      .
      .
      .
# mount /dev/dsk/c0t0d0s0 /a
      .
      .
      .
# cd /a/etc
# vi passwd
(Remove invalid entry)
# cd /
# umount /a
# init 6

Aborting a Booting Process

Occasionally, you may need to abort the booting process. The specific abort key sequence depends on your keyboard type. For example, on SPARC systems with a Sun keyboard, you might press Stop-A or L1-A. On TTY terminals, press the Break key.

To abort the booting process, type the abort key sequence for your system. When you abort the boot process, the monitor displays the ok PROM prompt.

ok

Type boot and press Return to restart the boot process, or type help and press Return to display a list of help options. If your terminal shows the > monitor prompt, type n to get the ok prompt.

Shutting Down a System

The following sections describe how to choose a shutdown and use it and init commands to shut down a system.

The Solaris Operating Environment is designed to be left running continuously so that the e-mail and network software can work correctly. You must, however, halt or shut down a system when performing the following tasks.

• Turning off system power.

• Installing a new release.

• Preparing for a power outage.

• Adding hardware to a system.

• Performing maintenance on a file system.

Choosing Which Shutdown Command to Use

When preparing to do a system administration task, you need to determine which shutdown command is appropriate for the system and the task at hand. The next sections describe how you might use each of the available shutdown commands.

• /usr/sbin/shutdown

• /etc/telinit and /sbin/init

• /usr/sbin/halt

• /usr/sbin/reboot

• /usr/sbin/uadmin

These commands initiate shutdown procedures, kill all running processes, write out any new data to the disk, and shut down the Solaris Operating Environment to the appropriate run level.

shutdown

Use the shutdown command when shutting down a system with multiple users. The shutdown command sends a warning message to all users who are logged in, waits 60 seconds (the default), and then shuts down the system to single-user state. You can choose a different default wait time.

telinit and init

Use the telinit or init command to shut down a single-user system or to change its run level. The init command changes the run level of the system. The telinit command tells init what run level you want. You can use the commands interchangeably, but telinit is the preferred command. You can use telinit to place the system in power-down state (init 0) or in single-user state (init 1).

halt

Use the halt command when the system must be stopped immediately and it is acceptable not to warn any current users. The halt command shuts down the system without any delay and does not warn any other users on the system. The halt command does not run the rc shutdown scripts and is not the preferred method for shutting down a system.

reboot

Use the reboot command to shut down a system that does not have multiple users and to bring it back into multiuser state. The reboot command does not warn users on the system, does not run the rc scripts, and is not the preferred method for shutting down a system.

Shutting Down a Multiuser System

Before shutting down a multiuser system, inform the other users on the system and give them time to complete critical procedures such as saving changes.

paperbark% su
Password:
# cd /
# shutdown

Shutdown started.    Tue May  2 13:16:57 WST 2000

Broadcast Message from root (pts/7) on paperbark Tue May 2 13:16:59...
The system paperbark will be shut down in 1 minute

Broadcast Message from root (pts/7) on paperbark Tue May 2 13:17:29...
The system paperbark will be shut down in 30 seconds

Do you want to continue? (y or n): y
Broadcast Message from root (pts/7) on paperbark Tue May 2 13:17:53...
THE SYSTEM paperbark IS BEING SHUT DOWN NOW! ! !
LOG OFF NOW OR RISK YOUR FILES BEING DAMAGED
(Shutdown messages)

INIT: SINGLE USER MODE
Type control-d to proceed with normal startup,
(or give root password for system maintenance):

Shutting Down a System: Alternative Ways

To change the default actions of the shutdown command, choose one of the tasks in the following six sections.

Shutting Down a System Without Confirmation

Use the following steps to shut down a system without confirmation.

Changing the Shutdown Grace Period

The default is for the shutdown command to provide a 60-second grace period to enable users to save their changes. Use the following steps to change the shutdown 60-second grace period.

The following example changes the grace period to 120 seconds.

# cd /
# shutdown -g120

Shutting Down and Rebooting a Multiuser System

Use the following steps to shut down and reboot a multiuser system.

Shutting Down a Single-User System

To shut down a single-user system, type telinit 0 (or init 0) and press Return. The init command runs scripts that bring the system down cleanly. No warning messages are broadcast.

Shutting Down and Rebooting a Single-User System

To shut down and reboot a single-user system, type telinit 6 (or init 6) and press Return. Information is written to the disk, all active processes are killed, and the system is brought to a power-down state. The system is then rebooted to the default level (usually multiuser).

Shutting Down a System in a Hurry

To shut down a system in a hurry, type uadmin 2 0 and press Return. The system displays the OpenBoot PROM prompt.