copyrighted material

copyrighted material
The LPI 201
(60 Weights)
System Startup and
Advanced System
202.1 Customizing system startup and boot processes
(weight: 4)
202.2 System recovery (weight: 4)
205.4 Notify users on system-related issues (weight: 1)
206.1 Make and install programs from source (weight: 4)
An appropriate place to begin investigating advanced Linux
system administration is with the way the computer starts.
Therefore, this chapter covers that topic, including both boot
loader configuration and use and the tools Linux uses to start its own core processes.
Because a computer can’t boot without any software installed, this chapter continues
with a look at how to install software from source code, as opposed to using the package
systems with which you’re probably already familiar. Finally, this chapter describes tools
you can use to notify users of important system events, such as likely sluggishness due to a
major software package upgrade or an ongoing backup operation.
Exploring the Boot Process
Although the process normally proceeds smoothly once you press a computer’s power button,
booting a computer involves a large number of steps, ranging from hardware initialization to
the launch of potentially dozens of programs. Some of these boot-time tasks include:
The CPU initializes itself.
The CPU examines a particular memory address for code to run. This address
corresponds to part of the computer’s firmware, which contains instructions on how to
The firmware initializes the computer’s major hardware subsystems, performs basic
memory checks, and so on.
The firmware directs the computer to look for boot code on a storage device, such as a
hard disk, a removable disk, or an optical disc. This code, which is known as a stage 1
boot loader, is loaded and run.
The stage 1 boot loader code may direct the system to load additional stages of itself.
Ultimately, the boot loader code loads the operating system’s kernel and runs it. From
this point on, the kernel is in control of the computer.
The kernel looks for its first process file. In Linux, this file is usually /sbin/init, and
its process, once running, is known as init.
The init process reads one or more configuration files, which tell it what other
programs it should launch.
Linux systems typically launch processes both directly from init and under the
direction of System V (SysV) startup scripts or the Upstart system.
Exploring the Boot Process
During the startup process, the computer mounts disks using the mount utility
under direction of the /etc/fstab fi le. It may also perform disk checks using the fsck
utility. Controlling these processes is described in detail in Chapter 3, “Basic Filesystem
As part of the init-directed startup procedures (steps 7 and 8), Linux systems normally
launch user login tools, such as the text-mode login or an X Display Manager (XDM)
login screen. These programs enable ordinary users to log in and use the system. Server
computers are normally configured to launch server programs, some of which provide
similar login possibilities for remote users. Once users log in, they can of course launch
additional programs.
Although Linux distributions are designed to start up correctly once they’re installed,
you must know how to change these configurations. You may need to adjust a boot loader
configuration to boot a new kernel or to alter the options that the boot loader passes to
the kernel, for instance. If you want to install server software, you may need to change the
init or SysV startup procedures to launch the software automatically when the computer
boots. The following pages describe how to make such changes.
Computer Firmware Options
Since the 1980s, most x 86 and x 86 - 64 computers have used firmware known as the Basic
Input/Output System (BIOS). This firmware has become rather dated, however, and so a
shift is underway to a newer system, known as the Extensible Firmware Interface (EFI).
Since 2005, the Unified EFI (UEFI) variant of EFI has been available. As of late 2010,
EFI -based systems are still rare, although Intel-based Apple Macintoshes use EFI, and a
few UEFI -based x 86 - 64 systems are available. Some hardware manufacturers expect to
begin using UEFI in more systems beginning in 2011. Computers using CPUs other than
the common x 86 and x 86 - 64 use non- BIOS firmware, such as OpenFirmware or EFI.
The details of how firmware -mediated portions of the boot process can be altered vary
with the type of firmware installed on a computer. Even within a single type, such as
BIOS, there can be substantial variation from one computer to another. Typically, you use
a special keypress, such as F10, F12, or Delete, to enter a configuration utility that ’s built
into the firmware. You can then set options such as which disk devices to use to boot
the computer and which built-in hardware components to activate. You should consult
a computer ’s manual to learn the details of its firmware configuration.
Chapter 1
System Startup and Advanced System Management
Booting Linux
As just described, a computer must proceed through a series of steps before an OS, such as
Linux, can take control. The fi rst step that’s likely to be different on a Linux system than
on a computer that runs Windows, Mac OS, or some other OS, is the boot loader, which is
responsible for loading the kernel into memory. Several boot loaders are available that can
load Linux, including the Grand Unified Bootloader (GRUB), the Linux Loader (LILO),
and SysLinux. Most Linux installations use GRUB, which can also directly load some
non-Linux kernels or redirect the boot process to a boot loader for Windows. Thus, GRUB
can launch several OSs, should a computer have more than one installed. To configure
GRUB, you must edit its configuration fi les. You can also interact with the boot loader
at boot time, both to select your OS and to make on-the-fly changes, should you need
to customize the way the OS boots on a one-time basis.
Configuring GRUB
Two major versions of GRUB exist: The original GRUB, now known as GRUB Legacy,
has been frozen at version 0.97; and a new version, GRUB 2, is at version 1.98 as I write.
GRUB Legacy is no longer being actively developed. GRUB 2 is under active development,
and some features may change by the time you read this. The two versions are similar in
broad details and in how users interact with them at boot time; however, they differ in
some important configuration details. I therefore describe GRUB Legacy and then describe
how GRUB 2 differs from GRUB Legacy.
Configuring GRUB Legacy
The usual location for GRUB Legacy’s configuration fi le is /boot/grub/menu.lst. Some
distributions, such as Fedora, Red Hat, and Gentoo, use the filename grub.conf rather
than menu.lst. GRUB Legacy can read its configuration fi le at boot time, which means
you needn’t reinstall the boot loader to the boot sector when you change the configuration
fi le. The GRUB Legacy configuration fi le is broken into global and per-image sections,
each of which has its own options. Before getting into section details, though, you should
understand a few GRUB quirks.
GRUB Legacy Nomenclature and Quirks
Listing 1.1 shows a sample GRUB Legacy configuration fi le. It can boot several OSs
and kernels — Fedora on /dev/hda5, Debian on /dev/hda6, and Windows on /dev/hda2.
Fedora and Debian share a /boot partition (/dev/hda1), on which the GRUB configuration
Booting Linux
Listing 1.1: A sample GRUB legacy configuration file
# grub.conf/menu.lst
# Global Options:
# Kernel Image Options:
title Fedora (2.6.32)
root (hd0,0)
kernel /vmlinuz-2.6.32 ro root=/dev/hda5 mem=2048M
initrd /initrd-2.6.32
title Debian (2.6.36-experimental)
root (hd0,0)
kernel (hd0,0)/bzImage-2.6.36-experimental ro root=/dev/hda6
# Other operating systems
title Windows
rootnoverify (hd0,1)
chainloader +1
GRUB Legacy refers to disk drives by numbers preceded by the string hd and enclosed
in parentheses, as in (hd0) for the fi rst hard disk GRUB detects. GRUB doesn’t distinguish
between Parallel Advanced Technology Attachment (PATA), Serial ATA (SATA), and SCSI
drives. On a mixed system, ATA drives normally receive the lower numbers, although this
isn’t always the case. GRUB Legacy’s drive mappings can be found in the /boot/grub/ fi le.
Additionally, GRUB Legacy numbers partitions on a drive starting at 0 instead of 1,
which is used by Linux. GRUB separates partition numbers from drive numbers with a
comma, as in (hd0,0) for the fi rst partition on the fi rst disk or (hd0,4) for the fi rst logical
partition on the fi rst disk. Floppy devices are referred to as (fd0), or conceivably (fd1) or
higher if you have more than one floppy drive. Floppy disks aren’t partitioned, so they don’t
receive partition numbers.
GRUB Legacy defi nes its own root partition, which can be different from the Linux
root partition. GRUB’s root partition is the partition in which its configuration fi le (menu
.lst or grub.conf) resides. Because this fi le is normally in Linux’s /boot/grub/ directory,
the GRUB Legacy root partition will be the same as Linux’s root partition if you do not
use a separate /boot or /boot/grub partition. If you split off /boot into its own partition,
Chapter 1
System Startup and Advanced System Management
as is fairly common, GRUB’s root partition will be the same as Linux’s /boot partition.
You must keep this difference in mind when referring to fi les in the GRUB configuration
Essential Global GRUB Legacy Options
GRUB Legacy’s global section precedes its per-image configurations. A handful of GRUB
Legacy global configuration options are most important:
Default OS The default= option tells GRUB Legacy which OS to boot. Listing 1.1’s
default=0 causes the fi rst listed OS to be booted (remember, GRUB indexes from 0). If
you want to boot the second listed operating system, use default=1, and so on, through all
your OSs.
Timeout The timeout= option defi nes how long, in seconds, to wait for user input before
booting the default operating system.
Background Graphic The splashimage= line points to a graphics fi le that’s displayed as
the background for the boot process. This line is optional, but most Linux distributions
point to an image to spruce up the boot menu. The fi lename reference is relative to the
GRUB Legacy root partition, so if /boot is on a separate partition, that portion of the path
is omitted. Alternatively, the path may begin with a GRUB device specification, such as
(hd0,5) to refer to a fi le on that partition.
Essential Per-Image GRUB Legacy Options
GRUB Legacy’s per-image options are typically indented after the fi rst line, but this is a
convention, not a requirement of the fi le format. The options begin with an identification
and continue with options that tell GRUB Legacy how to handle the image:
Title The title line begins a per-image stanza and specifies the label to display when the
boot loader runs. The GRUB Legacy title can accept spaces and is conventionally fairly
descriptive, as shown in Listing 1.1.
GRUB Legacy Root The root option specifies the location of GRUB Legacy’s root
partition. This is the /boot partition if a separate one exists; otherwise, it’s usually the
Linux root (/) partition. GRUB can reside on a FAT partition, on a floppy disk, or on
certain other OSs’ partitions, though, so GRUB’s root could conceivably be somewhere
more exotic.
Kernel Specification The kernel setting describes the location of the Linux kernel as well
as any kernel options that are to be passed to it. Paths are relative to GRUB Legacy’s root
partition. As an alternative, you can specify devices using GRUB’s syntax, such as kernel
(hd0,5)/vmlinuz ro root=/dev/hda5. Note that you pass most kernel options on this line.
The ro option tells the kernel to mount its root fi lesystem read- only (it’s later remounted
read/write), and the root= option specifies the Linux root fi lesystem. Because these options
are being passed to the kernel, they use Linux-style device identifiers, when necessary,
unlike other options in the GRUB Legacy configuration fi le.
Booting Linux
Initial RAM Disk Use the initrd option to specify an initial RAM disk. Most
distributions use initial RAM disks to store loadable kernel modules and some basic tools
used early in the boot process; however, it’s often possible to omit an initial RAM disk if
you compile your own kernel.
Non-Linux Root The rootnoverify option is similar to the root option except that
GRUB won’t try to access fi les on this partition. It’s used to specify a boot partition for
OSs for which GRUB Legacy can’t directly load a kernel, such as DOS and Windows.
Chain Loading The chainloader option tells GRUB Legacy to pass control to another
boot loader. Typically, it’s passed a +1 option to load the fi rst sector of the root partition
(usually specified with rootnoverify) and to hand over execution to this secondary boot
To add a kernel to GRUB, follow these steps:
As root, load the menu.lst or grub.conf file into a text editor.
Copy a working configuration for a Linux kernel.
Modify the title line to give your new configuration a unique name.
Modify the kernel line to point to the new kernel. If you need to change any kernel
options, do so.
If you’re adding, deleting, or changing a RAM disk, make appropriate changes to the
initrd line.
If desired, change the global default line to point to the new kernel.
Save your changes, and exit the text editor.
At this point, GRUB Legacy is configured to boot your new kernel. When you reboot,
you should see it appear in your menu, and you should be able to boot it. If you have
problems, boot a working configuration to debug the issue.
Don’t eliminate a working configuration for an old kernel until you’ve
determined that your new kernel works correctly.
Configuring GRUB 2
In principle, configuring GRUB 2 is much like configuring GRUB Legacy; however, some
important details differ. First, the GRUB 2 configuration fi le is /boot/grub/grub.cfg.
GRUB 2 adds a number of features, such as support for loadable modules for specific
fi lesystems and modes of operation, that aren’t present in GRUB Legacy. (The insmod
command in the GRUB 2 configuration fi le loads modules.) GRUB 2 also supports
conditional logic statements, enabling loading modules or displaying menu entries only if
particular conditions are met.
Chapter 1
System Startup and Advanced System Management
If you merely want to add or change a single OS entry, you’ll fi nd the most important
changes are to the per-image options. Listing 1.2 shows GRUB 2 equivalents to the image
options shown in Listing 1.1.
Listing 1.2: GRUB 2 image configuration examples
# Kernel Image Options:
menuentry “Fedora (2.6.32)” {
set root=(hd0,1)
linux /vmlinuz-2.6.32 ro root=/dev/hda5 mem=2048M
initrd /initrd-2.6.32
menuentry “Debian (2.6.36-experimental)” {
set root=(hd0,1)
linux (hd0,1)/bzImage-2.6.36-experimental ro root=/dev/hda6
# Other operating systems
menuentry “Windows” {
set root=(hd0,2)
chainloader +1
Important changes compared to GRUB Legacy include the following:
The title keyword is replaced by menuentry.
The menu title is enclosed in quotation marks.
An opening curly brace ({) follows the menu title, and each entry ends with a closing
curly brace (}).
The set keyword precedes the root keyword, and an equal sign (=) separates root
from the partition specification.
The rootnoverify keyword has been eliminated; you use root instead.
Partitions are numbered starting from 1 rather than from 0. A similar change in disk
numbering is not implemented. This change can be very confusing. The most recent
versions of GRUB 2 also support a more complex partition identification scheme to
specify the partition table type or partitions that are embedded within other partitions,
as are often used on Solaris or Berkeley Standard Distribution (BSD) OS installations.
GRUB 2 makes further changes, in that it employs a set of scripts and other tools that
help automatically maintain the /boot/grub/grub.cfg fi le. The intent is that system
administrators need never explicitly edit this file. Instead, you would edit fi les in /etc/
grub.d, and the /etc/default/grub fi le, to change your GRUB 2 configuration.
Booting Linux
Files in /etc/grub.d control particular GRUB OS probers. These scripts scan the system
for particular OSs and kernels and add GRUB entries to /boot/grub/grub.cfg to support
those OSs. You can add custom kernel entries, such as those shown in Listing 1.2, to the
40_custom fi le to support your own locally compiled kernels or unusual OSs that GRUB
doesn’t automatically detect.
The /etc/default/grub fi le controls the defaults created by the GRUB 2 configuration
scripts. For instance, if you want to adjust the timeout, you might change the following
A distribution that’s designed to use GRUB 2, such as recent versions of Ubuntu, will
automatically run the configuration scripts after certain actions, such as installing a new
kernel with the distribution’s package manager. If you need to make changes yourself, you
can type update-grub after you’ve edited /etc/default/grub or fi les in /etc/grub.d. This
command re-reads these configuration fi les and writes a fresh /boot/grub/grub.cfg fi le.
Installing the GRUB Boot Loader
The command for installing both GRUB Legacy and GRUB 2 is grub-install. Also, you
must specify the boot sector by device name when you install the boot loader. The basic
command looks like:
# grub-install /dev/hda
# grub-install ‘(hd0)’
Either command will install GRUB into the fi rst sector of your fi rst hard drive. On many
systems, you would use /dev/sda rather than /dev/hda in the fi rst example. In the second
example, you need single quotes around the device name. If you want to install GRUB in
the boot sector of a partition rather than in the MBR, you include a partition identifier, as
in /dev/hda1 or (hd0,0). This option doesn’t always work well with GRUB 2, however.
Remember that you do not need to reinstall GRUB after making changes to its
configuration fi le! (You may need to run update-grub after updating GRUB 2’s /etc-based
configuration fi les, though.) You need to install GRUB this way only if you make certain
changes to your disk configuration, such as resizing or moving the GRUB root partition,
moving your entire installation to a new hard disk, or possibly reinstalling Windows
(which tends to wipe out MBR-based boot loaders). In some of these cases, you may need
to boot Linux via a backup boot loader, such as GRUB installed to floppy disk. (Type
grub-install /dev/fd0 to create one and then label it and store it in a safe place.)
Interacting with GRUB at Boot Time
The fi rst screen the GRUB Legacy or GRUB 2 boot loader shows you is a list of all the
operating systems you specified with the title or menuentry option in your GRUB
Chapter 1
System Startup and Advanced System Management
configuration fi le. You can wait for the timeout to expire for the default operating system
to boot. To select an alternative, use your arrow keys to highlight the operating system that
you want to boot. Once your choice is highlighted, press the Enter key to start booting.
Follow these steps when you want to change or pass additional options to your
operating system:
Use your arrow keys to highlight the operating system that most closely matches what
you want to boot.
Press the E key to edit this entry. You’ll see a new screen listing all the options for this
Use your arrow keys to highlight the kernel or linux option line.
In GRUB Legacy, press the E key to edit the kernel options. This step is not necessary
in GRUB 2.
Edit the kernel or linux line to add any options, such as 1 to boot to single-user mode.
GRUB will pass the extra option to the kernel when you boot.
Press the Enter key to complete the edits. This step is not necessary in GRUB 2.
Press the B key to start booting GRUB Legacy, or press Ctrl+X to start booting GRUB 2.
You can make whatever changes you like in step 5, such as using a different init
program. You do this by appending init=/bin/bash (or whatever program you want to
use) to the end of the kernel line.
More advanced boot-time interactions are possible by entering GRUB’s interactive
mode. You do this by pressing the C key at the GRUB menu. You can then type a variety
of commands that are similar to Linux shell commands, such as ls to view fi les. If you
type ls alone at the grub> prompt, you’ll see a list of partitions, using GRUB’s partition
nomenclature. You can add a partition identifier and a slash, as in ls (hd0,3)/, to view
the contents of that partition. By working your way through the partitions, you can
probably identify your kernel file and, if your system uses it, an initial RAM disk fi le. This
information, along with the identification of your root fi lesystem, should enable you to
build up a working GRUB entry for your system.
Customizing System Startup
Linux relies on runlevels to determine what features are available. Runlevels are numbered
from 0 to 6, and each one is assigned a set of services that should be active. Upon booting,
Linux enters a predetermined runlevel, which you can set. Knowing what these functions
are, and how to manage runlevels, is important if you’re to control the Linux boot process
and ongoing operations. Toward this end, you must understand the purpose of runlevels,
be able to identify the services that are active in a runlevel, be able to adjust those services,
be able to check your default and current runlevels, and be able to change the default and
current runlevels. Complicating matters, two major startup systems, SysV startup scripts
and Upstart, are available, and each provides different ways of doing these practical tasks,
although both employ similar runlevel concepts.
Customizing System Startup
Understanding Runlevels
Earlier in this chapter, I mentioned single-user mode, which is a special mode in which
Linux permits only root to log in. To get to this mode when booting Linux, you use
the number 1, the letter S or s, or the word single as an option passed to the kernel by
the boot loader. Single-user mode is simply an available runlevel for your system. The
available runlevels on most systems are the numbers 0 through 6. The letters S and s are
synonymous with runlevel 1 as far as many utilities are concerned.
Runlevels 0, 1, and 6 are reserved for special purposes; the remaining runlevels are
available for whatever purpose you or your Linux distribution provider decide. Table 1.1
summarizes the conventional uses of the runlevels. Other assignments — and even runlevels
outside the range of 0 to 6 — are possible, but such configurations are rare. (Gentoo uses an
unusual runlevel system, as described shortly.) If you run into peculiar runlevel numbers,
consult /etc/inittab—it defi nes them and often contains comments explaining the various
TA B L E 1 .1
Runlevels and their purposes
A transitional runlevel, meaning that it ’s used to shift the system from
one state to another. Specifically, it shuts down the system. On modern
hardware, the system should completely power down. If not, you’re
expected to either reboot the computer manually or power it off.
1, s, or S
Single-user mode. What services, if any, are started at this runlevel varies by
distribution. It’s typically used for low-level system maintenance that may be
impaired by normal system operation, such as resizing partitions. Typically,
s or S produces a root shell without mounting any filesystems, whereas 1
does attempt to mount filesystems and launches a few system programs.
On Debian and its derivatives (including Ubuntu), a full multi-user mode
with X running and a graphical login. Most other distributions leave this
runlevel undefined.
On Fedora, Mandriva, Red Hat, and most other distributions, a full
multi-user mode with a console (non- graphical) login screen.
Usually undefined by default and therefore available for customization.
On Fedora, Mandriva, Red Hat, and most other distributions, the same
behavior as runlevel 3 with the addition of having X run with an XDM
(graphical) login.
Used to reboot the system. This runlevel is also a transitional runlevel.
Your system is completely shut down, and then the computer reboots
Chapter 1
System Startup and Advanced System Management
Don’t configure your default runlevel to 0 or 6. If you do, your system will
immediately shut down or reboot once it finishes powering up. Runlevel 1
could conceivably be used as a default, but chances are you’ll want to use
2, 3, or 5 as your default runlevel, depending on your distribution and
use for the system.
As a general rule, distributions have been drifting toward Red Hat’s runlevel set;
however, there are some exceptions and holdouts, such as Debian and Ubuntu. Gentoo also
deserves special attention. Although it uses numbered runlevels at its core, Gentoo builds
on this by enabling an arbitrary number of named runlevels. The default runlevel is called,
appropriately enough, default. Gentoo’s system permits you to create named runlevels
for, say, connecting a laptop to half a dozen different networks, each with its own unique
network configuration requirements. When you move from one network to another, enter
the appropriate runlevel, as described in “Changing Runlevels on a Running System.”
Many of the files and file locations described in this chapter are based
on the Linux Standards Base (LSB), which is a specification of various
standards for the locations of files, the existence of particular libraries,
and so on. The LSB is designed to ensure a minimal level of compatibility
across common Linux distributions.
Configuring SysV Startup Scripts
In the past, most Linux distributions have used System V (SysV) startup scripts, which
are named after the System V version of Unix on which they originated. In the Linux
implementation of SysV startup scripts, the kernel launches a process called init, which
reads its configuration fi le and, in following its instructions, launches a series of scripts
that can vary from one runlevel to another. As described later, in “Configuring Upstart,” a
competing startup system is becoming common on Linux.
Identifying the Services in a Runlevel
There are two main ways to affect what programs run when you enter a new runlevel. The
fi rst is to add or delete entries in init’s configuration fi le, /etc/inittab. A typical /etc/
inittab fi le contains many entries, and except for a couple of special cases, inspecting or
changing the contents of this fi le is best left to experts. Once all the entries in /etc/inittab
for your runlevel are executed, your boot process is complete, and you can log in. The
second way to alter programs run in a given runlevel is to edit the SysV or Upstart startup
Customizing System Startup
Editing the /etc/inittab File
Entries in /etc/inittab follow a simple format. Each line consists of four colon-delimited
Each of these fields has a specific meaning, as identified in Table 1.2. In a traditional
configuration, /etc/inittab includes lines that launch the SysV startup scripts for each
runlevel, as described shortly.
TA B L E 1 . 2
Contents of a /etc/inittab entry
This field consists of a sequence of one to four characters that identifies
the entry ’s function.
This field consists of a list of runlevels for which this entry applies. For
instance, 345 means the entry is applicable to runlevels 3, 4, and 5.
Specific codes in this field tell init how to treat the process. For instance,
wait tells init to start the process once when entering a runlevel and
to wait for the process’s termination, and respawn tells init to restart
the process whenever it terminates (which is great for login processes).
Several other actions are available; consult the man page for inittab for
This field specifies the process to run for this entry, including any options
and arguments that are required.
The upcoming section “Checking and Changing Your Default Runlevel”
describes how to tell init what runlevel to enter when the system boots.
If you alter the /etc/inittab fi le, the changes won’t take effect until you reboot the
computer or type a command such as telinit Q to have it reread this file and implement its
changes. Thus, when making changes, you should keep them simple or test their effects,
lest problems occur later, after you’ve forgotten about changes to this file.
Understanding SysV Startup Scripts
The /etc/init.d/rc or /etc/rc.d/rc script performs the crucial task of running all
the scripts associated with the runlevel. The runlevel-specific scripts are stored in /etc/
Chapter 1
System Startup and Advanced System Management
rc.d/rc?.d, /etc/init.d/rc?.d, /etc/rc?.d, or a similar location. (The precise location
varies between distributions.) In all these cases, ? is the runlevel number. When entering a
runlevel, rc passes the start parameter to all the scripts with names that begin with
a capital S and passes the stop parameter to all the scripts with names that begin
with a capital K. These SysV startup scripts start or stop services depending on the
parameter they’re passed, so the naming of the scripts controls whether they’re started or
stopped when a runlevel is entered. These scripts are also numbered, as in S10network and
K35smb; the numbers control the order in which services are started or stopped.
The rc program runs SysV startup scripts in numeric order. This feature enables
distribution designers to control the order in which scripts run by giving them appropriate
numbers. This control is important because some services depend on others. For instance,
network servers must normally be started after the network is brought up.
In reality, the fi les in the SysV runlevel directories are symbolic links to the main scripts,
which are typically stored in /etc/rc.d, /etc/init.d, or /etc/rc.d/init.d (again, the
exact location depends on the distribution). These original SysV startup scripts have names
that lack the leading S or K and number, as in smb instead of K35smb.
To determine which services are active in a runlevel, search the appropriate SysV startup
script directory for scripts with fi lenames that begin with an S. Alternatively, you can use a
runlevel management tool, as described next.
You can start services by hand. Run them with the start option, as in
/etc/init.d/smb start to start the smb (Samba) server. Other useful
options are stop, restart, and status. Most scripts support all
these options.
Most distributions place useful information, such as the runlevels in which scripts run
by default, in comments near the start of each SysV startup script. These comments can be
helpful if you need to manually restore a system to its default configuration.
Managing Runlevel Services
The SysV startup scripts in the runlevel directories are symbolic links back to the original
script. This is done so you don’t need to copy the same script into each runlevel directory.
Instead, you can modify the original script without having to track down its copies in all
the SysV runlevel directories. Using a single linked-to fi le also simplifies system updates.
You can also modify which programs are active in a runlevel by editing the link
fi lenames. Numerous utility programs are available to help you manage these links, such
as chkconfig, ntsysv, update-rc.d, and rc-update. I describe chkconfig and updaterc.d tools because they are supported on many distributions. If your distribution doesn’t
support these tools, you should check distribution- centric documentation.
Using chkconfig
To list the services and their applicable runlevels with chkconfig, use the --list (or,
usually, -l) option. The output looks something like this but is likely to be much longer:
Customizing System Startup
# chkconfig --list
This output shows the status of the services in all seven runlevels. For instance, you can
see that nfs-common is inactive in runlevels 0 –2, active in runlevels 3 –5, and inactive in
runlevel 6.
On Red Hat, Fedora, and some other distributions, chkconfig can manage
servers that are handled by xinetd as well as SysV startup scripts. The
xinetd-mediated servers appear at the end of the chkconfig listing.
If you’re interested in a specific service, you can specify its name:
# chkconfig --list nfs-common
To modify the runlevels in which a service runs, use a command like this:
# chkconfig --level 23 nfs-common on
The previous example is for Debian-based systems. On Red Hat and
similar systems, you would probably want to target runlevels 3, 4, and 5
with something like --level 345 rather than --level 23.
You can set the script to be on (to activate it), off (to deactivate it), or reset (to set it to
its default value).
If you’ve added a startup script to the main SysV startup script directory, you can have
chkconfig register it and add appropriate start and stop links in the runlevel directories.
When you do this, chkconfig inspects the script for special comments to indicate default
runlevels. If these comments are in the fi le and you’re happy with the suggested levels, you
can add it to these runlevels with a command like this:
# chkconfig --add nfs-common
This command adds the nfs-common script to those managed by chkconfig. You would,
of course, change nfs-common to your script’s name. This approach may not work if the
script lacks the necessary comment lines with runlevel sequence numbers for chkconfig’s
Chapter 1
System Startup and Advanced System Management
Using update-rc.d
The update-rc.d program is most common on Debian and some of its derived
distributions. It fi lls much the same role as chkconfig; however, details of its operation are
quite different. Its basic syntax is:
update-rc.d [options] name action
The most common option is -n, which causes the program to report what it would do
without taking any real action. The name is the name of the service to be modified. The
action is the name of the action to be performed, along with any action-specific options.
Common actions are summarized in Table 1.3.
TA B L E 1 . 3
Contents of a /etc/inittab entry
Action code
Removes links in runlevel- specific directories to the named service.
The service’s main script must not exist. This option is intended to
clean up the SysV startup scripts after a service has been completely
removed from the system.
Creates links to start the service in runlevels 2, 3, 4, and 5, and to
stop it in runlevels 0, 1, and 6.
start NN runlevels
Creates a link to start the service in the specified runlevels, using
the sequence number NN.
stop NN runlevels
Creates links to stop the service in the specified runlevels, using the
sequence number NN.
enable [runlevel]
Modifies existing runlevel links to enable the service in the specified
runlevel. If no runlevel is specified, runlevels 2, 3, 4, and 5 are
disable [runlevel]
Modifies existing runlevel links to disable the service in the specified
runlevel. If no runlevel is specified, runlevels 2, 3, 4, and 5 are
As an example of rc-update.d in action, consider the following two commands:
# update-rc.d samba defaults
# update-rc.d gdm disable 234
Customizing System Startup
The fi rst of these examples sets the Samba server to run in the default runlevels. The
second causes the GNOME Display Manager (GDM) login server to not run in runlevels 2,
3, and 4.
Configuring Upstart
Several modern Linux distributions, including recent versions of Ubuntu and Fedora, now
use an init process called Upstart ( rather than the venerable
SysV startup system. Broadly speaking, Upstart does the same job as the SysV scripts, but
Upstart is designed to better handle today’s dynamically changing hot- plug hardware,
which can be connected to and disconnected from a computer while it’s still running.
Upstart provides SysV compatibility features, so you should be familiar with the SysV
methods described earlier; however, it also has its own unique scripts and differs in some
important ways. In particular, Upstart does away with /etc/inittab, instead providing
an integrated set of startup scripts that can, in principle, completely replace the SysV-style
/etc/inittab and runlevel-specific startup scripts. Upstart scripts also support starting
or stopping services based on a wider variety of actions than do SysV startup scripts; for
instance, Upstart can launch a service whenever a particular hardware device is attached.
Using Upstart-Native Methods
A system that uses nothing but Upstart and its native scripts replaces both /etc/inittab
and the runlevel-specific SysV startup script directories with scripts in the /etc/init
directory. (This directory was called /etc/event.d on earlier versions of Upstart.) You may
want to check the contents of this directory on your own Upstart-based system.
As I write, Upstart is under heavy development, and its configuration file
format is subject to change. Thus, you may find differences from what is
described in these pages.
To change the runlevels in which a particular service runs, you’ll have to edit its
configuration fi le in a text editor. Locate the script (typically /etc/init/name.conf, where
name is the name of the service), and load it into a text editor. Look for lines that include
the text start on and stop on, as in the following example:
start on (filesystem
and started hal
and tty-device-added KERNEL=tty7
and (graphics-device-added or stopped udevtrigger))
stop on runlevel [016]
Locate any runlevel specification and adjust it for your needs. For instance, you might
change the preceding example’s stop on runlevel specification to read stop on runlevel
[0126] to include runlevel 2 in the list of runlevels on which the service is to be stopped.
Chapter 1
System Startup and Advanced System Management
After you make such a change, you can use the start or stop command to immediately
start or stop the service, as in stop gdm to shut down the gdm server. Before changing your
runlevel (as described shortly, in “Changing Runlevels on a Running System”), you should
type initctl reload to have Upstart reread its configuration fi les.
If you upgrade the package that provides the Upstart configuration script,
you may need to reconfigure again.
Using SysV Compatibility Methods
Because the SysV startup script system has been so common for so long, a large number of
software packages include SysV startup scripts. In order to accommodate such packages,
Upstart provides a compatibility mode: It runs SysV startup scripts in the usual locations
(/etc/rc.d/rc?.d, /etc/init.d/rc?.d, /etc/rc?.d, or a similar location). Thus, if you
install a package that doesn’t yet include an Upstart configuration script, it should still
launch in the usual way. Furthermore, if you’ve installed utilities such as chkconfig, you
should be able to use them to manage your SysV-based services just as you would on a
SysV-based system.
You may fi nd, however, that chkconfig and other SysV-based tools no longer work for
some services. As time goes on, this is likely to be true for more and more services, because
the developers of distributions that favor Upstart may convert their packages’ startup
scripts to use Upstart-native methods.
Checking Your Runlevel
Sometimes it’s necessary to check your current runlevel. Typically, you’ll do this prior
to changing the runlevel or to check the status if something isn’t working correctly. Two
different runlevel checks are possible: checking your default runlevel and checking your
current runlevel.
Checking and Changing Your Default Runlevel
On a SysV-based system, you can determine your default runlevel by inspecting the /etc/
inittab fi le with the less command or opening it in an editor. Alternatively, you may use
the grep command to look for the line specifying the initdefault action. You might see
something like this:
# grep :initdefault: /etc/inittab
You may notice that this line does not defi ne a process to run. In the case of the
initdefault action, the process field is ignored.
If you want to change the default runlevel for the next time you boot your system, edit
the initdefault line in /etc/inittab and change the runlevel field to the value that you
Customizing System Startup
want. If your system lacks a /etc/inittab fi le, as is common on Upstart-based systems,
create one that contains only an initdefault line that specifies the runlevel you want to
enter by default.
Determining Your Current Runlevel
If your system is up and running, you can determine your runlevel information with the
runlevel command:
# runlevel
N 2
The fi rst character is the previous runlevel. When the character is N, this means the
system hasn’t switched runlevels since booting. It’s possible to switch to different runlevels
on a running system with the init and telinit programs, as described next. The second
character in the runlevel output is your current runlevel.
Changing Runlevels on a Running System
Sometimes you may want to change runlevels on a running system. You might do this to
get more services, such as going from a console to a graphical login runlevel, or to shut
down or reboot your computer. You can accomplish this with the init (or telinit),
shutdown, halt, reboot, and poweroff commands.
Changing Runlevels with init or telinit
The init process is the fi rst process run by the Linux kernel, but you can also use it to
have the system reread the /etc/inittab fi le and implement changes it fi nds there or to
change to a new runlevel. The simplest case is to have it change to the runlevel you specify.
For instance, to change to runlevel 1 (the runlevel reserved for single-user or maintenance
mode), you would type this command:
# init 1
To reboot the system, you can use init to change to runlevel 6 (the runlevel reserved for
# init 6
A variant of init is telinit. This program can take a runlevel number just like init to
change to that runlevel, but it can also take the Q or q option to have the tool reread /etc/
inittab and implement any changes it finds there. Thus, if you’ve made a change to the
runlevel in /etc/inittab, you can immediately implement that change by typing telinit q.
The man pages for these commands indicate slightly different syntaxes,
but telinit is sometimes a symbolic link to init, and in practice init
responds just like telinit to the Q and q options.
Chapter 1
System Startup and Advanced System Management
Changing Runlevels with shutdown
Although you can shut down or reboot the computer with init, doing so has some
problems. One issue is that it’s simply an unintuitive command for this action. Another
is that changing runlevels with init causes an immediate change to the new runlevel.
This may cause other users on your system some aggravation because they’ll be given no
warning about the shutdown. Thus, it’s better to use the shutdown command in a multiuser environment when you want to reboot, shut down, or switch to single-user mode. This
command supports extra options that make it friendlier in such environments.
The shutdown program sends a message to all users who are logged into your system
and prevents other users from logging in during the process of changing runlevels. The
shutdown command also lets you specify when to effect the runlevel change so that users
have time to exit editors and safely stop other processes they may have running.
When the time to change runlevels is reached, shutdown signals the init process for you.
In the simplest form, shutdown is invoked with a time argument like:
# shutdown now
This changes the system to runlevel 1, the single-user or maintenance mode. The now
parameter causes the change to occur immediately. Other possible time formats include
hh:mm, for a time in 24 -hour clock format (such as 6:00 for 6:00 a.m. or 13:30 for 1:30
p.m.), and +m for a time m minutes in the future.
You can add extra parameters to specify that you want to reboot or halt (that is, power
off) the computer. Specifically, -r reboots the system, -H halts it (terminates operation
but doesn’t power it off), and -P powers it off. The -h option may halt or power off the
computer, but usually it powers it off. For instance, you can type shutdown -r +10 to reboot
the system in 10 minutes.
To give people some warning about the impending shutdown, you can add a message to
the end of the command:
# shutdown -h +15 “system going down for maintenance”
If you schedule a shutdown but then change your mind, you can use the -c option to
cancel it:
# shutdown -c “never mind”
Changing Runlevels with the halt, reboot,
and poweroff Commands
Three additional shortcut commands are halt, reboot, and poweroff. As you might expect,
these commands halt the system (shut it down without powering it off), reboot it, or shut
it down and (on hardware that supports this feature) turn off the power, respectively.
Typically, two of these commands are symbolic links to a third; the single binary responds
differently depending on the name used to call it.
Compile and Install Programs from Source
Compile and Install Programs
from Source
Both system startup utilities and users run software, and that software has to be installed
in some way. The LPI Level 1 certification includes coverage of two common methods
of installing software on Linux systems: the RPM Package Manager (RPM) and Debian
packages. These tools are adequate and convenient for most common software packages;
however, from time to time you’ll have to install software that’s not available in these
forms. In such cases, you may need to compile and install the software from its original
source code. The following pages describe this process, including the advantages and
pitfalls of this approach, obtaining and unpacking source code, compiling the software,
installing it, and uninstalling or upgrading it should it be necessary.
Chapter 2, “Linux Kernel Configuration,” describes compiling the Linux
kernel in greater detail. Many of the procedures and issues covered in this
chapter apply to the kernel, but the kernel has its own special needs with
respect to configuration, compilation, and installation.
Understanding Source Code Issues
Most Linux software is available in two forms: as source code, which programmers write
and can subsequently modify; and as object code or binary code, which the computer runs.
(Some software is written in interpreted computer languages, in which this distinction
does not exist.) Software is converted from source code to binary code form by a program
known as a compiler. Software in source code form can theoretically be compiled to run
on any computer that provides the necessary compiler and associated tools. Binary code,
on the other hand, is customized for one particular OS and hardware family. For instance,
a Linux program in binary form for an x86 - 64 CPU can’t run on a computer with a
PowerPC CPU, even if that computer runs Linux; nor can the same binary run on MacOS
X, even if it’s running on an x86 - 64 CPU.
Tools such as QEMU ( and Wine
( provide ways to break some of these restrictions;
they can run one CPU’s or OS’s binaries on another CPU or OS. CPU
emulators such as QEMU work at the cost of speed; the code runs much
slower under QEMU than it does on native hardware. WINE is useful only
for running Microsoft Windows software under Linux or other Unix-like
OSs, and it doesn’t work with all Windows software.
Chapter 1
System Startup and Advanced System Management
If you don’t have access to a binary package for your computer but want to run the
software, you must compile the software yourself. This activity carries with it several
You must have appropriate software development tools installed on your system.
Typically, this means the GNU Compiler Collection (GCC), including the GCC
package for the language in which the software was written, such as C or C++.
You must have appropriate development libraries (also known as header files) installed
on the computer. Note that development libraries are usually installed separately from
their binary library equivalents; the latter are required for binaries to run, but to
create the binaries, you need a separate development library. The development library
is not required when you install a precompiled binary package.
Several generic support tools are necessary, such as the tar program that’s used to
extract files from the source code package. These tools are usually installed by default
on most Linux systems, but there may be exceptions to this rule.
Source code packages usually include documentation, described shortly, that
summarizes its specific requirements. You may need to use your distribution’s binary
package management tools to locate and install various prerequisites.
Unfortunately, problems often occur while compiling software. Frequently, these
problems can be overcome by installing missing packages, such as development libraries.
Sometimes, though, the problems are more fundamental. Old programs may rely on
equally old libraries that are no longer available; or the libraries may have been updated in
such a way that the old program no longer compiles. Highly specialized programs may be
written for a specific platform and simply won’t compile under Linux, or they may need to
be modified to compile properly. If you run into serious problems compiling software, you
should study any error messages you encounter. A Web search on an error message may
turn up a solution or at least help you to understand what’s going wrong.
Fortunately, in many cases there are no problems at all. Linux is a popular enough
platform that most open source programs for Unix-like OSs compile fi ne on Linux—
provided you’ve installed the necessary development tools and libraries!
Preparing Source Code
The fi rst step in compiling source code is to obtain it and understand the author’s
directions on using it. Source code can be obtained from a variety of places. Although there
are some common practices in source code distribution, there are few rules that you can
rely upon to be true in all cases. Therefore, you must be prepared to do different things
to install different source packages, and it’s very important that you read a package’s
Obtaining Source Code
If you already know you want to install a particular package from source code, chances are
you already know where and how to obtain it. If you’re looking for software to perform
Compile and Install Programs from Source
some task but don’t know its name, though, you may want to check out an open source
repository site, such as SourceForge (, Google Code (http://, or Freshmeat ( You could also try performing a
Web search on key words relevant to the software you want to locate.
Sometimes program Web sites provide multiple packages intended for different
platforms. Linux source code tarballs usually come in fi les with names that end in .tgz,
.tar.gz, .tbz, .tbz2, or .tar.bz2. These fi lenames all denote tarballs — archive fi les
created with the tar utility. The .tgz and .tar.gz extensions denote tarballs that have
been compressed with gzip, while .tbz, .tbz2, and .tar.bz2 denote tarballs that have been
compressed with bzip2. Occasionally you’ll see source code distributed in PkZip .zip fi les,
which can be extracted in Linux with the unzip utility. These fi les are not tarballs, but they
serve the same function.
If you see a source RPM file, which has a name that ends in .src.rpm,
and if you have an RPM -based distribution, you can download it and
generate a binary RPM. Source RPMs are converted into binary RPMs
by typing rpmbuild --rebuild aprogram-1.2.3.src.rpm, where aprogram1.2.3.src.rpm is the source RPM’s filename. The binary RPM will be
stored in a location that is specified about a dozen lines above the end
of the resulting output. You should not follow the normal source code
compilation and installation instructions when installing a source RPM.
Unpacking Source Code
To uncompress any type of tarball, you use the tar utility, passing it the -x (or --extract)
operation name along with either -z (--gzip) or -j (--bzip2) if the tarball was compressed
and -f (--file) to specify the fi lename. You may want to add -v (--verbose) to see a list of
fi lenames as they’re extracted. The fi nal command might look like this:
$ tar xvzf aprogram-1.2.3.tgz
The leading dash (-) can be, and often is, omitted when using single character options with the tar program.
Some people prefer to call gunzip or bunzip2 separately, piping the result through tar:
$ gunzip -c aprogram-1.2.3.tgz | tar xv
Tarballs are conventionally built such that, when they’re extracted, they create a
subdirectory, usually with the same name as the tarball, and all fi les are placed within the
new directory. This isn’t always true, though, and it’s often not true of .zip fi les. If you
want to be sure that a tarball will extract neatly into a new subdirectory rather than litter
the current directory with its fi les, you can use the -t (--list) operation, as in tar tvzf
aprogram-1.2.3.tgz, to view its contents before extracting it.
Chapter 1
System Startup and Advanced System Management
You can extract a source tarball into your home directory and work on it there; however,
if you intend to install a program on the system for all users’ benefit, you may prefer to
extract the tarball into a subdirectory of /usr/src. This directory exists to hold source code
for programs that are locally compiled. You can then leave the source code in that location,
ensuring that the necessary tools remain behind for uninstalling the software, should that
become necessary. (The upcoming section “Uninstalling or Upgrading Software” describes
how to uninstall locally compiled software.) By default, /usr/src is normally writeable
only by root, so you may need to acquire superuser privileges to extract a tarball to this
directory. It’s usually possible to compile software as an ordinary user, so you may want to
adjust permissions on the extracted directory to enable yourself to write to that directory
tree as a non-root user. You will have to use root privileges to install the software, at least if
you want to install it to a standard location for use by all users.
Reading Documentation
Once you’ve extracted the source code, you should type ls in the source code directory to
view the files it contains. In most cases, you’ll find several documentation files. Common files
include COPYING (the license text), CHANGELOG (a history of technical changes to the software),
NEWS (another history of changes, this one less technical), README (general documentation),
and INSTALL (instructions on installing the software). Some packages come with additional
or different files, and sometimes one or more of these common files may be missing.
Documentation files like these usually have entirely uppercase names, but this isn’t always true.
You should be sure to read the general documentation (README) and installation
instructions (INSTALL) before proceeding with any source code compilation or installation
procedure. Although most programs follow a similar procedure, the actions required
are not completely standardized. You may fi nd that the software you want to install
requires some unusual steps, such as manual editing of a fi le or use of unusual syntax in
its compilation commands. You may also discover that you need to install development
libraries or tools that aren’t already installed on your system.
Programs sometimes specify that they have special requirements or
limitations on particular CPUs or with particular kernels. You can learn
about both with the uname command, which displays information on the
current CPU, kernel, and a few other system details. You can obtain various
specific types of information by passing particular options to uname, but
passing -a, as in uname -a, reveals all that the program can reveal. The
kernel version number will be obvious. The string SMP, if present, denotes
a symmetric multi-processing (SMP) CPU. A string such as i386 or x86_64
identifies a 32- or 64 -bit kernel, respectively, on the x 86/x 86 - 64 platform.
Compiling Software
Once you’ve extracted the source code, read its documentation, and installed any
additional tools you need to compile the software, you can begin configuring and compiling
the software. Problems can occur at either of these steps, although most programs compile
and install cleanly, provided you’ve satisfied all the prerequisites.
Compile and Install Programs from Source
Configuring the Compilation
Simple programs require little or nothing in the way of configuration. More complex
programs, however, ship with a tool that scans your system for available tools and libraries
and adjusts the compilation process for your particular computer.
The most common method of performing this task is a script called configure located
in the source code’s main directory. You can type ./configure to run this script. It will scan
your system and adjust a fi le called Makefile, which controls the compilation process, to
work optimally on your system.
The configure script often accepts parameters that enable you to set compile-time
options for the software. These vary from one package to another; however, some common
configure options are shown in Table 1.4. You might use these parameters to enable
debugging features if you believe a program contains a bug or use them to set programspecific features such as support for specific third-party libraries.
TA B L E 1 . 4
Common configure script parameters
Displays a summary of options.
Displays fewer messages as the script does its work.
Sets the installation directory for architecture -independent files
to directory. The default value is usually /usr/local.
Sets the installation directory for architecture - dependent files to
directory. The default value is usually /usr/local.
Enables a named FEATURE, which is program- specific.
Disables a named FEATURE, which is program- specific.
Sets debugging symbols. ARG is yes, no, or full, with a default of no.
Disables debugging output.
Enables support for a particular library or external tool, PACKAGE.
By default, ARG is yes.
Disables support for a particular library or external tool, PACKAGE;
equivalent to --with-PACKAGE=no.
Chapter 1
System Startup and Advanced System Management
When you run the configure script, it displays a series of lines that summarize what
it’s doing. These lines often begin with the word checking, and they report the status of
a check. If the script discovers that you’re missing some critical header fi les or software
component, it will terminate and display an error message, such as the following:
checking for Qt... configure: error: Qt (>= Qt 3.0) (headers and
libraries) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Such a message tells you what you’re missing that the program requires, but it may be
a bit cryptic or incomplete. In many cases, you can resolve the problem by loading a highlevel package management tool, such as Synaptic for Debian-based systems or Yumex on
Fedora or Red Hat, and searching for a development package named after the missing tool.
For instance, if you see the preceding message, you’d look for Qt development packages.
Development packages usually include the string -devel, -develop, or -library in their
names. Install any promising package and try again.
Some programs use other methods to configure the compilation. One such method,
which is used by the Linux kernel, is to type make config or some variant of this command.
In the case of the kernel, this command launches a tool that enables you to set various
compile-time options. (Chapter 2 covers kernel configuration and compilation in more
A few programs suggest that you edit a file called Makefile to customize the program
manually. Makefile is a configuration fi le for the make program, which controls the
software compilation process. Typically, if you must edit Makefile yourself, the changes
required are minor, such as changing the installation location or enabling support for one
or two libraries or compile-time features. The documentation usually describes how to
perform such changes; however, some developers assume you have a basic familiarity with
programming. If you need help with technical terms or don’t understand a description, try
performing a Web search on the relevant terms.
Software that you compile yourself (that is, locally) is generally installed in /usr/local
and its subdirectories. Installing software elsewhere can be dangerous, since you might
easily overwrite the fi les installed by your distribution’s package management tools; or such
tools might subsequently replace fi les from a locally compiled program. It’s generally a
good idea to verify that the software is configured to install its fi les in /usr/local.
Compiling the Source Code
Once you’ve run the configure script and it’s completed without errors, you can type make
to compile the software. Software that doesn’t use configure is also usually compiled
in the same way, although you should double- check the documentation to be sure. The
compilation process can take anywhere from a few seconds to several hours, depending
on the size of the program. You’ll see status lines appear on the screen during this process.
Compile and Install Programs from Source
Depending on the package, these lines may be the individual compilation commands and
their output or summaries. If you notice lines that contain the string warning along with
scary-sounding messages about problems, don’t be concerned; GCC generates warnings
like this when programmers use commands in ways that might be a bit risky or that might
be unsupported in the future. Such warnings seldom indicate real problems in release
software. If the output created by make includes the word error, though, and terminates
soon thereafter, this indicates a much more serious problem. An error prevents GCC from
compiling the software, so there’s no point in proceeding with installation until you’ve
found the source of the problem.
To investigate, scroll upward until you locate the fi rst error message. Frequently, one
error results in another, which results in another, and so on. Fixing the last error is likely to
be unproductive, but fi xing the fi rst error may eliminate all the subsequent errors. Compiletime errors in release software are often caused by missing header files or other programs.
Ideally, configure will fi nd such problems, but sometimes it doesn’t. If the error message
mentions a missing fi le or command, try doing a Web search on the name, or use your
distribution’s package manager to search for a package with a similar name. With any luck,
this will lead you to a solution.
Sometimes, release programs don’t compile because of changes in development tools —
GCC might have stopped supporting a particular syntax that the programmer used, or
changes in header fi les might require changes in the program. If you know enough about
programming, you can tackle such problems yourself. If not, you’ll have to contact the
program’s author or enlist the help of somebody with programming experience to solve the
Installing Software
Once the program has fi nished compiling, you can install it. Typically, typing make install
as root will do this: The binary program will be copied to a suitable location, such as
/usr/local/bin, and the program’s man pages and support fi les will also be copied to
reasonable locations, usually in the /usr/local directory tree. If the program is a normal
user program, you should then be able to launch it by typing its name, just as you’d run a
program installed via a package manager.
Some programs don’t provide an install target to make— that is, if you type make
install, nothing useful will happen. For such programs, you must copy the program
fi le manually. You may need to copy man pages or other support fi les, too; consult the
program’s documentation for details. Typically, typing cp progname /usr/local/bin (to
copy the progname binary) as root will do the job; however, the install program does
the copy job and will automatically adjust ownership and permissions for binaries. Typing
install progname /usr/local/bin as root copies progname to /usr/local/bin, changing
its ownership to the current effective user ID (root) and its permissions to 0755. Table 1.5
summarizes several common install options. Consult its man page for more advanced
Chapter 1
TA B L E 1 . 5
System Startup and Advanced System Management
Common install options
-b or --backup
Creates a backup of every destination file.
-g GROUP or --group=GROUP
Changes the group of the installed files to GROUP rather
than to the current group ID.
-m MODE or --mode=MODE
Changes the installed files’ mode to MODE.
-o OWNER or --owner=OWNER
Changes the owner of the installed files to OWNER rather
than to the current user ID.
-s or --strip
Strips symbol tables; reduces a binary ’s size, but makes
debugging harder.
-T or --no-target-directory
Treats the destination location as a file rather than as a
-v or --verbose
Displays the names of all files and directories as they ’re
being copied.
If the program is a server or other system utility that should be launched automatically,
you’ll need to perform additional configuration steps. For instance, you may need to create
a unique SysV startup script, launch the program via a line in /etc/rc.local or some other
generic system startup script, create an inetd or xinetd entry for the program, or create
an entry in /etc/profile or some other user-level startup script to launch the program for
individual users. Consult the program’s documentation if you’re unsure how to proceed. It
may include suggestions or sample configurations you can modify for your system.
After you install software, you can type make clean to remove files
generated during the compilation process. This can save disk space, but if
you need to reinstall the software, you’ll need to recompile it from scratch.
You can, of course, completely remove the source code directory to save
even more space; however, doing so will make it harder to uninstall the
software, should you decide to do so in the future.
Uninstalling or Upgrading Software
If you decide you don’t need the software after all or if you decide to install it from a
binary package for your distribution, you should uninstall it. Many source packages
Compile and Install Programs from Source
support an uninstall target to make so that you can type make uninstall as root in the
original source code directory to remove the software from the computer.
Typing make uninstall will remove the software, much like using the
uninstall feature of RPM or the Debian package manager. The make utility
doesn’t maintain a package database, though; it blindly removes whatever
files are specified in Makefile. Thus, if you use the Makefile from a
different version of the program than you have installed, you might not
remove the right files. If the Makefile is configured to install the program
outside of /usr/local, you might even delete files that were installed via a
package manager.
If the software doesn’t support a make uninstall operation, you’ll have to delete the
fi les manually. This shouldn’t be too tedious for small programs that install just a handful
of fi les, but it can become difficult for bigger programs. Fortunately, most big programs
support the uninstall target.
To upgrade software installed from source using another source distribution, it’s
generally best to compile the new version, uninstall the old software, and then install
the new version. This procedure ensures that you’ll remove all the old fi les and install
the relevant new fi les. Be sure to back up any configuration fi les and verify that your
configuration is correct after you install the new version, though.
In Exercise 1.1, you will practice compiling and installing software from source code.
E X E R C I S E 1 .1
Compiling and Installing Software from Source Code
This exercise gives you hands-on experience with software compilation procedures, using
the JED editor ( as an example. This editor is a small editor
that provides features similar to those of the much larger Emacs package. To compile and
install JED, follow these steps:
Like most open source programs, JED is available as a precompiled binary for many
distributions. Type jed to see if the program is installed; if it is, it will launch a text-mode
editor that you can exit by typing Ctrl+X Ctrl+C. If it’s already installed on your system,
you may want to uninstall it by typing rpm -e jed, dpkg -r jed, or some other
distribution-specific command as root.
Download the source code from; or consult the main JED Web page for a more recent version. This exercise uses JED version
0.99-19 from the jed-0.99-19.tar.bz2 source code file as a model.
Change to a convenient location in your home directory or to /usr/src and ensure you
have write permission to this directory. If necessary, use chmod as root or perform the
following steps as root.
Chapter 1
System Startup and Advanced System Management
Type tar xvjf ~/jed-0.99-19.tar.bz2, adjusting the path to the source tarball as
necessary. The result should be a list of files extracted into the jed-0.99-19 subdirectory.
Change into the jed-0.99-19 subdirectory and examine its contents. Consult the
README and INSTALL.unix files.
As directed by the INSTALL.unix file, use your package manager to ensure that the
slang development libraries are installed. These are likely to be called slang-devel,
libslang2-dev, or something similar.
Type ./configure to configure the build for your environment. Note that the INSTALL
.unix file specifies use of the --prefix=/usr/local option, but this is the default and
so is unnecessary. You may need to point the script to the slang libraries by using
--with-slang=/usr/include (or some other path to slang.h).
Type make clean to ensure any stray files from old compilation attempts are removed.
Type make to build the text-mode binary.
10. If you want it, type make xjed to build a minimally X-enabled version of the program.
11. As root, type make install to install the program.
12. Test the program by using it to review a text file; for instance, by typing jed INSTALL.unix.
You can test the xjed binary in a similar way. If you removed a binary package provided
by your distribution in step #1, you may need to type the complete path to the binary,
as in /usr/local/bin/jed INSTALL.unix. When you log out and back in again, this will no
longer be necessary, provided /usr/local/bin is on your PATH environment variable.
13. JED provides no uninstall target in its Makefile, so if you want to remove the software, you must do so manually, by deleting the /usr/local/jed directory tree and the
jed, jed-script, and xjed binary files from /usr/local/bin.
If any of the preceding steps fails, you will have to debug it, as described earlier in this
chapter. Chances are you can overcome the problem by installing a suitable software
package, such as gcc or make.
Notify Users of System-Related Issues
Computers are used by people, and people can become annoyed if their computers shut
down or otherwise behave strangely at unexpected times. Thus, you should know how
to communicate such issues with the users of a computer. Sometimes this task can be
accomplished by setting login messages, but other times you must send messages to users in
real time.
Notify Users of System- Related Issues
Setting Login Messages
When users log in via a text-mode login prompt, either at the console or remotely, the
computer displays various messages. The login: prompt itself is one such message, but you
can manipulate some others:
Local Login Messages The /etc/issue fi le holds a message that’s displayed above the
login: prompt at a text-mode console. Typically, this message identifies the computer. It
can contain variables that are replaced with the computer’s hostname, the kernel version
number, the time, and so on, as described shortly.
Network Login Messages The /etc/ fi le is similar to /etc/issue, but it holds
information that’s displayed by the Telnet server just before it presents the login: prompt
to the remote Telnet client. This fi le does not influence logins via the Secure Shell (SSH)
server, though.
Message of the Day The message of the day (MOTD) is a message that’s stored in /etc/
motd. This fi le, if it exists, typically holds information you want to communicate to users
about upcoming events or changes, such as scheduled downtime for system upgrades or
changes to system use policies. Because users see its contents only when they log in, it’s not
very useful for notifying users of events that will occur in a matter of minutes. Most textmode login methods, including console logins, Telnet, and SSH, display the MOTD. GUI
login methods typically don’t display it, though.
Fortunes Some system administrators like to spice up the login experience with a pithy
saying. You can do this with the help of the fortune program. Add a call to this program
to the /etc/bashrc fi le to give users a new saying each day. You should be sure to call
fortune only within an if clause, though, as shown in Listing 1.3; a direct call will
interfere with some programs, such as scp. Note that the fortune program doesn’t ship
with all distributions.
Listing 1.3: Code to call fortune from /etc/bashrc
if [ $TERM != “dumb” ]; then
The database used by fortune includes sayings that some people may
find offensive. Sayings that are most likely to be considered offensive
aren’t generated by default, though; they appear only if you use the -a or
-o option to the program. You should be very cautious when using these
options to fortune, lest you provoke the ire of (or even a lawsuit from) an
employer, employee, client, or other viewer of the fortunes.
The /etc/issue and /etc/ fi les support variables that you can use to
substitute information that might vary from one login to another or from one system
Chapter 1
System Startup and Advanced System Management
to another (thus enabling you to use one fi le on multiple systems). These include \n (the
computer’s hostname), \r (the kernel version number), \s (the OS name — Linux), \m (the
platform, such as x86), and \t (the time when the message is printed).
Be sure not to put too much information in system messages, particularly
in /etc/issue and /etc/ Advertising too much about your
system, such as its kernel version number and platform, can give
information to attackers that they can abuse to gain entry to your system.
One problem with all of these communication methods is that they’re all geared toward
text-mode users. If your system supports local or remote X-based users, these methods
won’t help you communicate with them. The same is true for users of servers, such as Web
servers or mail servers. Of course, you can always employ more generic communication
techniques, such as email, instant messaging tools, bulletin boards, paper memos, and even
word of mouth.
Sending Users Messages in Real Time
Two tools that enable you to send messages to users in real time, rather than when they log
into the computer, are:
Shutdown Alerts One particularly important type of user communication is the shutdown
alert. You can pass a message to all text-mode users when you shut down the system via
the shutdown command, as described previously in “Changing Runlevels with shutdown.”
Specifically, text after all other parameters is treated as a shutdown alert message. For
instance, shutdown -h +10 “System going down for maintenance“ displays the message System
going down for maintenance to all users with increasing frequency until the system shuts
Writing to All Terminals The Unix and Linux wall command writes a message to all
active terminals — that is, to all text-mode logins. The wall command may be invoked by
any user, but its exact usage differs from one distribution to others. Sometimes, you type
the command name followed by a message, as in wall Network access going down at 5:00
to display that message on all users’ terminals. Other versions of wall require you to place
the message in a fi le and then pass it to the program or accept input from standard input
rather than on the command line. To use this latter form, you’d type wall and then type the
message followed by Ctrl+D; or you could put the message in a file and pass the fi lename
to the program. Users can block wall messages by using the mesg command, as in mesg n to
block messages or mesg y to re- enable messages.
As with login messages, these messages are normally displayed only to users of textmode logins or shells. A GUI- only user who doesn’t have a text-mode shell open won’t see
such messages.
Exam Essentials
When a computer is fi rst turned on, it proceeds through a series of system-specific checks
and then passes control to the boot loader, which in turn loads the OS’s kernel. The most
common boot loader on Linux systems is GRUB, which is controlled through the menu.lst,
grub.conf, or grub.cfg fi le in the /boot/grub directory. You can edit the configuration
fi le, or scripts that re- create it when other commands run, in order to set certain boot-time
options, add a new kernel to the system, or make other boot-time changes. Once the kernel
has taken control of the system, it runs the init program, which reads its configuration
fi le and uses a series of scripts to launch login processes, servers, and other basic system
services. Traditionally, Linux has used a SysV startup system, which uses symbolic links
in runlevel-specific directories to control what services are started in each runlevel.
Recently, though, the Upstart system has become popular. Upstart supplements (and can
theoretically completely replace) the runlevel-specific directories with Upstart-specific
startup scripts that contain within them information on what conditions trigger the launch
or termination of specific services.
The programs launched by startup systems or users can be installed by package
management tools or by compiling the software locally. Few rules concerning the latter
apply with certainty; software can be written in a variety of languages and may be
prepared and installed in a variety of ways. Typically, though, the software must be
configured for your particular system and then installed. Both tasks are performed by
special scripts or by a fi le called Makefile, which is used by the make program.
You should endeavor to keep users informed of changes in system software or of
impending system shutdowns or other actions that may impact their ability to use the
computer. Several tools, such as options to shutdown, /etc/issue, /etc/motd, and wall,
can be used to help you communicate with users. Because many modern systems are used
primarily via a GUI, though, you may need to employ other methods, such as email or a
telephone, to alert users before making disruptive changes to the system.
Exam Essentials
Describe the boot process, in overview. When a computer fi rst powers up, it reads
instructions from fi rmware, which initiates a series of self- checks and further actions to
be taken. One of these actions is to load and execute code from the computer’s hard disk
or other storage hardware. This code, the boot loader, further directs the boot process
by loading the OS’s kernel, which runs regular OS programs (beginning with init, in the
case of Linux). These programs bring up the OS’s usual array of software, culminating in a
login prompt or an otherwise functional system.
Explain how a user may provide boot-time parameters to Linux. The Grand Unified
Bootloader (GRUB) uses configuration fi les to control the initial stages of the boot process.
Chapter 1
System Startup and Advanced System Management
These fi les provide default options for the system; however, by selecting a GRUB
menu option and then pressing the E key, a user may edit the default options on a
one-time basis.
Summarize the differences between SysV and Upstart. The traditional System V (SysV)
startup script relies on a handful of runlevels, each of which includes a number of services
that can be started by fi xed startup scripts stored in specific directories. Upstart provides
backward compatibility for SysV startup scripts, but Upstart-native startup scripts enable
starting or stopping services based on a wider variety of conditions, which can be helpful in
designing systems to use modern hot-plug hardware.
Describe how to change runlevels in Linux. The default runlevel is set by the id line
in the /etc/inittab fi le. (This fi le is often absent on Upstart-based systems, but Upstart
honors this one /etc/inittab line, if it’s present.) You can change runlevels temporarily by
passing the runlevel number to telinit or init, as in telinit 3 to change to runlevel 3.
Explain how to change what services run in a given runlevel on a SysV system. Scripts
(or, more commonly, links to scripts) in /etc/rc.d/rc?.d, /etc/init.d/rc?.d, /etc/rc?.d,
or a similar location, where ? is a runlevel number, determine what services are started or
stopped in any given runlevel. Scripts in these directories should be renamed to start with K
to stop them in the runlevel or to start with S to start them. Tools such as update-rc.d and
chkconfig can help simplify this task.
Provide an overview of the process of installing software from source code. Source code
programs must be downloaded (usually in the form of a tarball) and extracted. Most
programs provide a configure script, although some require no configuration or must be
configured in some other way. Typing make typically compiles the software, and typing
make config as root installs it. There is enough variability that reading the program’s
documentation prior to configuring it is advisable.
Describe important directories for locally compiled software. The /usr/src directory
tree is the usual location for source code that has been or is being compiled and
installed on the system, with each package having its own directory, such as /usr/src/
samba-3.5.4 for Samba version 3.5.4. Working files and copies of the binaries may be
held here, too, although such files are often removed to save space after the software is
installed. The binaries are usually stored in the /usr/local directory; this directory holds
functional subdirectories, such as /usr/local/bin for binaries and /usr/local/lib for
Summarize tools used to communicate with users. The /etc/issue and /etc/issue
.net fi les contain text that’s shown to local and remote text-mode users, respectively, as
part of the login prompt, while /etc/motd holds a message that’s shown after a successful
text-mode login. The shutdown command includes an option to pass a message to users
explaining an impending system shutdown, and wall enables you to send similar messages
even if the system isn’t about to be shut down.
Review Questions
Review Questions
What is the first program the Linux kernel runs once the kernel itself is running, assuming
a normal Linux startup procedure?
A. begin
You have accidentally renamed your system’s kernel file and rebooted the computer, with
the result that GRUB won’t start the computer. If you remember the name you used when
renaming the kernel file, how can you start the computer in a simple way?
A. Select the misbehaving kernel entry in GRUB, press the D key to have it detect your
kernels, and select the correct one from the list.
Select the misbehaving kernel entry in GRUB, press the E key, and edit the kernel’s name.
Hold down the Shift key while booting to enter the Recovery Console and select the
correct kernel within that tool.
You can’t; this error is severe enough that the only corrective measure is to reinstall
How can you boot Linux directly into single-user mode?
A. In GRUB, select the kernel image you want to boot, press E, and add 1 or single to
the kernel or linux line.
In GRUB, select the kernel image you want to boot, press the 1 key, and confirm your
intentions by responding yes to the prompt.
In GRUB, type single at the boot: prompt to boot the kernel while passing it the
parameter single.
In GRUB, type boot-single-user; true; boot-now to boot the default kernel in singleuser mode.
In what file is the system’s initial runlevel specified on a SysV system?
A. /etc/fstab
Chapter 1
System Startup and Advanced System Management
How can you enter GRUB’s interactive recovery mode?
A. Press the I key at the GRUB main menu.
Press the R key at the GRUB main menu.
Press the M key at the GRUB main menu.
Press the C key at the GRUB main menu.
What file would you edit to add an unusual operating system to a GRUB 2 boot menu?
A. /boot/grub/custom
The following line is present in a Linux computer’s /etc/inittab file. What can you say
about it?
A. The computer boots into runlevel 3.
The computer starts in text mode (X isn’t run).
The computer shuts down as soon as it boots.
The computer uses the Upstart startup system.
What might you find in the /etc/init.d directory?
A. Upstart startup scripts
SysV startup scripts
User login scripts
System login scripts
Where might you find runlevel-specific symbolic links to SysV startup scripts? (Choose all
that apply.)
A. /etc/inittab
10. You want to check the configuration of a server called waiter on a Fedora system, to see in
which runlevels it runs. What might you type to do this?
A. chkconfig --list waiter
info waiter
ps ax | grep waiter
runlevel waiter
Review Questions
11. Which of the following might you reasonably use as a default runlevel? (Choose all that
A. 0
12. An administrator of a Debian system types the following command as root. What will be
the effect, assuming that the appropriate software is installed?
update-rc.d enable disable 23
A. The disable service will be enabled in runlevels 2 and 3.
The disable service will be enabled except in runlevels 2 and 3.
The enable service will be disabled except in runlevels 2 and 3.
The enable service will be disabled in runlevels 2 and 3.
13. You’ve taken over administration of a Fedora Linux system that’s been running for more
than a year. You discover that the dostuff program was installed from source code and
resides in /usr/local/bin and related directories. You want to uninstall this program and
install a newer version from a precompiled binary package. Where is the best location for
you to look for the original source code directory so you can use its uninstall feature?
A. The /usr/portage/distfiles directory
The /var/lib/rpm directory
A subdirectory of /usr/src, probably /usr/src/dostuff or a related name
The /opt/dostuff directory or a directory with a related name.
14. Once you’ve located the original source code directory for a program (dostuff) that was
previously compiled and installed locally, what is a common and effective way to uninstall
the software?
A. Type rm -r /usr/local/bin as root.
Type rm -r /usr/src/dostuff, where dostuff is the original source directory.
Type rpm -e dostuff as root in the original source directory.
Type make uninstall as root in the original source directory.
15. You want to compile and install a program from source code on a Debian system. You’ve
located the program’s home page, where several files are listed in the download section.
Which of these files is most likely to be a source code tarball, based on its filename?
A. theprogram-7.2.12.pkg
Chapter 1
System Startup and Advanced System Management
16. Which of the following options describes the most common sequence for installing
software from source code?
A. Unpack tarball; type make install; type ./configure; type make clean as root.
Unpack tarball; type ./configure; type make; type make install as root.
Unpack tarball; type make; type make cloneconfig; type make uninstall as root.
Unpack tarball; type make; type make install; type make uninstall as root.
17. You want to compile software from source code and install it in the /opt directory tree
(an unusual location). The source code includes a configure script. How might you run this
script to achieve this goal?
A. ./configure --prefix=/opt
./configure --install=/opt
./configure --dir=/opt
./configure --goto=/opt
18. A source package’s Makefile does not include an install target to make. You type make to
create a binary file called theprog. How might you install the software, assuming you care
only about installing this one program? (Choose all that apply.)
A. cp theprog /usr/local/bin
rpm -i theprog
install theprog /usr/local/bin
make install theprog
19. You want to deliver a message to would-be Telnet users that your system is for official use
by employees of your company. What file would you edit to deliver this message before
Telnet users see a login: prompt?
A. /etc/
20. In reviewing files in /etc, you find that /etc/motd is completely empty. What does this
A. The system won’t display a message of the day after users log in.
Morton’s Own Temporary Documentation is not installed on the system.
The motd.conf file’s name has become corrupted and its contents lost.
Users will see no witty aphorisms appear on the screen after logging in.
Answers to Review Questions
Answers to Review Questions
D. By default, the kernel launches the /sbin/init program as its fi rst process, as option D
specifies. This program handles the rest of the system startup process, including launching
SysV or Upstart startup scripts. Options A, begin, and C, Startup, are fictitious programs.
Option B’s startx is a user script that’s used to start the X server after a text-mode login;
it’s not involved in the system startup process.
B. GRUB enables you to edit its entries on a one-time basis by selecting them and pressing
the E key, as specified in option B. Options A and C both describe fictitious procedures.
(Although Windows provides a tool called the Recovery Console, Linux does not.) Because
option B is correct, option D cannot be — although of course reinstalling Linux would fi x
the problem but hardly in a simple way.
A. Option A describes one method of booting into single-user mode. (It’s also possible to
create a permanent GRUB entry for single-user mode that you can select more directly.)
Options B, C, and D all describe fictitious actions that would have no effect. (Option C
describes a boot: prompt, which is a feature of the older Linux Loader, LILO, not of GRUB.)
C. The /etc/inittab specifies the initial runlevel on its id line, as stated in option C.
The /etc/fstab fi le of option A holds information on fi lesystems and their mount
points. The /etc/init.d/runlevel and /etc/runlevel fi les of options B and D are
both fictitious.
D. Pressing the C key enters GRUB’s interactive mode, as option D specifies. The other
options do not have this effect.
C. When a system uses GRUB 2, system administrators are encouraged to edit /etc/grub
.d/40_custom to add custom GRUB configurations for locally compiled kernels or unusual
OSs. After making such a change, you should type update-grub to update the GRUB runtime configuration fi le, /boot/grub/grub.cfg. Option A is a fictitious fi le. Options B and
D are two names for the GRUB Legacy configuration fi le; editing them has no effect on
A. The id line in /etc/inittab specifies the default runlevel, which in this example is 3,
as specified in option A. Although runlevel 3 is a text-mode-only runlevel on Red Hat and
related distributions, as option B specifies, this isn’t true of all distributions; Debian, Ubuntu,
Gentoo, and others control the startup of X in ways other than by the default runlevel. Thus,
option B is not a correct answer. Option C describes the effect of setting the default runlevel
to 0, not to 3, so it is incorrect. The /etc/inittab file is a standard part of the SysV startup
system, and it’s present on some Upstart-based systems. Thus, the presence of this file, or the
presence of the specified line in this file, is not diagnostic of an Upstart-based system, and
option D is incorrect.
B. The /etc/init.d directory holds SysV startup scripts on many Linux systems, as option
B specifies. Upstart startup scripts reside in /etc/init or /etc/event.d, so option A is
incorrect. User login scripts are stored in the users’ home directories under various names, so
option C is incorrect. System login names reside in /etc or subdirectories of it, usually under
names related to the shell, but not in /etc/init.d, so option D is incorrect.
Chapter 1
System Startup and Advanced System Management
C, D. Options C and D both specify directories where runlevel-specific symbolic links to
SysV startup scripts may reside (the ? is a stand-in for a runlevel number), depending on
the distribution in use. The /etc/inittab fi le is the configuration fi le for init in the SysV
startup system, but it doesn’t hold symbolic links, so option A is incorrect. The /etc/init
directory holds Upstart scripts on Upstart-based systems, not SysV startup scripts or links
to them, so option B is incorrect.
10. A. The chkconfig command displays information on or modifies the status of services
started by SysV startup scripts. The --list option displays the status of a service by the
specified name, so option A does as the question asks. The info command is a system
documentation tool; option B displays the info page, if it’s present, for the waiter
command, which is not what the question asks. Option C displays process information on
any processes called waiter or that include the string waiter in the command line. This
won’t reveal in what runlevels these processes run, so option C is incorrect. The runlevel
command displays the current and previous runlevel, but it won’t tell you in which
runlevels a particular program runs, so option D is incorrect.
11. B, C, D. Runlevels 2, 3, and 5 are all reasonable default runlevels, because they all
correspond to working multi-user modes. Debian and related distributions generally use
runlevel 2 as a default, and runlevels 3 and 5 are generally used as defaults without and
with X running, respectively, on Red Hat and related distributions. Runlevel 0 is not a
reasonable default, since runlevel 0 corresponds to system shutdown; if you set it as the
default, the system will shut down as soon as it boots. Thus, option A is not correct.
12. D. The update-rc.d utility affects the runlevels in which services run. It takes a service
name, an action, and a runlevel or list of runlevels as arguments. Thus, enable is a service
name, albeit a confusing one, and disable is a command to disable the service. This
command is applied to runlevels 2 and 3. Option D describes this effect, and the remaining
options do not.
13. C. Source code that’s compiled locally is traditionally extracted to /usr/src,
into a subdirectory named after the package to be installed. Thus, option C is correct,
although there’s no guarantee that the relevant directory will be found — it’s possible
the previous administrator deleted the fi les or used a non-standard location to compile
them. Option A describes a temporary holding location for source tarballs on a Gentoo
Linux system, but it’s not a likely location for a source directory on a Fedora system, so
this option is incorrect. The /var/lib/rpm directory is used by RPM to store its package
database and related fi les, but it’s not a likely location for an administrator to extract
source code for local compilation, so option B is incorrect. Binaries that are distributed in
tarball form are sometimes installed in /opt, but this isn’t a standard location for source
code, so option D is incorrect.
14. D. Many programs have an uninstall target to make, meaning that if you do as option D
suggests, the software will be uninstalled. This action isn’t guaranteed to work, but it is a
common approach, as the question suggests. Option A is incorrect because it will delete any
other unrelated binaries, it will miss any non-binary fi les (such as man pages), and it might
not even uninstall the binary, if it was installed in a non-standard location. Option B will
delete the source code directory, but unless the program was run directly from that location
Answers to Review Questions
(an unusual configuration), it won’t delete the installed binary program, so this option is
incorrect. Option C is incorrect because it’s a way to uninstall a package installed via the
RPM Package Manager (RPM), not from a source tarball.
15. C. Tarballs are fi les archived with tar and, frequently, compressed with gzip or bzip2.
They usually have fi lenames that end in .tgz, .tar.gz, .tbz, .tbz2, or .tar.bz2. Only
option C describes such a fi le. Although the fi lename doesn’t contain a hint that it contains
source code, this is not uncommon for Unix and Linux source tarballs. Option A’s .pkg
fi lename extension identifies it as a probable Mac OS X binary package fi le, not a source
tarball, so option A is incorrect. A .zip fi lename extension identifies a PkZip archive.
Although such fi les are comparable to tarballs in features, they aren’t technically tarballs.
These fi les are more commonly used in the Windows world, so it’s likely that option B
contains a Windows binary. Even if it contains source code, its non-tarball nature means
that this option is incorrect. Option D takes the form for a source RPM fi le. Although such
fi les contain source code, they aren’t source tarballs, as the question specifies, so option D
is incorrect.
16. B. Option B provides a correct, if simplified, description of how to install many source
code packages. Option A is likely to not build correctly, since the make install command
precedes ./configure. (It might work if the software includes no configure script,
but most open source software uses such a script.) Option C will result in no software
installation, since there is no call to make install or other software installation
commands. Option D might install the software, but the make uninstall command will
immediately uninstall it.
17. A. The --prefix option to a configure script usually sets the base of the installation
directory tree. In this example, binary files will probably go in /opt/bin, libraries in /opt/
lib, and so on. The --install, --dir, and --goto options are all fictitious.
18. A, C. Copying the compiled program with cp, as in option A, will install the software,
thus satisfying the question; however, the ownership and permissions on the program fi le
may not be optimal. The install program, used as in option C, changes ownership and
permissions as the fi le is copied, so it is a superior answer to the question —but both A and
C remain correct. The rpm command in option B will attempt to read theprog as an RPM
fi le and install its contents; however, since theprog is a Linux binary program fi le, this
won’t work, and option B will fail. Option D won’t work because the question specified
that the Makefile does not include an install target, so typing make install (even with
the additional parameter theprog) will not work.
19. C. The /etc/ fi le contains text that’s sent by the Telnet server to the remote
Telnet client prior to Telnet’s sending the login: prompt— precisely what the question
requires. There is no standard /etc/ configuration fi le, and /etc/profile is
a configuration fi le for the bash shell, which won’t help achieve the question’s goals. The
/etc/issue fi le is similar to /etc/, but it controls the message that’s displayed
on the local text-mode console.
Chapter 1
System Startup and Advanced System Management
20. A. The /etc/motd fi le holds the message of the day, which is displayed after users log in
using text-mode tools such as text-mode consoles or SSH. An empty /etc/motd fi le simply
means that no such message will appear, as option A describes. There is no such thing as
Morton’s Own Temporary Documentation, referred to in option B. There is no standard
/etc/motd.conf fi le, as described in option C. Witty aphorisms are created by the fortune
program, which is usually called in ways that don’t involve /etc/motd. Although they
might not be displayed, as option D suggests, there’s no linkage between this and the empty
/etc/motd fi le; fortunes are enabled or disabled in other ways.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF