Booting the System
Bootstrapping is the process a computer follows to load and execute the bootable operating system. The name is coined from the phrase “pulling yourself up by your bootstraps.” The instructions for the bootstrap procedure are stored in the boot PROM.
The boot process goes through the following phases:
Power On
Before powering on the system, make sure all your connections are secure. Check the SCSI cables that connect any external devices to the system (such as disk drives and tape drives) to make sure they are properly connected. Check your network connection. Also make sure that the keyboard and monitor are connected properly. Loose cables can cause your system to fail during the startup process.
Caution
Always connect your cables before turning on the hardware; otherwise, you could damage your system.
The correct sequence for powering on your equipment is to first turn on any peripherals (that is, external disk drives or tape drives) and then turn on power to the system.
Boot PROM and Program Phases
The bootstrap process begins after power-up when information located in the hardware’s PROM chip is accessed. Sun calls this the OpenBoot firmware, and it is executed immediately after you turn on the system. I cover OpenBoot in detail in Chapter 10, “OpenBoot,” but because it is part of the boot process, I’ll also cover it briefly here.
The primary task of the OpenBoot firmware is to boot the operating system either from a mass storage device or from the network. OpenBoot contains a program called the “monitor,” which controls the operation of the system before the kernel is available. When a system is turned on, the monitor runs a power-on self-test (POST) that checks such things as the hardware and memory on the system. If no errors are found, the automatic boot process begins. OpenBoot contains a set of instructions that locate and start up the system’s boot program and eventually start up the UNIX operating system.
The boot program is stored in a predictable area (sectors 1–15) on the system hard drive, CD-ROM, or other bootable device and is referred to as the bootblock (bootblk). The bootblock is responsible for loading the secondary boot program (ufsboot) into memory, which is located in the ufs file system on the boot device. The path to ufsboot is recorded in the bootblock, which is installed by the Solaris installboot utility.
ufsboot locates and loads the two-part kernel. The kernel consists of a two-piece static core called genunix and unix. genunix is the platform-independent generic kernel file, and unix is the platform-specific kernel file. When the system boots, ufsboot combines these two files into memory to form the running kernel.
The kernel (covered in detail later in this chapter) is the part of the operating system that remains running at all times until the system is shut down.
Kernel Initialization Phase
The OpenBoot PROM automatically issues the boot command if the OpenBoot parameter auto-boot is set to true (the default) and the OpenBoot PROM is not in fully secure mode. (See Chapter 10 for details on how this is set.) The system automatically starts the boot process after power has been turned on, and you do not see the ok prompt. To interrupt the auto-boot process, click Stop+A. The ok prompt appears. Table 9.1 lists the boot command options.
| Option | Description |
|---|---|
| -a | An interactive boot. |
| -r | A reconfiguration boot. |
| -s | Boots into a single-user state. |
| -v | Boots in verbose mode. All system messages are displayed. |
ok boot -v, for example, boots the system in verbose mode, which displays a full listing of system messages during the boot phase. The -v option can be used with other boot options to get verbose output. The default behavior is not to display all system messages during bootup.
The boot program is responsible for loading the UNIX kernel into memory and passing control of the system to it. The boot command must access the OpenBoot parameter boot-device. The alias assigned to the boot device (disk or disk#) tells the boot device where to find the kernel and how to start it up. For example, the alias disk provides the boot path /sbus@1,f8000000 /esp@0,40000/sd@3,0:a.
The boot Command
A noninteractive boot (boot) automatically boots the system using default values for the boot path. Initiate a noninteractive boot by typing the following command from the OpenBoot prompt:
ok boot
The system will boot without requiring more interaction.
An interactive boot (boot -a) stops and asks for input during the boot process. The system provides a dialog box in which it displays the default boot values and gives you the option of changing them. You might want to boot interactively to make a temporary change to the system file or kernel. Booting interactively enables you to test your changes and recove r easily if you have problems.
Exercise 9.1 The Interactive Boot Process
The following output shows an example of an interactive boot session:
ok ok boot -a Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args: -a Enter filename [kernel/sparcv9/unix]: Enter default directory for modules [/platform/SUNW,Ultra-5_10/kernel /platform/sun4u/kernel /kernel /usr/kernel]: Name of system file [etc/system]: SunOS Release 5.9 Version Generic_108621-04 64-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. root filesystem type [ufs]: Enter physical name of root device [/pci@1f,0/pci@1,1/ide@3/disk@0,0:a]: configuring IPv4 interfaces: hme0. configuring IPv6 interfaces: hme0. Hostname: ultra5 The system is coming up. Please wait. checking ufs filesystems /dev/rdsk/c0t0d0s5: is clean. /dev/rdsk/c0t0d0s7: is clean. /dev/rdsk/c0t0d0s6: is clean. Starting IPv6 neighbor discovery. Setting default IPv6 interface for multicast: add net ff00::/8: gateway ultra5 Starting rpc services: rpcbind done. Setting default IPv4 interface for multicast: add net 224.0/4: Print services started. volume management starting. Mar 13 09:21:48 The system is ready. ultra5 console login:
To view more detailed information during the boot process, use the -v option:
ok boot –v
The system responds with more detailed information:
ok boot -v
Resetting ...
Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard
OpenBoot 3.15, 128 MB memory installed, Serial #10642306.
Ethernet address 8:0:20:a2:63:82, Host ID: 80a26382.
Initializing Memory
Rebooting with command: boot -v
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args: -v
SunOS Release 5.9 Version Generic_108621-04 64-bit
Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved.
Ethernet address = 8:0:20:a2:63:82
mem = 131072K (0x8000000)
avail mem = 122306560
root nexus = Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz)
pcipsy0 at root: UPA 0x1f 0x0
pcipsy0 is /pci@1f,0
PCI-device: pci@1,1, simba0
simba0 is /pci@1f,0/pci@1,1
PCI-device: pci@1, simba1
simba1 is /pci@1f,0/pci@1
PCI-device: ide@3, uata0
uata0 is /pci@1f,0/pci@1,1/ide@3
dad0 at pci1095,6460 target 0 lun 0
dad0 is /pci@1f,0/pci@1,1/ide@3/dad@0,0
<ST34321A cyl 8892 alt 2 hd 15 sec 63>
root on /pci@1f,0/pci@1,1/ide@3/disk@0,0:a fstype ufs
PCI-device: ebus@1, ebus0
power0 at ebus0: offset 14,724000
power0 is /pci@1f,0/pci@1,1/ebus@1/power@14,724000
su0 at ebus0: offset 14,3083f8
su0 is /pci@1f,0/pci@1,1/ebus@1/su@14,3083f8
su1 at ebus0: offset 14,3062f8
su1 is /pci@1f,0/pci@1,1/ebus@1/su@14,3062f8
se0 at ebus0: offset 14,400000
se0 is /pci@1f,0/pci@1,1/ebus@1/se@14,400000
cpu0: SUNW,UltraSPARC-IIi (upaid 0 impl 0x12 ver 0x13 clock 270 MHz)
configuring IPv4 interfaces:SUNW,hme0 : PCI IO 2.0 (Rev Id = c1) Found
PCI-device: network@1,1, hme0
hme0 is /pci@1f,0/pci@1,1/network@1,1
hme0.
configuring IPv6 interfaces: hme0.
Hostname: ultra5
dump on /dev/dsk/c0t0d0s1 size 420 MB
SUNW,hme0 : Internal Transceiver Selected.
SUNW,hme0 : Auto-Negotiated 100 Mbps Half-Duplex Link Up
The system is coming up. Please wait.
checking ufs filesystems
/dev/rdsk/c0t0d0s5: is clean.
/dev/rdsk/c0t0d0s7: is clean.
/dev/rdsk/c0t0d0s6: is clean.
Starting IPv6 neighbor discovery.
Setting default IPv6 interface for multicast: add net ff00::/8: gateway ultra5
starting rpc services: rpcbind done.
Setting default IPv4 interface for multicast: add net 224.0/4:
syslog service starting.
Print services started.
Mar 13 11:04:03 unknown pseudo: pseudo-device: tod0
Mar 13 11:04:03 unknown genunix: tod0 is /pseudo/tod@0
Mar 13 11:04:03 unknown pseudo: pseudo-device: pm0
Mar 13 11:04:03 unknown genunix: pm0 is /pseudo/pm@0
Mar 13 11:04:04 unknown simba: PCI-device: SUNW,m64B@2, m640
Mar 13 11:04:04 unknown genunix: m640 is /pci@1f,0/pci@1,1/SUNW,m64B@2
Mar 13 11:04:04 unknown m64: m64#0: 1152x900, 4M mappable, rev 4750.7c
volume management starting.
Mar 13 11:04:06 unknown pseudo: pseudo-device: vol0
Mar 13 11:04:06 unknown genunix: vol0 is /pseudo/vol@0
Mar 13 11:04:07 unknown scsi: sd0 at uata0: target 2 lun 0
Mar 13 11:04:07 unknown genunix: sd0 is /pci@1f,0/pci@1,1/ide@3/sd@2,0
Mar 13 11:04:09 unknown ebus: fd0 at ebus0: offset 14,3023f0
Mar 13 11:04:09 unknown genunix: fd0 is /pci@1f,0/pci@1,1/ebus@1/fdthree@14,3023f0
Mar 13 11:04:15 unknown snmpdx:
The system is ready.
ultra5 console login: If you are not at the system console to watch the boot information, you can use the UNIX dmesg command to redisplay information that was displayed during the boot process, or you can view the information in the /var/adm/ messages file.
To view messages displayed during the boot process, use one of the following methods:
At a UNIX prompt, type /usr/sbin/dmesg and press Enter. The boot messages are displayed.
Note
Several pages of information will be displayed, so I recommend that you pipe the dmesg command to more, as shown here: /usr/sbin/dmesg|more.
At a UNIX prompt, type more /var/adm/messages and press Enter.
System Run States
After the boot command initiates the kernel, it begins several phases of the startup process. The first task is for OpenBoot to load the kernel. As stated, by default, the kernel is named /kernel/unix and is located in the root (/) partition on the disk, with its path defined in an OpenBoot PROM alias named disk.
The kernel consists of a small static core and many dynamically loadable kernel modules. Many kernel modules are loaded automatically at boot time, but for efficiency, others—such as device drivers—are loaded from the disk as needed by the kernel. When the kernel loads, the system reads a file named /etc/system. Parameters in this file control which modules and parameters are to be loaded by the kernel at boot time. Occasionally, kernel parameters in this file need to be adjusted for performance tuning.
Caution
Do not modify the / etc/system file unless you are certain of the results. A good practice is to always make a backup copy of any system file you modify in case the original needs to be restored. Incorrect entries could prevent your system from booting. If a boot process fails because of an unusable /etc/system file, boot the system using the interactive option boot -a. When requested to enter the name of the system file, enter the name of the backup system filename or /dev/null to use all default parameters.
After control of the system is passed to the kernel, the system begins initialization and enters one of eight run states—also called init states—as described in Table 9.2. Because run state 4 is currently not used, only seven usable run states exist.
Note
The difference between run level 1 and run level S,s is that in run level 1, all local file systems are mounted
The init state in which the system is running defines the services and resources available to users. When preparing to perform a system administration task, you need to determine which init state is appropriate for the task. Use Table 10.3 to determine what init state to use for a particular task. A system can run in only one init state at a time.
| Init State | When to Use It |
|---|---|
| 0 | To shut down the system so that it is safe to turn off the power (system administrator state). |
| S,s | Single-user (system administrator) state. This run state is used when the system administrator is performing administrative tasks that require all users to be logged out of the system, such as when performing level 0 backups or repairing file systems. Any function that requires the system administrator to be in single-user mode should be run at this run level. |
| 1 | Single-user (system administrator) state. This run state is used when the system administrator is performing administrative tasks and does not want additional users to log in to the system, such as when performing backups and file system checks on file systems currently not in use by logged-in users. |
| 2 | For normal operations when sharing of local file systems is not required. Multiple users can log in and access all of the file systems. All daemons are running except NFS server. Use this run state when you want to ensure that remote hosts cannot mount local file systems (read more about NFS in Chapter 22, “The NFS Environment”) or when you want the syslogd daemon inactive. |
| 3 | For normal operations, with NFS resource sharing available. This is the normal run state on most systems. |
| 4 | Alternative multiuser state (currently not used). |
| 5 | Power-down state. To shut down the operating system so that it is safe to turn off power to the system. All users are logged off the system, and the operating system services are stopped in an orderly manner. When complete, it’s safe to turn off power to the system and all peripherals. If supported by the system hardware, the power to the system is automatically turned off. |
| 6 | To shut down the system to run level 0 and then reboot to multiuser level (or whatever level is the default in the inittab file). |
To check which run level the system is currently at, type the following:
who –r <cr>
The system will respond with the following:
. run-level 3 Jul 18 18:09 3 0 S
This indicates that the system is currently at run level 3.
Swapper
The first task for the kernel is to start the swapper process. The swapper process is the part of the kernel that schedules all other processes. The swapper has a process ID of 0 and is named sched. Its first job is to start up the init process.
Note
In previous versions of Solaris, this process was called swapper but was renamed to sched in Solaris 8.
Init Phase
The /sbin/init command generates processes to set up the system based on the directions in / etc/inittab. The init process is the parent of all other processes. It examines the contents of the /etc/inittab file to determine the order for starting up other processes and what to do when one of these processes ends. Each entry in the /etc/inittab file has the following fields:
id:runlevel:action:process
Table 9.4 provides a more detailed description of each field.
| Field | Description |
|---|---|
| id | A unique identifier |
| runlevel | The run level |
| action | How the process is to be run |
| process | The name of 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
When the system is first booted, init starts all processes labeled sysinit in the /etc/inittab file. The initdefault entry in /etc/inittab identifies the default run level. In this example, the default is run level 3 (multiuser mode with network file sharing). The init daemon runs each process associated with this run level (that is, each entry that has a 3 in its run-level field). Each process is run using the entry from the action field. The action field can have one of the values listed in Table 9.5.
rc Scripts
Each init state has a corresponding series of run control scripts, referred to as rc scripts and located in the /sbin directory, to control each init state. These rc scripts are as follows:
rc0
rc1
rc2
rc3
rc5
rc6
rcS
Note
Many of the Solaris startup scripts can be identified by their “rc” prefix or suffix, which means “run control.”
The init process executes the /sbin/rc<n> scripts, which in turn execute a series of other scripts located in the /etc directory. For each rc script in the /sbin directory, a corresponding directory named /etc/rc<n>.d 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. At bootup, rc scripts are run in numerical order until the default run level is reached; for example, to get to run level 3, /sbin/rc1, /sbin/rc2, and /sbin/rc3 are run.
All 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<n>.d directories.
Note
Although the scripts appear as files in each directory, the rc<n>.d directories contain hard links to the /etc/init.d directory. On other UNIX systems, startup scripts are sometimes found in /sbin/rc<n>.d and in /etc/rc<n>.d directories. Links were put into Solaris so that users who were accustomed to other flavors of UNIX (HP-UX, SunOS, and so on) could locate the startup files easily. In addition, any scripts they might have ported over that reference these startup files are compatible without modification. Also, by putting all the scripts in one location, /etc/init.d, it’s convenient to find the script needed to start or stop a particular function without searching through all the /etc/rc<n>.d directories.
The following is a list of the default scripts located in /etc/rc2.d that were put there when the operating system was installed. As described later, the system administrator will add customized scripts to this directory:
ls /etc/rc2.d K03samba S05RMTMPFILES S72autoinstall S80spc K03sshd S10lu S72directory S85power K06mipagent S20sysetup S72inetsvc S88sendmail K07dmi S21perf S72slpd S88utmpd K07snmpdx S30sysid.net S73cachefs.daemon S89PRESERVE K16apache S40llc2 S73nfs.client S89bdconfig K21dhcp S42ncakmod S74autofs S90wbem K27boot.server S47pppd S74syslog S92volmgt K28kdc S69inet S74xntpd S93cacheos.finish K28kdc.master S70uucp S75cron S94ncalogd K28nfs.server S71ldap.client S75savecore S95svm.sync README S71rpc S76nscd S99audit S01MOUNTFSYS S71sysid.sys S80lp S99dtlogin
The /etc/rc<n>.d scripts are always run in ASCII sort order. The number following the first letter (S or K) designates the order in which the scripts are run and can be any numeric value. The name following the number does not relate to the order in which they are run. The scripts have names of this form:
[K,S][#][A-Z]
Files beginning with K are run to terminate (kill) a system process. Files beginning with S are run to start a system process. The actions of each run-control-level script are summarized in the following lists.
The / sbin/rc0 script runs the /etc/rc0.d scripts, which do the following:
The / sbin/rcS script runs the / etc/rcS.d scripts to bring the system up to single-user mode and to do the following:
Establish a minimal network
Mount /usr, if necessary
Set the system name
Check the / and /usr file systems
Mount pseudo file 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
Run level init S is similar to run level 1, except that all file systems get mounted and are accessible.
The / sbin/rc1 script runs the / etc/rc1.d scripts and does the following:
Stops system services and daemons except for the most basic OS services
Enables all file systems to be available and allows any logged-in users to remain logged in
Brings the system up in single-user mode
Tip
Use the init S run level to perform system administration tasks when you want to ensure that other users cannot log in and access the system.
The / sbin/rc2 script sets the TIMEZONE variable, runs the /etc/rc2.d scripts, and does the following:
Mounts all file systems
Enables disk quotas if at least one file system was mounted with the quota option
Saves editor temporary files in /usr/preserve
Removes any files in the /tmp directory
Configures system accounting
Configures the default router
Sets the NIS domain
Sets the ifconfig netmask
Reboots the system from the installation media or a boot server if either /.PREINSTALL or /AUTOINSTALL exists
Starts inetd, rpcbind, and named, if appropriate
Starts the Kerberos client-side daemon (kerbd)
Starts NIS daemons (ypbind) and NIS+ daemons (rpc.nisd), if appropriate
Starts keyserv
Starts statd, lockd, xntpd, vold, and utmpd
Mounts all NFS entries
Starts automount
Starts cron
Starts the lp daemons
Starts the sendmail daemon
Starts the name service cache daemon (nscd)
Starts syslog
The /sbin/rc3 script runs the /etc/rc3.d scripts and does the following:
Cleans up sharetab
Starts nfsd
Starts mountd
Starts the master agent, snmpdx, and the Solstice Enterprise Agents
If the system is a boot server, rc3 starts rarpd, rpld, and rpc.bootparamd
The /sbin/rc5 and /sbin/rc6 scripts run the /etc/rc0.d scripts and do the following: