Bootloader

Overview

This page first talks about the general boot process of a PC, which is necessary to understand the configuration of a concrete bootloader. This page then goes on to detail the configuration of various Linux bootloaders.

References

http://www.xs4all.nl/~lennartb/bootloaders/node3.html 

"How Boot Loaders Work". An excellent article that describes the fundamentals of bootloaders on an IBM PC.

http://en.wikipedia.org/wiki/Booting 

General Wikipedia article about the computer boot process (not only related to IBM PC)

http://en.wikipedia.org/wiki/Master_boot_record 

Wikipedia article that has details on the structure of the Master Boot Record.

Glossary

The definition of terms in this glossary is simplified to the uses I have for each term. In the context of other machines than an IBM PC, or another operating system than Linux, the terms may have other or extended meanings.

Booting 

The process of loading the operating system. This process typically occurs in stages where several programs of increasing complexity sequentially load one after the other.

Bootloader 

A series of programs that are used to achieve the booting process, i.e. to load the operating system.

Boot sector program 

Part of a bootloader. Very small (max. 512 bytes) and primitive program that resides entirely in the MBR or VBR and is used to chainload the second stage program.

Second stage program 

Part of a bootloader. Larger and more complex program that resides anywhere on a disk and is used to chainload the actual operating system (e.g. the Linux kernel).

Bootloader installer 

Part of a bootloader. This program does not take part in the actual boot process; instead it used to write the boot sector program into the MBR or VBR and to generally configure everything so that boot sector programs and second stage programs can find the next stage that they must load

MBR 

Master Boot Record. The first sector (sector 0) of a hard disk or other data storage device. See the References section for a link to the Wikipedia article.

VBR 

Volume Boot Record. The first sector (sector 0) of a partition. See the Wikipedia article.

Partition table

Defines how a hard disk is laid out in partitions or volumes. The partition table is stored in the MBR and occupies 64 bytes of space.

General description of the booting process

Overview

This section contains a condensed version of the article "How Boot Loaders Work".

The BIOS

The task of the BIOS is the following:

• The BIOS only knows how to load the first 512-byte sector from a hard disk. This sector is called the MBR (master boot record).
• The BIOS loads the content of the MBR into memory at a fixed memory address (address 0000:7C00) and then jumps to that address
• Assuming that the MBR contained a program, that program (called the "boot sector program") now starts to execute

Note that when the boot sector program needs to load something from disk, it must use BIOS interrupts. This is where the disk size limits often found in older BIOS' kicks in:

• The parameters of the disk I/O interrupt have a certain range limit
• On older systems (pre 1995) it was possible to address only up to 1024 cylinders
• On slightly newer systems (1995-1998) up to 8GB could be addressed
• Since 1998 systems use a new calling interface for their disk I/O interrupt, named LBA (linear block addresses, or logical block addressing), for which I don't know the limit

The boot sector program

The task of the boot sector program is the following:

• Possibly move itself to a different address in memory (so as not to overwrite itself in the next step)
• Load the next stage of the bootloader into memory (either at address 0000:7C00, or somewhere else). There are several options what can happen here:
  • It may load the content of a VBR (volume boot record). The VBR contains a partition-specific boot program which is also called "boot sector program". Depending on how sophisticated the boot sector program's implementation is, it may simply load from a pre-determined VBR (in this case the bootloader installer has hard-coded the VBR when it wrote the boot sector program to disk), or it may look at the partition table and use the VBR of the partition that is flagged as active.
  • It may load a second stage program from somewhere on disk. Because the boot sector program is very small and primitive, its implementation does not have the ability to access the second stage program by directory and file name. Therefore the bootloader installer probably has hard-coded the disk sector where to look for the second stage program directly into the boot sector program
  • It may load the kernel directly
• Jump to the address to continue the boot process with the next stage

LILO can be helpful to find out BIOS-specific details about where the different stages of a bootloader are loaded and run in memory. For instance on my machine:

osgiliath:~# lilo -T EBDA          
    Extended BIOS Data Area (EBDA) = 2K
    Conventional Memory = 638K    0x09F800

    The First stage loader boots at:  0x00007C00  (0000:7C00)
    The Second stage loader runs at:  0x0009C200  (9C20:0000)
    The kernel cmdline is passed at:  0x0009F600  (9000:F600)

The second stage program

Because the second stage program can be much larger than the boot sector program, it is capable of doing more complicated and sophisticated things. Its task is the following:

• Usually displays some sort of user interface that allows to select the
• When done, usually loads either the operating system

The bootloader installer

The task of the bootloader installer:

• Installs the boot sector program, either into the MBR or one of the VBRs
• Tells the boot sector program where the second stage boot loader is; usually hard-codes that location by writing one or more sector addresses into the boot sector program
• Tells the second stage boot loader where all relevant information is (configuration, kernels). This is the case with LILO: LILO creates a map file that contains all relevant sector addresses and puts pointers to the map file in the boot sector and/or second stage boot loader.

General HOWTOs

Use dd to read and write the MBR

Leave the partition table intact, but remove any boot sector program by overwriting the first part of the MBR with zeroes:

dd if=/dev/zero of=/dev/hda bs=446 count=1

Ditto, but also erase the partition table:

dd if=/dev/zero of=/dev/hda bs=512 count=1

Save a copy of the MBR (including the partition table) to a file:

dd if=/dev/hda of=./mbr-hda.backup bs=512 count=1

LILO

Overview

LILO is typically invoked because something in the system configuration has changed and the boot sector program or the second stage loader need to be rewritten. LILO needs to do this in the following cases:

• When a new kernel is installed or an existing kernel's files have been moved to different sectors on disk
• When any part of the second stage loader (e.g. the map file) has been moved to a different sector on disk

LILO has a configuration file:

/etc/lilo.conf

The files required at boot time are typically located in a separate directory on the root filesystem:

/boot

The files in this directory are:

• The actual kernel files (i.e. not symbolic links)
• Bitmap files that need to be displayed at the boot prompt
• The map file which is written by LILO every time it is invoked. This file is used by the boot sector program to locate all the other files that it requires to initiate the second stage of the boot process

Note: It may also be useful to have a very small partition that is reserved solely for storing boot-time files. That partition will then be mounted into the root filesystem at /boot. This is probably one of the reason why the kernel files in the root filesystem (e.g. /vmlinuz) are only symlinks into the /boot directory.

Simple usage

After updating everything in /etc/lilo.conf, the new configuration is written to disk by invoking

lilo

To test the configuration first:

lilo -t

With more detailed output, where "n" is the level of verbosity (1-5, default is 1):

lilo -t -v
lilo -t -v <n>

Alternative configuration file

To specify a different configuration file:

lilo -C /etc/lilo.conf.test

Override boot device

Override the boot device configured in lilo.conf (with boot=):

lilo -b /dev/foo

Notes:

• LILO will install the boot sector program to the specified device
• /dev/sdb installs into the MBR
• /dev/sdb1 installs into the VBR of partition 1

Override map file

Override the map file configured in lilo.conf (with map=):

lilo -m /boot/map.test

• LILO will write information required by the boot sector program to the specified file
• By convention the map file is /boot/map

Query map file

List the boot files in a map file:

lilo -q
lilo -q -v
lilo -q -m /boot/map.test

Install an MBR that boots the disk's active partition

Installs an MBR

lilo -M /dev/sdb mbr
lilo -M /dev/sdb ext

Quote from LILO's man page:

Install a Master Boot Record on the device specified as master-device, selecting the Standard or Extended Master Boot Loader per the option. The primary partition table on master-device is undisturbed. If no valid Volume-ID (serial number) is present, then generate one and write it to the MBR. If "mbr" is specified, the Standard Master Boot Loader will search partitions 1-4 for an active flag, and boot the flagged partition. Only one active flag is allowed. If "ext" is specified, the search for an active partition will include extended partitions as well.

Diagnostic messages

/dev/sdb is not on the first disk 

This warning does not indicate a problem with LILO per se, rater LILO issues the warning to alert the user that of the possibility that the computer BIOS might have trouble booting from a disk that is not the first disk.

The boot sector and map file are on different disks 

It appears that this warning is issued simply because LILO thinks the user might have made a mistake. In my setup, I have the root file system (including /boot/map) on /dev/sdb1, while the boot sector program is placed in the MBR of /dev/sda. It still works, though.

LILO chainloads LILO

In 99.9% of all cases, LILO will either directly boot the Linux kernel or chainload the Windows bootloader. It is also possible, though, to chainload another LILO bootloader. The setup in lilo.conf is very simple, for instance:

other=/dev/sdb
  label="Linux-on-sdb"

The other= directive can be used to boot an arbitrary system supported by LILO, and apparantly another LILO installation qualifies. The effect is that the other LILO installation's boot menu is displayed, so one could end up with two boot menus displayed in succession.

Grub

TODO

Booting on osgiliath

The BIOS of osgiliath allows to change the boot order so that it tries first to boot from SCSI/SATA disks before it tries to boot from IDE disks (or anything else). In another setting, it is possible to select whether the BIOS tries first to boot from SCSI or from SATA disks.

If SATA disks are made first priority, the BIOS always tries to boot from the first SATA disk. So far, I have not found a way to tell the BIOS that it should boot from the second SATA disk (/dev/sdb). There certainly is no explicit BIOS option for it, and when I tried to zero the MBR of the first SATA disk, in the hope that the BIOS would automatically go on and try the second disk, the boot process stopped without any error or notice after the regular message "Verifying DMI Pool Data".