The beginning of the boot process varies depending on the
hardware platform being used. However, once the kernel is found and
loaded by the boot loader, the default boot process is identical
across all architectures. This chapter focuses primarily on the x86
architecture.
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.
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 checks any diskette drives and CD-ROM drives
present for bootable media, then, failing that, looks to the
system's hard drives. In most cases, the order of the drives
searched while booting is controlled with a setting in the BIOS,
and it looks on the master IDE device on the primary IDE bus. The
BIOS then loads into memory whatever program is residing in the
first sector of this device, called the Master
Boot Record or MBR. The MBR is only
512 bytes in size and contains machine code instructions for
booting the machine, called a boot loader, along with the partition
table. Once the BIOS finds and loads the boot loader program into
memory, it yields control of the boot process to it.
This section looks at the default boot loader for the x86
platform, GRUB. Depending on the system's architecture, the boot
process may differ slightly. Refer to
Section 1.2.2.1 Boot Loaders for Other Architectures for
a brief overview of non-x86 boot loaders. For more information
about configuring and using GRUB, see Chapter 2 The GRUB Boot Loader.
A boot loader for the x86 platform is 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.
GRUB has the advantage of being able to read ext2 and ext3
partitions and load its configuration
file — /boot/grub/grub.conf —
at boot time. Refer to Section
2.7 GRUB Menu Configuration File for information on how
to edit this file.
 |
Tip |
| |
If upgrading the kernel using the Red Hat
Update Agent, the boot loader configuration file is updated
automatically. More information on Red Hat Network can be found
online at the following URL: https://rhn.redhat.com/.
|
Once the second stage boot loader is in memory, it presents the
user with a graphical screen showing the different operating
systems or kernels it has been configured to boot. On this screen a
user can use the arrow keys to choose which operating system or
kernel they wish to boot and press [Enter]. If no key is pressed, the boot loader
loads the default selection after a configurable period of time has
passed.
 |
Note |
| |
If Symmetric Multi-Processor (SMP) kernel support is installed,
more than one option is presented the first time the system is
booted. In this situation GRUB displays Red Hat Enterprise Linux (<kernel-version>-smp), which is
the SMP kernel, and Red Hat Enterprise
Linux (<kernel-version>), which is for
single processors.
If any problems occur using the SMP kernel, try selecting the a
non-SMP kernel upon rebooting.
|
Once the second stage boot loader has determined which kernel to
boot, it locates the corresponding kernel binary in the /boot/ directory. The kernel binary is named using
the following format — /boot/vmlinuz-<kernel-version> file (where
<kernel-version> corresponds to the
kernel version specified in the boot loader's settings).
For instructions on using the boot loader to supply command line
arguments to the kernel, refer to Chapter 2
The GRUB Boot Loader. For information on changing the
runlevel at the boot loader prompt, refer Section 2.8 Changing Runlevels at Boot
Time.
The boot loader then places one or more appropriate initramfs images into memory. Next, the kernel
decompresses these images from memory to /boot/, a RAM-based virtual file system, via
cpio. The initramfs is used by the kernel to load drivers and
modules necessary to boot the system. This is particularly
important if SCSI hard drives are present or if the systems use the
ext3 file system.
Once the kernel and the initramfs
image(s) are loaded into memory, the boot loader hands control of
the boot process to the kernel.
For a more detailed overview of the GRUB boot loader, refer to
Chapter 2 The GRUB Boot
Loader.
Once the kernel loads and hands off the boot process to the
init command, the same sequence of events
occurs on every architecture. So the main difference between each
architecture's boot process is in the application used to find and
load the kernel.
For example, the Itanium architecture uses the ELILO boot
loader, the IBM eServer pSeries architecture uses YABOOT, and the
IBM eServer zSeries and IBM S/390 systems use the z/IPL boot
loader.
Consult the Red Hat Enterprise Linux
Installation Guide specific to these platforms for information
on configuring their boot loaders.
When the kernel is loaded, it immediately initializes and
configures the computer's memory and configures the various
hardware attached to the system, including all processors, I/O
subsystems, and storage devices. It then looks for the compressed
initramfs image(s) in a predetermined
location in memory, decompresses it directly to /sysroot/, and loads all necessary drivers. Next,
it initializes virtual devices related to the file system, such as
LVM or software RAID, before completing the initramfs processes and freeing up all the memory
the disk image once occupied.
The kernel then creates a root device, mounts the root partition
read-only, and frees any unused memory.
At this point, the kernel is loaded into memory and operational.
However, since there are no user applications that allow meaningful
input to the system, not much can be done with the system.
To set up the user environment, the kernel executes the
/sbin/init program.
The /sbin/init program (also called
init) coordinates the rest of the boot
process and configures the environment for the user.
When the init command starts, it
becomes the parent or grandparent of all of the processes that
start up automatically on the system. First, it runs the /etc/rc.d/rc.sysinit script, which sets the
environment path, starts swap, checks the file systems, and
executes all other steps required for system initialization. For
example, most systems use a clock, so rc.sysinit reads the /etc/sysconfig/clock configuration file to
initialize the hardware clock. Another example is if there are
special serial port processes which must be initialized, rc.sysinit executes 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. Runlevels are a state, or mode, defined by the services listed in the SysV
/etc/rc.d/rc<x>.d/ directory, where <x> is the number of the runlevel. For
more information on SysV init runlevels, refer to Section 1.4 SysV Init
Runlevels.
Next, the init command sets the source
function library, /etc/rc.d/init.d/functions, for the system, which
configures how to start, kill, and 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 the
default in /etc/inittab. The rc directories are numbered to correspond to the
runlevel they represent. For instance, /etc/rc.d/rc5.d/ is the directory for runlevel
5.
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 of the /etc/rc.d/rc5.d/ directory:
K05innd -> ../init.d/innd
K05saslauthd -> ../init.d/saslauthd
K10dc_server -> ../init.d/dc_server
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12dc_client -> ../init.d/dc_client
K12FreeWnn -> ../init.d/FreeWnn
K12mailman -> ../init.d/mailman
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K20netdump-server -> ../init.d/netdump-server
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwhod -> ../init.d/rwhod
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30spamassassin -> ../init.d/spamassassin
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54dovecot -> ../init.d/dovecot
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K85mdmpd -> ../init.d/mdmpd
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13irqbalance -> ../init.d/irqbalance
S13portmap -> ../init.d/portmap
S15mdmonitor -> ../init.d/mdmonitor
S15zebra -> ../init.d/zebra
S16bgpd -> ../init.d/bgpd
S16ospf6d -> ../init.d/ospf6d
S16ospfd -> ../init.d/ospfd
S16ripd -> ../init.d/ripd
S16ripngd -> ../init.d/ripngd
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S27ypbind -> ../init.d/ypbind
S28autofs -> ../init.d/autofs
S40smartd -> ../init.d/smartd
S44acpid -> ../init.d/acpid
S54hpoj -> ../init.d/hpoj
S55cups -> ../init.d/cups
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S58ntpd -> ../init.d/ntpd
S75postgresql -> ../init.d/postgresql
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S87iiim -> ../init.d/iiim
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S96readahead -> ../init.d/readahead
S97messagebus -> ../init.d/messagebus
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
|
As illustrated in this listing, 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 begins 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.
|
Tip |
| |
After the system is finished booting, it is possible to 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 stops the Apache HTTP
Server.
|
Each of the symbolic links are numbered to dictate start order.
The order in which the services are started or stopped can be
altered by changing this number. The lower the number, the earlier
it is started. Symbolic links with the same number are started
alphabetically.
After the init command has progressed
through the appropriate rc directory for
the runlevel, the /etc/inittab script
forks an /sbin/mingetty process for each
virtual console (login prompt) allocated to the runlevel. Runlevels
2 through 5 have all six virtual consoles, while runlevel 1 (single
user mode) has one, and runlevels 0 and 6 have none. The /sbin/mingetty process opens communication pathways
to tty devices, sets their
modes, prints the login prompt, accepts the user's username and
password, and initiates the login process.
In runlevel 5, the /etc/inittab runs a
script called /etc/X11/prefdm. The
prefdm script executes the preferred X
display manager — gdm,
kdm, or xdm,
depending on the contents of the /etc/sysconfig/desktop file.
Once finished, the system operates on runlevel 5 and displays a
login screen.
