Mastergrub - an independent way of setting up GRUB booting

Background

When you have multiple systems on a PC or server, and you want to be able to choose between them at boot time, you need something like a GRUB bootloader which allows that selection. Although dual-booting or multiple-booting is not a very efficient way of working if you are constantly switching between systems, it is a good way of migrating step-wise to a new system, keeping the old system in place for a while, or for booting rarely-needed systems.

Although bootloaders installed with a new system may have a good go at detecting other systems present on the PC/server, the detection may be poor, or flawed (maybe giving access to hidden systems that you don't want the users of the system to have direct access to). And what happens if you want to back-out the system you have just installed: too late, the MBR has been overwritten for the new system and removing that new system will simply result in an unbootable PC.

In a flexible multiple system environment, the mastergrub method is a better bet.

More details

For my mastergrub setups, there is usually a partition of a few cylinders near the start of the hard disk. This linux-formatted partition contains a grub directory, and the grub.conf file has simple chain-loads to each of the available systems. Thus this mastergrub doesn't need to know about the kernels or ramdisks of each system: each image partition contains its own grub loader in its sector 1, and the mastergrub passes control to this. Chain-loading is often used within grub to boot a system like Windows which doesn't know about grub, but it can be used equally to boot another grub bootloader, whether it be grub version 1 or 2.

This is the sane alternative to copying the kernels and ramdisks from multiple systems into the boot directory of one of the systems, as is often the advice on the web for multiple boot systems, and so avoids unnecessary complications, not least when the system on the chosen partition becomes obsolete and is to be replaced.

I have a downloadable script which performs all that is necessary to set up such a partition. It installs a grub bootloader in the hard disk's MBR which will use the stage2 and grub.conf in the small mastergrub partition. The grub.conf file contains chain-loads to various installed systems. Your requirements will certainly vary. For me, I normally choose partition sda2 because sda1 often is a vendor-dependent diagnostic area.

Individual system requirements

Each system installed on the PC needs to have been set up so that the bootloader code is installed in the partition, rather than the disk MBR. This is possible in most install systems: all Red Hat Enterprise systems, Ubuntu, and most versions of Fedora.

It was tricky in Fedora 18 because the installer anaconda had recently been completely re-written, and didn't contain any ability in the interactive version to ask for the bootloader to be installed anywhere except the MBR. Hopefully this has got fixed as the anaconda product was enhanced. On the other hand, installing Fedora 18 using kickstart doesn't have this problem: as with other Red Hat compatible kickstart support, you just need to specify the usual

           bootloader --location=partition

When to run

As I run most initial installations using a kickstart file, I invoke the mastergrub setup as part of %post processing. For an interactive install, once a system has finished installing, but before you terminate the installation session, go to a shell window (Ctl-Alt-F2 in Red Hat and Fedora systems), and type a command similar to the one below.

If your systems are already installed, then ensure that the systems are ready with their bootloader code in the partition, not the MBR. Then you can use one of the installation methods below.

Setting up the mastergrub

It's easy, if your partitions are all in place, and you have installed your Linux systems putting the bootloader in the partition rather than the MBR. Here's an example setting up a mastergrub on a small pre-existing but empty partition 2; it's assumed that this partition does not itself contain a operating system or boot code:

   wget -q -O - http://www.ep.ph.bham.ac.uk/general/support/mastergrub-install.sh | sh -s 2

The downloaded script will scan the existing partitions and produce a grub.conf file based on what it finds. You may subsequently want to mount the mastergrub partition and edit the grub.conf file so that it does what you want. Mastergrub uses the simple grub version 1 syntax and so this is an easy thing to do.

To customise the initial grub configuration without subsequent editing, if you are sure of what you are doing, you can bypass some safety questions and provide details on the command line. Here's an example which sets the mastergrub partition on /dev/sda2, formatting that partition without any interactive "are you sure" checks, to invoke a Fedora 18 system on /dev/sda5 by default, and other systems on /dev/sda3 and /dev/sda7 respectively. The Linux systems need to have their own bootloader installed in the partition and not the MBR, remember, and the specified partition 2 will be erased by the format operation. You have been warned!

wget -q -O - http://www.ep.ph.bham.ac.uk/general/support/mastergrub-install.sh |
     sh -s 2 format use 5 "Fedora 18 system" 3 "Windows system" 7 "RHEL 6 system"

Sharing the mastergrub partition for other purposes

If you don't have a spare partition for mastergrub, not even a very small one, but do have a /home or /data partition, already formatted with a grub-compatible format, and which doesn't contain any bootloader code, then you can nominate that partition and specify noformat instead of format, in the command line or a response. Again, take care!

L.S.Lowe