The trouble with grub2

In my last post, I mentioned my disagreement with the way that grub2 is installed in Fedora 18.  If you read through the bugzilla report on that issue (linked in my last post), there’s a pretty good discussion of why the Fedora people did it that way, and why the grub2 developers think it should be done that way.

I’ll start by describing the way it works in a hypothetical situation which is similar to that on the test computer where I installed Fedora 18.

Assumptions:

  • openSUSE 12.2 is installed on the computer, inside an encrypted LVM, and “/boot” is on an unencrypted partition “/dev/sda1”
  • Fedora 18 is installed on the computer, with its root partition on “/dev/sda2”

Using lilo or legacy grub

If I had installed these using lilo or legacy grub, in the manner in which I would normally have done that, then:

  • I would have installed lilo or legacy grub on “/dev/sda1” for opensuse and on “/dev/sda2” for Fedora;
  • The MBR would contain generic boot code, that would attempt to boot the active partition, which would normally be either “/sda1” or “/sda2”;
  • The lilo or legacy grub menu for each would contain choices for booting that system, and also a choice to chain-load the booter for the other system.

The result would be that I could boot either system, no matter which of the two was marked as active.

Using grub2, installed in the PBR

If grub2 were installed in the partitions (rather than in the MBR), then here’s how it would work:

  • grub2 would be installed in “/dev/sda1” for opensuse, and in “/dev/sda2” for Fedora;
  • the MBR would contain generic boot code, selecting the active partition;
  • the opensuse boot menu would have an entry that allowed me to boot Fedora;
  • the Fedora menu would not have an entry to boot opensuse.  There would be no menu entry because opensuse is installed in an encrypted LVM.

Obviously, my best choice is to make the opensuse system active, since that has more versatile boot options.  I am not sure why there is no menu item in the Fedora grub configuration.  All of the needed files are there in the “/boot” of the opensuse system, and that is not encrypted.  But apparently the installer has trouble recognizing it.

The important difference from the lilo or legacy grub case, is that there is no attempt to add chainload entries to the menu.  I can manually add those, and I usually do.

While running Fedora, I can open the encrypted LVM with “cryptsetup”, and then make the LVM volumes accessible (if “lvm2” is installed in Fedora).  And then, running grub2-mkconfig will rebuild the grub2 menu so that it does include an entry for opensuse.

Updating the kernel

After a kernel update to Fedora, the opensuse boot menu will fail to boot Fedora.  That’s because updating the kernel requires updating the boot parameters.  An update done in Fedora will update the Fedora menu, but it won’t update the opensuse menu.  So the opensuse menu entry for booting Fedora will be out of date.  I will have to run grub2-mkconfig from within the opensuse system to fix that.  It’s actually worse, because unless the encrypted LVM is unlocked and the volumes made accessible during the Fedora kernel update, the entry for booting opensuse will disappear from the Fedora menu.

There are similar problems if I update the opensuse kernel.

Using grub2 installed in the MBR

If I set both opensuse and Fedora to install grub2 in the MBR, then the last installation overrides the earlier one.  If opensuse is installed last, I’ll be able to boot either system.  If Fedora is installed last, I’ll only be able to boot Fedora for it won’t have a menu entry for opensuse (due to the use of encryption).

I can fix those problems, as described previously.  But I think you can already see that this is an undesirable situation.

Updating the kernel

If I update the kernel, I run into the same problems as described earlier.  I lose the ability to boot one of the two systems.  I’ll have to run grub2-mkconfig on whichever system won the battle to own the MBR.

If the kernel update reinstalls grub2, things are different.  At present, that happens with opensuse 12.2.  I do not know whether that happens with Fedora.  Assuming a reinstall, then a kernel update of opensuse will still allow me to boot both systems.  Assuming a reinstall also for Fedora, a kernel update will make opensuse inaccessible until I fix it again.

With that grub2 reinstall for kernel updates, the menu will switch from that provided by opensuse to that provided by Fedora.  This can be disconcerting, since they have different appearances and different ordering of entries.

How booting works

Typically, booting starts by the BIOS loading a small amount of boot code into memory, and running that.  The typical way is for that small bootstrap code to load an operating system load, and then the system loader in turn loads the kernel of the operating system.  With Windows, the system loader is NTLOADER.

Traditionally, either lilo or legacy grub were used as the linux loader.  But grub2 doesn’t want to be a loader.  It wants to be a general purpose boot manager that can stand alone, separate from a particular operating system.

For booting Windows, this works.  It loads NTLOADER, and allows that to start windows.  If a kernel update of windows occurs, that won’t change the way that NTLOADER is started, though it might change what NTLOADER has to do.  Any change of kernel parameters would not affect grub2 when booting Windows.

For booting linux, there is now a problem, because linux does not have a separate system loader and grub2 has to satisfy both the system loader requirement and it general purpose boot manager function.  So grub2 directly loads the kernel.

It seems to me that linux needs its own system loader independent of grub2.  That way, grub2 could load the system loader and the system loader would then load the kernel.  Updating a kernel would then only change the configuration that the system loader has to follow.

UEFI

To some extent, what I have descibed above is related to the limitations of the old MBR method of booting.  Newer systems are likely to come with UEFI and a GPT (GUID partition table).  This will give a system more flexibility in how it boots.

It seems to me that, even with UEFI, it would be best for linux to have its own loader, separate from grub2.

That’s how I see it.

Advertisements

Tags: ,

About Neil Rickert

Mathematician and computer scientist who dabbles in cognitive science.

2 responses to “The trouble with grub2”

  1. Gijun Idei says :

    First of all, I quite agree with you.

    I’m installing CentOS 6.4 on sda and Fedora 16, Fedora 17, openSUSE 12.3 on sdb, chainloading from CentOS. Fedora 16 and 17 were GRUB2, but there was an option to install GRB2 on MBR or PBR of /boot of each OS, and I have installed on PBR of each /boot as well as openSUSE 12.3.
    However, Fedora 18 dose not have such a option. BIOS of my PC is not able to boot from upper area of HD beyond 120GB, so I set many 200MB /boot partitions for each OSs on lower area. For Fedora 18, /boot on sdb6,
    and / on sdb10.
    This time, I have to be forced to make ” #grub2-install –force /dev/sdb6 “,
    after installing without bootloader, then made 3 step booting via Fedora 16.
    It works as a 2 step booting from CentOS as same as other OSs, however I am not sure if it is the right solution.

    Avoiding neusans of applying “grub2-mkconfig” at main OS on each time of update in individual OS, chain loading is the best as you mentioned about.

    Like

    • Neil Rickert says :

      Yes, Fedora 18 has made a bad decision here.

      In my particular case, I have a 9 year old computer that I keep around for testing how well linux systems do on old hardware. The CD drive is broken, and the BIOS has no support for booting from a USB. However, if I use PLOP boot manager, set to boot via a grub menu choice, I can boot from a USB.

      I try to keep the system so that I can still use PLOP boot manager even if something goes wrong with the latest install. The Fedora way of handling grub installs makes this difficult.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: