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
POST: If the PROM
diag-switch? parameter is set
true, output from the POST (Power On Self Test) will be
viewable on a serial terminal. The PROM
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
OBP message will be seen on a serial terminal. The MMU (memory
management unit) is enabled.
- NVRAM: If
use-nvramrc? is set to
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-level are set, additional diagnostics will appear
on the system console.
auto-boot?: If the
PROM parameter is set, the boot process will begin. Otherwise, the
system will drop to the
ok> PROM monitor prompt, or
security-mode are set)
> security prompt.
The boot process will use the
boot-file PROM parameters unless
diag-switch? is set. In this case, the boot process
will use the
bootblk: The OBP (Open Boot PROM) program loads
bootblk primary boot program from
diag-switch? is set).
bootblk is not present or needs to be regenerated,
it can be installed by running the
after booting from a CDROM or the network.
A copy of the
bootblk is available at
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,
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:
For 64-bit Solaris systems, the files are:
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.
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.
file is read by the kernel, and the system parameters are set.
The following types of customization are available in the
- 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.
/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 process is sometimes called
init: The kernel starts PID 1 (
init process reads the
and follows the instructions in those files.
Some of the entries in the
- fs: sysinit (usually
- is: default init level (usually 3, sometimes 2)
- s#: script associated with a run level (usually
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
Debugging can often be done on these scripts by adding
lines to a script to print either a "I got this far" message or to print
out the value of a problematic variable.