Solaris Boot Process

Solaris, originally developed by Sun Microsystems and now maintained by Oracle, is a robust UNIX operating system designed for enterprise environments. It is known for stability, scalability, and advanced features like ZFS and SMF.

Understanding the Solaris boot process helps in troubleshooting, system recovery, performance tuning, and managing upgrades.

This guide explains each phase of the Solaris boot sequence in a deeper yet easy-to-understand way.

Complete Solaris Boot Process

1. Power-On Self Test (POST)

When the system is powered on, the hardware begins execution from firmware stored on the motherboard.

POST performs low-level hardware checks:

• CPU initialization
• Memory detection and basic memory tests
• I/O controller checks
• System board verification
• Peripheral device presence detection

If any critical hardware failure is detected, the system halts and displays diagnostic messages.

Once POST completes successfully, control passes to the system firmware — Open Boot PROM (OBP) on SPARC systems.

2. Open Boot PROM (OBP)

OBP is the firmware interface used on SPARC-based Solaris systems. It is comparable to BIOS or UEFI on x86 systems.

OBP responsibilities include:

• Initializing hardware required for boot
• Building the device tree
• Detecting bootable devices
• Providing an interactive command-line interface
• Allowing manual boot control and diagnostics

OBP uses the Forth programming language internally. When interrupted, it presents the ok prompt.

Example:

ok printenv

This command displays boot-related environment variables such as:

• boot-device
• auto-boot?
• boot-file
• diag-device

You can modify boot parameters directly:

ok setenv boot-device disk

ok setenv auto-boot? false

To manually boot:

ok boot

3. Boot Device Selection

The system determines the boot device using the boot-device variable.

Common boot sources:

• Internal disk
• CD/DVD
• USB device
• Network (PXE)
• Alternate disk slice

To view the current boot device:

ok printenv boot-device

To boot from a specific device manually:

ok boot disk1

You can also boot into single-user mode:

ok boot -s

Or verbose mode:

ok boot -v

These options are passed to the kernel during loading.

4. Boot Blocks

Boot blocks are small programs located in the first sectors of the boot disk.

Their purpose is simple but critical:

• Read the filesystem structure
• Locate the secondary boot program
• Load /boot/solaris

Boot blocks are architecture-specific and installed using the installboot command.

Example:

installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0

If boot blocks become corrupted, the system cannot proceed past firmware.

5. Boot Loader (/boot/solaris)

The secondary boot loader takes over after boot blocks.

Its main responsibilities:

• Load the Solaris kernel (unix or kernel/unix)
• Load the boot archive
• Interpret boot flags
• Provide boot-time configuration options

On newer systems, Solaris uses GRUB (on x86 platforms).

On SPARC, the boot loader interacts directly with OBP.

6. Boot Archive

The boot archive is a compressed filesystem image.

Location:

/platform/<platform-name>/boot_archive

It contains:

• Essential kernel modules
• Device drivers required for root filesystem access
• Early boot libraries

The system uses the boot archive before the full root filesystem is mounted.

If drivers are missing from the boot archive, the system may fail to boot.

To rebuild the boot archive:

$ bootadm update-archive

If corruption occurs:

$ bootadm update-archive -f

7. Kernel Initialization

Once loaded into memory, the Solaris kernel begins initialization.

Major activities during this stage:

a) Hardware Initialization

• CPU configuration
• Interrupt controller setup
• Device driver loading

b) Memory Initialization

• Virtual memory setup
• Kernel memory allocator initialization
• ZFS ARC initialization (if ZFS root)

c) Root Filesystem Mounting

• Mount root (UFS or ZFS)
• Switch from boot archive to real root

d) Device Configuration

• Creation of /devices entries
• /dev symbolic links

e) Process Subsystem Initialization

• Scheduler startup
• Process table initialization
• Thread management

After this phase, the kernel starts the first user-space process:

/sbin/init

This process always runs as PID 1.

8. init Process (PID 1)

The init process controls system state transitions.

In older Solaris versions, init reads:

/etc/inittab

It determines the default run level.

Common run levels:

Run Level  Meaning

0        Halt

1        Single-user mode

2        Multi-user (no NFS)

3        Full multi-user

5        Power off

6        Reboot

Example default entry:

id:3:initdefault:

This means the system boots into full multi-user mode.

9. Service Management Facility (SMF)

Modern Solaris systems rely heavily on SMF instead of traditional rc scripts.

SMF provides:

• Dependency-based service startup
• Automatic restart of failed services
• Centralized service management
• Logging and fault tracking

Key process:

svc.startd

You can manage services using:

$ svcs

$ svcadm enable <service>

$ svcadm disable <service>

$ svcadm restart <service>

To check failed services:

$ svcs -xv

SMF improves reliability compared to traditional UNIX init scripts.

10. Run Control Scripts (Legacy Method)

Older systems use:

/etc/rc?.d/

Scripts follow naming convention:

S##name → Start

K##name → Kill

Example:

/etc/rc3.d/S99dtlogin

Scripts execute in numerical order.

11. Login Services

After all services are initialized:

• Console login appears
• SSH daemon starts
• Graphical login (CDE/GNOME) may start

Processes involved:

• getty (console login)
• sshd (remote login)
• dtlogin (CDE display manager)

At this point, the system is fully operational.

Advanced Technical Concepts

Boot Environments (ZFS-Based)

Solaris supports multiple Boot Environments (BEs).

Each BE is a ZFS clone of the root filesystem.

Benefits:

• Safe OS upgrades
• Kernel testing
• Easy rollback
• No downtime for rollback

To list boot environments:

$ beadm list

To activate one:

$ beadm activate <BE_name>

Reboot to switch.

Network Boot (PXE)

Solaris can boot over the network.

Process:

• OBP sends DHCP request
• DHCP provides boot server info
• TFTP downloads bootloader
• Kernel loads from network

Useful for:

• Diskless clients
• Mass deployment
• Automated installations

Troubleshooting Boot Issues

Boot to Single User Mode

ok boot -s

Boot from Alternate Disk

ok boot disk1

Rebuild Device Tree

From single-user mode:

$ devfsadm -Cv

Check Boot Archive

$ bootadm list-archive