Solaris SPARC Boot Sequence

整理自网络

介绍Solaris系统启动的过程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 <code>Hardware Power ON</code> 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(Power On Self Test):

If the PROM <code>diag-switch?</code> parameter is set to <code>true</code>, output from the POST  will be viewable on a serial terminal.

on these settings.) If a serial terminal is not connected, a <code>prtdiag -v</code> 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(Open Boot PROM): If <code>diag-switch?</code> is set, an <code>Entering OBP</code> message will be seen on a serial

terminal. The MMU (memory management unit) is enabled.

NVRAM: If <code>use-nvramrc?</code> is set to <code>true</code>, read the <code>NVRAMRC</code>. 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.

Extended Diagnostics: If <code>diag-switch?</code> and <code>diag-level</code> are set, additional diagnostics will appear on the system console.

<code>auto-boot?</code>:

If the <code>auto-boot?</code> PROM parameter is set, the boot process will begin. Otherwise, the system will drop to the <code>ok&gt;</code>PROM monitor prompt, or (if <code>sunmon-compat?</code> and <code>security-mode</code> are set) the <code>&gt;</code> security

prompt.

The boot process will use the <code>boot-device </code>and <code>boot-file</code> PROM parameters unless <code>diag-switch?</code> is set. In this case, the boot process will use the <code>diag-device</code> and <code>diag-file</code>.

bootblk: The OBP (Open Boot PROM) program loads the <code>bootblk</code>primary boot program from the <code>boot-device</code> (or <code>diag-device</code>, if<code>diag-switch?</code> is

set). If the <code>bootblk</code> is not present or needs to be regenerated, it can be installed by running the <code>installboot</code>command after booting from a CDROM or the network. A copy of the <code>bootblk</code> is available at <code>/usr/platform/`arch -k`/lib/fs/ufs/bootblk</code>

ufsboot: The secondary boot program, <code>/platform/`arch -k`/ufsboot</code>is run. This program loads the kernel core image files. If this file is corrupted or missing, a <code>bootblk: can't find the boot program</code> or similar error message will be returned.

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

<code>/platform/`arch -k`/kernel/unix</code>

<code>/kernel/genunix</code>

For 64-bit Solaris systems, the files are:

<code>/platform/`arch -k`/kernel/sparcV9/unix</code>

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 <code>ufsboot</code> program until it has loaded enough modules to mount the root filesystem itself. At that

point, <code>ufsboot</code> 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.

This can be a useful diagnostic procedure if the kernel is not loading properly.

<code>/etc/system</code>: The <code>/etc/system</code> file is read by the kernel, and the system parameters are set.

The following types of customization are available in the<code>/etc/system</code> 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 <code>/etc/system</code> 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 <code>/etc/system</code> file

renders the system unbootable, it might be possible to bring the system up with a <code>boot -a</code> 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 ( <code>sched</code>). The<code>sched</code> process is sometimes called the "swapper."

init: The kernel starts PID 1 (<code>init</code>).

follows the instructions in those files.

Some of the entries in the <code>/etc/inittab</code> are:

fs: sysinit (usually <code>/etc/rcS</code>)

is: default init level (usually 3, sometimes 2)

s#: script associated with a run level (usually <code>/sbin/rc#</code>)

Debugging can often be done on these scripts by adding <code>echo</code>lines to a script to print either a "I got this far" message or to print out the value of a problematic variable.