- Introduction
- Booting a System
- The OpenBoot Environment
- The OpenBoot Architecture
- The OpenBoot Interface
- Getting Help in OpenBoot
- PROM Device Tree (Full Device Pathnames)
- OpenBoot NVRAM
- OpenBoot Security
- OpenBoot Diagnostics
- OpenBoot PROM Versions
- Booting a System
- The Kernel
- System Run States
- System Shutdown
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Kernel
Boot the system; access detailed information.
After the boot command initiates the kernel, the kernel begins several phases of the startup process. The first task is for OpenBoot to load the two-part kernel. The secondary startup program, ufsboot, which is described in the preceding section, loads the operating system kernel. The core of the kernel is two pieces of static code called genunix and unix. genunix is the platform-independent generic kernel file, and unix is the platform-specific kernel file. The platform-specific kernel used by ufsboot for systems running in 32-bit mode is named /platform/´uname -m´/kernel/unix. The platform-specific kernel used by ufsboot for systems running in 64-bit mode is named /platform/´uname -m´/kernel/sparcv9/unix. When ufsboot loads these two files into memory, they are combined to form the running kernel.
The kernel initializes itself and begins loading modules, using ufsboot to read the files. After 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 creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file. (The /sbin/init process is described in the "System Run States" section, later in this chapter.)
The kernel is dynamically configured in Solaris 9. The kernel consists of a small static core and many dynamically loadable kernel modules. Many kernel modules are loaded automatically at boot time, but for efficiency, others—such as device drivers—are loaded from the disk as needed by the kernel.
A kernel module is a software component that is used to perform a specific task on the system. An example of a loadable kernel module is a device driver that is loaded when the device is accessed. Drivers, file systems, STREAMS modules, and other modules are loaded automatically as they are needed, either at startup or at runtime. This is referred to as autoconfiguration, and the kernel is referred to as a dynamic kernel. After these modules are no longer in use, they can be unloaded. Modules are kept in memory until that memory is needed. This makes more efficient use of memory and allows for simpler modification and tuning.
The modinfo command provides information about the modules that are currently loaded on a system. The modules that make up the kernel typically reside in the directories /kernel and /usr/kernel. Platform-dependent modules reside in the /platform/´uname –m´/kernel and /platform/´uname –i´/kernel directories.
When the kernel is loading, it reads the /etc/system file where system configuration information is stored. This file modifies the kernel's parameters and treatment of loadable modules. It specifically controls the following:
The search path for default modules to be loaded at boot time as well as the search path for modules not to be loaded at boot time
The modules to be forcibly loaded at boot time rather than at first access
The root type and device
The new values to override the default kernel parameter values
The following is an example of the default /etc/system file:
*ident "@(#)system 1.18 97/06/27 SMI" /* SVR4 1.5 */ * * SYSTEM SPECIFICATION FILE * * moddir: * *Set the search path for modules. This has a format similar to the *csh path variable. If the module isn't found in the first directory *it tries the second and so on. The default is /kernel /usr/kernel * *Example: *moddir: /kernel /usr/kernel /other/modules * root device and root filesystem configuration: * *The following may be used to override the defaults provided by *the boot program: * *rootfs: Set the filesystem type of the root. * *rootdev: Set the root device. This should be a fully * expanded physical pathname. The default is the * physical pathname of the device where the boot * program resides. The physical pathname is * highly platform and configuration dependent. * *Example: * rootfs:ufs * rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a * *(Swap device configuration should be specified in /etc/vfstab.) * exclude: * *Modules appearing in the moddir path which are NOT to be loaded, *even if referenced. Note that ´exclude' accepts either a module name, *or a filename which includes the directory. * *Examples: * exclude: win * exclude: sys/shmsys * forceload: * *Cause these modules to be loaded at boot time, (just before mounting *the root filesystem) rather than at first reference. Note that *forceload expects a filename which includes the directory. Also *note that loading a module does not necessarily imply that it will *be installed. * *Example: * forceload: drv/foo * set: * *Set an integer variable in the kernel or a module to a new value. *This facility should be used with caution. See system(4). * *Examples: * *To set variables in 'unix': * * set nautopush=32 * set maxusers=40 * *To set a variable named 'debug' in the module named 'test_module' * * set test_module:debug = 0x13
CAUTION
Modifying the /etc/system File You should not modify the /etc/system file unless you are certain of the results. A good practice is to always make a backup copy of any system file you modify, in case the original needs to be restored. Incorrect entries could prevent your system from booting. If a boot process fails because of an unusable /etc/system file, you should boot the system by using the interactive option boot -a. When you are asked to enter the name of the system file, you should enter the name of the backup system filename or /dev/null, to use all default parameters.
The /etc/system file contains commands that have this form:
set <parameter>=<value>
For example, the setting for the kernel parameter MAXUSERS is set in the /etc/system file with the following line:
set maxusers = 40
Commands that affect loadable modules have this form:
set <module>:<variable>=<value>
NOTE
Editing the /etc/system File A command must be 80 or fewer characters in length, and a comment line must begin with an asterisk (*) or hash mark (#) and end with a hard return.
If you need to change a tunable parameter in the /etc/system file, you can use the sysdef command to verify the change. sysdef lists all hardware devices, system devices, loadable modules, and the values of selected kernel-tunable parameters. The following is the output that is produced from the sysdef command:
*
* Hostid
*
80a26382
*
* sun4u Configuration
*
*
* Devices
*
packages (driver not attached)
terminal-emulator (driver not attached)
deblocker (driver not attached)
obp-tftp (driver not attached)
disk-label (driver not attached)
SUNW,builtin-drivers (driver not attached)
sun-keyboard (driver not attached)
ufs-file-system (driver not attached)
chosen (driver not attached)
openprom (driver not attached)
client-services (driver not attached)
options, instance #0
<output truncated>
...
* Utsname Tunables
*
5.9 release (REL)
ultra5 node name (NODE)
SunOS system name (SYS)
Beta_Refresh version (VER)
*
* Process Resource Limit Tunables (Current:Maximum)
*
0x0000000000000100:0x0000000000010000 file descriptors
*
* Streams Tunables
*
9 maximum number of pushes allowed (NSTRPUSH)
65536 maximum stream message size (STRMSGSZ)
1024 max size of ctl part of message (STRCTLSZ)
*
* IPC Messages module is not loaded
*
*
* IPC Semaphores module is not loaded
*
*
* IPC Shared Memory module is not loaded
*
*
* Time Sharing Scheduler Tunables
*
60 maximum time sharing user priority (TSMAXUPRI)
SYS system class name (SYS_NAME)
Configuring the kernel and tunable parameters is a complex topic to describe in a few sections of a chapter. This introduction to the concept provides enough information for the average system administrator and describes the topics you'll need to know for the exam. If you are interested in learning more about the kernel and tunable parameters, refer to the additional sources of information described at the end of this chapter.