SLES Startup Procedures

After you power on your SLES server, the operating system is initialized and background services (including OES daemons) are started prior to the server providing a login prompt. As an administrator, it is important for you to understand the process your SLES server follows to bring the server up to this usable state.

Bootloader Configuration

By default, a SLES9 installation uses the GRand Unified Bootloader (GRUB) to load the Linux kernel into memory. GRUB performs this task by writing a loader program to the Master Boot Record (MBR) of the first hard disk in the computer system. Following the computer's Power-On Self Test (POST) process, GRUB will be initialized and able to load the appropriate Linux kernel into memory.

GRUB employs a dual-stage loader process in which the configuration of GRUB itself is stored on the local filesystem under the /boot/grub directory. This directory is known as the GRUB Root Partition and contains the configuration files used by the GRUB bootloader. With a SLES installation, the file containing the GRUB menu configuration options is called menu.lst and resides within this GRUB Root Partition. An example of menu.lst is shown in Figure 6.1.

Figure 6.1. A sample SLES9 menu.lst configuration file.

The menu.lst file contains a listing of possible boot configurations for the computer. These configurations typically include at least a normal bootup configuration and a failsafe configuration. All possible bootup configurations are listed in menu.lst and identified using the title directive. Each of these configuration entries includes a reference to the kernel being used and any number of possible kernel parameters, which are used during the initialization process. These kernel parameters are required for proper hardware initialization and can be customized to meet specific requirements of the SLES server. Table 6.1 shows common kernel parameters.

Table 6.1. Common Kernel Parameters

PARAMETER	DESCRIPTION
acpi=off acpi=oldboot	When this parameter is set to off, the Advanced Configuration and Power Interface (ACPI) system is completely disabled. Setting this to oldboot disables most ACPI components, but leaves boot-related components intact.
apm=off	Disables Advanced Power Management.
ide=nodma	Disables DMA mode for all IDE controllers.
noapic	This parameter instructs the kernel not to use the computer's Advanced Programmable Interrupt Controller (APIC).
nosmp	Disables multiprocessing capabilities of an SMP-aware kernel.
splash=silent splash=verbose splash=native	Causes boot messages to be hidden behind the SLES splash screen. Setting this to verbose enables messages written on a colored splash screen. A setting of native enables a simple black console screen with boot messages.
vga=normal	This parameter causes the console resolution to be set to the default video resolution.
0-6	Specifying a number as an option forces the system to boot to the specified runlevel.

NOTE

For more information on possible kernel parameters, refer to the kernel- parameters.txt document found in /usr/src/linux/Documentation.

After you select a bootup configuration, GRUB loads the appropriate Linux kernel (as designated by the kernel directive in the configuration entry) into memory. The kernel itself is normally found in the /boot directory and called vmlinuz-<version number>.

In addition to the kernel, GRUB also loads a file called initrd-<version number> into memory. The initrd file is actually a compressed filesystem that contains all hardware modules required to access the root filesystem. The contents of initrd can be modified by editing the /etc/sysconfig/kernel file and making the appropriate changes to the INITRD_MODULES directive. Following modifications to this file, the mkinitrd command is used to generate a new initrd image. This is normally not required, but hardware changes after installation may require some manual intervention.

Daemon Initialization

After the root filesystem has been mounted, the process of bringing the server up to a usable state can continue. To accomplish this task, the Linux kernel loads the initialization (or init) daemon into memory. The init daemon is responsible for the final "look and feel" of a Linux server. It does this by referencing a configuration file, and then parsing a number of startup directories.

NOTE

A daemon is simply a system process that runs in the background to provide specific services. Daemons do not typically have a user interface.

The configuration file for the init daemon is /etc/inittab. This file is used to do such things as trap the Ctrl+Alt+Del keystroke, set up UPS monitoring services, enable the virtual terminals, and determine the default initialize level of the server. In Linux, any number of background daemons can be started or stopped at any point in time. However, the server itself can be considered to be running in one of a small set of possible configurations. These possible configurations are called runlevels. A server's runlevel is used to describe what state the server is in and what background daemons are started. Table 6.2 lists standard runlevels used in SLES9.

Table 6.2. Runlevels in SLES9

RUNLEVEL	DESCRIPTION
0	System halt (power down)
1 or S	Single-user mode (troubleshooting mode)
2	Local multiuser mode with no remote networking support (such as NFS)
3	Full multiuser mode with networking services
4	Not used
5	Full multiuser mode with networking and graphic environment
6	System reboot

After the init daemon is started, the inittab file is checked for the default initialization level. This value is one of the possible runlevels listed in Table 6.2 (although using a default runlevel of 0 or 6 doesn't make much sense). After the runlevel has been determined, the init daemon executes the /etc/init.d/boot script to control the bootup process, and must then process startup scripts for daemons allowed in the specified runlevel. This process is very important to understand and worth a little looking into.

To start daemons required in a certain runlevel, the init daemon executes the Master Resource Control script, /etc/init.d/rc, with a parameter indicating the desired runlevel. The rc script then uses the information found in the /etc/init.d directory and its subdirectories to finish the runlevel initialization.

The /etc/init.d directory contains startup scripts for all daemons installed on the local server. Some examples of commonly installed daemons include sshd, postfix, and nfsserver. Each of these daemons should have a startup script located in the /etc/init.d directory, shown in Figure 6.2.

Figure 6.2. Contents of the /etc/init.d directory.

These scripts accept command-line parameters that indicate whether the corresponding daemon is to be started or stopped (among other possible parameters). For an administrator, using these startup scripts is the correct method of invoking background daemons. (For example, the command /etc/init.d/sshd start would be used to start the sshd daemon.) During system initialization, the rc script must also use these daemon initialization scripts.

TIP

In addition to starting services by directly calling the /etc/init.d startup scripts, SLES also creates symbolic links to these startup scripts under /sbin. These symbolic links all start with "rc". Because the /sbin directory is in the root user's PATH, these links can be used to start and stop services quickly. For example, to start sshd using one of these links, you would use the rcsshd start command.

Under the /etc/init.d directory, subdirectories are used to represent all possible runlevels. These subdirectories are named rc*.d (where * represents 0 through 6 or every possible runlevel). Within each rc*.d directory, there are symbolic links back to daemon initialization scripts found in /etc/init.d, shown in Figure 6.3. The naming of these links is quite important. These links can use either a "K" or an "S" as the first character in the naming of the link.

Figure 6.3. Contents of the /etc/init.d/rc3.d directory.

When the rc script attempts to initialize a certain runlevel, the symbolic links in that runlevel's directory are analyzed. During the initial boot cycle, this is a straightforward process in which all links that begin with an "S" are executed using a start command-line parameter.

When switching from one runlevel to another, links that begin with a "K" are scripts for services that should be stopped in the new runlevel. These scripts are executed with a stop command-line parameter. Scripts starting with an "S" are then executed using a start command-line parameter.

The second and third characters in the link filenames should be numeric. These are used in ordering the startup and shutdown of system daemons. Symbolic links to daemon startup scripts are simply executed with a start or stop parameter in numeric order, based on these second and third characters.

NOTE

The rc script in SLES9 does have a large amount of logic built in. When changing runlevels, the rc script will check the current runlevel and compare its configuration to the new runlevel. Services running in both runlevels are not unnecessarily stopped and then restarted.

Managing the system services enabled in each runlevel can be easily done on a SLES server via the graphical YaST tool or via command-line tools such as insserv and chkconfig. More information on YaST can be found later in this chapter.

Summary of the SLES Startup Process

Table 6.3 and the diagram in Figure 6.4 summarize the key aspects of the startup process of a SLES9 server.

Table 6.3. Summary of SLES9 Boot-Related Files and Commands

FILE OR COMMAND	DESCRIPTION
/boot/grub	GRUB root partition containing bootloader configuration files.
/boot/grub/menu.lst	Main configuration file for GRUB.
/boot/vmlinuz-<version>	The Linux kernel.
/boot/initrd-<version>	Ramdisk image used to provide hardware modules to the kernel during the boot process.
/etc/sysconfig/kernel	Configuration file used when building initrd image.
/etc/inittab	Configuration file for init daemon.
/etc/init.d	Directory containing startup scripts for system daemons.
/etc/init.d/boot	First script used during the initialization process. This script configures system-wide variables and is responsible for control of the startup process.
/etc/init.d/rc*.d	Configuration directory for specific runlevels.
mkinitrd	Used to build new initrd image.
runlevel	Used to display previous and current runlevel. "N" indicates that the runlevel has not changed since startup.
init N	Used to switch to a new runlevel.

Figure 6.4. Overview of the SLES9 boot process.