Oracle Documentation
Using Run Control Scripts
Implementation of the Boot Archives on Solaris SPARC
Oracle Solaris Tunable Parameters Reference Manual
other:
Booting Problems in Solaris (pre Solaris 10).
Solaris SPARC Boot Sequence (pre Solaris 10).
Init State/Run Level| Function |
|
| 0 | Power-down state |
| 1 | System administrator state (single-user) |
| 2 | Multiuser state (resources not exported) |
| 3 | Multiuser state (resources exported) |
| 4 | Alternative multiuser state (currently unused) |
| 5 | Software reboot state |
| 6 | Reboot |
| S,s | Single-user state |
- The /sbin/init program keeps the system running correctly. In addition, /sbin/init is the command you use to change init states. You can also specify the init state as an argument to the shutdown command with the -i option.
- There are four types of init states:
-
- Power-down (run level 0)
- Single-user (run levels 1 and s or S)
- Multiuser (run levels 2 and 3)
- Reboot (run levels 5 and 6)
- When preparing to do a system administration task, you need to determine which init state is appropriate for the system and the task at hand.
| Init State | Run Level | Use This Level... |
|
| power-down state | 0 | To shut down the system so that it is safe to turn off the power. |
| system administrator state | 1 | When performing administrative tasks that require you to be the only user on the system. / and /usr are the only file systems mounted, and you can access only minimum kernel utilities. The terminal from which you issue this command becomes the console. No other users are logged in. |
| multiuser state | 2 | For normal operations. Multiple users can access the system and the entire file system. All daemons are running except for NFS server and syslog. |
| remote resource-sharing state | 3 | For normal operations with NFS resource-sharing available. |
| alternative multiuser state | 4 | This level is currently unavailable. |
| interactive reboot state | 5 | When you want to be prompted for a device other than the default boot devices. You can also change to this level by using the reboot -a command. |
| reboot state | 6 | To shut down the system to run level 0, and then reboot to multiuser level (or whatever level is the default in the inittab file). |
| single-user state | s or S | To run as a single user with all file systems mounted and accessible. |
How to Determine a System's Init State
-
* Type who -r and press Return. The run level, date and time, process termination status, process ID, and process exit status are displayed.
- In this example, pluto is at the default multiuser init state (run level 3), the date and time are 3 Feb 6 15:46, the process termination status is 3, the process ID is 0, and process exit status is S:
-
pluto% who -r
. run-level 3 Feb 6 15:46 3 0 S
pluto%
|
Solaris 8 /etc/inittab
ap::sysinit:/sbin/autopush -f /etc/iu.ap
ap::sysinit:/sbin/soconfig -f /etc/sock2path
fs::sysinit:/sbin/rcS sysinit >/dev/msglog 2<>/dev/msglog
is:3:initdefault:
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/msglog
sS:s:wait:/sbin/rcS >/dev/msglog 2<>/dev/msglog
s0:0:wait:/sbin/rc0 >/dev/msglog 2<>/dev/msglog
s1:1:respawn:/sbin/rc1 >/dev/msglog 2<>/dev/msglog
s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog
s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog
s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog
s6:6:wait:/sbin/rc6 >/dev/msglog 2<>/dev/msglog
fw:0:wait:/sbin/uadmin 2 0 >/dev/msglog 2<>/dev/msglog
of:5:wait:/sbin/uadmin 2 6 >/dev/msglog 2<>/dev/msglog
rb:6:wait:/sbin/uadmin 2 1 >/dev/msglog 2<>/dev/msglog
sc:234:respawn:/usr/lib/saf/sac -t 300
co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T sun -d /dev/console -l console -m ldterm,ttcompat
Solaris 10 /etc/inittab
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# The /etc/inittab file controls the configuration of init(1M); for more
# information refer to init(1M) and inittab(4). It is no longer
# necessary to edit inittab(4) directly; administrators should use the
# Solaris Service Management Facility (SMF) to define services instead.
# Refer to smf(5) and the System Administration Guide for more
# information on SMF.
#
# For modifying parameters passed to ttymon, use svccfg(1m) to modify
# the SMF repository. For example:
#
# # svccfg
# svc:> select system/console-login
# svc:/system/console-login> setprop ttymon/terminal_type = "xterm"
# svc:/system/console-login> exit
#
#ident "@(#)inittab 1.41 04/12/14 SMI"
ap::sysinit:/sbin/autopush -f /etc/iu.ap
sp::sysinit:/sbin/soconfig -f /etc/sock2path
smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/msglog
Boot sequence for SPARC, Solaris 10 Update 6 (10/08)
1. Open Boot Prom Phase
When a user types "boot" on an OBP-based system, the device selected - eitherfrom the command line or via the "boot-device" nvram variable - has its "open" and "load" methods called. The program loaded by this process is then executed, and the boot process enters the booter phase. This is unchanged from previous releases of Solaris.
1a. Disk
For disk devices, the FW driver usually uses the OBP label package's "load" method, which parses the VTOC label at the beginning of the disk to locate the specified partition, then reads sectors 1-15 of that partition into memory. This area is commonly called the boot block and usually contains a filesystem reader.
1b. Net
For network devices, the process is slightly different between booting over a LAN versus booting over a WAN. In both cases, however, the prom will download a booter from a boot or install server (inetboot in this case).
1c. LAN boot
When booting over a LAN, the FW uses either RARP and BOOTP or DHCP to discover its boot or install server. It then uses TFTP to download the booter (inetboot in this case).
1d. WAN boot
When booting over a WAN, the FW uses either DHCP or nvram properties to discover its install server, and the router and proxies needed to connect to it. It then uses HTTP to download the booter, and may optionally check the booter's signature with a predefined private key.
2. Booter phase
This phase is derived from the SPARC wanboot ramdisk process, and is responsible for reading the boot archive from the root file system (or install server in wanboot's case) into a ramdisk device. It does this by:
1) opening the boot-device (which it found as the "bootpath" property in the OBP
"/chosen" node)
2) using its file system specific reader to read the boot archive (by default,
/platform/`uname -m`/boot_archive)
3) creating a ramdisk device in "/ramdisk"
4) creating "bootarchive" and "fstype" properties in "/packages/boot-properties"
5) booting the archive (a ramdisk is just another type of disk, so executing the
boot block area serves this purpose)
3. Ramdisk Phase
The ramdisk is self-describing in the same sense any disk image is by virtue of having a filesystem reader in its boot block. This reader is over 90% the same as the disk boot block for a given filesystem so the same program is re-used. Its job is to load and execute the kernel from the archive by:
1) opening the boot archive (the "bootarchive" property from the previous phase)
2) using its file system specific reader to read the kernel (by default,
/platform/`uname -i`/kernel/unix)
3) creating "impl-arch-name", "whoami" and "elfheader" properties
4) executing the kernel
4. Kernel phrase
When krtld gains control, it mounts the boot archive and loads additional kernel modules from the boot archive via the ramdisk. Subsequent kernel initialization procedures remain the same until after the kernel mounts the root file system. At that point, the kernel throws away the boot archive and reclaims the memory it occupies. Note that in the install case, the ramdisk actually contains the root file system, and is not thrown away. The kernel ramdisk driver simply takes over control of the ramdisk image.