UEFI is a can of worms
I have been experimenting with a UEFI box, as mentioned previously. When I look around the web for discussions of linux on UEFI systems, I often see recommendations to stick to legacy MBR booting. I am beginning to see why. However, I do not personally recommend going back to MBR. Rather, we need to work out the difficulties and work out how to solve them.
My own UEFI system is a Dell Inspiron 660 desktop computer. It is using version A05 of the Dell BIOS. Some of the problems that I discuss might be specific to this BIOS, and some might be more general. I have only tested on the one box, so I cannot be sure how a different version of UEFI firmware would work.
My UEFI box came with Windows 8 installed. I have kept that. I added a second hard drive. Thus “/dev/sda” is the original drive that came with the system, and “/dev/sdb” is the second drive that I added.
UEFI booting is done via the EFI system partition (sometimes called the ESP). The box, as purchased, used “/dev/sda1” as the EFI system partition for “/dev/sda”. It is a vfat formatted partition of 500M. After installing the second disk, I added an EFI system partition to that disk. It is “/dev/sdb1”, which I also made 500M, and it too is vfat formatted. I allowed the initial install of opensuse 12.3 to format that partition, so that my primary install of opensuse 12.3 can be said to boot from the EFI partition on “/dev/sdb”. Since then, I have added a second install of opensuse, this time booting from the EFI partition on “/dev/sda”.
Both primary and secondary installs of opensuse have been setup to use secure boot.
NVRAM and booting
The term “NVRAM” refers to non-volatile memory used by the UEFI firmware to remember some information.
When I boot the system, I can pound on F12 while booting. And, if I do that, I am prompted by the UEFI to select which system to boot. If secure-boot is disabled, this boot menu lists both UEFI bootable systems and MBR bootable systems. If secure-boot is enabled, then the menu only shows UEFI bootable systems, and even then it only shows those which allow secure-boot.
There’s an additional limitation. There’s a standard place to put a boot entry, and that is in the directory “/EFI/Boot” in the EFI system partition. The boot menu from using F12 shows only those UEFI systems defined in the standard place, together with those which have entries in NVRAM. There can be other boot loaders not defined in NVRAM, but they will not show as boot options on my system.
At present, there are two entries in my NVRAM. One of those is for “Windows Boot Manager” and will boot Windows 8. The other is for “opensuse-secureboot” and will boot my primary opensuse 12.3 system. Currently, the “opensuse-secureboot” entry is set as the default. So if I boot the system, and do not use F12 to get a firmware menu, it will boot into my primary opensuse system or, more correctly, to the grub2-efi bootmanager for that system.
At least with my BIOS, it seems that NVRAM can only hold one defined entry for each EFI system partition. Since I have only one EFI partition per disk, that limitation could be either one system per disk or one system per EFI partition. I suspect it is the latter, and may sometime test by adding a second EFI partition to “/dev/sda”. It is allowed to have more than one EFI partition, though this is usually not recommended.
I know of this limitation, because when I installed my secondary opensuse 12.3, booting from “/dev/sda1”, that left an entry in NVRAM for booting that system, but removed the entry for booting Windows 8. And that’s what suggests a limitation of one system for an EFI partition (or, perhaps, for a disk).
There’s a second limitation. When I installed my secondary opensuse system, that erased the NVRAM entry for the primary opensuse system. I presume that this is because both installed systems would be using the same system name “opensuse-secureboot” for their NVRAM entries.
Windows does not play nice
As mentioned above, when I installed the secondary opensuse system (booting from “/dev/sda1”), that erased the Windows entry from NVRAM. That did not prevent me from booting Windows, for the grub2 menu had an entry for Windows. Using that entry did get me into Windows.
After having booted into Windows, I then found that I could only boot into Windows. The Windows system had added back a Windows entry to NVRAM. And, presumably because of the NVRAM limitations mentioned above, that erased the NVRAM entry for opensuse.
It is possible that this is a limitation of my particular BIOS. However, I have seen similar reports for other systems. That link is for a ubuntu system on a Sony computer.
The equivalent for an MBR system would be that if Windows noticed that the Windows partition were not active, it would mark it active and then store its own boot code in the MBR. This would lock out linux.
I’ll note that when I have my primary opensuse install, booting from “/dev/sdb”, and when the Windows entry is still in NVRAM, then Windows does not seem to touch NVRAM. It leaves opensuse as the default. So I don’t think Windows is trying to prevent the use of other systems, but I do think it is insisting that there be an NVRAM entry for Windows.
Chain booting is unreliable
With my primary opensuse system booting from “/dev/sdb1” set as default, and with an entry for Windows also in NVRAM, the grub2 configuration does include an entry to boot Windows with chainloading. That entry works if secure-boot is disabled. It does not work if secure-boot is enabled. The error comes from the Windows loader, not from the UEFI system, and mentions a problem with the BCD (boot configuration data). I am suspecting that this might be a Windows bug, but I don’t know their design plans so I can’t be sure of that. Once I have finished with my testing, I will probably disable secure-boot and leave it disabled. That way, booting will work reasonably.
I’ll note that chain booting does not depend on having an NVRAM entry for the system to be booted. As noted in the previous section, when only the opensuse entry (for my secondary opensuse install) was in NVRAM, it could still boot Windows.
With my current setup, the NVRAM entries are for my primary opensuse (booting from “/dev/sdb1”) and for Windows, with the opensuse entry the default. However, my secondary opensuse install is still setup to boot from “/dev/sda1”, though it lacks an NVRAM entry. So I manually added a chainload entry to grub.cfg that should have allowed me to boot that secondary opensuse. It did not work. Instead, the chainload got me back to the primary opensuse. I am not sure whether this is a flaw in grub2 (failing to tell the UEFI firmware which disk should be used for the boot), or a failure of the UEFI system to follow the specification of which disk to use.
It is still possible to boot the secondary opensuse, but not with chainloading.
Windows boot manager
One of the things to try, was to use Windows boot manager to boot opensuse. If that could work, then it would be a way of dealing with some of the problems listed above. Alas, I could not find a way of doing this. I searched the web, and I asked at a Windows forum. I was unable to find anything. The documentation for BCDEDIT does not provide any suggestive options. There’s a lot of information on booting linux with the Windows boot manager in an MBR setup, but I could not find any that apply to UEFI systems.
Grub2-mkconfig is broken
The normal way to boot another linux system with grub2, is for the “grub.cfg” file to contain rules to load the kernel and initrd for the other system. The rules are generated by running “grub2-mkconfig”. Unfortunately, this does not work properly at present. I plan posting a bug report on this, and I’ll add a comment to this post once that is done.
The rules being generated by grub2-mkconfig are loading the kernel, but failing to also load the “initrd”. Whether this is a problem depends on the importance of what’s in the “initrd”. One of my installed opensuse systems uses an encrypted LVM which cannot successfully load without an “initrd” to handle the decryption.
On the positive side, grub2-efi is opensource, so this problem can be fixed.
At present, there are multiple problems with UEFI. We need to get these ironed out.