An enigma – grub

Grand Unified Bootloader, that is grub. It can boot lots of operating systems on many different platforms. It is the default bootloader now for most, if not all, common linux distributions. Yet I say grub is brain-dead. That is not really a good description. What I should say is that grub is not well designed to keep your operating system boot code safe, secure, and reliable. Instead, it places it out in the middle of your hard drive, maybe in multiple places, only one of which is valid. It is commonly placed in the /boot/grub directory of the last operating system you install. This makes it very vulnerable. When I say ‘it’, I am mis-speaking, because it is really composed of about 3 separate pieces in a typical linux distribution.

I say grub is an enigma because although you can find tons of information on how to configure the grub configuration file /boot/grub/menu.lst, you will find much less information on the detailed sequence that grub follows when it boots. Normally you find something slightly more detailed than this:

run stage 1

run stage 1.5

run stage 2

That is not much help. Nor have I found any information on how to make grub work in a safe, reliable, secure manner. If you install 4 operating systems, one at a time, on your hard drive, then the later systems will contain grub boot information about the earlier systems, but the earlier systems won’t contain information about the later systems. And if you boot the the first system and edit the /boot/grub/menu.list file there to help fill in the blanks, you might as well be spitting into the wind. Unless you do something drastic to tell grub to go back and look at that file, it will never see it again, even though you edited it properly.

To my knowledge, this problem is unique to grub. Lilo does not have this problem. I have not seen a Windows system with the problem, although they have not worked in a similar manner until about Windows XP. But the real grand-daddy of modern bootloaders AFAIK is the OS-2 bootloader. I have been pondering why IBM’s OS-2 worked without fail, and grub crashes your system when you remove things.

The common problem with grub is that the data it needs to boot is at the end of a daisy chain of drive partition table entries scattered out across your hard drive. Break any link in the chain before the partition with the grub info, and you are dead in the water. So it is bad construction to put the data (the menu list) way out there. It should be held close to the Master Boot Record (MBR). But the way grub is designed, that is not possible for a disk with more than 3 operating systems.

As part of the MBR, there is a partition table that describes the location of 4 partitions on your hard disk. No more, fewer is OK. The partitions defined in the MBR are referred to as Primary partitions, as they are in the primary table in the MBR. So if you have 5 operating systems installed, one cannot be included in the MBR. And in a realistic setup, one of the 4 entries would point to the ‘extended’ partition table, leaving you only three entries to use. So now 3 operating systems max can have their location defined in the MBR, thus avoiding the daisy chaining issue. This would place them relatively close to the front of the hard drive.

But is that what the OS-2 boot loader did? Well, no. It put the bootloader in a small partition at the end of the hard drive, as far from the MBR as possible. So how did they do that? I never dug into it really. No need, it just worked. But in thinking about it in terms of what can be done with what we have, an obvious solution is to create a small primary partition at the end of the hard drive, and put grub there. Since is is still a primary drive, it is directly referred to by the MBR, and is not subject to daisy chain breakage. There is no rule that says an extended partition cannot be followed by a primary partition. It is true that this would put the partitions out of numerical order, but that should not matter. It only matters when one partition has to point backwards to the next partition. But only logical partitions in the extended partition point to another partition in the diasy chain. Primary partitions never piont to another partition, they are dead ends. So by definition they can’t need to point backwards down the drive, and being out of sequence should not matter.

So, what if we put create a device, call it /dev/hda3, at the very end of the hard drive, out of the way. When we install our first OS, we create a linux swap file at /dev/hda1, so it has quick access. We create another swap file at /dev/hda2, just to force the numbering scheme. We create a small partition at the end of the hard drive, it will be /dev/hda3. Then we create and extended partition in the rest of the disk space, it will be hda4.

Now, logical partition in the extended partition always start with the number 4, whether you use all 4 of the previous numbers or not.

For OS#1, we will create /dev/hda5 for it / (root) directory, and /dev/hda6 for its /home directory.

For OS#2, we will create /dev/hda7 for it / (root) directory, and /dev/hda8 for its /home directory.

For OS#3, we will create /dev/hda9 for it / (root) directory, and /dev/hda10 for its /home directory.

So our file system table for system 2, say would have entries that contain:

/dev/hda7 / (yes, I left out some more parameters)
/dev/hda8 /home

/dev/hda3 /boot/grub (we put the grub directory on the small partition at the end)

And our file system table for system 3 would have entries that contain:

/dev/hda9 /

/dev/hda10 /home

/dev/hda3 /boot/grub (It’s the same place as for OS#2!)

So, by doing this, OS#3, when we create it, will overwrite what OS#2 ut in /boot/grub. But maybe that is OK, because grub is grub. It will have newer entries, as it will have data for OS#3 that was not there before. And if we boot back into OS#2, and look at the grub menu list /boot/grub/menu.lst, we will see, and be able to edit, the list that is now one and the same file for all three systems. We no longer have to wonder which of the menu lists grub is really going to read. We see a consistent list regardless of which system we look at it from. And it is a primary partition, and not subject to the daisy chain vulnerabilities of the extended partition.

Will this work? I don’t know, I have not tried it. But think I will, as the present operation of grub is driving me crazy. It just does not work logically, when it works at all.