Boot Loaders:

Some Information and Practical Advice on Booting Linux and Other OSes

by James R. Williams Zavada, August 2003
It's not so hard to lift yourself by your bootstraps once you're off the ground.
- Daniel B. Luten

An adequate bootstrap is a contradiction in terms.
- Anonymous Quote

Table of Contents

Disclaimer:

 This information is provided in the hopes that you will find it useful and instructive. However, it is provided with ABSOLUTELY NO WARRANTY OF ANY KIND.

Any and all trademarks mentioned in this text are property of their respective owners.

Introduction:

By the end of this presentation, we hope to have provided you enough information to understand what a bootloader is and does, and how you can use one to your benefit in a single-boot Linux environment, as well as a dual- or multi-boot environment.

The topics we'll cover include:

  1. The Boot Process of an IBM-PC Compatible (Wintel, x86, etc.) Computer.

  2. The Two Most Popular Linux Boot Loaders and Some Configuration Details

  3. Linux Kernel Boot Parameters

  4. The Ins and Outs of Multi-Booting

  5. Odds, Ends, and Resources

Because your individual booting circumstances are quite likely to vary from mine or anyone else's, and because several HOWTOS already exist on the topic, this presentation will not be a tutorial on installing or configuring boot loaders, nor will it go into great detail about how to set up a dual- or multi-boot system. It will, however, provide a list of links to other resources that do provide such details, as well as provide some very practical advice that will help you to avoid potential boot-loader problems.

It is also important to keep in mind that an incorrectly installed and/or configured boot loader can render your computer unbootable, and thereby unusable, so I highly recommend you read any and all bootloader documentation for your system before attempting anything mentioned in this presentation. Also bear in mind that although I strive for accuracy herein, you may encounter typographical or other errors, so any changes you make to your system are done AT YOUR OWN RISK. In other words, you can frig up your computer very easily by doing the wrong thing, or by doing the right thing in the wrong way. So be very, very careful when changing your bootloader and/or its configuration. YOU HAVE BEEN WARNED.

The Boot Process:

Although booting up a computer may be to you as simple as flipping on the power switch, there is quite a bit that goes on under the hood. Actually, booting up a computer to run an operating system, any operating system, is a very intricate process. Think about this for a moment: A computer, at its very heart, is nothing more than a machine that follows instructions. An operating system, is a very complicated set of instructions that allow one or more users access to the computer's resources to perform specific tasks. How does a computer go from having no instructions at all, to running an entire operating system full of instructions? This is what the boot process is all about. Early computers were so simple that they had no real boot process or operating systems. Instructions had to be entered when the computer was started, either manually, from some type of storage device. In order to actually run programs, a computer has to be first prepped with a set of instructions that enable it to load and run programs from a storage device, and to do this process is to "boot" a computer. To quote Eric S. Raymond's Jargon File:
...this term [boot] derives from bootstrap loader, a short program that was read in from cards or paper tape, or toggled in from the front panel switches. This program was always very short (great efforts were expended on making it short in order to minimize the labor and chance of error involved in toggling it in), but was just smart enough to read in a slightly more complex program (usually from a card or paper tape reader), to which it handed control; this program in turn was smart enough to read the application or operating system from a magnetic tape drive or disk drive. Thus, in successive steps, the computer 'pulled itself up by its bootstraps' to a useful operating state. Nowadays the bootstrap is usually found in ROM or EPROM, and reads the first stage in from a fixed location on the disk, called the 'boot block'. When this program gains control, it is powerful enough to load the actual OS and hand control over to it.

The first step in the x86 boot process, is to load a very basic set of input/output instructions, that enable the system to access a storage device, in order to load an operating system. In x86 terminology, these instructions are collectively known as the "BIOS", that is, the Basic Input/Output System, whereas on non-x86 systems, it is often called the system's "firmware". The BIOS (or firmware) is hardwired into memory, and the computer is set up to automatically load and run these instructions when the power is turned on. The part of the BIOS that we're interested in is the boot loader. On a traditional x86 computer, the BIOS boot loader reads the first sector (512 bytes) of a floppy disk or hard drive into memory (at 7C00h for those of you interested). It then checks the sector for a valid boot signature (the last two bytes must be 55AAh). If there is a valid boot signature, it then executes the instructions, no matter what they are.

The typical floppy boot sector contains instructions that allow the system to find the rest of what needs to be loaded, whether it be the guts of an operating system, or another boot loader that is more sophisticated and able to load the rest of the system. The typical hard disk boot sector (often referred to as the Master Boot Record, or MBR) also contains a "partition table", that is, a table of entries that allow the computer to divvy up the hard drive into originally as many as four partitions. Later on, the idea of "extended partitions" was invented, to allow hard drives to have more than just four partitions.

When booting from a hard drive, the BIOS will load the MBR into memory, and at the very least the instructions on the MBR will choose the first partition flagged as bootable, valid its first sector as bootable, load it into memory, and execute its instructions. Usually, these instructions are similar to a floppy boot sector, in that there is now no longer a partition table.

Over time, as the demands on boot loaders have grown more sophisticated, there was no longer room to fit the entire set of instructions in the 512 bytes available in a disk sector (less if you have to fit a partition table). Thus, many modern boot loaders use several stages. The first stage has to fit into 512 bytes, so it is designed to load a second stage that provides all the features that users have grown to expect in a boot loader. The second stage is then responsible for loading the guts of the operating system. The two boot loaders we'll focus on next use this method to do their job.

The LILO Boot Loader:

Without going into a lot of technical detail, thus risking a bit of technical and historical inaccuracy, the Linux kernel was originally designed to be booted directly, either as part of the floppy boot sector, or one of the partitions loaded by a hard drive's Master Boot Record. Installing a Linux kernel into a boot sector is easy if you're a very learned PC hacker. However, few folks who want to use Linux, know very much about the boot process, not even most PC gurus. Moreover, several early adopters of Linux wanted a way to share a system between two OSes, and choose which one to run at boot time. Without a specifically designed boot loader, this was impossible. Fortunately, one of the early Linux developers came to the rescue: LILO, the LInux LOader. LILO is a sophisticated boot loader that gives the computer user a wide range of configurable options regarding the boot process.

LILO allows the computer user to set up the boot process as menu-driven or command-line, and permits the user to choose from amongst several boot options. It also allows for a default boot option after a configurable timeout, and current versions are designed to allow booting from broken Level 1 (mirrored) RAID arrays. It has the ability to create a highly configurable, "GUI-fied" boot menu, or a simple, text-only, command-line prompt. LILO can pass parameters to the kernel, use an initrd (initial ramdisk), and has several options to enable loading other OSes for multi-booting.

Although LILO saves many of us considerable time and energy, it has one serious drawback. Every time you recompile the Linux kernel, you have to re-configure LILO so that it knows where to find the kernel. This one little flaw can cause some very serious problems. For example, let's say you've just installed a newly recompiled kernel. You're so excited to give it a trial run that you run "shutdown -r now", and all of a sudden you realize that you forgot to update LILO. But it's already too late, the system's already past the BIOS memory test, and LILO has already spewed its error message. Gotcha!! Actually, even though it may seem as if all is lost, there is are still ways out. First, you did create a boot floppy when installed your system, right? What? You say you didn't? For shame!! My first bit of advice is to always, Always, ALWAYS create a boot floppy. Even though you think may never need it, do it anyways. The one time you're in a pinch and can still boot your system and fix things will pay for all the times you make one and never use it. So you boot off your emergency boot floppy, rerun LILO and you're all set. But what if you don't have a boot floppy?

You still have some options you can try. Find your Linux install CD, boot off it into whatever your distribution calls "rescue mode". Or, if you have Tom's Root/Boot Rescue floppy, boot off it. Then make sure your "/boot", "/", and "/etc" filesystems are mounted under "/mnt". Now rerun LILO using the following command-line, and you're good to go:

lilo -r /mnt -C /etc/lilo.conf

The fact that you can get yourself into a situation where you need to do this is what I consider to be LILO's one major drawback. This flaw has driven others to continue developing boot loaders, one of which I will discuss next.

The Grub Boot Loader:

A boot loader that solves LILO's problem while still providing many of the same features is Grub, the GRand Unified Bootloader. With Grub, you can recompile your kernel at will, but because it understands the Linux ext2 filesystem, it can always find the kernel and load it. Moreover, its config file is very similar to LILO's. My only complaint about it is that it doesn't have the ability to automatically boot from a broken Level 1 (mirrored) RAID array, like LILO. Grub is my boot loader of choice, and if you're new to Linux, or new to kernel compilation, I highly recommend using Grub. As a matter of fact, I use Grub so much that my LILO knowledge is getting rusty. And the only time I've gotten myself into trouble using Grub is when I tried to install it on a pre-existing LILO system, without having RTFMed first.

Kernel Boot Parameters and How to Use Them:

Although they are often overlooked, Kernel Boot Parameters can be very useful for enhancing your system, and they are quite easy to use (especially with Grub). As an example, I've an older dual-processor motherboard that doesn't implement the SMP (Symetric Multi-Processor) protocol properly, and used to lock up after a couple of hours. After doing a google search, I found that disabling the APIC could help. All I had to do was add the kernel boot parameter "noapic", and I was up and running. Now I only have to worry about lockups every other month or so (until I can afford to upgrade to a better motherboard ;-). With Grub, you merely add the boot parameter to the "kernel" line in the config file, and with LILO you add an "append" statement. I also use boot parameters is to set the system runlevel (I use runlevels to experiment with various system init options). Yet another way I use kernel boot parameters is to make my kernel view my ATAPI CDwriter as a ide-scsi device, so that I can burn CDs with ease. Another nifty way I use them is to pass environment variables to the system init, which I also use to experiment with various system setups.

The Ins and Outs of Multi-Booting:

So you want to make your system multi-boot, eh? First of all, I don't recommend it, unless you're on an extremely limited budget, or you really like to experiment with multi-boot. The reason is simple: In my experience, you're in the middle of doing some work using one OS, yet you need to access a feature only available in the other OS, and the only option is to save ALL your work. Then you have to wait for however long it takes for your current OS to shutdown and the other one to finish booting. When that's done, you get to do something that likely only takes a minute or two, then you have to reboot all over again and reload all your saved work. I find this very annoying. However, I'll admit that there are those who prefer multi-booting (and I've even done it myself on occasion), so here's my advice on how to do it and avoid some problems.

First and foremost, use two (or more) hard disks. Usually, when you install a single OS, you have it use up the entire disk space available, and when you want to install a second, there's no room left to do so. Save yourself the hassle of re-partitioning the hard drive and trying to squeeze the original OS into a smaller space. Buy a second hard drive and install the other OS on it. You'll be glad you did!

My second piece of advice is this: Install Windows first. Because Windows thinks that it's the only OS you'll ever want or need, it has very limited multi- boot capabilities (or none if using Win9x), and WILL overwrite your hard drive's Master Boot Record. And if you've already installed Linux along with an intelligent boot loader, you will lose the boot loader and it's ability to boot Linux.

My next bit of advice is that when learning to set up a multi-boot system, it is always better to practice on an unimportant machine first. That way, you don't have to worry about munging a workstation with important programs and data on it. And these days, throw-away 486 boxes aren't to hard to find, and 2-8Gb hard drives are pretty easy to come by as well. So do yourself a favour and practice your multi-boot install on a cheap practice machine.

My final piece of advice is one we've all heard before, but frankly, if we all did it more often we'd have a lot less problems. RTFM. Read The Fine Manual. The more you research a solution before you implement it, the less likely you are to encounter problems.

Odds, Ends and Resources:

Before I wrap things up, there is one other use for boot loaders that I've already mentioned, but I'd to add some details. One of my favourite uses for boot loaders is to multi-boot into the same OS (Linux) but use different parameters. LILO and Grub make it easy to create several experimental boot environments, while keeping a known, stable default. This enables hackers who just can't leave well enough alone to eat their cake and still have it. I can't tell you how many times I've created an experimental environment that didn't work and would've hosed my system if it hadn't been for the default. So whenever you want to change your boot environment, make sure to configure the old one as a default.

One last tidbit. I tinker alot on old throw-away 486 boxes. Many of them cannot boot off a CD to do a Linux install. I used to do network installs, until I discoverd a boot loader called "Smart Boot Manager" ( http://www.turbolinux.com.cn/~suzhe/). This puppy can be installed on a floppy, and allows you to boot from a bootable CD, even though the system's BIOS doesn't support it. It makes for a very handy tool when using those old 486es!

And finally, here's a list of resource links: