Friday, March 9, 2012

The trouble with GRUB

Most Linux systems use the Grand Unified Boot Loader (GRUB) to control their boot process. In general this is a wonderfully simple but powerful system that allows you to easily define a menu that will be presented at boot time allowing the user to choose from a range of installed Linux versions to boot (of course most people have set up a default option which gets booted after a short delay if no other choice is made).

This tool is very useful for people who want to try out Linux, but want the security of being able to easily switch back to Windows if they regret the decision. Although GRUB doesn't officially understand how to control the Windows boot process, there is a well understood trick to allow you include Windows versions in your GRUB boot menu. Since Windows can only be booted from the first partition on your hard disk, you simply need to get GRUB to make the partition containing the version of Windows you want to boot look like the first partition and then GRUB hands control to the Windows boot loader to do the rest. Most Linux installers will automatically configure GRUB for you at install time with a choice of all of the different operating systems found on your different partitions, so you don't really need to learn much about how it works under the covers.

Every time you update your version of the Linux Kernel it is necessary to tweak the configuration files to include an entry for this new kernel, Luckily, the most recent version of GRUB (which is confusingly known as Grub2 although the current version is v1.99) has a great configuration system which includes scripts to automatically rebuild updated configuration files each time you install a new Linux kernel.

With such a glowing praise for GRUB, you might wonder why I entitled this post "The trouble with GRUB". However, there is one minor, problem with the way that GRUB works which is very annoying. The GRUB2 automatic scripts for building configuration files assume that the configuration files should be contained in the /boot/grub/ directory on the partition that the current version of Linux was booted from, but at boot time GRUB might look for a menu definition file in a completely different partition. For example I currently normally run Ubuntu Oneric (v11.10) on my laptop which is installed on partition /dev/sda5, but at boot time GRUB looks for its boot menu on /dev/sda3 (where RHEL 6 is installed) - this means that I need to remember to manually copy the grub menu definitions from  /boot/grub/grub.cfg on /dev/sda5 to /boot/grub/grub.cfg on /dev/sda3 or else I will continue to use an old version of the kernel.

This must be a nuisance to many Linux users and not just me. Does anyone know of an easy way to tell grub which partition should be used for storing Partition files? Even better does anyone know how the automated configuration scripts could be updated to figure this out for themselves?

No comments:

Post a Comment