Hands on: Booting problems with Linux

We have previously looked at some of the booting and filesystem aspects of Linux and PCs, including partitions and image files.

This time, we’ll take a much closer look at the initial booting process and how to overcome a very common problem associated with removing Linux from a computer that’s also running Windows.

Most of the problems experienced with booting into Linux (or any PC operating system) lie with the Bios, which is an archaic piece of software dating back to the first PCs, and on which Microsoft Dos and older versions of Windows used to rely.

These days, the Bios is used largely just to initialise the hardware and start the operating system, but its limitations still have an impact on how operating systems are installed.

After switching on a PC, the Bios must find and start the operating system on the hard drive. To do that, it loads the first sector of the hard drive into memory and executes the code there. A sector is 512 bytes, and is the smallest chunk of data a hard drive handles. This first sector is commonly referred to as the Master Boot Record (MBR) and contains the boot code, together with the disk’s partition table.

MBR structure
At just half a kilobyte, a sector isn’t a huge amount of space to do anything with, especially when you compare it with a typical 200GB hard drive (around 420 million sectors). It consists of two fixed sections. The first 446 bytes are reserved for executable code and it is this that is executed directly via the Bios on startup. After that comes 64 bytes for the partition table and a final fixed two-byte code to identify the sector as a valid MBR.

We recently saw in Hands On that a standard PC can have only four primary partitions, and now it may become clearer why: with just 64 bytes available for the partition table, that leaves 8 bytes per partition – just enough to locate each one on the disk, set the filesystem type and bootable flag. Take a look at screen 1 for an example of a real MBR, viewed in a hex editor. The final two bytes (0x55 and 0xaa) mark the end of the MBR. The partition table starts at position 0x01be (marked in red in the screenshot).

The fixed structure of the MBR means that only the final 66 bytes (including the 2 byte signature) are necessary for a valid MBR and partition table, since the first 446 bytes are used only for booting. It is here that the common Dos bootloader used by Windows sits, or if Grub is installed, the first stage of the bootloader.

In the case of the former, the code performs a very simple task: it scans the partition table for any partition marked as bootable (or ‘active’ in Dos terms) and then executes that. It cannot do anything else, which is why it’s unsuitable for any kind of dual-boot configuration or for starting a Linux kernel. Grub, on the other hand, is a far more versatile piece of software, but as such it needs a lot more space than 446 bytes can afford.

The first stage of the Grub bootloader does little except to locate the next stage. Due to the awkward restrictions imposed by the Bios, a small amount of extra space is available directly after the MBR. If you look at a partition table with Linux’s fdisk and set the units to sectors, you will see that the first partition begins at sector 63. You can see this for yourself by running the following command, assuming your hard drive is /dev/hda:

$ sudo fdisk -l -u /dev/hda

We know that the first sector is used for the MBR, which leaves 62 sectors spare, or 31KB (62x512 bytes). This anomaly is because of the old ‘cylinders, heads and sectors’ method for locating a position on a hard drive. Starting at sector 63 allows the first partition to start on a cylinder boundary; Linux doesn’t worry about this, but it’s maintained for compatibility. Grub uses this extra space for its ‘stage 1.5’ code.

The next stage of Grub must be loaded from a regular filesystem on a partition. Grub can read most partition types, including the standard Linux ones and Fat. This is where the images for a graphical interface version of Grub are found, too, and where the configuration data for the menu is kept.

On a typical Linux system, this data is found in /boot, which may be on its own partition or part of the root (main) partition.