I currently have the following partition scheme.

300MB    NTFS          Recovery  
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.

  • I don't think you need to do this, but probably counts a opinionated answer :). Unless you change the settings when installing, most installers for linux systems will make a new bootloader after each install (after/during modifying the disk) - most will also check if there are any other system bootloaders present (e.g. using 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 2 '15 at 15:41
  • I saw that. I had a /boot for both of the Ubuntu installations and when I uninstalled one of the Ubuntu (the Unity to be precise) it took away it's copy of grub with it and rendered the system unbootable. I finally booted using the boot-menu of my BIOS (which had entries for both of the Ubuntu installations). I have played with installing grub2 on a USB drive and had succeeded in achieving what I wanted but I don't want to have to carry a USB with me just to boot into Ubuntu. – Ashhar Hasan Dec 2 '15 at 16:13
  • 1
    The 128MB partition is required by Windows as its system reserved. With UEFI you do not need separate grub. And with grub2 you do not need a unique grub partition. I had that back with grub legacy and chainloaded. But grub2 can directly boot just about anything. You do have to decide which install is your primary and use that grub as main working grub. I do also have grub installed to flash drive(s) to also boot system separate from live installer. Best to backup ESP -- efi system partition. There is a small grub.cfg in the ESP that configfile(chains) to the partition with the full grub.cfg. – oldfred Dec 2 '15 at 16:44
  • 1
    You can leave the boot stuff in the root partition (depends on your setup, EFI etc as oldfred says), you may not necessarily need a separate boot partition (if you doing multiple linux it will probably be a lot easier with the boot partition in the root partition of each OS - linux can usually work easily with ONE partition). The GRUB bootloader is also installed to the MBR of the hard disk, which then points wherever it needs to go to boot. – Wilf Dec 2 '15 at 16:58
  • EDIT: Wilf I just read your reply. Thanks for that. So I won't bother with the above stuff I wrote (will experiment on a VM nevertheless). ORIGINAL: @oldfred So you mean to say that the best course of action for me would be to simply go about installing the distros I want along with their copy of grub? If that is the case, could I install all of the stuff on a single / (root) partition and not make a separate /boot? – Ashhar Hasan Dec 2 '15 at 17:01

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

  • If you have multiple installs you can change grub. Not sure if this works on UEFI, but it definitely works on BIOS. You can just uncheck with spacebar all drives and grub will not have a reinstall location. askubuntu.com/questions/503417/… – oldfred Dec 4 '15 at 15:53
  • So, I could basically use, say Ubuntu GNOME's grub and install Fedora, Kali and Arch with something similar to the ubiquity -b method and I won't have to worry as long as I don't remove Ubuntu GNOME? – Ashhar Hasan Dec 4 '15 at 17:54
  • Ashhar, yes -- provided you can figure out how to tell each OS to not install its own GRUB, and provided that Ubuntu's GRUB can properly manage them all (or provided you're capable of creating the necessary GRUB entries manually). Unless you're an expert on GRUB, those are a lot of caveats. It's decades of dealing with this sort of problem that led me to create rEFInd. The gummiboot (now systemd-boot) developers have another solution, but it really goes less than halfway because it requires buy-in from each distribution. – Rod Smith Dec 6 '15 at 16:05

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.

  • The MBR is used for BIOS boot. If using UEFI, then you have the ESP - efi system partition. – oldfred Dec 2 '15 at 18:35
  • Yup. My bad. Am I correct when I say that it is installed to /EFI/ubuntu or /EFI/fedora inside the EFI partition? – Ashhar Hasan Dec 2 '15 at 21:03
  • Part of grub somewhat equivalent to what is in MBR with BIOS is in ESP in /EFI/ubuntu. But real grub.cfg and kernels are in /boot folder and other configuration settings or parts of grub are in various other folders. – oldfred Dec 2 '15 at 23:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.