Customizing system startup and boot processes
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).
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
image=/boot/bzImage-2.7.4 label="experimental" image=/boot/vmlinuz label="linux" initrd=/boot/initrd.img append="devfs=mount acpi=off quiet" vga=788 read-only other=/dev/hda3 label=dos
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.
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) makeactive chainloader +1
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.
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.
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/S56-resolution.sh. 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 S98-resolution.sh 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.