Solaris Boot Process

The boot process loads the binary kernel from a bootable system disk into physical memory, initializes the kernel structure, sets system tunable parameters, starts system processes and brings the system to a known, usable state.

the basic steps of booting are :

1. The 'boot' command reads and loads the bootblock into memory.
2. The bootblock locates and loads the secondary boot program, ufsboot, into memory and passes control to it.
3. Ufsboot locates and loads the core kernel images and the required kernel runtime linker into memory and passes control to the loaded kernel.
4. The core kernel locates and loads mandatory kernel modules from the root-disk directory tree and executes the main startup code.
5. The kernel startup code executes, creating and initializing kernel structures, resources and software components.
6. The system executes shell scripts from the system directories, bringing that system upto the init state specified in /etc/inittab.


The initial stage of the boot process requires support from system firmware, typically loaded into a PROM,
such that a bootable device can be addressed and that some minimal I/O functionality exists for reading of a promary bootblock.

For SPARC, the firmware is known as OpenBoot PROM or OBP and is written in forth programming language.

Immediately after system is powered on, OBP does the following :
1. Provide a Power-On Self Test or POST.
2. Test and initialize the system hardware.
3. Determine the hardware configuration.
4. Boot the operating system.
5. Provide interactive debugging facilities for testing hardware and software.

The OBP (Open Boot PROM) program loads the bootblk(located on physical disk sectors 1 through 15) primary boot program from the boot-device. A copy of the bootblk is available at /usr/platform/`arch -k`/lib/fs/ufs/bootblk. The utility dd(1) is used to copy the bootblock to the specified disk partition. 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.

Then 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.

The kernel is loaded and run. For 32-bit Solaris systems, the relevant files are:

* /platform/`arch -k`/kernel/unix
* /kernel/genunix

For 64-bit Solaris systems, the files are:

* /platform/`arch -k`/kernel/sparcV9/unix
* /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.

Then the kernel is initialized. The kernel creates PID 0 ( sched) and starts PID 1 (init).The sched process is sometimes called the "swapper".

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

Then 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.
A system's run level defines what services and resources ae available to users. A system can be in only one run level at a time.
Presently, Solaris environment has eight run levels.

Run level Init State Description
0 Power-down state Shut down the operating system to safely power off the system
1 Administrative state Allows accessing all available file systems with user login allowed.
2 Multiuser state For normal operations. Multiusers can access the system. All daemons are running except the NFS
server daemons.
3 Multiuser For normal operations with NFS resource sharing available
4 Alternative Multiuser state Currently unavailable
5 Power-down state To shut down the operating system to safely power it off
6 Reboot state To shutdown the system to run level 0 and to reboot
s or S Single-user state To run as a single user with all file systems mounted and accessible.

So thats is how Solaris boots after getting powered on. Please leave a comment if you want.