Behind the Scenes of the Boot Process
 | Note |
|---|---|
This section looks at the x86 boot process, in particular. Depending on your system's architecture, your boot process may be slightly different. However, once the kernel is found and loaded by the system, the default Red Hat Linux boot process is identical across all architectures. Please see the Section called Differences in the Boot Process of Other Architectures for more information on a non-x86 boot process. |
When a computer is booted, the processor looks at the end of the system memory for the Basic Input/Output System (BIOS) and runs it. The BIOS program is written into read-only permanent memory and is always available for use. The BIOS provides the lowest level interface to peripheral devices and controls the first step of the boot process.
The BIOS tests the system, looks for and checks peripherals, and then looks for a drive to use to boot the system. Usually, it checks the floppy drive (or CD-ROM drive on many newer systems) for bootable media, if present, and then it looks to the hard drive. The order of the drives used for booting is usually controlled by a BIOS setting on the system. Once Red Hat Linux is installed on a hard drive of a system, the BIOS looks for a Master Boot Record (MBR) starting at the first sector on the first hard drive, loads its contents into memory, and passes control to it.
This MBR contains instructions on how to load the boot loader, GRUB or LILO (LInux LOader) depending on the boot loader you installed. The MBR then loads the boot loader, which takes over the process (if the boot loader is installed in the MBR). In the default Red Hat Linux configuration, GRUB or LILO uses the settings in the MBR to display boot options and allow for user input on which operating system to actually start up.
But this begs the question: How does the boot loader in the MBR know what to do when the MBR is read? LILO actually has already written the instructions there through use of the lilo program with in turn reads the /etc/lilo.conf configuration file. The boot instructions for GRUB written in the /boot/grub/grub.conf configuration file. For more information about GRUB, see Chapter 4.
Options in /etc/lilo.conf
Most of the time, you will have no need to change the Master Boot Record on your hard drive unless you need to boot a newly installed operating system or want to use a new kernel. If you do need to create a new MBR using LILO but using a different configuration, you will need to log in as root, edit /etc/lilo.conf, and run the lilo command again.
 | Warning |
|---|---|
If you are planning to edit /etc/lilo.conf, be sure to make a backup copy of the file before making any changes. Also, be sure that you have a working boot floppy available so that you will be able to boot the system and make changes to the MBR if there is a problem. See the man pages for mkbootdisk for more information on creating a boot disk. |
The file /etc/lilo.conf is used by lilo to determine which operating system to utilize or which kernel to start, as well as to know where to install itself (for example, /dev/hda for the first MBR of the first IDE hard drive). A sample /etc/lilo.conf file looks like this:
boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message lba32 default=linux image=/boot/vmlinuz-2.4.0-0.43.6 label=linux initrd=/boot/initrd-2.4.0-0.43.6.img read-only root=/dev/hda5 other=/dev/hda1 label=dos |
This example shows a system configured to boot two operating systems: Red Hat Linux and DOS. Here is a deeper look at a few of the lines of this file (your /etc/lilo.conf may look a little different):
boot=/dev/hda tells LILO to install itself on the first hard disk on the first IDE controller.
map=/boot/map locates the map file. In normal use, this should not be modified.
install=/boot/boot.b tells LILO to install the specified file as the new boot sector. In normal use, this should not be altered. If the install line is missing, LILO will assume a default of /boot/boot.b as the file to be used.
The existence of prompt tells LILO to show you whatever is referenced in the message line. While it is not recommended that you remove the prompt line, if you do remove it, you can still get a prompt by holding down the
[Shift] key while your machine starts to boot.timeout=50 sets the amount of time that LILO will wait for user input before proceeding with booting the default line entry. This is measured in tenths of a second, with 50 as the default.
message=/boot/message refers to the screen that LILO displays to let you select the operating system or kernel to boot.
lba32 describes the hard disk geometry to LILO. Another common entry here is linear. You should not change this line unless you are very aware of what you are doing. Otherwise, you could put your system in an unbootable state.
default=linux refers to the default operating system for LILO to boot from the options listed below this line. The name linux refers to the label line below in each of the boot options.
image=/boot/vmlinuz-2.4.0-0.43.6 specifies the linux kernel to boot with this particular boot option.
label=linux names the operating system option in the LILO screen. In this case, it is also the name referred to by the default line.
initrd=/boot/initrd-2.4.0-0.43.6.img refers to the initial ram disk image that is used at boot time to actually initialize and start the devices that makes booting the kernel possible. The initial ram disk is a collection of machine-specific drivers necessary to operate a SCSI card, hard drive, or any other device needed to load the kernel. You should never try to share initial ram disks between machines.
read-only specifies that the root partition (see the root line below) is read-only and cannot be altered during the boot process.
root=/dev/hda5 tells LILO what disk partition to use as the root partition.
LILO then shows the Red Hat Linux initial screen with the different operating
systems or kernels it has been configured to boot. If you only have
Red Hat Linux installed and have not changed anything in
/etc/lilo.conf, you will only see
linux as an option. If you install SMP
kernel support, you will see linux-up as an
option. If you have set up LILO to boot other operating systems as
well, this screen is your chance to select what operating system will
boot. Use your arrow keys to highlight the operating system and press
If you would like to have a command prompt to enter commands to LILO,
press
If LILO is booting Linux, it first loads the kernel into memory, which is a vmlinuz file (for example, vmlinuz-2.4.0-xx) located in the /boot/ directory. Then the kernel passes control to init.
| Warning |
|---|---|
Do not remove the /initrd/ directory for any reason. Removing this directory will cause your system to fail to boot with a kernel panic error message. |
At this point, with the kernel loaded into memory and operational, Linux is already started, although at a very basic level. However, with no applications utilizing the kernel and with no ability for the user to provide meaningful input to the system, not much can be done with it. The init program solves this problem by bringing up the various services that allow the system to perform its particular role.
Init
The kernel finds /sbin/init and executes it. It is the init command which coordinates the rest of the boot process.
When init 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 filesystems, and so on. Basically, rc.sysinit takes care of everything that your system needs to have done at system initialization. Most systems use a clock, so on them rc.sysinit uses the /etc/sysconfig/clock file to initialize the clock. If you have special serial port processes that need to be initialized, rc.sysinit may also run rc.serial.
Then, init runs the /etc/inittab script, which describes how the system should be set up in each runlevel and sets the default runlevel. (See the Section called Init Runlevels for more information on init runlevels.) This file states, among other things, that /sbin/update should be run whenever a runlevel starts. The update program is used to flush dirty buffers back to disk.
Whenever the runlevel changes, init uses the scripts in the /etc/rc.d/init.d/ directory to start and stop various services, such as a Web server, DNS server, and so on. First, init sets the source function library for the system (commonly /etc/rc.d/init.d/functions), which spells out how to start or kill a program and how to find out the PID of a program. Then, init determines the current and the previous runlevel.
Next, init starts all of the background processes necessary for the system to run by looking in the appropriate rc directory for that runlevel (/etc/rc.d/rc<X>.d/, where the <X> is a numerical value between 0 and 6). The init command then runs each of the kill scripts (their file name starts with a K) with a stop parameter. Then, init runs all of the start scripts (their file names start with an S) in the appropriate runlevel directory with a start so that all services and applications are started correctly. In fact, after the system is finished booting you can log in as root and execute these same scripts manually with the command /etc/rc.d/init.d/httpd stop or /sbin/service httpd stop. This will stop the httpd server.
None of the scripts that actually start and stop the services are located in the /etc/rc.d/rc<X>.d/ directory. Rather, all of the files in /etc/rc.d/rc<X>.d/ are symbolic links that point to actual scripts located in the /etc/rc.d/init.d/ directory. A symbolic link is nothing more than a file that points to another file, and they are used in this case because they can be created and deleted without affecting the actual script that kills or starts the service. The symbolic links to the various scripts are numbered in a particular order so that they start in that order. You can change the order in which the services start up or are killed by changing the name of the symbolic link that refers to the script that actually starts or kills the service. You can give symbolic links the same number as other symbolic links if you want that service start or stop right before or after another service.
For example, for runlevel 5, init looks into the /etc/rc.d/rc5.d/ directory and might finds the following (your system and configuration may vary):
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 S97rhnsd -> ../init.d/rhnsd S99local -> ../rc.local |
These symbolic links tell init that it needs to 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, and rhnsd. The last thing init does is run /etc/rc.d/rc.local to run any special scripts configured for that host. At this point, the system is considered to be operating at runlevel 5.
After init has progressed through all of the runlevels, the /etc/inittab script forks a getty process for each virtual console (login prompts) for each runlevel (runlevels 2 through 5 get all six; runlevel 1, which is single user mode, only gets one console; runlevels 0 and 6 get no virtual consoles). Basically, getty opens lines to tty devices [1], sets their modes, prints the login prompt, gets the user's name, and then initiates a login process for that user. This allows users to authenticate themselves to the system and begin to use it.
Also, /etc/inittab tells init
how it should handle a user hitting
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.
At this point, you should be looking at a login prompt. All that, and it only took a few seconds.
SysV Init
The SysV init is the standard init process used under Red Hat Linux to control the startup of software at boot time, because it is easier to use and more powerful and flexible than the traditional BSD init.
SysV init also differs from BSD init in that the configuration files are in the /etc/rc.d/ directory instead of residing directly in /etc/. In the /etc/rc.d/ directory, you will find rc, rc.local, rc.sysinit, and the following directories:
init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d |
SysV init represents each of the init runlevels with a separate directory, using init and symbolic links in each of the directories to actually stop and start the services as the system moves from runlevel to runlevel.
In summary, the chain of events for a SysV init boot is as follows:
The kernel looks in the /sbin/ directory for the init command.
init runs the /etc/rc.d/rc.sysinit script.
rc.sysinit handles most of the boot loader's processes and then runs rc.serial (if it exists).
init runs all the scripts for the default runlevel.
init runs the /etc/rc.d/rc.local script.
The default runlevel is decided in /etc/inittab. You should have a line close to the top like:
id:3:initdefault: |
The default runlevel is 3 in this example, the number after the first colon. If you want to change it, you can edit /etc/inittab by hand. Be very careful when you are editing the inittab file as typos can cause your system to become unbootable without a using a boot diskette or going into rescue mode.
If you use LILO as your boot loader, you can fix the
inittab file by rebooting, accessing the
boot: prompt with
boot: linux single |
If you are using GRUB as your boot loader, you can fix the inittab file with the following steps.
In the graphical GRUB boot loader screen, select the Red Hat Linux boot label and press
[e] to edit it.Arrow down to the kernel line and press
[e] to edit it.At the prompt, type single and press
[Enter] .You will be returned to the GRUB screen with the kernel information. Press the
[b] key to boot the system into single user mode.
 | Tip |
|---|---|
It is also possible to change runlevels at boot-time with GRUB using the same method as above except replacing single with, for example, 3 or 5. The rest of the steps are exactly as they are shown above. |
This should allow you to boot into single-user mode so you can re-edit inittab to its previous value.
Next, we will discuss information in the files within the /etc/sysconfig/ directory which define the parameters used by different system services when they start up.