Hands-On: Linux UEFI multi-boot part three, problem solving
We're in the home stretch now. In the first post of this series I looked at the general characteristics of Linux installations on systems with UEFI firmware - specifically how the disk is partitioned, and how multi-boot installations interact with each other.
In the second post I looked at some details of the boot process, and how the GRUB configuration file was set up, first for a simple Linux-only installation and then for multi-boot with Linux only and Linux/Windows combinations. Whew. That's a good bit of territory to cover, and I congratulate those who are still with me at this point.
Now I want to look at a couple of exceptions, unusual or uncooperative situations.
Enterprise Software
One common case is installing both Ubuntu and Linux Mint on the same system. I consider this an 'uncooperative' situation, for several reasons. It starts out with the fact that Linux Mint uses an EFI boot directory named ubuntu, which obviously conflicts with what Ubuntu itself uses (duh). But you are not likely to notice that the first time you try to install these two together, because neither of them actually tells you what they are going to do for UEFI installation, or where they are going to do it.
So the typical scenario is: you install one of these two on your UEFI system, and it works great. You're just sitting back and thinking about how easy it was, and what a wonderful world this is, when you install the other one (the order doesn't matter, by the way). The second installation completes normally, with no errors or warnings, and it boots and runs just fine. Now you're really pleased... until you try to boot the first one you installed, and what actually comes up is the second one. Uh-oh.
What has happened is that because of the name conflict, the second one you installed overwrote the EFI boot configuration of the first. Unfortunately, neither Ubuntu nor Linux Mint lets you choose the EFI boot partition during installation, so you can't avoid this problem. In fact, you can't even see it coming because as I mentioned above, neither of them even tells you what it is going to do, nor warns you that there is something already in place which is going to be overwritten.
Note: I was hoping that this situation would improve with newer releases. But I have tried the latest Ubuntu 15.04 Beta, and it still gives no information and no flexibility/configurability on UEFI installation. The beta release of Linux Mint Debian Edition 2 looks better - it at least tries to let you select the EFI boot directory - but it is not at all clear that the 'normal' Mint distribution will switch from the Ubuntu Ubiquity installer to the :MDE installer.
The easiest and most reliable way I have found to avoid this problem is to intervene between the two installations, and move the first EFI boot directory out of the way. The obvious way to do that is to simply rename it, for example install Mint first, and then rename /boot/efi/EFI/ubuntu to /boot/efi/EFI/mint. Unfortunately that doesn't work either, because both distributions appear to have something hard-coded in the EFI GRUB programs that reference the name ubuntu. Bleah.
The workaround that I use is to create another EFI boot partition. Just use gparted or whatever disk/partition manager you prefer, and create a small FAT32 partition (128MB or so). Then mount that filesystem somewhere convenient, create a /EFI directory on it, then copy (or move) the /boot/efi/EFI/ubuntu directory to it, and then unmount it. You also need to edit /etc/fstab so that it mounts this new EFI boot partition to /boot/efi the next time you boot.
Finally, you need to configure something to actually use this new EFI boot partition. If you are using the GRUB configuration that I described in the previous post, then you have to modify the root value; if you want to use the BIOS Boot Select function (F12 or whatever), then you have to use the Linux efibootmgr command to make a new entry in the boot list, something like:
efibootmgr -c -b 0000 -l "\EFI\ubuntu\grubx64.efi" -L Mint -p 9
The -b 0000 will have to be a unique number in your boot order - don't worry, you'll get an error if you try to use one that is already defined. The -p 9 is the number of the new EFI partition you created.
There is a much simpler approach to moving/recreating the EFI boot directory to avoid this conflict, using the Linux grub-install command. To use this you have to specify on the command line the EFI architecture required (basically i386 or x86_64), the location where it should create the EFI directory (almost always /boot/efi) and the name to be used for the EFI boot directory (something other than ubuntu):
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=mint
Unfortunately, this still doesn't solve the problem in the Ubuntu/Mint case, because as I mentioned above, there appears to be something hard-coded that points to the name 'ubuntu'. What actually happens is that it appears to work, meaning that the new EFI boot directory is created, and it looks like it contains the right files... and in fact, when you change the boot configuration to point to this new directory, the system looks like it works.
But if you then delete the old ubuntu EFI directory, the next time you try to boot it fails, which means that the boot process is still looking for something under the old name. If you subsequently install the other distribution, which once again creates the /boot/efi/EFI/ubuntu directory, and then you try to boot the original one which you changed in this way, what actually ends up booting is once again the new distribution. Ugh.
Yeah, I know, that's kind of confusing and very messy, but I'm not the one who decided to have Mint use the Ubuntu name. It's kind of irritating, actually, because the first Mint release which had UEFI support didn't do this, but then something went wrong and the Mint developers decided that the only way they could fix it was to use the Ubuntu name. Even more irritating, LMDE (Mint Debian) does not use this name, it installs to /boot/efi/EFI/linuxmint, so they obviously know how to avoid this conflict. I wonder if the problem they can't get around has something to do with using the Ubuntu installer rather than the Mint installer.
Anyway, that's one problem out of the way. Another one which often crops up is trying to install a Linux distribution which doesn't have UEFI support onto a Linux UEFI multi-boot system.
Whenever I start to explain this to people, they always want to stop me and say "just enable Legacy Boot". Fair enough, in some cases, but there are a number of situations where this is not possible, or not the best choice - for example, you might already have several other UEFI-compatible distributions installed, and you prefer to continue on that path rather than switch to Legacy Boot (MBR) for all of them.
In this case, you have to enable Legacy Boot in the system BIOS at least long enough to install the non-UEFI compatible distribution. Then what I prefer to do while installing it is to either embed the MBR boot info into its own root partition, or just not install a bootloader at all. Either or both of these are usually options with most Linux installers, but in the worst case if you don't have either one available, you can go ahead and let it install to the MBR of the disk drive.
Once the installation is complete, you can switch back to UEFI boot, and then in whatever you choose to use as the primary boot installation, you can either run the grub-mkconfig command, or manually set up the grub.cfg file as I described and illustrated in the previous post, using linuxefi and initrdefi to load the new operating system.
I have done this a number of times to get Kali Linux and Manjaro Linux installed on UEFI systems, and it works OK. Not great, but OK. It has exactly the disadvantage that I described in the previous post, that kernel updates in the target distribution are not automatically picked up by the boot configuration.
The final situation I want to look at here is installing a non-UEFI Linux distribution, and then adding UEFI boot capability to it. This also turns out not to be too difficult, but you have to at least be able to get an EFI-compatible version on GRUB, along with a couple of support packages from the distribution repositories:
grub-efi (or grub2-efi, the name can vary)
efibootmgr
dosfstools
Then as before, create an EFI boot partition (FAT filesystem), and mount it on /boot/efi. Remember that this has to be mounted on every boot, so it will have to be added to /etc/fstab. Then use the grub-install command as described above to create the EFI boot directory and its contents. I have used this on Manjaro Linux, for example, and the command looked like:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro
Next, use the grub-mkconfig command to create the appropriate grub.cfg file. That gets Linux itself ready for UEFI boot. The final step is to add an entry to the BIOS boot configuration for this distribution using the efibootmgr command. We've seen this before as well:
efibootmgr -c -b 0000 -l "\EFI\manjaro\grubx64.efi" -L Manjaro -p 2
Remember, the boot sequence number specified with the -b option has to be unique; you can use efibootmgr -v to check the existing configuration and see what numbers are already used. The -p flag has to specify the partition number of the EFI boot partition.
OK, that's enough.
Summary: I started out showing how the disks are partitioned for UEFI boot, and how the boot process itself works. I then showed how I set up multi-boot on my systems, in a way that I find the most reliable. Finally, I have looked at the most common causes of problems and confusion in multi-boot systems, and some possible ways around those problems. I hope that all of this information proves to be more useful than confusing to those who are trying to deal with UEFI firmware today.
Read more of my blog: