Red Hat Linux 9: Red Hat Linux Reference Guide

Prev Chapter 1. Boot Process, Init, and Shutdown Next

1.2. A Detailed Look at the Boot Process

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
on the x86 architecture.

1.2.1. 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 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 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.

1.2.2. The Boot Loader

This section looks at the boot loaders for the x86 platform. Depending on the
system's architecture, the boot process may differ slightly. Please see Section
1.2.2.1 Boot Loaders for Other Architectures for a brief overview of non-x86 boot
loaders.
Under Red Hat Linux two boot loaders are available: GRUB or LILO. GRUB is
the default boot loader, but LILO is available for those who require or prefer it.
For more information about configuring and using GRUB or LILO, see Chapter 2
Boot Loaders.
Both 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.
GRUB is the newer boot loader and has the advantage of being able read ext2
and ext3 [1] partitions and load its configuration file — /boot/grub/grub.conf —
at boot time. See Section 2.7 GRUB Menu Configuration File for information on
how to edit this file.
With LILO, the second stage boot loader uses information on the MBR to
determine the boot options available to the user. This means that any time a
configuration change is made or kernel is manually upgraded, the /sbin/lilo -v
-v command must be executed to write the appropriate information to the MBR.
For details on doing this, see Section 2.8 LILO.

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 the
Red Hat Linux initial, 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 will load the default selection after a
configurable period of time has passed.

Note

If Symmetric Multi-Processor (SMP) kernel support is installed, there

will be more than one option present the first time the system is
booted. In this situation, LILO will display linux, which is the SMP
kernel, and linux-up, which is for single processors. GRUB displays
Red Hat Linux (<kernel-version>-smp), which is the SMP kernel,
 and Red Hat 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, see Chapter 2 Boot Loaders. For information on changing the runlevel
at the GRUB or LILO prompt, see Section 2.10 Changing Runlevels at Boot
Time.
The boot loader then places the appropriate initial RAM disk image, called an
initrd, into memory. The initrd is used by the kernel to load drivers necessary
to boot the system. This is particularly important if SCSI hard drives are present
or if the systems uses the ext3 file system [2].

Warning

Do not remove the /initrd/ directory from the file system for any
reason. Removing this directory will cause the 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.
For a more detailed overview of the GRUB and LILO boot loaders, see Chapter 2
Boot Loaders.

1.2.2.1. Boot Loaders for Other Architectures

Once the Red Hat Linux 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 Alpha architecture uses the aboot boot loader, while the
Itanium architecture uses the ELILO boot loader.
Consult the Red Hat Linux Installation Guide specific to these platforms for
information on configuring their boot loaders.

1.2.3. The Kernel

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 initrd image in a predetermined location in memory,
decompresses it, mounts it, and loads all necessary drivers. Next, it initializes
virtual devices related to the file system, such as LVM or software RAID before
unmounting the initrd disk image 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 it.
In order to set up the user environment, the kernel executes the /sbin/init
program.

1.2.4. 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 a Red Hat Linux system. First, it runs
the /etc/rc.d/rc.sysinit script, which sets the environment path, starts swap,
checks the file systems, and takes care of everything the 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
hardware clock. Another example is if there are 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 [3]. Among other things, the
/etc/inittab sets the default runlevel and dictates that /sbin/update should be
run whenever it starts a given runlevel [4].
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 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
K10psacct -> ../init.d/psacct
K12cWnn -> ../init.d/cWnn
K12FreeWnn -> ../init.d/FreeWnn
K12kWnn -> ../init.d/kWnn
K12mysqld -> ../init.d/mysqld
K12tWnn -> ../init.d/tWnn
K15httpd -> ../init.d/httpd
K15postgresql -> ../init.d/postgresql
K16rarpd -> ../init.d/rarpd
K20bootparamd -> ../init.d/bootparamd
K20iscsi -> ../init.d/iscsi
K20netdump-server -> ../init.d/netdump-server
K20nfs -> ../init.d/nfs
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwalld -> ../init.d/rwalld
K20rwhod -> ../init.d/rwhod
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35atalk -> ../init.d/atalk
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K35winbind -> ../init.d/winbind
K40mars-nwe -> ../init.d/mars-nwe
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K45smartd -> ../init.d/smartd
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K54pxe -> ../init.d/pxe
K55routed -> ../init.d/routed
K61ldap -> ../init.d/ldap
K65identd -> ../init.d/identd
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ntpd -> ../init.d/ntpd
K74ups -> ../init.d/ups
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K84bgpd -> ../init.d/bgpd
K84ospf6d -> ../init.d/ospf6d
K84ospfd -> ../init.d/ospfd
K84ripd -> ../init.d/ripd
K84ripngd -> ../init.d/ripngd
K85zebra -> ../init.d/zebra
K90isicom -> ../init.d/isicom
K92ipvsadm -> ../init.d/ipvsadm
K95firstboot -> ../init.d/firstboot
S00microcode_ctl -> ../init.d/microcode_ctl
S05kudzu -> ../init.d/kudzu
S08ip6tables -> ../init.d/ip6tables
S08ipchains -> ../init.d/ipchains
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13portmap -> ../init.d/portmap
S14nfslock -> ../init.d/nfslock
S17keytable -> ../init.d/keytable
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S28autofs -> ../init.d/autofs
S44acpid -> ../init.d/acpid
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S80sendmail -> ../init.d/sendmail
S80spamassassin -> ../init.d/spamassassin
S84privoxy -> ../init.d/privoxy
S85gpm -> ../init.d/gpm
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90cups -> ../init.d/cups
S90xfs -> ../init.d/xfs
S95anacron -> ../init.d/anacron
S95atd -> ../init.d/atd
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
S99mdmonitor -> ../init.d/mdmonitor

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 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.

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 will stop the Apache
Web 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. Those symbolic links with the same
number are started alphabetically.

Note

One of the last things the init program executes is the

 /etc/rc.d/rc.local file. This file is useful for system customization.
See Section 1.3 Running Additional Programs at Boot Time for more
on using the rc.local file.

After the init command has progressed through the appropriate rc directory for
the runlevel, the /etc/inittab script forks a /sbin/mingetty 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 /sbin/mingetty process opens communication
pathways to tty devices [5], sets their modes, prints the login prompt, gets the
user name, and initiates the login process for the user.
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.
At this point, the system is operating on runlevel 5 and displaying a login screen.

Notes

[1] GRUB reads ext3 file systems as ext2, disregarding the journal file. See
the chapter titled The ext3 File System in the Red Hat Linux
Customization Guide for more information on the ext3 file system.

[2] For details on making an initrd, see the chapter titled The ext3 File
System in the Red Hat Linux Customization Guide.

[3] For more information on SysV init runlevels, see Section 1.4 SysV Init
Runlevels.

[4] The update command is used to flush dirty buffers back to disk.

[5] See Section 5.3.11 /proc/tty/ for more information on tty devices

1.3. Running Additional Programs at Boot Time

The /etc/rc.d/rc.local script is executed by the init command at boot time or
when changing runlevels. Adding commands to this script is an easy way to
perform necessary tasks like starting special services or initialize devices without
writing complex initialization scripts in the /etc/rc.d/init.d/ directory and
creating symbolic links.
The /etc/rc.serial script is used if serial ports must be setup at boot time. This
script runs setserial commands to configure the system's serial ports. See the
setserial man page for more information.

1.4. SysV Init Runlevels

The SysV init runlevel system provides a standard process for controlling which
programs init launches or halts when initializing a runlevel. SysV init was
chosen because it is easier to use and more flexible than the traditional BSD-
style init process.
The configuration files for SysV init are located in the /etc/rc.d/ directory.
Within this directory, are the rc, rc.local, rc.sysinit, and, optionally, the
rc.serial scripts as well as the following directories:

init.d/
rc0.d/
rc1.d/
rc2.d/
rc3.d/
rc4.d/
rc5.d/
rc6.d/

The init.d/ directory contains the scripts used by the /sbin/init command
when controlling services. Each of the numbered directories represent the six
default runlevels configured by default under Red Hat Linux.

1.4.1. Runlevels
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.

The idea behind SysV init runlevels revolves around the fact that different
systems can be used in a different ways. For example, a server runs more
efficiently without the drag on system resources created by the X Window
System. Other times, a system administrator may need to operate the system at
a lower runlevel to perform diagnostic tasks, like fixing disk corruption in runlevel
1, when no other users can possibly be on the system.
The characteristics of a given runlevel determines which services are halted and
started by init. For instance, runlevel 1 (single user mode) halts any network
services, while runlevel 3 starts these services. By assigning specific services to
be halted or started on a given runlevel, init can quickly change the mode of the
machine without the user manually stopping and starting services.
The following runlevels are defined by default for Red Hat Linux:
 • 0 — Halt
• 1 — Single-user text mode
• 2 — Not used (user-definable)
• 3 — Full multi-user text mode
• 4 — Not used (user-definable)
• 5— Full multi-user graphical mode (with an X-based login
screen)
• 6 — Reboot
In general, users operate Red Hat Linux at runlevel 3 or runlevel 5 — both full
multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific
needs. since they are not used.
The default runlevel for the system is listed in /etc/inittab. To find out the
default runlevel for a system, look for the line similar to the one below near the
top of /etc/inittab:

id:5:initdefault:

The default runlevel listed in the example above is five, as the number after the
first colon indicates. To change it, edit /etc/inittab as root.

Warning

Be very careful when editing /etc/inittab. Simple typos can cause

the system to become unbootable. If this happens, either use a boot
diskette, enter single-user mode, or enter rescue mode to boot the
computer and repair the file.
For more information on single-user and rescue mode, see the
chapter titled Rescue Mode in the Red Hat Linux Customization
Guide.

It is possible to change the default runlevel at boot-time by modifying the

arguments passed by the boot loader to the kernel. For information on changing
the runlevel at boot time, see Section 2.10 Changing Runlevels at Boot Time.

1.4.2. Runlevel Utilities

One of the best ways to configure runlevels is to use an initscript utility. These
tools are designed to simplify the task of maintaining files in the SysV init
directory hierarchy and relieves system administrators from having to directly
manipulate the numerous symbolic links in the subdirectories of /etc/rc.d/.
Red Hat Linux provides three such utilities:
• /sbin/chkconfig — The /sbin/chkconfig utility is a simple
command-line tool for maintaining the /etc/rc.d/init.d directory
hierarchy.
• /sbin/ntsysv — The ncurses-based /sbin/ntsysv utility provides an
interactive text-based interface, which some find easier to use than
chkconfig.

• Services Configuration Tool — The graphical Services

Configuration Tool (redhat-config-services) program is a flexible
GTK2-based utility for configuring runlevels.
Please refer to the chapter titled Controlling Access to Services in Red Hat
Linux Customization Guide for more information regarding these tools.

1.5. Shutting Down

To shut down Red Hat Linux, the root user may issue the /sbin/shutdown
command. The shutdown man page has a complete list of options, but the two
most common uses are:

/sbin/shutdown -h now
/sbin/shutdown -r now

After shutting everything down, the -h option will halt the machine, and the -r
option will reboot.
Non-root users can use the reboot and halt commands to shut down the system
while in runlevels 1 through 5. However, not all Linux operating systems support
this feature.
If the computer does not power itself down, be careful not turn off the computer
until a message appears indicating that the system is halted.
Failure to wait for this message can mean that not all the hard drive partitions are
unmounted, and can lead to file system corruption.