| |
|
Home
|
| Red Hat Linux 7.3: The Official Red Hat Linux Reference Guide |
|---|
| Prev | Chapter 3. Boot Process, Init, and Shutdown | Next |
 | 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.
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
[Enter]
If you would like to have a command prompt to enter commands to LILO,
press
[Ctrl]-[X]. LILO
displays a LILO: prompt on the screen and waits for
input from the user. (The amount of time LILO waits is set by the
timeout line in the
/etc/lilo.conf file.) If your
/etc/lilo.conf is set to give LILO a choice of
operating systems, at this time you could type in the label for
whichever operating system you want to boot.
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.
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 to handle a user hitting
[Ctrl]-[Alt]-[Delete] at the console. By default under Red Hat Linux,
/etc/inittab instructs init to
execute the command /sbin/shutdown -t3 -r now,
which cleanly shuts down the system and helps prevent disk corruption.
In addition, /etc/inittab states what
init should do in case of power failures, if your
system has a UPS unit attached to it.
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.
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:
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
[Ctrl]-[X], and typing:
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.
|
|
|
|
|
|
|
|
Disclaimer: For authoritative source or latest update to this
documentation, please refer to http://www.redhat.com/docs/manuals/linux/ |
|
 |
|
|
|
Quotes: The proof that man is the noblest of all creatures is that no other creature has ever denied it.
|
|
|
|
|
|
|