initialization by dandanhuanghuang


									                                           System Administration
                                             Course Notes #13

Booting, Initialization, and Services
Here, we examine the boot process, initializing the operating system through shell scripts, and
services started and how to start and stop services. We also discuss some of the more common
services (some of which you will already be familiar with to some extent).

The Boot Process

When the computer is first powered on, main memory is empty. This is because main memory is
volatile, or requires constant electrical power to retain its contents. So, after shutting the machine
down, memory is empty. In order to use the computer, you need to have the operating system
loaded and initialized. How then can we get the operating system loaded, initialized and running
when it is the operating system that takes care of loading and running programs for us? We need a
special, one time process, called booting1.

The boot process operates as follows (see figure 9-1 on page 403 of your textbook):
   1. The CPU initializes itself (initializes its registers) and sends out control signals to various
       components in the computer system.
   2. The basic I/O system (BIOS) performs a power-on self test (POST) where it checks
       memory and tests devices for responses.
   3. The hard disk controllers (SCSI first, then IDE) are signaled to initialize themselves (note:
       the disk controller is not the disk drive, but a card inserted into the expansion slots of your
   4. Other devices are tested, network card, USB, etc.
   5. BIOS determines where the OS is stored. This is usually done by testing each of these
       devices in a pre-set order looking for the OS: floppy disk, CD-ROM, first IDE disk drive,
       next disk drive, etc.
   6. If your computer has multiple operating systems, then a boot loader program is run to
       determine which OS to load and run. One such program is called GRUB, another is LILO.
   7. If Linux is selected, then the Linux Kernel is loaded from disk into memory. At this point
       in time, control moves from the boot program to the Linux Kernel and shell scripts are run.

The basic boot program is stored in ROM (read only memory). BIOS is also stored in ROM.
However, portions of the boot program and BIOS may also be stored on hard disk so that less ROM
is required.

A boot loader program is a program that runs in order to select an OS to load and initialize. Before
Linux became popular, boot loaders were rare because few if any users had a need or desire to run
multiple OSs on their computer. The OS was tied fairly closely to the hardware so that your
computer would always boot into the same OS every time you booted it. However, with PC
popularity, some users wanted the option to boot in either Windows or Unix. Now with Linux’
 The term booting comes from the term bootstrapping, a term used to describe how one can pull himself up by his own
bootstraps, like a fireman when he gets up in the middle of the night in response to a fire alarm, the term itself is
attributed to the tales of Baron Munchhausen.
popularity among personal computer users, it is far more common to want to have this option. This
is where the boot loader comes in. Immediately after performing the various BIOS tests, the next
step is to load the OS. Which one? If there are multiple OSs available, then a boot loader must run
to allow the user to make this decision.

GRUB (Grand Unified Bootloader) is installed by default with most versions of Linux. This gives
Linux users the option of having other OSs be bootable. The boot decision is based on the
information stored in the GRUB configuration file, /boot/grub/grub.conf. This file stores such
information as the default OS (a number) so that, if the user does not intervene, the default OS is
loaded, the time given to the user before the default starts, the image displayed during startup, and
the specification of each OS kernel listed by title, kernel location, the root partition location (if
necessary), and any special initialization files (scripts) to run. Page 410 of your textbook shows an
example of a GRUB configuration file for booting either Linux or DOS. A simpler bootloader is
called LILO, which uses the configuration file /etc/lilo.config or /etc/lilo.conf.anaconda depending
on the specific version of Linux that you might be using.

Initialization Scripts

The shell script is a basic tool of system administrators. The idea behind a script is that it is an
enumeration of steps to take to carry out some task. As such, scripts are often used during the
system initialization process.

In Linux, the first script to run is /etc/inittab. The files referenced or started by inittab are primarily
in the directory /etc/rc.d. These files may include rc.sysinit (the initialization script used in Red Hat
and Fedora linux) which includes commands for setting up how the keyboard works, which
environment variables are needed, and other configuration details not handled by the Linux kernel,
rc which starts up various Linux services such as the network, printing, and daemons, and rc.local,
which is an initially empty script that the system administrator can edit to specialize the startup
routines for that particular machine. The inittab starts Linux based on a pre-specified startup level.
There are 7 levels (see table 9-1 on page 413 of the textbook) but in fact, only 4 will ever be used by
inittab. These are level 1 (single-user mode used for system maintenance without password), level
2 (multiuser mode without network, also used for system maintenance), level 3 (regular multiuser
mode with network, text-based), and level 5 (same as level 3 except it is GUI-based). Most
commonly, a stand-alone machine will boot in level 5 or possibly level 3. A server may boot in
level 2 and await the system administrator to complete other operations before being brought up to
level 3 or 5.

The next step for inittab is usually something like this: 1:2345:respawn:/sbin/mingetty tty1. the
mingetty program starts a virtual console (tty1 indicates the type) to provide a login prompt. The
respawn command ensures that this console will restart if it is exited so that a person cannot get
around the login prompt. Once login takes place, the rest of the initialization process takes place:
checking the user against the passwd and shadow files for authentication and finding the user’s
directory and shell, initializing the shell (using the various shell scripts like .bashrc) and
establishing the user’s current directory as their home directory, and bringing up the rest of the GUI
if called for.

A service is an application (or set of applications) that runs in the background waiting to be used, or
carrying out essential tasks. Services include daemons which watch for events. Some services are
application specific such as services associated with the Apache web server or MySQL. Other
services monitor or interface with hardware devices such as the network service or the printing

Depending on the run-level used, some services are automatically started during system
initialization. This is done by the rc script which was called upon by the inittab script. The rc script
iterates through one of the rc.d directories (rc.d has subdirectories called rc1.d, rc2.d, rc3.d, etc for
the run levels). Each directory contains a list of symbolic links named K##name or S##name,
where K means kill (or stop) the service (do not start it) and S means start the service. The ## is a
two digit number that references any needed patches. Some example names are K01yum, K74ntpd,
S12syslog and S55cups. Each of these is a symbolic link to the actual service program stored in the
directory /etc/rc.d/init.d. The reason for the symbolic links is so that each run level can have a
specific list of services started or not, but without having to duplicate physical files. One can alter
the services started or stopped by renaming the link names and changing the S to K or K to S. This
should not be necessary though.

As a system administrator, you can start, stop, restart or check the status of any service. There are
three ways to do this. First is to use the /sbin/service program, as in /sbin/service network
command. The command is one of start, stop, restart, status. The status command tells you
whether the service is running or not. You would stop and later restart a service if you had to
perform some operations on that service (e.g., installing a new script, altering service parameters) or
altered the hardware associated with that service. Second, you can issue the command directly by
calling upon the program in the /etc/rc.d/init.d directory as in /etc/rc.d/init.d/network stop. Finally,
you can perform these various commands using the GUI service tool by running /sbin/serviceconf
(you can also start this tool through the menus).

To top