Chainloading with gpt and uefi+ fixing Mint efi installation

[viking777]

Not many of you will need to do this at the moment, but in the future you will maybe have no choice, uefi booting and gpt partition tables are coming to a computer near you and working with them sucks!! (Once you actually succeed in getting it working is has advantages - like 128 primary partitions for example). Combine it with grub2 though (which has always sucked) and what you get is a nightmare. What is more, not many people know much about all this, so finding solutions to problems is difficult. As I managed to find a solution to a problem I was struggling with I thought I would write it down for future reference.

What I wanted to do (which was so easy with grub-legacy) was to chainload (instead of directly loading) other distributions from the one installed on my mbr.

First of all with Uefi/gpt machines you need a separate boot partition (fat32). A working uefi installer should supply this automatically (if you use an automatic install like 'Alongside Windows or 'Whole Disk' but you will need to do it manually if you use manual partitioning). I will assume you have this already, if you don't the rest of the tutorial will be a waste of time for you.

On my Ubuntu install (at the time I installed Mint its Uefi capabilities were not functioning). It provided me with a /boot partition on /dev/sda1 with a mount point of /boot/efi - this is important as you will see later. I had problems with this, but that is another story, once I had fixed them I installed both Manjaro and Mint on separate partitions, installing grub to the partition in both cases. As mentioned Mint did not install an efi boot loader, but Manjaro did and my goal was to chainload Manjaro from the Ubuntu grub. This is how it goes.

First look in the /boot/efi/ folder. You will see a /EFI folder and inside that you should see a folder relevant to the distro you are trying to chainload, in my case it was called /manjaro_grub. Inside this is the file you are looking for and in my case it was called grubx64.efi. So you have now found the file which will actually carry out the chainload for you. Make a note its address.

Now run:

Code: Select all

sudo blkid -c /dev/null

in a terminal and make a note of the UUID of the boot partition (/dev/sda1 in my case):

Code: Select all

sudo blkid -c /dev/null
/dev/sda1: LABEL="BOOT" UUID="DDE9-FCDA" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="aa549ca7-3738-4dc6-a3c9-b1ab69525f24"

You can now construct the grub chainloader entry like this:

Code: Select all

menuentry Manjaro {
search --fs-uuid --no-floppy --set=root DDE9-FCDA
chainloader (${root})/EFI/manjaro_grub/grubx64.efi
}

The --set=root UUID comes from blkid and the chainloader address is the address of the grubx64.efi file, but please note here that the mount point of this folder is /boot/efi so that part of the address is not required, it is supplied by the (${root}) prefix. Also take note that it is very easy to miss off one of the brackets around all this including the } brace at the end of the entry, if you do, nothing will work.

So now you have got an entry what do you do with it?

The best place for it is in /etc/grub.d/40_custom, just paste it in there and it will appear in the grub menu when you update grub. More importantly it won't be overwritten by later grub updates.

If you have only one other distro then you could now disable /etc/grub.d/30_os-prober with:

Code: Select all

sudo chmod -x /etc/grub.d/30_os-prober

And it won't clutter up your menu with Manjaro entries you don't want. Unfortunately I can't do that because I can't chainload MInt - or at least not yet so I still need those to be added, but I will work on that.
BTW the same technique should work for a Windows chainload although the folder address will be different it will have /Microsoft in it somewhere.

I told you it was fun

PART 2 How to install an efi based boot loader when Mint has wrongly installed a non-efi version.

This was the situation I found myself in with regard to Mint after I initially installed it. At the time I installed Mint its efi implementation was broken and it did not install an efi based grub, thus I was unable to chainload it. This is how I fixed it. You will need a second working linux distro already installed, I haven't tried this from a live cd, the procedure would be similar but not identical so I don't feel confident in writing it down. The reason Mint's installation was not efi was that it installed the wrong version of grub. It installed grub-pc and what it should have installed was grub-efi-amd64. So the first thing to do is to install that package. This automatically removes grub-pc. At this time I suppose it would have been quite possible to run

Code: Select all

sudo grub-install /dev/sda

but that would have installed it to the mbr and I had already spent a lot of time configuring Ubuntu's grub on the mbr and I didn't want it over written. So in order to install it to the partition boot record the following was necessary.

Boot into another distro. Make sure that the partition on which Mint is installed is mounted. My Mint partition is already mounted by fstab so I didn't have to do that, if that is not the case, (and assuming Mint is on /dev/sda5), do this:

Code: Select all

sudo mount /dev/sda5 /mnt

Now run the command:

Code: Select all

sudo grub-install --root-directory=/mnt /dev/sda5

I got an error to say that /dev/sda5 did not look like a gpt partition (which it isn't) but grub was installed properly. Other documentation recommends changing the command to install to your /boot/efi partition. I didn't do this because I had no idea if it would overwrite the existing data there (I don't think it would have, but there was a risk it might so I elected not to) I therefore had another step to follow.

In your Mint installation you will now find a file called /boot/grub/grub.efi - copy this file. Now, in the distribution you are running from, create a new folder called 'mint' in the location /boot/efi/EFI. Open folder /boot/efi/EFI/mint and drop the grub.efi file inside this folder. You can now create your menuentry in /etc/grub.d/40_custom as above

Code: Select all

menuentry Mint {
search --fs-uuid --no-floppy --set=root DDE9-FCDA
chainloader (${root})/EFI/mint/grub.efi
}

A quick

Code: Select all

sudo update-grub

and you should be chainloading Mint's loader from your other distro.

Phew!!

[srs5694]

IMHO, GRUB 2 is overly complicated for the sort of manually fine-tuned configuration you want to do. I recommend you look at either gummiboot or my own rEFInd as your primary boot manager. Both use much simpler configuration systems than GRUB 2 does. rEFInd is designed to auto-detect other EFI boot loaders by default, so if you want to continue using GRUB 2 to boot your various kernels, you might need do nothing else; however, I've been pushing rEFInd toward easier use without GRUB, so you might actually need to change some things to keep your kernels out of the rEFInd menu, like remove the ext4fs driver that the rEFInd installer will probably put in place. Another approach would be to tweak it to not auto-detect your kernels and add manual stanzas that would give you submenu options to boot different kernels for each distribution. By contrast, gummiboot will probably require some configuration to get each distribution's GRUB to show up in its menu.

[viking777]

IMHO, GRUB 2 is overly complicated for the sort of manually fine-tuned configuration you want to do. I recommend you look at either gummiboot or my own rEFInd as your primary boot manager. Both use much simpler configuration systems than GRUB 2 does. rEFInd is designed to auto-detect other EFI boot loaders by default, so if you want to continue using GRUB 2 to boot your various kernels, you might need do nothing else; however, I've been pushing rEFInd toward easier use without GRUB, so you might actually need to change some things to keep your kernels out of the rEFInd menu, like remove the ext4fs driver that the rEFInd installer will probably put in place. Another approach would be to tweak it to not auto-detect your kernels and add manual stanzas that would give you submenu options to boot different kernels for each distribution. By contrast, gummiboot will probably require some configuration to get each distribution's GRUB to show up in its menu.

I am sorry to disappoint you but I can only speak as I find. I did install and use refind before doing all this, and I went back to grub. Refind was awful to install, I had to use all the 'renaming' options given in your excellent documentation, and when I did get it going, it slowed down the boot considerably. The resolution at which it was displayed was dreadful - I only have 3 distros and it couldn't display all those on my 1280x1024 monitor, I had to scroll sideways to see the third one. Only one of the three distros I have installed had a logo (ubuntu) the others were indistinguishable so I couldn't tell what I was booting. Lastly, I assumed that this was a boot 'loader' but it isn't, it is just a chainloader, if I clicked the Ubuntu icon all it did was load Ubuntu's grub which forced me to choose again, slowing down the boot process even further. I am sorry to have to say this but the experience was extremely disappointing and it didn't last long on my hard drive. The other thing about it is that even if it did look and behave as described on your website, I do not like graphical boot loaders, I just want a list of installed kernels in plain text. Luckily your excellent documentation made it a breeze to uninstall. I would like to be more positive, but I can't be, it was not a positive experience, I am sorry, but it just wasn't.