Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam 201 prep: System startup

Intermediate Level Administration (LPIC-2) topic 202

David Mertz, Developer, Gnosis Software
David Mertz
David Mertz is Turing complete, but probably would not pass the Turing Test. For more on his life, see his personal Web page. He's been writing the developerWorks columns Charming Python and XML Matters since 2000. Check out his book Text Processing in Python.

Summary:  In this tutorial, David Mertz begins continues you to take the Linux Professional Institute® Intermediate Level Administration (LPIC-2) Exam 201. In this second of eight tutorials, you learn the steps a Linux™ system goes through during system initialization, and how to modify and customize those behaviors for your specific needs.

View more content in this series

Date:  31 Aug 2005
Level:  Intermediate PDF:  A4 and Letter (226 KB | 12 pages)Get Adobe® Reader®

Activity:  63090 views

Customizing system startup and boot processes

What is a boot loader?

A few years ago, a program called LILO was pretty much universally used to boot Linux on x86 systems. The name LILO is short for "LInux LOader." Nowadays, another program called GRUB (GRand Unified Bootloader) is more popular. On non-x86 Linux systems, other boot loaders are used, but they are generally configured in the same manner as LILO or GRUB.

While there are differences in their configuration syntaxes, LILO and GRUB perform largely the same task. Basically, each presents a choice of operating systems (including, perhaps, multiple Linux kernels) and loads the selected OS kernel into memory. Both programs let you pass arguments on to a Linux kernel along the way, and both can be configured to boot non-Linux operating systems on the same machine.

Either LILO or GRUB (or other boot loaders) generally lives in the MBR (Master Boot Record) of the primary hard disk, which is automatically loaded by system BIOS. LILO was restricted to loading a specific raw sector from a harddisk. GRUB is more sophisticated in that it understands a number of filesystem types such as ext2/3, ReiserFS, VFAT, and UFS. This means that GRUB doesn't need to rewrite the MBR every time a configuration file is changed (the way LILO does).

Configuring the LILO boot loader

The LILO boot loader is configured with the contents of the file /etc/lilo.conf. For full details on configuration options, read the manpage on lilo.conf. Several initial options control general behavior. For example, you will often see boot=/dev/hda or similar; this installs LILO to the MBR of the first IDE hard disk. You might also install LILO within a particular partition, usually because you use a different main boot loader. For example, boot=/dev/sda3 installs LILO to the third partition of the first SCSI disk. Other options control the appearance and wait time of LILO.

Remember that after you have edited a /etc/lilo.conf configuration, you need to run LILO to actually install a new boot sector used during initialization. It is easy to forget to install new settings, but the boot loader itself cannot read the configuration except as encoded as raw sector offsets (which LILO calculates when run).

When using LILO you are mainly interested in the one or more image= lines and perhaps in some other= lines if you multiboot to other operating systems. A sample /etc/lilo.conf might contain:

Listing 2. Sample LILO configuration
append="devfs=mount acpi=off quiet"

This configuration would allow you to choose at runtime either a 2.7.4 development kernel or a stable kernel (the latter happens to utilize an initial ramdrive during boot). You can also select a DOS installation installed to partition 3 on the first IDE drive.

Configuring the GRUB boot loader

A nice thing about GRUB is that it does not need to be reinstalled each time you change boot configuration. Of course, you do need to install it once in the first place, usually using a command like grub-install /dev/hda. Generally, distributions will do this for you during installation, so you may never explicitly run this.

However, since GRUB knows how to read many filesystems, normally you can simply change the contents of /boot/grub/menu.lst to change the options for the next bootup. Let's look at a sample configuration:

Listing 3. Sample GRUB configuration
timeout 5
color black/yellow yellow/black
default 0
password secretword

title linux
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 quiet
vga=788 acpi=off
initrd (hd0,1)/boot/initrd.img

title experimental
kernel (hd0,1)/boot/bzImage-2.7.4 root=/dev/hda2 quiet

title dos
root (hd0,4)
chainloader +1

Changing options within the boot loader (LILO)

Both LILO and GRUB allow you to pass special parameters to the kernel you select. If you use LILO, you may pass boot prompt arguments by appending them to your kernel selection. For example, for a custom boot setting, you might type:

LILO: linux ether=9,0x300,0xd0000 root=/dev/ha2 vga=791 acpi=on

This line passes special parameters to the Ethernet module, specifies the root partition, chooses video mode, etc. Of course, it is not all that friendly, since you need to know the exact options available and type them correctly.

Of particular importance is the option to change the runlevel from the boot loader. For example, for recovery purposes, you may want to run in single-user mode, which you can do with the following:

LILO: experimental single


LILO: linux 1

Another special option is the init= argument, which lets you use a program other than init as the first process. An option for a fallback situation might be init=/bin/sh, which at least gets you a Linux shell if init fails catastrophically.

Changing options within the boot loader (GRUB)

With GRUB, you have even more flexibility. In fact, GRUB is a whole basic shell that lets you change boot loader configurations and even read filesystems. For custom boot options, press "e" in the GRUB shell, then add options (such as a numeric runlevel or the keyword "single" as with LILO). All the other boot prompt arguments you might type under LILO can be edited in a GRUB boot command, using simple readlines-style editing.

For some real sense of the power, you can open a GRUB command line. For example, suppose you think your /etc/inittab might be misconfigured, and you want to examine it before booting. You might type:

grub> cat (hd0,2)/etc/inittab

This would let you manually view your initialization without even launching any operating system. If there were a problem there, you might want to boot into single-user mode and fix it.

Customizing what comes after the boot loader

Once you understand the steps in a Linux post-kernel boot process (in other words, the init process and everything it calls), you also understand how to customize it. Basically, customization is just a matter of editing /etc/inittab and the various scripts in /etc/rc?.d/ directories.

For example, I recently needed to customize the video bios on a Debian-based Linux laptop using a third-party tool. If this didn't run before X11 ran, my XOrg driver would not detect the correct video modes. Once I figured out what the issue was, the solution was as simple as creating the script /etc/rcS.d/ In other words, I began running an extra script during every system startup.

Notably, I made sure this ran before /etc/rcS.d/S70xorg-common by the simple convention that scripts run in alphabetical order (if I wanted it to run later, I might have named it instead). Arguably, I might have put this script only in the /etc/rc5.d/ directory to run when X11 does -- but my way lets me manually run startx from other runlevels.

Everything in the initialization process is out in the open, right in the filesystem; almost all of it is in editable text scripts.

3 of 6 | Previous | Next


TutorialTitle=LPI exam 201 prep: System startup