All of the various computers I have around here have GRUB multi-boot configurations, ranging from a selection of four or five Linux distributions to ten or more plus either XP or Vista. These are a few notes about things I have learned along the way, some of them the hard way.
Most of the popular Linux distributions will try to look around for other bootable partitions when installing GRUB, and automatically add them to the configuration file. Their success at finding and correctly identifying them is extrememly variable, so you are probably going to want to keep your own list of what is installed where. Pencil and paper works just fine for this…
There are some interesting compatibility issues with the ext4 filesystem. Some distributions include a GRUB which is able to read and boot from an ext4 partition, while the Linux kernel itself doesn’t have ext4 support (openSuSE 11.1, for example). Others have a GRUB which can not handle ext4 yet, but a kernel which can (Fedora 10 and 11, for example). Of course, more and more of the newer distributions support ext4 in both GRUB and the kernel (Ubuntu since 9.04, Mandriva starting with 2010). The point is, if you are going to use ext4, be prepared for the possibility of a bit more effort to configure and maintain GRUB.
Different versions of GRUB: Besides the obvious “Legacy GRUB” and “GRUB 2”, there are more subtle differences with those two categories. The ability to read ext4 filesystems mentioned above is one of those. Another is that some versions are able to display a graphic screen on boot, rather than the traditional plain ASCII screen with colors. SuSE and Mandriva (and their derivatives) are probably best known for this, but there are a number of others. Ubuntu is not one of them. Oh, and a huge warning here – GRUB 2 has changed the partition numbering system from starting at 0 to starting a 1. This is probably a good idea, because it matches the device names created by the Linux kernel – so for example (hd0,1) is /dev/sda1 – but if you have been manually configuring GRUB for some time, this change is guaranteed to send you screaming into the night for a while. Especially if you are going to have to continue to maintain both legacy GRUB and GRUB 2 configurations for some time.
Speaking of graphic boot screens, the one in SuSE actually has two different ones. The most common is the green-background “static” version, but there is also an animated “Penguin Winter” version. By default, the animated version is rarely displayed, but that can be changed. Without going into too much detail, the file /boot/message is actually a cpio archive. Extract the files from it, edit the *.cfg file, find the comment about the penguin screen, and change it from the default value of -1 to a percentage indicating the likelihood of the penguin screen being shown. Then recreate /boot/message with the updated file (and of course the rest of the original files).
When you are setting up a multi-boot Linux configuration, there are two basic ways to handle the different partitions. You can either put all of the boot commands (kernel and usually initrd) directly in the GRUB configuration file (menu.lst), or you can just point GRUB at the config files in the other partitions (with a configfile line). Both approaches have advantages and drawbacks, and each approach is used by some distributions by default. I generally use the configfile method, because this has the advantage of avoiding problems caused by kernel name changes due to updates. However, it can lead to some compatibility problems; the simplest are because of the differences in graphic boot display capability, the more difficult/complex because of mixed Legacy/GRUB2 installations. Oh, and Moblin includes a “vga=current” specification which most other versions of GRUB choke on.
Simple Repair and Disaster Recovery: When you have a multi-boot configuration, things can sometimes go wrong. The simplest case is that you install a new distribution, and it makes itself the default boot, but you don’t want that. In more difficult/nasty cases, either you make a mistake in editing, or you install a new distribution which mangles your MBR or doesn’t correctly find and identify your other partitions, or which installs a different version of GRUB that you don’t want to use. Being able to recover from this without having to completely reinstall a distribution is important.
For the simple case, when GRUB is not booting from the partition that you want, you can fix it by running GRUB from a command line. First, check what valid partitions GRUB can see, with a command like grub> find /boot/grub/stage1. This is important, because if you just assume that you know what partition you want, and that GRUB will be able to boot from it, you can end up making the problem worse instead of better. The output from the find command will be a list of patitions where the file was found. You can then select one of those partitions with grub> root (hd0,2) or whatever, and grub> setup (hd0). Reboot, and it should come up from the partition you want. If you get this wrong, or there is some other minor problem, GRUB might come up and complain about not finding the boot file, and you just get the grub> prompt. Don’t panic, just repeat the file, root and setup commands, make sure you get them right, and then reboot again.
If things go more seriously wrong, you can always retreat to some sort of bootable Live media, such as a LiveCD or USB stick. This can happen, for example, if you have some ext4 partitions and you end up with a GRUB installed that doesn’t understand ext4. When you boot the Live media, make sure you choose the simple boot option, not the installation option. You can then start a terminal window from the Live boot, and use the grub commands above to find and setup the boot configuration you want. Then reboot again, and you should be ok.
One more note about mixing GRUB 2 with Legacy GRUB. Because most distributions are still using the legacy version, I find it easiest to continue to use that as the default. But I also generally use the configfile specification to get to point GRUB at other partitions – and because the config file is totally different between Legacy and GRUB 2, this doesn’t work. There are still two ways to handle this mix, though. The most obvious is to simply include the boot commands for the GRUB 2 partition directly in the Legacy GRUB configuration file. Of course, what this effectively does is eliminate use of GRUB 2, but if your goal is to simply boot that partition, that’s fine. You can copy the boot commands from the GRUB 2 grub.cfg file, but you have to change the linux specification to kernel for Legacy GRUB to understand it. No big deal. But if you are stubborn, curious, or would like to learn how to use, manage and configure GRUB 2, you can chainload GRUB 2 from Legacy GRUB. I just described this in a previous post, so I won’t repeat the details here, but it is not difficult.
One last note about Windows, and Vista in particular. There is often, but not always, a “hidden” partition at the beginning of the disk. Well, “hidden” to Windows, but Linux partition managers and GRUB see it just fine, of course. Sometimes this partition is just a part of the Windows bootloader, and sometimes it is combined with a factory-installed “Recovery” partition. In either case, when GRUB is installed it will see both the “hidden” partition and the “real” Vista partition, and it will create chainload boot entries for both of them. You are probably best off to remove the one which is not the “real” Vista partition, because booting the other one is at best not likely to be very interesting, and could be very bad if it kicks off some sort of recovery process that could wipe your disk.
That’s it for now – but it’s certainly not everything about GRUB by a long stretch.
jw
