-
Basic hardware detection (memory, disk, keyboard, mouse,
and the like) and executing the firmware system initialization program .
In Solaris this is called Boot PROM phase—After you turn on power to
the system, the PROM displays system identification information and runs
self-test diagnostics to verify the system's hardware and memory. PROM chip
contains Forth OpenBoot firmware, and
it is executed immediately after you turn on the system. The primary task of the OpenBoot firmware is to boot the
operating system either from a mass storage device or from
the network. OpenBoot contains a program called the
monitor that controls the operation of the system before
the kernel is available. When a system is turned on, the
monitor runs a power-on self-test (POST) that checks such
things as the hardware and memory on the system. If no errors are found, the automatic boot process
begins. OpenBoot contains a set of instructions that locate
and start up the system's boot program and eventually start
up the Unix operating system.
-
Locating and running the initial boot program (IPL or
bootloader) from a predetermined location on the disk (MBR in PC). In
Solaris the primary boot program, called bootblk, is loaded from its location
on the boot device (usually disk) into memory.
-
Locating and starting the Unix kernel. The kernel image file to execute may be determined
automatically or via input to the bootloader. In Solaris the bootblk
program finds and executes the secondary boot program
(called ufsboot) from the Unix file system
(UFS) and loads it into memory. After the ufsboot
program is loaded, the ufsboot program loads
the two-part kernel.
-
The kernel initializes itself and then performs final,
high-level hardware checks, loading device drivers and/or kernel modules as
required. In Solaris the kernel initializes itself and begins loading
modules, using
ufsboot to read the files. When the kernel has
loaded enough modules to mount the root file system, it
unmaps the ufsboot program and continues, using
its own resources.
-
The kernel starts the init process, which in turn
starts system processes (daemons) and initializes all active subsystems. When
everything is ready, the system begins accepting user logins. In Solaris kernel starts
the Unix operating system, mounts the necessary file
systems, and runs /sbin/init to bring the
system to the initdefault state specified in
/etc/inittab.
The kernel creates a user process and starts the /sbin/init process, which starts other processes by
reading the /etc/inittab file. The /sbin/init process starts the run
control (rc) scripts, which execute a series of
other scripts. These scripts (/sbin/rc*) check
and mount file systems, start various processes, and
perform system maintenance tasks.
The Service Management Facility is
a new, unified model for services and service management that is
included in the Solaris Operating System. SMF provides a deeper,
more functional view into the processes managed during startup
and shutdown of a Solaris system. In addition, processes managed
through SMF can have dependencies and they are monitored to
allow for restarts if a process fails or is improperly stopped.
SMF is a core part of the predictive self-healing technology
available in the Solaris 10 OS, and it provides automatic
recovery from software and hardware failures as well as
administrative errors. In addition, SMF-managed services can be
delegated to non-root users. Finally, SMF is a follow-on to the
legacy method of starting and stopping services, though
/etc/rc scripts will continue to run
when present for backward compatibility.
Deployment of services through SMF provides a much more
consistent and robust environment. First, users can query the
Solaris OS with a simple command (svcs -a)
to determine if a service is running, instead of attempting a
connection and wondering if the connection will succeed.
Additionally, critical services can be restarted automatically
in the event of a problem, such as someone inadvertently killing
a service, a bug causing a core dump, or other process failures
occurring. Further, SMF provides detailed and common logging as
well as robust error handling to prevent services from hanging
after a system state change. Please see the
man page for smf(5) for more
information.
After a typical software installation, there can be a half
dozen or more processes that need to be started and stopped
during system startup and shutdown. In addition, these processes
may depend on each other and may need to be monitored and
restarted if they fail. For each process, these are the logical
steps that need to be done to incorporate these as services in
SMF:
- Create a service manifest file.
- Create a methods script file to define the start, stop,
and restart methods for the service.
- Validate and import the service manifest using
svccfg(1M).
- Enable or start the service using
svcadm(1M).
- Verify the service is running using
svcs(1).
Using SAS processes as an example, we will create two
services, one for the SAS Metadata Server (OMR) and one for the
SAS Object Spawner. In this example, the Object Spawner cannot
attempt to start before the OMR is started and should be stopped
before the OMR is stopped.
Note If you change an NVRAM setting on a
SPARC system and the system will no longer start up, it is possible to reset
the NVRAM variables to their default settings by holding down the Stop and N
keys simultaneously while the machine is powering up. When issuing this
command, hold down Stop+N immediately after turning on the power to the
SPARC system; keep these keys pressed for a few seconds or until you see the
banner (if the display is available). This is a good technique to force a
system's NVRAM variables to a known condition.
- 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 server.
- POST: If the PROM
diag-switch? parameter
is set to true, output from the POST (Power On Self
Test) will be viewable on a serial terminal. The PROM
diag-level parameter 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
Entering OBP message will be seen on a serial
terminal. The MMU (memory management unit) is enabled.
- NVRAM: If
use-nvramrc? is set to
true, read the 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-switch? and
diag-level are set, additional diagnostics will
appear on the system console.
auto-boot?: If the auto-boot? PROM
parameter is set, the boot process will begin. Otherwise, the
system will drop to the ok> PROM monitor prompt,
or (if sunmon-compat? and security-mode
are set) the > security prompt.
The boot process will use the boot-device and
boot-file PROM parameters unless
diag-switch? is set. In this case, the boot process
will use the diag-device and diag-file.
- bootblk: The OBP (Open Boot PROM) program loads the
bootblk primary boot program from the
boot-device (or diag-device, if
diag-switch? is set). 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. A copy of the bootblk is
available at /usr/platform/`arch
-k`/lib/fs/ufs/bootblk
- 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, a 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:
/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.
The following types of customization are available in the
/etc/system file:
- 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.
If the /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). The sched process is sometimes
called the "swapper."
- init: The kernel starts PID 1 (
init).
init: The init process reads the
/etc/inittab
and /etc/default/init and follows the instructions in
those files.
Some of the entries in the /etc/inittab are:
- fs: sysinit (usually
/etc/rcS)
- is: default init level (usually 3, sometimes 2)
- s#: script associated with a run level (usually
/sbin/rc#)
- 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 run
level. Debugging can often be done on these scripts by adding
echo lines to a script to print either a "I got this
far" message or to print out the value of a problematic variable.