Getting to Grips with GRUB 2

GRUB to GRUB 2 graphic

For a long time, the Grand Unified Bootloader, or GRUB, has been the standard way of getting a PC to boot into your Linux, or other Unix operating system. The flexibility offered by GRUB makes it easy to dual boot, triple boot… well, actually, do pretty much what you want in terms of installing operating systems on your own computer.

The newer versions of Ubuntu (from 9.10) and their derivatives are going through a transition. The old ‘legacy’ GRUB is giving way to the new GRUB 2. The name is similar and the spirit is similar, but GRUB 2 makes a lot of changes to the bootloader setup. In this post, aimed at people who are already familiar with GRUB Legacy, I hope to outline some of the important differences so you can get up to speed as newer distributions adopt the new bootloader.

Using the Bootloader

For the most part, how you actually interact with GRUB once it has been set up is mostly the same. You still get the same list of operating systems to boot, from which you choose the one you want. It still should be good about auto-detecting other operating systems co-existing on the same machine, such as Windows, and offering you those choices.

A couple of key differences when actually using the bootloader:

If you have only one operating system on your machine, the menu is bypassed entirely and the machine boots straight away into your OS.
With the ‘hidden menu’ feature, you now press Shift rather than Esc to show the menu.

Fundamentally, though, it’s pretty much the same thing. You can still, for example, press e when an entry is highlighted to edit the boot commands at runtime, although the key combination to actually boot once you are in this mode has been changed from b to Ctrl-X.

Configuring and Installing

Some really important changes have been made to the way the GRUB configuration file is set up and read by the program once it is running. These changes have been the most frustrating for me personally.

The menu.lst file (or occasionally grub.conf) has gone away, to be replaced by grub.cfg. The format of the file has also changed quite a lot — it now includes its own Bourne shell-like scripting language.

The biggest and most important change, however, is that the grub.cfg file is not meant to be edited manually. (It is certainly possible, but expect your changes to get overwritten without warning.)

Instead, there are a series of scripts that are placed in /etc/grub.d which are executed by the update-grub command in order to generate the grub.cfg file. The names of these files begin with a number, which sets the order in which the scripts are processed.

For example, on my Linux Mint 9 system, I see these files:

00_header  05_debian_theme  06_mint_theme  10_linux  10_lupin  20_memtest86+  30_os-prober  40_custom  README

If you want to add any custom entries to your boot menu, you can use the file 40_custom and set up entries with a syntax very similar to that of GRUB Legacy. Again, in my example, I have a CentOS 5 install co-existing with Linux Mint, but the GRUB 2 auto-detect process doesn’t create a GRUB menu entry that actually will boot the system successfully, perhaps due to the older version of the kernel on CentOS (it even still uses hda,b,c notation to refer to IDE hard drives, rather than the more common sda,b,c). Therefore, I’ve set up a custom entry to boot CentOS:

menuentry "CentOS" {
      insmod ext2
      set root='(hd1,1)'
      linux /vmlinuz ro root=/dev/hdb1
      initrd /initrd
}

As you might guess, you can reorder these different sections of the boot menu by simply renaming the files and setting the number prefix so that those entries are in the desired order. In my example, I could rename 40_custom to 15_custom.

Also notable in /etc/grub.d is the 30_os-prober file, which is designed to search for other operating systems co-existing on your machine, such as Windows, and automatically adding an entry to boot them. This should, in the long run, make dual-boot environments more reliable in the face of changes, as this search process is re-run every time that update-grub is executed.

There is also a /etc/default/grub file which contains more general GRUB 2 settings, including the default timeout before the default choice will be booted, the screen resolution and even whether GRUB makes a beep when it starts.

Once you’re done editing any of those ‘source’ configuration files, simply run update-grub for it to regenerate the main configuration file.

I think the changes in the configuration files are likely to be the biggest hurdle to overcome in the migration from GRUB Legacy to GRUB 2. I’ve spent plenty of time screaming at the way it works in GRUB 2, but am now grudgingly coming to accept it as I learn to keep my customisations in 40_custom and learned where all of the new configuration files are.

For new installations and relatively simple dual-boot environments, GRUB 2 should work just great without too much fiddling.

Useful Resources

Perhaps I am lazy — I’ve only really looked into GRUB 2 for as much as I need to do, which mostly has involved setting up my PC system with a ridiculous number of operating system boot choices.

There are lots of other useful resources out there which can help you to get your head around the changes and get used to the new way of doing things.

GRUB 2 isn’t standard across the board yet, with many Linux distributions taking the cautious approach for now and sticking with GRUB Legacy, which still works very well. But with Ubuntu and its derivatives taking the lead on the issue, it would make a lot of sense for anyone involved with administering Linux systems to get used to the new version now.

Have you had experience with GRUB 2? Are the changes good or bad? Feel free to have your say in the comments.

FOSSwire