The first step is booting the kernel. As described in the previous section, this can be done from floppy or hard drive. As the kernel loads into memory, it will print messages to the system console, but usually also saves them in the system logfiles as well. As root, you can always check the file /var/log/messages (which contains kernel messages emitted during runtime as well). The command dmesg prints out the last lines of the kernel message ring buffer; directly after booting, naturally, you will get the boot messages .

The following few paragraphs go through a couple of the more interesting messages and explain what they mean. These messages are all printed by the kernel itself, as each device driver is initialized. The exact messages printed depend on what drivers are compiled into your kernel and what hardware you have on your system. You are likely to have more, fewer, or different messages; we’ll concentrate here on the messages that are quite common.

The line:

Linux version 2.6.11.4-21.7-default (geeko@buildhost) (gcc version 3.3.5 2005011
7 (prerelease) (SUSE Linux)) #1 Thu Jun 2 14:23:14 UTC 2005

tells you the version number of the kernel, on which machine, when, and with which compiler it was built.

Next, the kernel reports a number of things about the BIOS, the amount of memory found, power management settings, and so one. Here are some of the more interesting lines (of course, depending on your hardware and setup, these may look different for you):

...
127MB HIGHMEM available.
896MB LOWMEM available.
...
Kernel command line: root=/dev/hda6 vga=0x314 selinux=0 splash=silent resume=/de
v/hda5
...
Detected 599.481 MHz processor.
...

Notice in particular the kernel command line; you can double-check here that you are actually booting the configuration that you think you are booting.

Then, the kernel tells us which console settings it has picked and which console type it has detected:

Console: colour dummy device 80x25

Note that this involves only the text mode being used by the kernel, not the capabilities of your video card. It also has nothing to do with the X Window System; the kernel is not concerned with that at all.

You’ll then see the “BogoMIPS” calculation for your processor:

Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920)

This is an utterly bogus (hence the name) measurement of processor speed, which is used to obtain optimal performance in delay loops for several device drivers.

The kernel gathers information about the PCIbus and checks for any PCI cards present in the system:

PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8
PCI: Using configuration type 1
...
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
...

Linux then sets up networking, the mouse port, and the serial driver. A line such as:

ttyS00 at 0x03f8 (irq = 4) is a NS16550A

means that the first serial device (/dev/ttyS00, or COM1) was detected at address 0x03f8, IRQ 4, using 16550A UART functions. Next comes some more hardware detection, such as the real-time clock and the floppy drive:

Real Time Clock Driver v1.12
...
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
loop: loaded (max 8 devices)
...

The line:

Adding 1029632k swap on /dev/hda5.  Priority:42 extents:1

tells you how much swap space the kernel has found. Among the further tasks performed during a typical boot are finding and configuring a parallel port (lp1), detecting and configuring the network card, and finally setting up the USB subsystem.

Again, depending on the kernel version and your configuration and hardware, you will see other messages (this was just an excerpt, after all).

Once the device drivers are initialized, the kernel executes the program init, which is found in /etc, /bin, or /sbin (it’s /sbin/init on most systems). init is a general-purpose program that spawns new processes and restarts certain programs when they exit. For example, each virtual console has a getty process running on it, started by init. Upon login, the getty process is replaced with another. After logging out, init starts a new getty process, allowing you to log in again.

init is also responsible for running a number of programs and scripts when the system boots. Everything init does is controlled by the file /etc/inittab. To understand this file, you need to understand the concept of runlevels first.

A runlevel is a number or letter that specifies the current system state, as far as init is concerned. For example, when the system runlevel is changed to 3, all entries in /etc/inittab containing 3 in the column specifying the runlevels will be executed. Runlevels are a useful way to group entries in /etc/inittab together. For example, you might want to say that runlevel 1 executes only the bare minimum of configuration scripts, runlevel 2 executes everything in runlevel 1 plus networking configuration, runlevel 3 executes everything in levels 1 and 2 plus dial-in login access, and so on. Today, the Red Hat and SUSE distributions are set up so that runlevel 5 automatically starts the X Window System graphical interface. Debian does so at runlevels 2 through 5--provided you have installed an X display manager such as xdm.

For the most part, you don’t need to concern yourself with runlevels. When the system boots, it enters the default runlevel (set in /etc/inittab, as we will soon show). On most systems, this default is runlevel 3 or 5. After we discuss normal booting, we’ll show you how to enter another runlevel that you will sometimes need to use—runlevel 1, or single-user mode. Debian users may want to investigate the file-rc package, which lets you configure runlevels in a single file.

Let’s take a look at a sample /etc/inittab file:

# Set the default runlevel to three
id:3:initdefault:

# First script to be executed
si::bootwait:/etc/init.d/boot

# Run /etc/init.d/rc with the runlevel as an argument
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# Executed when we press ctrl-alt-delete
ca::ctrlaltdel:/sbin/shutdown -t3 -rf now

# Start agetty for virtual consoles 1 through 6
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

Fields are separated by colons. The last field is the most recognizable: it is the command that init executes for this entry. The first field is an arbitrary identifier (it doesn’t matter what it is as long as it’s unique in the file), and the second indicates what runlevels cause the command to be invoked. The third field tells init how to handle this entry; for example, whether to execute the given command once or to respawn the command whenever it exits.

The exact contents of /etc/inittab depend on your system and the distribution of Linux you have installed.

In our sample file, we see first that the default runlevel is set to 3. The actionfield for this entry is initdefault, which causes the given runlevel to be set to the default. That’s the runlevel normally used whenever the system boots. You can override the default with any level you want by running init manually (which you might do when debugging your configuration) and passing in the desired runlevel as an argument. For instance, the following command shuts down all services that belong to the current runlevel, but not to runlevel 5 (warn all your users before doing this!):

tigger# init 5

GRUB can also boot in single-user mode (usually runlevel 1)--see "Specifying boot-time options,” earlier in this chapter.

The next entry tells init to execute the script /etc/init.d/boot when the system boots. (The action field is si [sysinit], which specifies that this entry should be executed when init is first started at system boot.) On other distributions, this file might be elsewhere, but /etc/init.d/boot is where it belongs according to the Linux Filesystem Hierarchy Standard (FHS). The file is simply a shell script containing commands to handle basic system initialization; for example, swapping is enabled, filesystems are checked and mounted, and the system clock is synchronized with the CMOS clock. Many of the commands in this file are discussed in "Managing Filesystems" and “Managing Swap Space” in Chapter 10.

Next, we see that the system executes the script /etc/init.d/rc when it enters any of the runlevels through 6, with the appropriate runlevel as an argument. rc is a generic startup script that executes other scripts as appropriate for that runlevel. The action field here is wait, which tells init to execute the given command and to wait for it to complete execution before doing anything else.

Linux stores startup commands in files with rc in the name, using an old Unix convention. The commands do all the things necessary to have a fully functioning system, such as starting the servers or daemons mentioned in “Processes” in Chapter 10. Thanks to these commands, the system comes up ready with logging facilities, mail, a web server, or whatever you installed and asked it to run. As explained in the previous section, the files are invoked from /etc/inittab. The commands are standard shell commands, and you can simply read the various rc files to see what they do.

In this section, we describe the structure of the rc files so that you can understand where everything starts, and so that you can start or stop servers manually in the rare case that they don’t do what you want them to do. We use SUSE as our model, but once you get the idea of what to look for, you can find the corresponding files on any Linux distribution. SUSE is pretty good at sticking with the FHS, so other distributions are likely to look fairly similar, or at least will converge to look fairly similar. The Linux FHS is a distribution-neutral initiative to define standard directory names and filenames for important system files. Any Linux distribution that wants to be a good Linux citizen should follow this standard. Debian is another example of a distribution that does so. On Red Hat, the top-level rc script is /etc/rc.d/rc.

In the previous section, you saw how /etc/inittab invokes the script under a variety of circumstances with different numbers from 0 to 6 as arguments. The numbers correspond to runlevels, and each one causes the rc files to invoke a different set of scripts. So our next step is to find the scripts corresponding to each runlevel.

According to the FHS, scripts for each runlevel are stored in the directory /etc/init.d/rcN.d, where N is the runlevel being started. Thus, for runlevel 3, scripts in /etc/rc.d/rc3.d would be used. Again, slightly different conventions are the rule in other distributions.

Take a look in one of those directories; you will see a number of filenames of the form Snnxxxx or Knnxxxx where nn is a number from 00 to 99, and xxxx is the name of some system service. The scripts whose names begin with K are executed by /etc/rc.d/rc first to kill any existing services, and then the scripts whose names begin with S are executed to start new services.

The numbers nn in the names are used to enforce an ordering on the scripts as they are executed: scripts with lower numbers are executed before those with higher numbers. The name xxxx is simply used to help you identify to which system service the script corresponds. This naming convention might seem odd, but it makes it easy to add or remove scripts from these directories and have them automatically executed at the appropriate time by /etc/rc.d/rc. For customizing startup scripts, you’ll find it convenient to use a graphical runlevel editor, such as KSysV in KDE (discussed later in this chapter). Some distributions also include a graphical runlevel editor as part of their administration tool.

For example, the script to initialize networking might be called S10network, while the script to stop the system logging daemon might be called K70syslog. If these files are placed in the appropriate /etc/init.d/rcN.d directories, /etc/init.d/rc will run them, in numerical order, at system startup or shutdown time. If the default runlevel of your system is 3, look in /etc/init.d/rc3.d to see which scripts are executed when the system boots normally.

Because the same services are started or stopped at different runlevels, the SUSE distribution uses symbolic links instead of repeating the same script in multiple places. Thus, each S or K file is a symbolic link that points to a central directory that stores startup or shutdown scripts for all services, typically /etc/init.d. On Debian and SUSE, the directory contains a script called skeleton that you can adapt to start and stop any new daemons you might write.

Knowing the location of a startup or shutdown script is useful in case you don’t want to completely reboot or enter a different runlevel, but need to start or stop a particular service. Look in the init.d directory for a script of the appropriate name and execute it, passing the parameter start or stop. For example, on SUSE, if you want the Apache web server to be running but your system is in a runlevel that does not include Apache, just enter the following:

tigger# /sbin/init.d/apache start

Many distributions are set up such that the script /etc/init.d/boot.local is executed at the end of the boot process. You can edit this file to accomplish any peculiar or otherwise out-of-place system commands at boot time, or if you’re not sure where else they should be executed. For shutting down, there is often the equivalent /etc/init.d/halt.local.

The next entry, labeled ca, is executed when the key combination Ctrl-Alt-Delete is pressed on the console. This key combination produces an interrupt that usually reboots the system. Under Linux, this interrupt is caught and sent to init, which executes the entry with the action field of ctrlaltdel. The command shown here, /sbin/shutdown -t3 -rf now, will do a “safe” reboot of the system. (See "Shutting Down the System,” later in this chapter.) This way we protect the system from sudden reboot when Ctrl-Alt-Delete is pressed.

Finally, the inittab file includes entries that execute /sbin/mingetty for the first six virtual consoles. mingetty is one of the several getty variants available for Linux. These programs permit logins on terminals; without them the terminal would be effectively dead and would not respond when a user walked up and pressed a key or mouse button. The various getty commands open a terminal device (such as a virtual console or a serial line), set various parameters for the terminal driver, and execute /bin/login to initiate a login session on that terminal. Therefore, to allow logins on a given virtual console, you must be running getty or mingetty on it. mingetty is the version used on a number of Linux systems, but others use getty or agetty, which have a slightly different syntax. See the manual pages for getty, mingetty, and agetty on your system.

mingetty takes one argument, a device name. The port names for Linux virtual consoles are /dev/tty1, /dev/tty2, and so forth. mingetty assumes the given device name is relative to /dev. The baud rate for virtual consoles should generally be 38,400, which is why mingetty, unlike, for example, agetty, defaults to this value and does not require it to be explicitly specified.

Note that the action field for each mingetty entry is respawn. This means that init should restart the command given in the entry when the mingetty process dies, which is every time a user logs out.