How to keep grub independent of all the OSes?

Question

I currently have the following partition scheme.

300MB    NTFS          Recovery  
100MB    FAT32         LOOKS LIKE IT IS THE EFI BOOT PARTITION  
128MB    Other         This is empty and thus I suspect it to be the padding partition
150GB    NTFS          Windows
700GB    NTFS          Data partition
80.53GB  Unallocated

I want to install a lot of different Linux distros over time (some of them may be uninstalled in the process, some overwritten) and want a bootloader configuration that would be able to keep up and not break.

I have read about chainloading them and about a dedicated grub2 partition and also the scheme where people install ubuntu and delete the / partition but keep the /boot to use as grub.

I was looking for the pros and cons of each of these.

Also, I wanted to ask if I can make the dedicated grub2 partition in the start or end of the unallocated space? I think I will go with the dedicated grub setup. I read about rEFInd bootloader somewhere and it looks like a no-maintainance required tool. Would it be compatible with every Linux distro out there?

PS: I am fairly new to bootloaders and the deepest I have been was editing some grub.cfg files to move the Windows entry to the top and to rename the entries.

PPS: Some background info: I had installed both Ubuntu and Ubuntu GNOME (both 15.04) in the unallocated space using 40GB for each. I then wanted to keep only Ubuntu GNOME but I had installed Ubuntu Unity after I had installed Ubuntu GNOME. So deleting Ubuntu Unity would make the grub disappear. I want to avoid these kind of scenarios by keeping GRUB2 independent of every other thing.

Answer 1

The problem with a multiple-Linux-distribution configuration is that you'll end up with multiple GRUB installations, which is redundant and confusing. Each distribution will set its own GRUB up as the default and configure it either to chainload other distributions' GRUBs or to boot their kernels directly (or maybe to do both things). There are problems with this:

• When you boot a distribution whose GRUB is not the primary one and update its kernel, chances are the controlling GRUB's configuration will not be updated. If the controlling GRUB boots other distributions' kernels directly and if kernel updates happen often enough, the distribution with updated kernels may stop booting because the original kernels will be gone. Even if the distribution continues to boot, it will be via an older kernel that may have security or other problems. You'll then have to go to the distribution whose GRUB is in charge and run update-grub (or something equivalent) to get it working again. A chainload configuration is more robust against such problems, so if you have a choice, that's how I'd set it up.
• After an update to their own GRUB packages, many distributions will try to reset their own GRUBs as the default. The result can be that which GRUB boots first will change every now and then. If one does a better job than the others, you'll then have to use efibootmgr to reset the boot priorities from time to time.
• If you delete the distribution whose GRUB launches by default, chances are its GRUB will stop working. (This isn't always the case, since it depends on where GRUB stores its configuration files, but it's the way most distributions set things up.) You can bypass this problem by using the firmware's built-in boot manager, but it's still a nuisance -- and a serious problem for users who don't know how to use the firmware's boot manager. (After the first boot when this happens, you'd need to install another distribution or use efibootmgr to set another GRUB as the default to avoid having to use the firmware's boot manager.)

These problems are not insurmountable, but they are nuisances. Setting up one boot manager as the default bypasses these issues, but usually requires manual configuration that's likely to take more effort than it does to overcome the problems I've just described. rEFInd (which I maintain) is designed to bypass these problems by being less dependent on configuration files. In particular, rEFInd does not need per-kernel configuration, which every other Linux boot loader I know of does need. Instead, rEFInd relies on a configuration file that provides options that apply to every kernel in a given directory. This requires some explicit up-front configuration when you install a distribution, but that's a matter of running one script that comes with rEFInd (mkrlconf). Thereafter, when you upgrade your kernel, rEFInd doesn't need reconfiguration; it just takes the old options and applies them to the new kernel. (Note that GRUB does need reconfiguration after a kernel update. Ubuntu hides this by running scripts to do the reconfiguration as part of the kernel update/installation process -- but as noted earlier, these scripts update just one GRUB's configuration, which might not be the one that needs to be updated.)

If you install rEFInd, you'll still have the issue of each distribution trying to set its own GRUB as the default. There are usually ways around this, though. For Ubuntu, rather than booting the installation medium and selecting the option to install directly, you should boot to the "try before installing" mode, open a Terminal window, and then type ubiquity -b. This will run the installer and tell it to not install GRUB. The same trick can obviously also be used if you want some other distribution's GRUB to handle everything. To boot after installing in this way, rEFInd will have to have already been installed; or you could boot with rEFInd on a USB flash drive or CD-R and install it then.

You may want to figure out how easy it is to disable GRUB in each distribution you plan to install. Using that information, in conjunction with your own plans and priorities, you can decide which one(s) you want to install and which ones you want to bypass.

Another option to all of this is to use virtualization, like VirtualBox. If you've got enough memory, you can run half a dozen distributions simultaneously in virtual machines while another controls the computer as a whole. This approach bypasses boot loader conflicts, making configuration much simpler -- each OS is entirely in charge of its own "computer."

Answer 2

As @oldfred and @Wilf have pointed out in the comments, GRUB2 has matured a lot and can handle the situations I mentioned comfortably. The solution to follow:

1. Take a backup of your ESP or EFI or Boot partition (the FAT32 partition).
2. Install the Linux distros you want to separate partitions (you can easily install all of the distro on a single / partition instead of making a separate /boot)
3. The distro which we will install the last will be the master and its grub will be used.
4. In case you want to, you can manually edit the grub.cfg in the EFI/distro directory on the EFI partition to manage all the bootloaders.

Explanation for how it works:

GRUB2 installs itself to /boot of the distro and makes a grub.cfg in a subdirectory in the EFI partition which then chainloads the actual grub.