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
nterprise server, or a !"! or !,! in the case of an older #ltra system. These indications will not be present
on a monitor connected directly to the server.
POST: $f the %&'( diag-switch? parameter is set to true, output from the %'ST )%ower 'n Self
Test* will be viewable on a serial terminal. The %&'( diag-level parameter determines the extent of
the %'ST tests. )See the +ardware Diagnostics page for more information on these settings.* $f a serial
terminal is not connected, a prtdiag -v will show the results of the %'ST once the system has booted.
$f a keyboard is connected, it will beep and the keyboard lights will flash during %'ST. $f the %'ST
fails, an error indication may be displayed following the failure.
Init System: The !$nit System! process can be broken down into several discrete parts:
o OBP: $f diag-switch? is set, an Entering OBP message will be seen on a serial terminal. The
((# )memory management unit* is enabled.
o NVRAM: $f use-nvramrc? is set to true, read the NVRAMR. This may contain information
about boot devices, especially where the boot disk has been encapsulated with ,x,( or
DiskSuite.
o Probe All: This includes checking for S-S$ or other disk drives and devices.
o Install Console: .t this point, a directly connected monitor and keyboard will become active, or
the serial port will become the system console access. $f a keyboard is connected to the system,
the lights will flash again during this step.
o Banner: The %&'( banner will be displayed. This banner includes a logo, system type, %&'(
revision level, the ethernet address, and the hostid.
o Create Device Tree: The hardware device tree will be built. This device tree can be explored
using %&'( monitor commands at the o!" prompt, or by using prtcon# once the system has
been booted.
!ten"e" Dia#nostics: $f diag-switch? and diag-level are set, additional diagnostics will appear on
the system console.
auto-$oot?: $f the auto-$oot? %&'( parameter is set, the boot process will begin. 'therwise, the
system will drop to the o!" %&'( monitor prompt, or )if sunmon-compat? and securit%-mode are set*
the " security prompt.
The boot process will use the $oot-device and $oot-#ile %&'( parameters unless diag-switch? is
set. $n this case, the boot process will use the diag-device and diag-#ile.
bootbl$: The '/% )'pen /oot %&'(* program loads the $oot$l! primary boot program from the
$oot-device )or diag-device, if diag-switch? is set*. $f the $oot$l! is not present or needs to be
regenerated, it can be installed by running the install$oot command after booting from a -D&'( or
the network. . copy of the $oot$l! is available at &usr&plat#orm&'arch -!'&li$&#s&u#s&$oot$l!
u%sboot: The secondary boot program, &plat#orm&'arch -!'&u#s$oot is run. This program loads the
kernel core image files. $f this file is corrupted or missing, a $oot$l!( can)t #ind the $oot
program or similar error message will be returned.
$ernel: The kernel is loaded and run. 0or 122bit Solaris systems, the relevant files are:
*+ &plat#orm&'arch -!'&!ernel&uni,
-+ &!ernel&genuni,
0or 342bit Solaris systems, the files are:
.+ &plat#orm&'arch -!'&!ernel&sparcV/&uni,
0+ &!ernel&genuni,
.s 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 initiali5es itself and begins loading modules, reading the files with the u#s$oot program
until it has loaded enough modules to mount the root filesystem itself. .t that point, u#s$oot is
unmapped and the kernel uses its own drivers. $f the system complains about not being able to write to
the root filesystem, it is stuck in this part of the boot process.
The $oot -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&s%stem: The &etc&s%stem file is read by the kernel, and the system parameters are set.
The following types of customi5ation are available in the &etc&s%stem file:
o mo""ir: -hanges path of kernel modules.
o %orceloa": 0orces loading of a kernel module.
o e!clu"e: xcludes a particular kernel module.
o root%s: Specify the system type for the root file system. )ufs is the default.*
o root"ev: Specify the physical device path for root.
o set: Set the value of a tuneable system parameter.
$f the &etc&s%stem file is edited, it is strongly recommended that a copy of the working file be made to
a well2known location. $n the event that the new &etc&s%stem file renders the system unbootable, it
might be possible to bring the system up with a $oot -a command that specifies the old file. $f this has
not been done, the system may need to be booted from -D or network so that the file can be mounted
and edited.
$ernel initiali&e": The kernel creates %$D 6 ) sched*. The sched process is sometimes called the
!swapper.!
init: The kernel starts %$D 7 )init*.
init: The init process reads the &etc&initta$ and &etc&de#ault&init and follows the instructions
in those files.
Some of the entries in the &etc&initta$ are:
o %s: sysinit )usually &etc&rc1*
o is: default init level )usually 1, sometimes 2*
o s': script associated with a run level )usually &s$in&rc2*
rc scri(ts: The rc scripts execute the files in the &etc&rc2+d directories. They are run by the &s$in&rc2
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 !$ got this far! message or to print out the value of a
problematic variable.