Solaris 10 – Boot Process of Solaris 10 Operating System on x86 Platform


Like most contemporary operating systems, Solaris initialization begins with the bootloader, continues with the kernel, and finishes with user-mode programs.

The Bootloader

On x86 platforms, the Solaris 10 OS is designed to be loaded by GNU Grand Unified Bootloader (GRUB). By default, the bootloader displays a boot menu with two entries:

Solaris 10 10/08 s10x_u6wos_07b X86
Solaris failsafe

When a Solaris boot entry is chosen, GRUB loads the kernel specified by the entry into memory and transfers control to it. The entry also directs GRUB to load a boot archive with copies of the kernel modules and configuration files essential for startup. See the boot manual page for more about the boot archive. The failsafe entry facilitates troubleshooting and recovery.

Note that the GRUB that is supplied with Solaris contains extensions to GNU GRUB required to load the Solaris OS.

The Kernel

The kernel starts by initializing the hardware, clearing the console, and printing a banner:

SunOS Release 5.10 Version Generic_137138-06 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.

After hardware initialization, the kernel mounts the root file system and executes user-mode programs.

User-Mode Programs

As with all UNIX operating systems, most Solaris functionality is driven by user-mode programs. The kernel starts them by executing the /sbin/init file in the first process, which always has process ID (“pid”) 1.

Like other UNIX operating systems, init reads the /etc/inittab configuration file and executes programs according to it. Unlike most UNIX operating systems, the default inittab does not instruct init to execute init scripts in the /etc/rc*.d directories. Instead, the processes that implement most system-delivered functionality on Solaris are started by the service management facility or SMF. Accordingly, the Solaris init contains special-purpose functionality to start and restart (as necessary) the daemons that implement SMF. In turn, the facility is responsible for executing the init scripts.

Users accustomed to the Solaris 9 operating system will notice that the Solaris 10 operating system displays much less information on the console during boot. This is because SMF now starts service daemons with standard output directed to log files in /var/svc/log, rather than the console.

Near the end of startup, SMF will execute the ttymon program on the console device at the direction of the console-login SMF service:

examplehost login:

If the SUNWdtlog package was installed, SMF will also start an X server on the console device and the dtlogin greeter on the display as part of the cde-login SMF service.

GRUB Extensions

The GRUB installed by Solaris differs from standard GNU GRUB in a few ways:

• It can read Solaris UFS file systems (which differ from BSD UFS file systems).

• It recognizes the kernel$ and module$ commands (since 10/08 release).

• It can read Solaris ZFS pools, and recognizes the bootfs command (since 10/08 release).

• It recognizes the findroot command (since 10/08 release).

As a result, versions of GRUB not delivered with Solaris will generally not be able to boot a Solaris system image.

Modifying Boot Behavior

The Solaris kernel can accept a string of boot arguments from the bootloader. Recognized arguments are listed in the kernel manual page. Below are the commonly used boot arguments:

Argument Description
-k Start the kernel debugger, kmdb, as soon as possible.
-s Single-user mode. Starts only basic services and present an sulogin prompt.
-v Be verbose by printing extra information on the console.
-m verbose Instruct the SMF daemons to be verbose.

The boot arguments for a single boot sequence can be set from the GRUB menu. Select an entry and press the e key. GRUB will display the entry editing screen.

In GRUB edit menu, you can modify the kernel behavior for a specified boot entry. This menu is accessed at boot time, by typing e to interrupt the boot process, then with the boot entry selected, typing e again to enter the edit menu for the selected entry.

Select the line beginning with kernel and press the e key.

After the path for unix, add the boot arguments. Press enter to commit the change and b to boot the temporarily modified entry.

Boot arguments for a single boot can also be set on the reboot command line. See the reboot manual page.

Boot arguments can be installed permanently by modifying menu.lst file. Use bootadm list-menuto locate the file in the file system.

(Editing GRUB entry)

Run Levels

The Solaris OS defines eight run levels. Each run level is associated with particular system behaviors.

By default, Solaris boots into run level 3. This is taken from the initdefault entry of the /etc/inittab configuration file. It can be changed to a single boot sequence by specifying -s in the boot arguments.

To change the run level while the operating system is running, use the init command. See its manual page for a detailed description of run levels.


If you encounter problems during the boot process, check the tools and solutions described here for a remedy.

(Editing GRUB menu at boot time)

Run Level Behavior
S Single-user mode. No login services running except for sulogin on the console.
0 The operating system is shut down and the computer is running its firmware.
-1 Like S, except applications which deliver into /etc/rc1.d are also started.
2 Multi-user mode. Local login services running. Some applications-usually-local may be running.
3 Multi-user server mode. All configured services and application running, including remote login and network-visible applications.
4 Alternative multi-user server mode. Third party applications may behave differently than under run level 3.
5 Powered off.
6 Reboot.

If a problem prevents user programs from starting normally, the Solaris 10 OS can be instructed to start as few programs as possible during boot by specifying -m milestone=none in the boot arguments. Once logged in, svcadm milestone all can be used to instruct SMF to continue initialization as usual.

If a problem prevents the kernel from starting normally, then it can be started with the assembly-level kernel debugger, kmdb. When the -k option is specified in the boot arguments, the kernel loads kmdbas soon as possible. If the kernel panics, kmdb will stop the kernel and present a debugging prompt on the console. If the -d option is also specified, kmdb will stop the kernel and present a debugging prompt as soon as it finishes loading. For more information, see the kmdb manual page.

The second GRUB menu entry installed by default is labeled “failsafe”. Selecting it will start the same kernel, but with the failsafe boot archive. It contains copies of the kernel modules and configuration files as delivered by the installer, without any user modifications. By default it also launches an interactive program that facilitates updating the normal boot archive for instances of the Solaris OS found on the disk.


Please enter your comment!
Please enter your name here