Hosting provided by:

Visit our blog, Open Sores: Tips From the Trenches

Red Hat Linux 8.0: The Official Red Hat Linux Reference Guide
Prev	Chapter 3. Boot Process, Init, and Shutdown	Next

A Detailed Look at the Boot Process

The very beginning of the boot process varies depending the platform on which you are booting Red Hat Linux. However, once the kernel is found and loaded by the system, the default boot process is identical across all architectures. In the example outlined below, the system will be an x86 computer.

The BIOS

When an x86 computer is booted, the processor looks at the end of system memory for the Basic Input/Output System or BIOS program and runs it. The BIOS controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. For this reason it is written into read-only, permanent memory and is always available for use.

Other platforms use different programs to perform low-level tasks roughly equivalent to those of the BIOS on an x86 system. For instance, Itanium-based computers use the Extensible Firmware Interface (EFI) Shell, while Alpha systems use the SRM console.

Once loaded, the BIOS tests the system, looks for and checks peripherals and then locates a valid device with which to boot the system. Usually, it first checks any floppy drives and CD-ROM drives present for bootable media, then it looks to the system's hard drives. The order of the drives searched for booting can often be controlled with a setting in BIOS. Often, the first hard drive set to boot is the C drive or the master IDE device on the primary IDE bus. The BIOS loads whatever program is residing in the first sector of this device, called the Master Boot Record or MBR, into memory. The MBR is only 512 bytes in size and contains machine code instructions for booting the machine along with the partition table. Once found and loaded the BIOS passes control whatever program is on the MBR.

The Boot Loader

This section looks at the boot process for the x86 platform. Depending on your system's architecture, the boot process may differ slightly. Please see the Section called Differences in the Boot Process of Other Architectures for a brief overview of non-x86 boot processes.

Linux boot loaders for the x86 platform are broken into at least two stages. The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory. Under Red Hat Linux you can install one of two boot loaders: GRUB or LILO. GRUB is the default boot loader, but LILO is available for those who require it for their hardware setup or who prefer it. For more information about configuring and using GRUB or LILO, see Chapter 4.

If you are using LILO under Red Hat Linux, the second stage boot loader uses information on the MBR to determine what boot options are available to the user. This means that any time a configuration change is made or you upgrade your kernel manually, you must run the /sbin/lilo -v -v command to write the appropriate information to the MBR. For details on doing this, see the Section called LILO in Chapter 4.

GRUB, on the other hand, can read ext2 partitions and therefore simply loads its configuration file — /boot/grub/grub.conf — when the second stage loader is called. See the Section called GRUB Menu Configuration File in Chapter 4 for information on how to edit this file.

Do you need help?

Tip Tip

If you upgrade the kernel using the Red Hat Update Agent, the MBR or the /boot/grub/grub.conf will be updated automatically. For more information on RHN, refer to the following URL, https://rhn.redhat.com

Once the second stage boot loader is in memory, it presents the user with the Red Hat Linux initial, graphical screen showing the different operating systems or kernels it has been configured to boot. If you have only Red Hat Linux installed and have not changed anything in the /etc/lilo.conf or /boot/grub/grub.conf, you will only see one option for booting.

If you have configured the boot loader to boot other operating systems, this screen gives you the opportunity to select it. Use the arrow keys to highlight the operating system and press [Enter]. If you do nothing, the boot loader will load the default selection.

Note Note

If you installed Symmetric Multi-Processor (SMP) kernel support, you will see more than one option the first time you boot your system. Under LILO you will see linux and linux-up. Under GRUB you will see Red Hat Linux (kernel version) and Red Hat Linux (kernel version-smp). Thelinux or Red Hat Linux (kernel version-smp) option is the SMP kernel. If you experience any problems with the SMP kernel, select the linux-up or non-SMP kernel upon rebooting.

If you need to alter the command line arguments to the kernel, see Chapter 4. For information on changing the runlevel at the GRUB or LILO prompt, see the Section called SysV Init.

Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The proper binary is the /boot/vmlinuz-2.4.x-xx file that corresponds to the boot loader's settings. Next the boot loader places the appropriate initial RAM disk image, called an initrd, into memory. The initrd is used by the kernel to load any drivers not compiled into it that are necessary to boot the system. This is particularly important if you have SCSI hard drives or are using the ext3 file system [1].

Do you need more help?

Warning Warning

Do not remove the /initrd/ directory from the file system for any reason. Removing this directory will cause your system to fail with a kernel panic error message at boot time.

Once the kernel and the initrd image are loaded into memory, the boot loader hands control of the boot process to the kernel.

The Kernel

When the kernel loads, it immediately initializes and configures the computer's memory. Next it configures the various hardware attached to the system, including all processors and I/O subsystems, as well as any storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers. Next it initializes file system-related virtual devices, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory it once occupied.

After the kernel has initialized all the devices on the system, it creates a root device, mounts the root partition read-only, and frees unused memory.

At this point, with the kernel loaded into memory and operational. However, with no user applications to give the user the ability to provide meaningful input to the system, not much can be done with it.

To set up the user environment, the kernel starts the /sbin/init command.

The `/sbin/init` Program

The init program coordinates the rest of the boot process and configures the environment for the user.

Can we help you?

When the init command starts, it becomes the parent or grandparent of all of the processes that start up automatically on a Red Hat Linux system. First, it runs the /etc/rc.d/rc.sysinit script, which sets your environment path, starts swap, checks the file systems, and so on. Basically, rc.sysinit takes care of everything that your system needs to have done at system initialization. For example, most systems use a clock, so on them rc.sysinit reads the /etc/sysconfig/clock configuration file to initialize the clock. Another example is if you have special serial port processes which must be initialized, rc.sysinit will execute the /etc/rc.serial file.

The init command then runs the /etc/inittab script, which describes how the system should be set up in each SysV init runlevel [2]. Among other things, the /etc/inittab sets the default runlevel and dictates that /sbin/update should be run whenever it starts a given runlevel [3].

Next, the init command sets the source function library, /etc/rc.d/init.d/functions, for the system. This spells out how to start or kill a program and how to determine the PID of a program.

The init program starts all of the background processes by looking in the appropriate rc directory for the runlevel specified as default in /etc/inittab. The rc directories are numbered to corresponds to the runlevel they represent. For instance, /etc/rc.d/rc5.d/ is the directory for runlevel five.

When booting to runlevel 5, the init program looks in the /etc/rc.d/rc5.d/ directory to determine which processes to start and stop. Below is an example listing for a runlevel 5, /etc/rc.d/rc5.d/ directory:
K01pppoe -> ../init.d/pppoe K05innd -> ../init.d/innd K10ntpd -> ../init.d/ntpd K15httpd -> ../init.d/httpd K15mysqld -> ../init.d/mysqld K15pvmd -> ../init.d/pvmd K16rarpd -> ../init.d/rarpd K20bootparamd -> ../init.d/bootparamd K20nfs -> ../init.d/nfs K20rstatd -> ../init.d/rstatd K20rusersd -> ../init.d/rusersd K20rwalld -> ../init.d/rwalld K20rwhod -> ../init.d/rwhod K25squid -> ../init.d/squid K28amd -> ../init.d/amd K30mcserv -> ../init.d/mcserv K34yppasswdd -> ../init.d/yppasswdd K35dhcpd -> ../init.d/dhcpd K35smb -> ../init.d/smb K35vncserver -> ../init.d/vncserver K45arpwatch -> ../init.d/arpwatch K45named -> ../init.d/named K50snmpd -> ../init.d/snmpd K54pxe -> ../init.d/pxe K55routed -> ../init.d/routed K60mars-nwe -> ../init.d/mars-nwe K61ldap -> ../init.d/ldap K65kadmin -> ../init.d/kadmin K65kprop -> ../init.d/kprop K65krb524 -> ../init.d/krb524 K65krb5kdc -> ../init.d/krb5kdc K75gated -> ../init.d/gated K80nscd -> ../init.d/nscd K84ypserv -> ../init.d/ypserv K90ups -> ../init.d/ups K96irda -> ../init.d/irda S05kudzu -> ../init.d/kudzu S06reconfig -> ../init.d/reconfig S08ipchains -> ../init.d/ipchains S10network -> ../init.d/network S12syslog -> ../init.d/syslog S13portmap -> ../init.d/portmap S14nfslock -> ../init.d/nfslock S18autofs -> ../init.d/autofs S20random -> ../init.d/random S25netfs -> ../init.d/netfs S26apmd -> ../init.d/apmd S35identd -> ../init.d/identd S40atd -> ../init.d/atd S45pcmcia -> ../init.d/pcmcia S55sshd -> ../init.d/sshd S56rawdevices -> ../init.d/rawdevices S56xinetd -> ../init.d/xinetd S60lpd -> ../init.d/lpd S75keytable -> ../init.d/keytable S80isdn -> ../init.d/isdn S80sendmail -> ../init.d/sendmail S85gpm -> ../init.d/gpm S90canna -> ../init.d/canna S90crond -> ../init.d/crond S90FreeWnn -> ../init.d/FreeWnn S90xfs -> ../init.d/xfs S95anacron -> ../init.d/anacron S95firstboot -> ../init.d/firstboot S97rhnsd -> ../init.d/rhnsd S99local -> ../rc.local S99mdmonitor -> ../init.d/mdmonitor

As you can see, none of the scripts that actually start and stop the services are located in the /etc/rc.d/rc5.d/ directory. Rather, all of the files in /etc/rc.d/rc5.d/ are symbolic links pointing to scripts located in the /etc/rc.d/init.d/ directory. Symbolic links are used in each of the rc directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference.

The name of each symbolic link begin with either a K or an S. The K links are processes that are killed on that runlevel, while those beginning with an S are started.

The init command first stops all of the K symbolic links in the directory by issuing the /etc/rc.d/init.d/<command> stop command, where <command> is the process to be killed. It then starts all of the S symbolic links by issuing /etc/rc.d/init.d/<command> start.

Can't find what you're looking for?

Tip Tip

After the system is finished booting, you can log in as root and execute these same scripts to start and stop services. For instance, the command /etc/rc.d/init.d/httpd stop will stop the Apache Web server.

Each of the symbolic links are numbered to dictate start order. You can change the order in which the services are started or stopped by changing this number. Those symbolic links with the same number are started alphabetically.

In the example /etc/rc.d/rc5.d/ directory above, the init command will kill pppoe, innd, ntpd, httpd, mysqld, pvmd, rarpd, bootparamd, nfs, rstatd, rusersd, rwalld, rwhod, squid, amd, mcserv, yppasswdd, dhcpd, smb, vncserver, arpwatch, named, snmpd, pxe, routed, mars-nwe, ldap, kadmin, kprop, krb524, krb5kdc, gated, nscd, ypserv, ups, and irda.

After all processes are killed, init looks into the same directory and finds start scripts for kudzu, reconfig, ipchains, portmap, nfslock, autofs, random, netfs, apmd, identd, atd, pcmcia, sshd, rawdevices, xinetd, lpd, keytable, isdn, sendmail, gpm, canna, crond, FreeWnn, xfs, anacron, firstboot, rhnsd, and mdmonitor.

The last thing the init program does is run any scripts located in /etc/rc.d/rc.local (see the Section called Running Programs at Boot Time for more on customizing the rc.local file). At this point, the system is considered to be operating at runlevel 5.

After the init command has progressed through the appropriate rc directory for the runlevel, the /etc/inittab script forks a getty process for each virtual console (login prompts) allocated to the runlevel. Runlevels 2 through 5 get all six virtual consoles, while runlevel 1 (single user mode) gets only one and runlevels 0 and 6 get none. The getty process opens communication pathways to tty devices [4], sets their modes, prints the login prompt, gets the user name, and initiates the login process for the user.

In runlevel 5, /etc/inittab runs a script called /etc/X11/prefdm. The prefdm script runs the preferred X display manager, gdm if you are running GNOME or kdm if you are running KDE, based on the contents of the /etc/sysconfig/desktop/ directory.

Don't know where to look next?

Finally, the init command runs the /etc/rc.d/rc.local script.

At this point, you should be looking at a login prompt.

Notes

[1]	For details on making an initrd, see the section about converting to an ext3 file system in the Official Red Hat Linux Customization Guide.
[2]	For more information on SysV init, see the Section called SysV Init. For more about init runlevels, see the Section called Init Runlevels.
[3]	The `update` command is used to flush dirty buffers back to disk.
[4]	See the Section called `/proc/tty/` in Chapter 2 for more information on `tty` devices.

Prev	Home	Next
Boot Process, Init, and Shutdown	Up	Running Programs at Boot Time