There are several ways of booting Linux on your system. The most common methods involve booting from the hard drive or using a boot floppy . In many cases, the installation procedure will have configured one or both of these for you; in any case, it's important to understand how to configure booting for yourself.
17.1.1. Using a Boot Floppy
Traditionally, a Linux boot floppy simply contains a kernel image, which is loaded into memory when you insert the floppy and start the system.[*]
Many Linux distributions create a boot floppy for you in this way when installing the system. Using a boot floppy is an easy way to boot Linux if you don't want to bother booting from the hard drive. (For example, Windows NT/2000/XP's boot manager is somewhat difficult to configure for booting Linux. We talk about this in the next section.) Once the kernel has booted from the floppy, you are free to use the floppy drive for other purposes.
We include some technical information here in order to explain the boot process, but rest assured that in most cases, you can just insert the floppy disk, and booting works. Reading the following paragraphs will help you understand your system, though.
The kernel image is usually compressed, using the same algorithm as the gzip or the bzip2 compression programs (more on this in "Compiling the kernel" in Chapter 18). Compression allows the kernel, which may be several megabytes or more in size, to require only a few hundred kilobytes of disk space. Part of the kernel code is not compressed: this part contains the routines necessary to uncompress the kernel from the disk image and load it into memory. Therefore, the kernel actually bootstraps itself at boot time by uncompressing into memory.
A number of parameters are stored in the kernel image. Among these parameters is the name of the device to use as the root filesystem once the kernel boots. Another parameter is the text mode to use for the system console. All these parameters may be modified using the rdev command, which we discuss later in this section.
After the kernel has started, it attempts to mount a filesystem on the root device hardcoded in the kernel image itself. This will serve as the root filesystemthat is, the filesystem on /. "Managing Filesystems" in Chapter 10 discusses filesystems in more detail; all that you need to know for now is that the kernel image must contain the name of your root filesystem device. If the kernel can't mount a filesystem on this device, it gives up, issuing a kernel "panic" message. (Essentially, a kernel panic is a fatal error signaled by the kernel itself. A panic will occur whenever the kernel is terminally confused and can't continue with execution. For example, if there is a bug in the kernel itself, a panic might occur when it attempts to access memory that doesn't exist. We'll talk about kernel panics more in the section "What to Do in an Emergency" in Chapter 27.)
The root device stored in the kernel image is that of your root filesystem on the hard drive. This means that once the kernel boots, it mounts a hard drive partition as the root filesystem, and all control transfers to the hard drive. Once the kernel is loaded into memory, it stays therethe boot floppy need not be accessed again (until you reboot the system, of course).
Given a reasonably small kernel image, you can create your own boot floppy. On many Linux systems, the kernel itself is stored in the file /boot/vmlinuz.[*] This is not a universal convention, however; other Linux systems store the kernel in /vmlinuz or /vmlinux, and still others in a file such as /Image. (If you have multiple kernel images, you can use GRUB to select which one to boot. See the next section.) Note that newly installed Linux systems may not have a kernel image on the hard drive if a boot floppy was created for you. In any case, you can build your own kernel. It's often a good idea to do this anyway: you can customize the kernel to include only those drivers for your particular hardware. See "Building the Kernel" in Chapter 18 for details.
All right. Let's say that you have a kernel image in the file /boot/vmlinuz. To create a boot floppy, the first step is to use rdev to set the root device to that of your Linux root filesystem. (If you built the kernel yourself, this should be already set to the correct value, but it can't hurt to check with rdev.) We discussed how to create the root device in "Editing /etc/fstab" in Chapter 2.
As root, use rdev -h to print a usage message. As you will see, there are many supported options, allowing you to specify the root device (our task here), the swap device, ramdisk size, and so on. For the most part, you needn't concern yourself with these options now.
If we use the command rdev /boot/vmlinuz, the root device encoded in the kernel found in /boot/vmlinuz will be printed:
courgette:/# rdev /boot/vmlinuz Root device /dev/hda1
If this is incorrect, and the Linux root filesystem is actually on /dev/hda3, we should use the following command:
courgette:/# rdev /boot/vmlinuz /dev/hda3 courgette:/#
rdev is the strong, silent type; nothing is printed when you set the root device, so run rdev /boot/vmlinuz again to check that it is set correctly.
Now you're ready to create the boot floppy. For best results, use a brand-new, formatted floppy. You can format the floppy under Windows or using fdformat under Linux; this will lay down the sector and track information so that the system can autodetect the size of the floppy. (See the section "Managing Filesystems" in Chapter 10 for more on using floppies.)
To create the boot floppy, use dd to copy the kernel image to it, as in the following example:
courgette:/# dd if=/boot/vmlinuz of=/dev/fd0 bs=8192
If you're interested in dd, the manual page will be illustrative; in brief, this copies the input file (if option) named /boot/vmlinuz to the output file (of option) named /dev/fd0 (the first floppy device), using a block size (bs) of 8192 bytes. Of course, the plebian cp can be used as well, but we Unix sysadmins love to use cryptic commands to complete relatively simple tasks. That's what separates us from mortal users.
Your boot floppy should now be ready to go. You can shut down the system (see "Shutting Down the System" later in this chapter) and boot with the floppy, and if all goes well, your Linux system should boot as it usually does. It might be a good idea to make an extra boot floppy as a spare. In "What to Do in an Emergency," in Chapter 27, we describe methods by which boot floppies can be used to recover from disaster.
17.1.2. Using GRUB
GRUB is a general-purpose boot manager that can boot whatever operating systems you have installed on your machine, including Linux. There are dozens of ways to configure GRUB. Here, we discuss the two most common methods: installing GRUB on the master boot record of your hard drive and installing GRUB as a secondary bootloader for Linux only.
GRUB is the most common way to boot Linux from the hard drive. (By the expression "boot from the hard drive," we mean that the kernel itself is stored on the hard drive and no boot floppy is required, but remember that even when you use a boot floppy, control is transferred to the hard drive once the kernel is loaded into memory.) If GRUB is installed on your drive's master boot record, or MBR, it is the first code to run when the hard drive is booted. GRUB can then boot other operating systemssuch as Linux or Windowsand allow you to select between them at boot time.
Windows NT and later versions of Windows have boot managers of their own that occupy the MBR. If you are using one of these systems, in order to boot Linux from the hard drive, you may have to install GRUB as the "secondary" bootloader for Linux only. In this case, GRUB is installed on the boot record for just your Linux root partition, and the boot manager software (for Windows NT/2000) takes care of executing GRUB from there when you wish to boot Linux.
As we'll see, however, the Windows NT/2000/XP boot managers are somewhat uncooperative when it comes to booting GRUB. This is a poor design decision, and if you must absolutely use one of these boot managers, it might be easier to boot Linux from floppy instead. Read on. Or, if you really want to go with Linux all the way, you can use GRUB to boot Windows NT/2000/XP and dump the Windows boot managers completely. That is usually a fairly painless way, and the one we recommend. It is also what most distributions install automatically if you try to install Linux on a computer with an existing Windows installation.
Use of GRUB with Windows 95/98/ME/2000/XP is quite simple. You just configure GRUB to boot Windows 95/98/ME/2000/XP (see the next section). However, if you install Windows 95/98/ME/2000/XP after installing GRUB, you need to reinstall GRUB (as the Windows 95/98/ME/2000/XP installation procedure overwrites the MBR of your primary hard drive). Just be sure you have a Linux boot floppy on hand so that you can boot Linux and rerun GRUB.
Before proceeding you should note that a number of Linux distributions are capable of configuring and installing GRUB when you first install the Linux software. It might be a good idea to just let your distribution's installation program do its thing, install GRUB, and then check what it has done; this gives you something working to start with that you can then tweak to your taste.
220.127.116.11. The /etc/grub.conf file
The first step in configuring GRUB is to set up the GRUB configuration file, which is often stored in /etc/grub.conf. The /etc/grub.conf file references other configuration files that we look at later. Often, the /etc/grub.conf file can be very short.
We are going to look at a sample grub.conf file. You can use this file as a base for your own grub.conf and edit it for your own system.
It should be said at this point that GRUB is very flexible and can actually drop you into a shell that lets you enter GRUB commands interactively during the boot process. However, most users would find this both tedious and error-prone, which is why we describe another use here, which will provide you with a convenient menu that you can select from (for example, in order to boot different kernels or even different operating systems). With this setup, the grub.conf file can be quite concise. Here is an example:
root (hd0,0) install --stage2=/boot/grub/stage2 /grub/stage1 (hd0) /grub/stage2 0x8000 (hd0,0)/grub/menu.lst quit
The first line specifies the drive to boot from. In this case, it is the first partition on the first hard disk--hd is for hard disk, the first zero is for the first hard disk in the system, and the second zero for the first partition on that particular hard disk (GRUB always starts counting at zero!). It is quite common among Linux users to reserve a small partition (often mounted as /boot) for the kernel image and booting-related files. Because there have been limits in the past regarding the parts of the disk from which bootloaders could load kernel images, it has become customary to make this partition the very first one. Although these limits are mostly gone with modern hardware, modern BIOSes, and modern bootloaders, this tradition prevails, and it definitely does not hurt to keep it.
A few more examples: (fd0) would mean to boot from the first floppy disk in the system, and (hd3,4) would mean the fifth partition on the fourth hard drive (of one lucky Linux user who apparently can afford lots of hardware). There is also the special name (nd) which is used for booting the kernel image from the network, something that is beyond the scope of this book.
The second line is fairly complex. It would go too far to dissect the complete booting process, but we can at least say that GRUB uses a two-stage booting process, and this command specifies where to get the instructions for the two stages from, at which address to load them into the computer's memory, and what to do then. The "what to do then" part is the most interesting for us; in the example configuration file, it is the (hd0,0)/grub/menu.lst part at the end. Where should this file be located so that GRUB can find it? If you try:
pooh:~ # ls /grub/menu.lst /bin/ls: /grub/menu.lst: No such file or directory
you will not find it. But remember that GRUB uses the parentheses to denote a device, in our case a hard disk partition, the first partition on the first hard drive. This could be anywhere, of course, but if you remember that most systems create a small partition that does not contain much except the kernel image and the bootloader files, and that it is often mounted as /boot, you can try:
pooh:~ # ls /boot/grub/menu.lst /boot/grub/menu.lst
Aha! Of course, if you are installing GRUB from scratch on your system and, unlike us, do not have a preinstalled configuration that you are just fiddling around with, then you will not get a result here either. Rest assured, however, that this is where GRUB will search for the menu file.
What would such a menu file look like? Here is an example of a version that loads two different Linux configurations and MS-Windows, all presented in a convenient menu:
default 0 timeout 10 title Linux kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 vga=0x314 title Linux Failsafe kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 ide=nodma apm=off acpi=off vga=normal noresume barrier=off nosmp noapic maxcpus=0 3 title Windows root (hd0,0) chainloader +1
The first two lines together mean that when the boot menu is presented by GRUB, the user has 10 seconds (timeout) to make a choice; otherwise, the first entry of the following list will be booted.
After these two initial lines, there are three sections that each start with title. After the title, a string is specified that will be shown in the boot menu at boot time. For the two Linux configurations, there is then a kernel line that shows where the kernel image is loaded from. Everything else is passed directly to the kernel as boot parameters, including what the root device should be, and the terminal mode (vga=0x314). In the so-called failsafe configuration, we specify a lot of kernel parameters that turn off just about any kernel functionality that has the slightest chance of going wrong. Such a system will be slow and not have complete functionality, but if you have misconfigured something, the failsafe kernel may still get along and let you at least boot the system so that you can repair things.
If you type in those commands manually at the GRUB shell, you would have ended with the command boot. The kernel command loads the kernel into memory, but does not actually boot it; the boot command performs the actual booting process. However, if you use the GRUB menu system as we do here, the boot command is implicit and can be left out at the end of each section.
Loading Windows works differently. GRUB is not able to load operating systems other than Linux, the BSD family, and a few others directly. For those other systems, such as Windows, it invokes instead the bootloader that comes with those systems. This is called chain-loading, and the GRUB command to do this is not surprisingly called chainloader. The +1 means that GRUB can find the bootloader on the partition specified with the previous root command, one sector into the partition.
When you are satisfied with your GRUB setup, you still need to install it. This is best done with the command grub-install, which expects to be told the directory in which the stage files and kernel images can be found, and on which device to install the bootloader. This could look like this:
pooh:~ # grub-install --root-directory=/boot /dev/hda
This installs the bootloader on the first IDE hard drive (/dev/hda), which is typically the one that the computer's BIOS searches for finding the initial booting information.
This was just a short introduction into the world of GRUB. GRUB can do a lot more, such as booting kernel images from the network or over a serial line, providing fancy graphics, and so on. If you plan to do any serious work with GRUB (and since a bootloader is crucial for being able to use the system at all, any changes of configuration files beyond trivial things such as changing the strings of the menu entries, the default entry, or the timeout, can be considered serious in this context), we urge you to read the excellent GRUB documentation that comes as Info files, and that you can read nicely in KDE by typing info:grub in Konqueror's location bar.
18.104.22.168. Specifying boot-time options
When you first installed Linux, more than likely you booted either from a floppy or a CD-ROM, which very likely gave you a GRUB (or other bootloader) boot menu. Selecting an entry and typing e gets you a boot prompt. At this prompt you can enter several boot-time options, such as:
to specify the hard drive geometry. Each time you boot Linux, it may be necessary to specify these parameters in order for your hardware to be detected correctly. If you are using GRUB to boot Linux from the hard drive, you can specify these parameters in the kernel line in the GRUB configuration file instead of entering them at the boot prompt each time. To the Linux entry, just add a line such as:
append = "hd=683,16,38"
This causes the system to behave as though hd=683,16,38 were entered at the GRUB boot prompt. If you wish to specify multiple boot options, you can do so with a single append line, as in:
append = "hd=683,16,38 hd=64,32,202"
In this case, we specify the geometry for the first and second hard drives, respectively. Once you are done with your changes at the boot prompt, press the Esc key to go back to the boot menu, and boot from there.
Note that you need to use such boot options only if the kernel doesn't detect your hardware at boot time, which is unlikely unless you have very old or very uncommon hardware. You should already know if this is necessary, based on your experiences with installing Linux; in general, you should have to specify kernel parameters in the kernel lines in the GRUB menu file only if you had to specify these boot options when first booting the Linux installation media.
There are a number of other boot-time options. Most of them deal with hardware detection, which has already been discussed in Chapter 2. However, the following additional options may also be useful to you:
Any of these options can be entered by hand at the GRUB boot prompt or specified in the kernel line in the GRUB configuration file.
22.214.171.124. Removing GRUB
If you have GRUB installed on your MBR, the easiest way to remove it on Windows 95/98/ME is to use Windows FDISK. The command:
runs FDISK and overwrites the MBR with a valid Windows boot record. On Windows NT/2000/XP, the procedure is a lot more involved.