Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Solaris Startup and Shutdown

The normal Unix boot process has these main phases:

• Basic hardware detection (memory, disk, keyboard, mouse, and the like) and executing the firmware system initialization program .  In Solaris this is called Boot PROM phase—After you turn on power to the system, the PROM displays system identification information and runs self-test diagnostics to verify the system's hardware and memory. PROM chip contains Forth OpenBoot firmware, and it is executed immediately after you turn on the system. 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 that 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.
   

• Locating and running the initial boot program (IPL or bootloader) from a predetermined location on the disk (MBR in PC). In Solaris the primary boot program, called bootblk, is loaded from its location on the boot device (usually disk) into memory.
   

• Locating and starting the Unix kernel. The kernel image file to execute may be determined automatically or via input to the bootloader. In Solaris the bootblk program finds and executes the secondary boot program (called ufsboot) from the Unix file system (UFS) and loads it into memory. After the ufsboot program is loaded, the ufsboot program loads the two-part kernel.
   

• The kernel initializes itself and then performs final, high-level hardware checks, loading device drivers and/or kernel modules as required.  In Solaris the kernel initializes itself and begins loading modules, using ufsboot to read the files. When the kernel has loaded enough modules to mount the root file system, it unmaps the ufsboot program and continues, using its own resources.
   

• The kernel starts the init process, which in turn starts system processes (daemons) and initializes all active subsystems. When everything is ready, the system begins accepting user logins. In Solaris kernel starts the Unix operating system, mounts the necessary file systems, and runs /sbin/init to bring the system to the initdefault state specified in /etc/inittab. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file. The /sbin/init process starts the run control (rc) scripts, which execute a series of other scripts. These scripts (/sbin/rc*) check and mount file systems, start various processes, and perform system maintenance tasks.

Old News

[May 2, 2007] Using Service Management Facility (SMF) in the Solaris 10 OS: A Quick Example

The key idea of SMF is to provide XML definition file that serves as an envelope for actual scripts that invoke the services and which documents some properties and context in which each typical operation (start, stop, restart) should be performed and path tot he script itself which now can be part of the application. That gives the possibility to execute those operations more intelligemently, for example introduce the concept of dependencies.

But the problem is that XML template used smells with overcomplexity and slightly lessens the transparency which was the main advantage of rc* files approach...

Availability of svcs -a functionality cannot be legitimately sited as an advantage as it can be easily implemented with th4 old approach (as was done in Red Hat with services command). 

I am not sure that conversion of init scripts to Perl cannot achieve the same functionality at lower cost.

The Service Management Facility is a new, unified model for services and service management that is included in the Solaris Operating System. SMF provides a deeper, more functional view into the processes managed during startup and shutdown of a Solaris system. In addition, processes managed through SMF can have dependencies and they are monitored to allow for restarts if a process fails or is improperly stopped.

SMF is a core part of the predictive self-healing technology available in the Solaris 10 OS, and it provides automatic recovery from software and hardware failures as well as administrative errors. In addition, SMF-managed services can be delegated to non-root users. Finally, SMF is a follow-on to the legacy method of starting and stopping services, though /etc/rc scripts will continue to run when present for backward compatibility.

Deployment of services through SMF provides a much more consistent and robust environment. First, users can query the Solaris OS with a simple command (svcs -a) to determine if a service is running, instead of attempting a connection and wondering if the connection will succeed. Additionally, critical services can be restarted automatically in the event of a problem, such as someone inadvertently killing a service, a bug causing a core dump, or other process failures occurring. Further, SMF provides detailed and common logging as well as robust error handling to prevent services from hanging after a system state change. Please see the man page for smf(5) for more information.

After a typical software installation, there can be a half dozen or more processes that need to be started and stopped during system startup and shutdown. In addition, these processes may depend on each other and may need to be monitored and restarted if they fail. For each process, these are the logical steps that need to be done to incorporate these as services in SMF:

• Create a service manifest file.
• Create a methods script file to define the start, stop, and restart methods for the service.
• Validate and import the service manifest using svccfg(1M).
• Enable or start the service using svcadm(1M).
• Verify the service is running using svcs(1).

Using SAS processes as an example, we will create two services, one for the SAS Metadata Server (OMR) and one for the SAS Object Spawner. In this example, the Object Spawner cannot attempt to start before the OMR is started and should be stopped before the OMR is stopped.

OpenBoot OpenBoot Non-Volatile RAM (NVRAM)

Note If you change an NVRAM setting on a SPARC system and the system will no longer start up, it is possible to reset the NVRAM variables to their default settings by holding down the Stop and N keys simultaneously while the machine is powering up. When issuing this command, hold down Stop+N immediately after turning on the power to the SPARC system; keep these keys pressed for a few seconds or until you see the banner (if the display is available). This is a good technique to force a system's NVRAM variables to a known condition.

Solaris Tips and Tricks

• Solaris 10 has a new feature boot -m verbose which allows you to customize boot console output.

Recovering from a Boot Disk Failure with Solstice DiskSuite

Miscellaneous Solaris notes

You too can understand<br> device numbers and mapping in Solaris ...

Solaris SPARC Boot Sequence

The following represents a summary of the boot process for a Solaris 2.x system on Sparc hardware.

• Power On: Depending on the system involved, you may see some output on a serial terminal immediately after power on. This may take the form of a Hardware Power ON message on a large Enterprise server, or a "'" or "," in the case of an older Ultra system. These indications will not be present on a monitor connected directly to the server.

• POST: If the PROM diag-switch? parameter is set to true, output from the POST (Power On Self Test) will be viewable on a serial terminal. The PROM diag-level parameter determines the extent of the POST tests. (See the Hardware Diagnostics page for more information on these settings.) If a serial terminal is not connected, a prtdiag -v will show the results of the POST once the system has booted. If a keyboard is connected, it will beep and the keyboard lights will flash during POST. If the POST fails, an error indication may be displayed following the failure.

• Init System: The "Init System" process can be broken down into several discrete parts:
  • OBP: If diag-switch? is set, an Entering OBP message will be seen on a serial terminal. The MMU (memory management unit) is enabled.
  • NVRAM: If use-nvramrc? is set to true, read the NVRAMRC. This may contain information about boot devices, especially where the boot disk has been encapsulated with VxVM or DiskSuite.
  • Probe All: This includes checking for SCSI or other disk drives and devices.
  • Install Console: At this point, a directly connected monitor and keyboard will become active, or the serial port will become the system console access. If a keyboard is connected to the system, the lights will flash again during this step.
  • Banner: The PROM banner will be displayed. This banner includes a logo, system type, PROM revision level, the ethernet address, and the hostid.
  • Create Device Tree: The hardware device tree will be built. This device tree can be explored using PROM monitor commands at the ok> prompt, or by using prtconf once the system has been booted.

• Extended Diagnostics: If diag-switch? and diag-level are set, additional diagnostics will appear on the system console.

• auto-boot?: If the auto-boot? PROM parameter is set, the boot process will begin. Otherwise, the system will drop to the ok> PROM monitor prompt, or (if sunmon-compat? and security-mode are set) the > security prompt.

  The boot process will use the boot-device and boot-file PROM parameters unless diag-switch? is set. In this case, the boot process will use the diag-device and diag-file.

• bootblk: The OBP (Open Boot PROM) program loads the bootblk primary boot program from the boot-device (or diag-device, if diag-switch? is set). If the bootblk is not present or needs to be regenerated, it can be installed by running the installboot command after booting from a CDROM or the network. A copy of the bootblk is available at /usr/platform/`arch -k`/lib/fs/ufs/bootblk

• ufsboot: The secondary boot program, /platform/`arch -k`/ufsboot is run. This program loads the kernel core image files. If this file is corrupted or missing, a bootblk: can't find the boot program or similar error message will be returned.

• kernel: The kernel is loaded and run. For 32-bit Solaris systems, the relevant files are:
  1. /platform/`arch -k`/kernel/unix
  2. /kernel/genunix
  For 64-bit Solaris systems, the files are:
  1. /platform/`arch -k`/kernel/sparcV9/unix
  2. /kernel/genunix

  As part of the kernel loading process, the kernel banner is displayed to the screen. This includes the kernel version number (including patch level, if appropriate) and the copyright notice.

  The kernel initializes itself and begins loading modules, reading the files with the ufsboot program until it has loaded enough modules to mount the root filesystem itself. At that point, ufsboot is unmapped and the kernel uses its own drivers. If the system complains about not being able to write to the root filesystem, it is stuck in this part of the boot process.

  The boot -a command singlesteps through this portion of the boot process. This can be a useful diagnostic procedure if the kernel is not loading properly.

• /etc/system: The /etc/system file is read by the kernel, and the system parameters are set.

  The following types of customization are available in the /etc/system file:
  

  • moddir: Changes path of kernel modules.
  • forceload: Forces loading of a kernel module.
  • exclude: Excludes a particular kernel module.
  • rootfs: Specify the system type for the root file system. (ufs is the default.)
  • rootdev: Specify the physical device path for root.
  • set: Set the value of a tuneable system parameter.

  If the /etc/system file is edited, it is strongly recommended that a copy of the working file be made to a well-known location. In the event that the new /etc/system file renders the system unbootable, it might be possible to bring the system up with a boot -a command that specifies the old file. If this has not been done, the system may need to be booted from CD or network so that the file can be mounted and edited.

• kernel initialized: The kernel creates PID 0 ( sched). The sched process is sometimes called the "swapper."

• init: The kernel starts PID 1 (init).

• init: The init process reads the /etc/inittab and /etc/default/init and follows the instructions in those files.

  Some of the entries in the /etc/inittab are:
  

  • fs: sysinit (usually /etc/rcS)
  • is: default init level (usually 3, sometimes 2)
  • s#: script associated with a run level (usually /sbin/rc#)

• rc scripts: The rc scripts execute the files in the /etc/rc#.d directories. They are run by the /sbin/rc# scripts, each of which corresponds to a run level. Debugging can often be done on these scripts by adding echo lines to a script to print either a "I got this far" message or to print out the value of a problematic variable.

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

• BigAdmin Feature Article Using Service Management Facility (SMF) in the Solaris 10 OS A Quick Example
• Sun's "OpenBoot 3.x Command Reference Manual", Chapter 1. (Currently at http://docs.sun.com/db/doc/805-4436/6j4719c8a?a=view).
• How to Perform System Boot and Shutdown Procedures for Solaris 10 ...
• Solaris SPARC Boot Sequence
• Solaris 9 System Startup and Shutdown > OpenBoot Security
• Solaris 9 System Startup and Shutdown