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."
os-prober), in which case they will add entries for those other systems so you can boot all of the systems known on the disks. BTW Windows often has odd partitions for varying things, often for recovery, booting(, malware) etc – Wilf Dec 02 '15 at 15:41