System Initialization

When you turn on your computer, a lot happens even before Fedora starts up. Here are the basic steps that occur each time you boot up your computer to run Fedora:

1. Boot hardware — Based on information in the computer’s read-only memory (referred to as the BIOS), your computer checks and starts up the hardware. Some of that information tells the computer which devices (floppy disk, CD, hard disk, and so on) to check to find the bootable operating system.

2. Start boot loader — Typically, the BIOS checks the master boot record on the primary hard disk to see what to load next. With Fedora installed, the GRUB boot loader is started, allowing you to choose to boot Fedora or another installed operating system.

3. Boot the kernel — Assuming that you selected to boot Fedora, the Linux kernel is loaded. That kernel mounts the basic file systems and transfers control to the init process. The rest of this section describes what happens after the kernel hands off control of system startup to the init process.

Starting init

In the boot process, the transfer from the kernel phase (the loading of the kernel, probing for devices, and loading drivers) to init is indicated by the following lines:

INIT: version 2.85 booting                             Welcome to Fedora Core                              Press "I" to enter interactive startup.  

The init program, part of the SysVinit RPM package, is now in control. Known as “the father of all processes,” the output from ps always lists init as PID (process identifier) 1. Its actions are directed by the /etc/inittab file, which is reproduced next.

The inittab file

The following example shows the contents of the /etc/inittab file as it is delivered with Fedora:

#  # inittab       This file describes how the INIT process should set up  #               the system in a certain run level.        .        .        .  id:3:initdefault:    # System initialization.  si::sysinit:/etc/rc.d/rc.sysinit    l0:0:wait:/etc/rc.d/rc 0  l1:1:wait:/etc/rc.d/rc 1  l2:2:wait:/etc/rc.d/rc 2  l3:3:wait:/etc/rc.d/rc 3  l4:4:wait:/etc/rc.d/rc 4  l5:5:wait:/etc/rc.d/rc 5  l6:6:wait:/etc/rc.d/rc 6    # Trap CTRL-ALT-DELETE  ca::ctrlaltdel:/sbin/shutdown -t3 -r now    # When our UPS tells us power has failed, assume we have a few minutes  # of power left. Schedule a shutdown for 2 minutes from now.  # This does, of course, assume you have powerd installed and your  # UPS connected and working correctly.  pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"                # If power was restored before the shutdown kicked in, cancel it.  pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"                # Run gettys in standard runlevels  1:2345:respawn:/sbin/mingetty 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    # Run xdm in runlevel 5  # xdm is now a separate service  x:5:respawn:/etc/X11/prefdm -nodaemon  

Format of the inittab file

The plain-text inittab file consists of several colon-separated fields in the format:

 id:runlevels:action:command  

The id field is a unique identifier, one to four alphanumeric characters in length that represents a particular action to take during system startup. The runlevels field contains a list of run levels in which the command will be run. Common run levels are 0, 1, 2, 3, 4, 5, and 6 (s and S represent single-user mode, which is equivalent to 1). Run levels 7, 8, and 9 can also be used as the special run levels associated with the on demand action (a, b, and c, which are equivalent to A, B, and C). The next field represents the type of action to be taken by init (valid actions and the results of those actions are listed in Table 12-3), and the last field is the actual command that is to be executed.

Table 12-3: Valid init Actions

Action	How the Command Is Run
once	The command is executed once when entering the specified run level.
wait	The same as once, but init waits for the command to finish before continuing with other inittab entries.
respawn	The process is monitored, and a new instance is started if the original process terminates.
powerfail	The command is executed on receiving a SIGPWR signal from software associated with a UPS unit.
powerwait	The same as powerfail, but init waits for the command to finish.
powerwaitok	The command is executed on receiving a SIGPWR signal if the /etc/powerstatus file contains the word OK. This is generally accomplished by the UPS software, and indicates that a normal power level has been restored.
ondemand	The command is executed when init is manually instructed to enter one of the special run levels a, b, or c (equivalent to A, B, and C, respectively). No change in run level actually takes place. The program is restarted if the original process terminates.
sysinit	The command is executed during the system boot phase; the runlevels field is ignored.
boot	The command is executed during the system boot phase, after all sysinit entries have been processed; the runlevels field is ignored.
bootwait	The same as boot, but init waits for the command to finish before continuing with other inittab entries; the runlevels field is also ignored.
initdefault	The run level to enter after completing the boot and sysinit actions.
off	Nothing happens (perhaps useful for testing and debugging).
ctrlaltdel	Traps the Ctrl+Alt+Del key sequence, and is typically used to gracefully shut down the system.
kbrequest	Used to trap special key sequences, as interpreted by the keyboard handler.

Breakdown of the inittab file

Because the inittab file is a configuration file, not a sequential shell script, the order of lines is not significant. Lines beginning with a hash (#) character are comments and are not processed.

The first non-commented line in the preceding sample inittab file sets the default run level to 3. A default of 3 means that, following the completion of all commands associated with the sysinit, boot, and bootwait actions, run level 3 will be entered (booting to a text-based login). The other common initdefault level is run level 5 (booting to a GUI login screen). Table 12-4 describes each of the run levels and helps you choose the run level that is best suited as the default in your environment.

Table 12-4: Possible Run Levels

Run Level	What Happens in This Run Level
0	All processes are terminated and the machine comes to an orderly halt. As the inittab comments point out, this is not a good choice for initdefault, because as soon as the kernel, modules, and drivers are loaded, the machine will halt.
1, s, S	This is single-user mode, frequently used for system maintenance and where it may be preferable to have few processes running and no services activated. In single-user mode, the network is nonexistent, the X server is not running, and it is possible that some file systems are not mounted.
2	Multiuser mode. Multiple user logins are allowed, all configured file systems are mounted, and all processes except X, the at daemon, the xinetd daemon, and NIS/NFS are started. If your machine doesn’t have (or perhaps doesn’t need) a permanent network connection, this is a good choice for initdefault.
3, 4	Multiuser mode with network services. Run level 3 is the typical value for initdefault on a Fedora server, but run level 4 (generally left to be user-defined) is almost identical in a default Fedora configuration.
5	Multiuser mode with network services and X. This run level starts the X server and presents a graphical login window, visually resembling any of the more expensive UNIX-based workstations. This is a common initdefault value for a Fedora workstation or desktop system.
6	All processes are terminated and the machine is gracefully rebooted. Again, the comments in the inittab file mention that this is not a good choice for initdefault, perhaps even worse than run level 0. The effect is a possibly infinite cycle of booting, followed by rebooting.
7, 8, 9	Generally unused and undefined, these run levels have the potential to meet any needs not covered by the default options.
a, b, c, A, B, C	Used in conjunction with the ondemand action. These don’t really specify a run level but can launch a program or daemon "on demand" if so instructed.

Note 

If there is no initdefault specified in the inittab file, the boot sequence will be interrupted and you will be prompted to specify a default run level into which the machine will boot.

The next line in the inittab file instructs init to execute the /etc/rc.d/rc.sysinit script before entering the default run level. This script performs many initialization routines such as choosing a keymap file, checking and mounting root and proc file systems, setting the clock and hostname, configuring swap space, cleaning up temp files, and loading modules.

The seven following lines control the commands executed within each major run level. In each, the /etc/rc.d/rc script is called, using the desired run level as an argument. It, in turn, descends into the appropriate directory tree (for example, the /etc/rc3.d directory is entered for run level 3).

The ctrlaltdel action in the inittab file tells init to perform exactly what PC users would expect if the Ctrl, Alt, and Delete keys were pressed simultaneously. The system reboots itself in an orderly fashion (a switch to run level 6) after a three-second delay.

The next two lines (with their comments) deal with graceful shutdowns if you have an uninterruptible power supply (UPS) and software installed. The first line initiates a halt (a switch to run level 0) two minutes after receiving a signal from the UPS indicating a power failure. The second line cancels the shutdown in the event that power is restored.

The six getty lines start up virtual consoles to allow logins. These processes are always running in any of the multiuser run levels. When someone connected to a virtual console logs out, that getty process dies, then respawn action tells init to start a new getty process.

The last line indicates that as long as the system is in run level 5, the “preferred display manager” (xdm, gnome, KDE, and so on) will be running. This presents a graphical login prompt rather than the usual text-based login, and eliminates the need to run startx to start the GUI.