Certification Objective 3.01Understanding the Solaris Boot Process

Certification Objective 3.01—Understanding the Solaris Boot Process

Exam Objective 3.1: Given a scenario, explain boot PROM fundamentals, including OpenBoot Architecture Standard, boot PROM, NVRAM, POST, Abort Sequence, and displaying POST to serial port for SPARC.

Exam Objective 3.3: Execute basic boot PROM commands for a SPARC system.

The term booting has its origin in the phrase "pull yourself up by your bootstraps." The physical memory of your computer does not keep the program instructions or data when the system is shutdown. When you just start up your Solaris machine, there is no operating system running on it. The CPU wakes up, and there is nothing for it in the RAM; therefore, it starts by taking instructions from a chip that has the instructions burned in. In other words, each SPARC-based system has a programmable read-only memory (PROM) chip that contains a program called the OpenBoot PROM monitor. The monitor controls the operation of the system before the Solaris kernel is loaded into the memory.

When a system is turned on, the monitor runs a quick self test to check the hardware and memory on the system, called power-on self test (POST). If no errors are found, the system continues the boot process.

The Basic Boot Process

The boot process takes the machine from the point at which the machine is turned on to the point at which the operating system (Solaris in this case) takes over the machine. To understand the boot process, it is important to clearly understand the terms that are explained in the following text.

The Basic Terms

The basic terms involved in the boot process are described here:

• OpenBoot PROM chip. This is a programmable read-only memory (PROM) chip based on the OpenBoot architecture standard. It contains a program called OpenBoot PROM Monitor. Such programs, stored in read-only memory (ROM) or PROM, are also called firmware.

• OpenBoot PROM monitor. The most important job of OpenBoot firmware (OpenBoot PROM monitor) is to boot the system, which is the process of checking the hardware devices and loading and starting the operating system. The boot process is governed by a number of configuration variables that are stored in NVRAM.

• NVRAM. Non-Volatile Random Access Memory (NVRAM) is a chip that stores the system configuration variables whose values determine the startup machine configuration. If you modify the variable values, the modifications will survive across system shutdowns and reboots (or across power cycles). That is why it's called non-volatile. The variables it stores, called NVRAM configuration variables, control the boot process.

• OpenBoot configuration variables. These are the variables that govern the boot process. They are also called NVRAM configuration variables.

• eeprom. This is the utility that Solaris offers to change the values of the OpenBoot configuration variables.

• Power cycle. The power cycle of a machine consists of powering on the machine, booting it, working on it, shutting it down, and turning the power off. The data in RAM does not persist across power cycles.

Now that you can distinguish these terms related to the boot process from each other, let's take a look at the boot process itself.

The Boot Phases

The different phases of the boot process on SPARC-based systems are described here:

• Boot PROM phase. The PROM displays the system identification information and then runs power-on self test (POST), which is a diagnostics routine that scans the system to verify the installed hardware and memory. POST runs diagnostics on hardware devices and builds a device tree, which is a data structure describing the devices attached to the system. After the completion of POST, the PROM loads the primary boot program bootblk.

• Boot programs phase. The bootblk program loaded by PROM finds the secondary boot program ufsboot located in the UFS file system on the default boot device and loads it into the memory.

• Kernel initialization phase. The ufsboot program loads the kernel into the memory. The kernel initializes itself and uses the ufsboot program to locate and load OS modules to control the system. A module is a piece of software with a specific functionality, such as interfacing with a particular hardware device. After loading enough modules to mount the root (/) file system, the kernel umnaps the ufsboot program and continues gaining control of the system. At the end of the kernel initialization phase, the kernel starts the /sbin/init process.

• The init phase. The init phase starts when, after initializing itself, the kernel starts the /sbin/init process, which in turn starts /lib/svc/bin/svc.startd to start the system services to do the following:

  • Check and mount file systems.

  • Configure network and devices.

  • Start various processes and perform tasks related to system maintenance.

The svc.startd process also executes run control (rc) scripts for backward compatibility. The steps in the boot process are illustrated in Figure 3-1.

Figure 3-1: Steps in the boot process

You might ask: how can I control the boot process? The boot process is controlled by the boot configuration variables. If the value of the auto-boot? variable is false, the system will display the Boot PROM prompt: ok. On this prompt you can issue various Boot PROM commands.

Basic Boot PROM Commands

When the system is turned on or reset, it first runs POST, and then one of the following two things can happen:

• The system will automatically reboot if the value of the configuration variable auto-boot? is true, the value of the boot-command variable is boot, and OpenBoot is not in diagnostic mode. In order to boot, the system will automatically load, and executes the program and its arguments specified by the boot-file variable from the device described by the boot-device variable.

• If the configuration variable auto-boot? is false, the system may stop at the OpenBoot user interface without booting the system and will display the ok prompt.

You can issue the Boot PROM commands at the ok prompt. One obvious command is the boot command to boot the system, which you can use in one of the following ways:

• Issue the boot command without any arguments if you want to boot the system from the default boot device using the default boot arguments.

• Issue the boot command with an explicit boot device as an argument if you want to boot the system from the specified boot device using the default boot arguments.

• Issue the boot command with explicit boot arguments if you want to boot the system from the default device by using the specified arguments.

• Issue the boot command with an explicit boot device and with explicit arguments if you want to boot the system from the specified device with the specified arguments.

The general syntax of the boot command is shown here:

    boot [<device>] [<arguments>] 

Arguments and options are described here:

• <device>. Specifies the full path or the alias for the boot device. The typical values are:

  • cdrom for CD-ROM drive

  • disk for hard disk

  • floppy for 3.5 inch diskette drive

  • net for network

  • tape for SCSI tape

• <arguments>. Specify the arguments for the boot command such as the name of the file that contains the program that will be started as a result of the command. The name is relative to the selected device and partition. If this argument is not specified, the boot program uses the value of the NVRAM parameter: boot-file.

In addition to the boot command there are other administrative and diagnostic commands that you can issue at the Boot PROM prompt: ok. The commonly used OpenBoot PROM commands issued from the ok prompt are described in Table 3-1.

Table 3-1: Commonly used OpenBoot PROM commands (do not type ok; it's a command prompt)

Command	Description	Example
ok banner	Displays current power-on banner.	-h
ok boot [<arguments>] [<options>]	Boots the system.	ok boot Boots with default options.
ok .enet-addr	Displays current Ethernet address of the machine.	—
ok .version	Displays the version of the Boot PROM.	—
ok eject <media>	Ejects the media.	ok eject floppy ok eject cdrom ok eject tape
ok help [<category>] ok help [<command>]	The help command without arguments displays a list of command categories, and, with a category as an argument, displays help for all the commands in that category.	ok help dump Displays help for the dump command.
ok password	Sets the security password.	—
ok printenv	Displays a table showing the boot configuration variable names, their current values, and default values.	—
ok reset-all	Resets the system. It's equivalent to performing a power cycle.	—
ok set-default <varName>	Sets the value of the specified variable to its default value.	ok set-default auto-boot?
ok setenv <varName> <value>	Sets the value of a boot configuration variable.	ok auto-boot? false
ok show-devs	Displays the list of all the devices in the OpenBoot device tree.	—
ok test <device>	Tests the specified device. No message displayed means test succeeded.	ok test floppy ok test cdrom ok test /memory ok test tape

You can issue the PROM commands either from the console (most commonly) or from the serial terminal attached to the ttya or ttyb port on a Solaris machine. Table 3-2 presents some useful emergency commands related to booting.

Table 3-2: Emergency commands from keyboard (<key1>-<key2> means hold down both keys at the same time)

Command Hold down the key or keys during power-on sequence	Effect
Stop	Bypass POST.
Stop-A	Abort.
Stop-D	Enter diagnostic mode. Enter this command if your system bypasses POST by default and you don't want it to.
Stop-N	Reset NVRAM content to default values.

You can use the stop-A command to get the Boot PROM command prompt from the running system. You can also use this command to reboot a hung system, as shown in the following exercise. If you only want to allow the Stop-A key combination to work during the boot sequence and you don't want it to work when the system is up and running, uncomment the following line in the /etc/default/kbd file:

    KEYBOARD_ABORT = disable 

Exercise 3-1: Rebooting the Hung System

In order to reboot the hung system and force a crash dump, perform the following steps. This procedure will work even if the system is not hung.

1. Press the stop key sequence for your system. The specific stop key sequence depends on your keyboard type. For example, it could be Stop-A or L1-A. On terminals, press the Break key. The system will go to the PROM phase and display the ok prompt.

2. Synchronize the file systems and write the crash dump.

       > n    ok sync 

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

3. Verify that the system boots to run level 3. The login prompt is displayed when the boot process has finished successfully.

       <login prompt>: 

4. Login as root, and issue the following command to force a crash dump:

       halt -d 

5. At the ok prompt, issue the boot command to boot the system:

       ok boot 

In this exercise, the sync command actually returns control to the OS, which performs the data-saving operation. This is important because the system may have frozen (crashed) without saving the data that was supposed to be saved to the disk.

When a system is booted, a certain number of services are started at the end of the boot process. Which services are started depends on the run level to which the system boots.

Understanding Run Levels

A run level denoted by a digit or a letter represents the state of a system. The Solaris system always runs in one of a set of well'defined run levels. Run levels are also referred to as init states because they are maintained by the init process. The Solaris system has eight run levels described in Table 3-3. The default run level is specified in the /etc/inittab file by the initdefault entry, and its value in the default version of the file is 3. However, note that this value will be used by the init process only if the milestone property has not been specified for the SMF facility svc.startd; otherwise, the default run level specified by the milestone property will be used.

Table 3-3: Solaris run levels

Run Level	Init state	Purpose
0	Power-down	Shut down the operating system so that it will be safe to turn off the power to the machine.
S or s	Single-user	Run the system in a single-user mode with some file systems mounted and accessible.
1	Single-user administrative	Run the system in a single-user administrative mode with all available file systems accessible but user logins disabled.
2	Multiuser	Run the system in multiuser mode. Multiple users can log in, all file systems are accessible, but the NFS daemon is not running.
3	Multiuser with NFS	Run the system in the standard mode: normal operations allowed, NFS used to share resources. Default run level.
4	Alternative multiuser	Unused by default, but you can define it according to your needs.
5	Power-down	Same as run level 0; in addition it will automatically turn off the power if the hardware supports that.
6	Reboot	Shut down the system to run level 0 and then reboot it to the default run level specified in the inittab file.

You can determine the run level in which your system is currently running by issuing the following command:

    who -r 

The output will look like the following:

    run-level 3 Jul 04 11:15 3 2 1 

The parts of this sample output are described here:

• run-level 3. The current run level of the system.

• Jul 04 11:15. Time of last run level change.

• 3. Current run level of the system, same as column one.

• 2. Number of times the system has been at this run level since the last reboot.

• 1. The previous run level.

Different run levels are distinguished from each other by the services or the processes running on the system. When you boot the system or change the run level with the init (or the shutdown) command, the init daemon starts processes by reading information from the /etc/inittab file. This file contains two important pieces of information for the init process: which processes to use to start monitor and restart if they terminate, and what to do if the system enters a new run level. The default inittab file installed with Solaris 10 looks like the following:

 ap::sysinit:/sbin/autopuah -f /etc/iu.ap sp::sysinit:/sbin/soconfig -f /etc/sock2path smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/... 

An entry in the inititab file has the following general syntax:

    id>:<runState>:<action>:<command> 

The colon (:) separated fields are described here:

• <id>. Specifies one to four characters long id used to uniquely identify the entry.

• <runState>. Specifies a list of run levels for which this entry will be processed. If this field is left blank, then the entry is assumed to be valid for all run levels from 0 through 6.

• <action>. Specifies a keyword to tell init how to treat the process specified in this entry. Some of the valid keywords for this field include:

  • boot. The entry will be processed only when the init process reads it at boot-time. The init will start the specified process, will not wait for its termination, and will not restart it if it dies.

  • once. If the process specified in the entry is currently running (exists), do nothing and continue scanning the inittab file. If the process does not already exist, start the process, do not wait for its termination, and do not restart the process when it dies.

  • respawn. If the process specified in the entry is currently running (exists), do nothing and continue scanning the inittab file. If the process does not already exist, start the process, do not wait for its termination, and restart the process when it dies.

  • wait. Start the process and wait for its termination before proceeding further. This will be done only once when the system enters the specified run level, and all the subsequent readings of the inittab file during the time the system is in the same run level will ignore this entry.

  • powerfail. Execute the specified process only if init receives the power fail signal: SIGPWR.

  • sysinit. Execute the specified process before displaying the login prompt. Start the process and wait for its completion before proceeding further. This entry is used only to initialize the devices.

• <command>. Specifies a command to execute a process.

Exam Watch

The initdefault entry is ignored in Solaris 10 if the milestone property for the svc.startd facility has been specified to be used as the default run level. You can use the "svcadm milestone -d" for the functionality similar to modifying the initdefault entry in previous versions of Solaris.

As an example, the fields of an entry in the /etc/inittab file are described in Figure 3-2.

Figure 3-2: Fields of an entry in the /etc/inittab file

The Solaris system normally runs in run level 3. Following is the list of things that happen when the system is brought to run level 3:

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

2. The init process reads the inittab file and does the following:

   • Executes any process entries that have sysinit in the <action> field so that any special initializations can take place before users log in.

   • Passes the startup activities to the svc.startd daemon.

   • The init process initiates the core components of the service management facility, svc.configd and svc.startd, and restarts these components if they fail.

Each run level <n> has a corresponding run control script /sbin/rc<n>:/sbin/rc0 for run level 0, /sbin/rc1 for run level 1, and so on. When the system enters a run level <n>, the init process runs the corresponding /sbin/rc<n> script, which in turn executes the files in the /etc/rc<n>.d directory, which are actually links to files in the /etc/init.d directory. This is illustrated in Figure 3-3.

Figure 3-3: Relationship between run levels and run control scripts

The /etc/rc<n>.d scripts are always run in ASCII sort order. The scripts have names of the form:

    [K|S] [0-9] [0-9]* 

For example, K03samba and S47pppd are two files (actually the links to the files in the /etc/init.d directory) in the /etc/rc2.d directory.

Files that begin with K are run to terminate (kill) a system service, whereas files that begin with S are run to start a system service.

On the Job 

If you want to add a run control script to start or stop a service, copy the script into the /etc/init.d directory and create links in the appropriate rc<n>.d directory corresponding to the run level where you want the service to start or stop.

You can use the init command or the svcadm command to initiate a transition of the system from current run level to another run level. The init command takes a run level as an argument. For example, the following command will transition the system from the current run level to run level 2:

    init 2 

Now you have an overall view of the boot process, and shutting down the system is just changing its run level to 0 or 5. However, as a system administrator, you can have more control over the boot and shutdown procedures that we discuss next.