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.
- 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.
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.