One of the most important jobs of any system administrator is managing system configuration. A Unix system's basic configuration is created during the process of system startup. Thus, a thorough understanding of the mechanics of system startup is needed for any administrator.

During system startup

• the system is assembled from parts
• system integrity is verified and hardware initialized
• subsystems, which are packages of software, are initialized

Improper startup means some subsystems or hardware may be unavailable.

Basic chronology of system startup

1. Boot loader phase

The ROM-resident boot program (such as the BIOS) begins the boot process. Once upon a time, this ROM-resident boot program booted the operating system itself. Today, it branches to the boot sector of the startup device to begin a second-level boot loader. Currently, the boot loader on linux is called grub.

The boot loader has some configuration that tells it where the kernel is located. It also is smart enough to read the linux filesystem to load the kernel. In the case of grub, it also loads some supporting data for early use by the kernel (the initrd file). The boot loader may also be smart enough to initiate a network boot.

2. Kernel phase

The kernel (and its initial small filesystem (initrd)) is loaded by the boot loader and the kernel is started. Since the state of the filesystem has not been ascertained, the kernel is assumed to be correct. This seems dangerous, but the kernel has a large number of consistency checks that it performs as it is initializing. If it finds an inconsistency at any time it aborts with a panic message. If the boot loader is smart enough (such as grub), you may be able to try to reboot the system with an alternate kernel. Otherwise, a rescue operation must be begun. More information on these issues will be discussed in Part Two.

The kernel is responsible for probing the hardware and enabling drivers to deal with components. The hardware should be in a ready state by the time this phase is entered so that the kernel will configure itself correctly to make the hardware available. Messages from this kernel phase of system initialization appear on the console (unless suppressed by a boot splash image via plymouth) and are saved in the dmesg file (/var/log/dmesg). After the system is booted, kernel boot messages may be examined from this file (as root) or as a normal user using the command dmesg. This file contains a lot of kernel noise, but some portions may yield helpful information.

The portion of the dmesg file above shows that this system has a single ATA disc, which is accessed using SCSI emulation (as sda:) and that disk has 9 partitions. It also identifies the disk as model ST320418AS. It also has a CD/DVDW drive. It also identifies the size of the disk, and some of the capabilities of both it and the CD/DVD drive. You can see at the bottom that the root filesystem was found and mounted (/dev/sda3)

Kernel initialization includes hardware initialization and initialization of support software that is so low-level that it must be incorporated into the kernel (as modules). Some of the files containing modules of the kernel must be available prior to mounting the root device, so they are part of a file that is made available to the kernel at boot, called the initrd (or initramfs) file. Most software initialization, however, must be done outside of the kernel (extra-kernel), in a separate process. 

3. Extra-kernel initialization

Initialization outside of the kernel must be performed in a process. As we learned in the section on processes, every process comes from another process. Since no processes yet exist, the kernel creates the first few processes spontaneously. They are used to house a few portions of the kernel that are "dressed up" to look like processes, but are really kernel code. This is done so that these functions can be controlled and monitored just like any other process. These 'kernel processes' have very low process-ids and include code to manage low-level functions such as the I/O system, the virtual memory subsystem, and the scheduler. 

After the creation of the kernel processes, it is time to start the first true process. This process, which is again created by the kernel spontaneously, is used to house the first program to be run, init.

Running the first real process encounters a chicken-and-egg situation. In order to run this process, the kernel must access the filesystem. However, the state of the filesystem has not yet been ascertained, and it is dangerous to begin operations on a filesystem that is inconsistent. This problem is traditionally solved by temporarily mounting the root of the filesystem read-only. Later, after the filesystems are checked during initialization outside of the kernel, the filesystem is remounted read-write.

There is one special extra-kernel process that is started by the kernel to make the boot process "pretty". This process is called plymouth, and it is responsible for generating a nice boot screen with a pretty progress bar (or whatever configuration has been set in its configuration file), suppressing the noisy (and confusing, if not alarming) kernel messages at boot time. plymouth is started in a process by the kernel if the kernel is invoked with either of the parameters splash or rhgb on the kernel command-line. The kernel command-line can be viewed after boot by examining /proc/cmdline.

Once init begins, it drives the remainder of system initialization.