UEFI Boot with Korora/Fedora and Mint/Ubuntu, hands-on
Installing Linux on computers with UEFI BIOS has a bad reputation - sometimes deservedly so. It can be easy, but perhaps more often than not it can be difficult, tedious and messy - and sometimes, as far as I have been able to determine, it just isn't possible; or at least I haven't figured it out yet.
I have written about UEFI boot and Linux several times before - Multiboot Linux with UEFI and Installing Linux with UEFI Secure Boot contain a lot of information that I will not repeat here, so please refer to those if you need more background information.
What I want to deal with now has to do with the fact that a UEFI boot system is set up with a special disk partition where one or more boot images are stored. This is called the 'EFI Boot Partition' (how imaginative), and it is a FAT32 filesystem.
Within that partition there will be directories (folders) which contain the actual EFI boot files. If you are running Windows 8, two of those directories are very likely to be called 'Boot' and 'Microsoft'. If you install Linux on a UEFI system, it will mount the EFI boot partition on /boot/efi, and it will add a directory in that partition to hold its boot files.
There are several Linux distributions which already include support for installation with UEFI boot. The ones which I am familiar with, and have installed on the two UEFI boot systems I own are Debian GNU/Linux, OpenSuSE and Fedora. There are more Linux distributions which are derived from one of these UEFI-capable distributions, and thus basically "inherit" UEFI capability.
The distributions of this type which I am familiar with are Ubuntu (from Debian), Linux Mint (from Ubuntu) and Korora (from Fedora).
For the picky reader, please note that I said "Mint derived from Ubuntu", because at this time only the "numbered" Mint distributions (such as Mint 16) include UEFI support, while Linux Mint Debian Edition still did not, at least as of the last ISO images, although those were released a long time ago (March 2013) and I really hope that the next set of LMDE images will include UEFI support - they should be coming along pretty soon now.
The problem arises because of conflicts over the name of the directory that the Linux distribution creates in the EFI boot partition. The "first generation" distributions each chose their own directory names, so Debian uses "/boot/efi/EFI/debian", OpenSuSE uses "/boot/efi/EFI/opensuse" and Fedora uses "/boot/efi/EFI/fedora".
The distributions which are derived from these generally chose not to change the name of this directory. The exception is Ubuntu, and I have a feeling that Ubuntu might have done the UEFI implementation themselves rather than using Debians, but I don't know that for sure.
In any case, the specific cases that are of interest here are that Linux Mint 16 uses /boot/efi/EFI/ubuntu, and Korora uses /boot/efi/EFI/fedora. That leads to a very unfortunate situation where if you install both the "parent" and the "derived" distribution on the same UEFI system, the second one overwrites the UEFI boot information of the first. Ugh.
Note: Linux Mint actually did change the name of the boot directory in the Mint 15 release, to /boot/efi/EFI/linuxmint, but in the later releases of Mint 16 KDE and Xfce it was broken, and in the Mint 16 release it has gone back to /boot/efi/EFI/ubuntu. Not nice.
The first work-around that I tried for this problem was the obvious one - rename the directory before installing a conflicting distribution. So I would install Fedora, then rename /boot/efi/EFI/fedora to /boot/efi/EFI/fedora19, then install Korora which would create a new /boot/efi/EFI/fedora directory, and for safety I would also rename that one to /boot/efi/EFI/korora.
This almost worked - it seemed to work at first, but then I realized that the problem was when there were updates which affected the EFI boot files, it got confused because the files weren't in the place it expected to find them. Of course I could change the name back to the original before installing updates, but remembering to do that is rather impractical, at least for me, and it sort of turns into a house of cards pretty quickly.
Then, when Ubuntu 13.10 and Linux Mint 16 came out, something had changed inside the UEFI boot setup which caused the renaming not to work anyway. The boot configuration seems to have /boot/efi/EFI/ubuntu hard wired in it somewhere, so when I renamed the directory it wouldn't boot any more: argh.
That's the reason for my recent posts about it being impossible to install Ubuntu and Mint on the same UEFI boot system.
Over the weekend, while I was installing the new Korora 20 release, I realised that there is a much better, easier and more reliable solution for this problem.
I actually mentioned in my earlier posts that Fedora (Anaconda) by default wants to create a new EFI boot partition when it is installed. I don't like creating new partitions for something that already exists, as I consider it a waste of disk space, so I have made the effort to change the configuration and have it use the existing EFI boot partition.
I basically outsmarted myself in this case, because if I just shut up and leave it alone so that it creates the new partition, it will be the only thing in that partition and there can be no conflict. If you install both Fedora and Korora on the same system, each of them will create their own EFI partition and the world will be a very happy place.
The only minor "problem" is that you will end up with two 500MB paritions, one of which contains about 10MB of data. But considering today's disk sizes (even SSD disks), who really cares? Especially when it solves such a problem.
Unfortunately, I have not found a way to use this work-around to avoid the Ubuntu/Mint problem. I can't find a way to specify the EFI boot partition to be used on installation, or to tell the Ubuntu installer that it should create a new partition rather than use the existing one.
I might try a bit harder at this if I have some time, but honestly my interest level in having Ubuntu installed, or conversely my disappointment level at not having it installed, is so low that I might just not get around to it. At the moment all I do is on UEFI systems I install Mint, don't bother with Ubuntu, and the world is a nice place again.
A bit more general discussion about my experience with Linux systems and UEFI boot: looking at it only from the perspective of a boot system configuration and operation, I like it - probably more than MBR boot now.
I think it is cleaner, easier to see and understand, and certainly less fragile than embedding a boot block at the beginning of a disk or partition. I might be a special case in this context, because I have so many multi-boot systems around, but I still think that the basic advantages are significant, without even going into the details of why UEFI was developed, whether Secure Boot is a good thing or not, and so on.
How I installed Fedora 18 with UEFI Secure Boot
Look at what is involved when I do a typical MBR multi-boot installation, with Linux (GRUB) as the bootloader.
I generally want to be able to go back to the Windows bootloader, just in case, so the first thing I have to do is save the first 512 bytes from the raw disk. Not difficult, but not trivial either. Then, if I want to have multiple Linux parititions which are bootable, I have to embed the boot block in each of them, and I have to ignore the warning from 'grub2-install' about that not being a good idea.
Finally, if I want to see what I have done, or what the current boot configuration of an MBR disk is, well, that's just not easy. I can read the bootloader config files, if I have access to them, but even then there is no guarantee that the actual configuration on the disk agrees with what the files claim.
On the other hand, for a UEFI boot configuration everything is laid out in a normal filesystem (FAT32, but still), I can look at the directories and files and see what is really there. Because of this, it was relatively easy for me to see what had gone wrong when the distributions were overwriting each other, as described above.
What I have done on both of my UEFI systems is set up GRUB from openSuSE as the default bootloader, and then I put each of the other Linux distributions into the openSuSE grub.cfg file with 'chainloader' pointing to their EFI boot directory.
Please note, this ONLY works with Secure Boot disabled, and it is NOT the way that GRUB sets up the configuration itself when you run 'grub2-mkconfig'.
But it has the distinct advantage of keeping the boot configuration independent of kernel updates in the other Linux installations. If I use the default GRUB multi-boot configuration, and Fedora updates the kernel from 3.12.5 to 3.12.6, the openSuSE configuration would still boot the "old" Fedora kernel, unless I run 'grub2-mkconfig' to generate a new grub.cfg file.
But if I am chainloading the Fedora GRUB, then it will always boot the latest kernel, because it gets updated when the Fedora update is installed.
Finally, my positive feelings about UEFI boot are based only on my use of GRUB and being able to configure it to do what I want.
If I had to try to figure out how to configure the Windows 8 bootloader to do this, I would certainly feel differently - I know this, because I have tried and failed and gotten very frustrated over it. Also, it does NOT take into consideration anything related to boot configuration in NVRAM, or the Linux 'efibootmgr' utility, because that it is completely vendor-specific, and while it is not bad on the Acer AO725, it is downright awful on the HP dm1-4310, and I still won't even try a Samsung UEFI system because of the problems with NVRAM changes causing the system to brick some time ago.
As I have said before, it seems increasingly unlikely that UEFI BIOS and boot are going to go away, no matter how much the Linux community disllikes them, complains about them, or tries to ignore or boycott them.
In fact it seems unlikely that there will even be very significant changes to the installation and configuration in the future, at this point. I can see the advantages, I can learn to live with it and make the most of it, and I know only too well what the problems with MBR boot are. So why not just get over it, and move ahead with UEFI.
That's what I am going to do, anyway. I hope this probably-too-lengthy post helps some others reach their own decisions about it.