UNIX System Administration Handbook - Evi Nemeth [142]
• /usr/kernel – similar to /kernel
You can determine your platform-name and hardware-class-name with uname -i and uname -m, respectively. Here’s an example:
% uname -i
SUNW,Ultra-Enterprise
% uname -m
sun4u
When Solaris boots, it searches the path
/platform/platform-name/kernel:/kernel:/usr/kernel
in an attempt to find a kernel. It first looks for files named unix, and then it looks for files named genunix. genunix is a generic kernel that represents the platform-independent portion of the base kernel.
Each of the directories listed above can contain several standard subdirectories, listed in Table 12.2. Since the subdirectories can exist within any of the kernel directories, we use the generic name KERNEL to symbolize any and all kernel directories.
Table 12.2 Subdirectories of Solaris kernel directories
You should not normally have to change any files in these directories unless you install a new device driver. The one exception to this rule may be the .conf files in the KERNEL/drv directory, which specify device-specific configuration parameters. It’s rarely necessary to change them, however, and you should really only do it if a device’s manufacturer tells you to.
Configuring the kernel with /etc/system
Solaris’s /etc/system file serves as the master configuration file for the kernel. Table 12.3 shows the directives and variables that can appear in this file. Directives are keywords in their own right; variables must be assigned a value with the set directive.
Table 12.3 Directives and variables used in /etc/system
a. D = directive, V = variable
/etc/system is consulted at boot time and can be so badly mutilated that the system no longer boots. boot -a lets you specify the path to a backup copy of /etc/system if you made one (if you don’t have a backup copy and your existing one doesn’t work, you can use /dev/null).
An example /etc/system file
Let’s look at a sample /etc/system file for a simple kernel.
rootfs:ufs
rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
These lines specify that the root filesystem will be of type UFS (Unix File System) and that it will reside on the sd3a disk partition. The syntax used to specify the root device is identical to that used by Sun’s openprom monitor. It varies from platform to platform, so consult your hardware manual or follow the symlinks in /dev that map the weird names to sensible ones. An ls -l after following the link will show the exact long name.
moddir: /platform/SUNW,Ultra-Enterprise/kernel:/platform/sun4u/kernel:
/kernel:/usr/kernel
This line (which has been wrapped to fit the page) specifies the search path for loadable modules. This value is suggested by the kernel man page; however, it is not the default, so you must specify it explicitly.
exclude: sys/shmsys
forceload: drv/superplotter
The first line excludes the shared memory system from the kernel, making it slightly leaner. (This is actually a bad idea in the general case. Things will break.) The second line forces the “superplotter” driver to be loaded.
set maxusers=64
This line sizes the kernel’s tables appropriately for 64 simultaneous logins.
Debugging a Solaris configuration
Since Solaris makes up its view of the world on the fly, debugging a troubled machine can be frustrating. Fortunately, Solaris provides several tools that display the machine’s current configuration.
The prtconf command prints the machine’s general configuration, including its machine type, model number, amount of memory, and some information about the configured hardware devices. Lines that describe devices (drivers, really) are indented to show the dependencies among them.
sysdef is prtconf on steroids. In addition to the information given by prtconf, it also lists pseudo-device drivers, tunable kernel parameters, and the filenames of loaded modules. If you modify the default kernel for an important machine, be sure to add a copy of the output of sysdef to your documentation