More experiments with Linux-only UEFI Secure Boot installation

UEFI BIOS and Secure Boot work perfectly well with only Linux installed according to the experiments I have conducted on my own PC.
Written by J.A. Watson, Contributor

My recent series of posts concerning UEFI and Secure Boot technology has drawn several comments and questions about the possibility of installing only Linux on such a system. 

I have just had to completely reload my HP Pavilion dm1-4310 system (don't ask), so before reloading Windows 8, I decided to take the opportunity to do a bit of testing.  The results have been quite interesting and encouraging.

How I installed Fedora 18 with UEFI Secure Boot

Before performing these installations, in order to ensure that there would be no "relics" left on the disk, I deleted all of the existing partitions. I also ensured that UEFI Boot and Secure Boot were enabled, and Legacy Support was disabled. 

I made the installations from the standard openSuSE 12.3 and Fedora 18 ISO images, both of which are compatible with UEFI Secure Boot. I decided to do the testing in four steps - first, I installed only Fedora to the empty disk; then I wiped the disk again, and installed only openSuSE to the empy disk; then I reduced the size of the openSuSE partition to free up some space, and installed Fedora alongside openSuSE; finally, I wiped the disk again and reinstalled Windows 8 using the HP Recovery USB stick.

Step One: Fedora 18 installation

I specifically tried to let anaconda make a "default" installation, the only significant change that I made was to select "Standard Partitions" rather than LVM disk management. 

Fedora was installed with five paritions; one was a FAT partition for EFI Boot, and the others were ext4 partitions for swap, root, home and boot. When I rebooted after the installation was complete, it booted Fedora with absolutely no problem, with UEFI Secure Boot still enabled. When I checked the UEFI boot configuration with efibootmgr, I found that it had cleared out all the old entries and made a single entry to boot Fedora via the shim EFI binary.

Step Two: openSuSE 12.3 installation

Once I was convinced that the Fedora 18 installation was working properly, I once again deleted all of the existing disk partitions, and installed openSuSE to the empty disk.  The only change that I made this time was to correct the bootloader installation, from "grub2" to "grub2-efi" (the necessity for this is described in my prevoius post about Installing openSuSE 12.3 with UEFI).  This time the installer created four partitions (openSuSE does not create a separate /boot partition by default).

Once again the EFI boot configuration had been cleared but this time it had created two new entries, one for Secure Boot which pointed to the shim EFI binary, and the other pointed to a grub EFI binary, which could be used when Secure Boot is disabled.  When I rebooted after installation, with Secure Boot still enabled, openSuSE came up with no problem.

Step Three: Adding Fedora to the existing openSuSE installation

I reduced the size of the openSuSE home partition to make room for Fedora, then went through the normal Fedora installation.  I once again let anaconda make a default installation, chaning only to Standard Partitions. Interestingly, anaconda created new partitions for both EFI boot and swap, even though there were existing partitions for both of those. If I had been doing a "normal" installation, I would have directed it to use the existing partitions for both of those. 

When I checked the EFI Boot configuration, I saw that the installer had created an entry for Fedora, but the number was higher than the existing openSuSE entries. Sure enough, when I rebooted it came up with openSuSE so it was obviously booting the lowest numbered entry.  I then deleted the openSuSE boot entries, using efibootmgr, and when I rebooted it came up with Fedora.

At this point I decided to do some experimenting with UEFI boot configuration - prevoiusly, with the standard HP Windows 8 configuration, any changes I made to the UEFI boot configuration were very unpredicable - some worked, some didn't, and some appeared to work for a while but then would suddenly be removed and it would return to the default configuration. 

As a first small step, with the configuration containing only the Fedora boot information, I added a line for openSuSE with identification number 0000, so it became the first in the list. 

Then I rebooted, and openSuSE came up.  So far so good. 

Then I removed both of the boot entries, and created them again, this time with Fedora first at number 0001, and openSuSE at number 0002.  This also worked as I expected, when I rebooted it once again came up with Fedora.  Finally, I rebooted and pressed F9 (Boot Select), and I could then select to boot either openSuSE or Fedora.

This is all very good news, it means that the erratic behavior I had previously seen, with EFI Boot configuration changes getting lost is indeed a result of some sort of special handling set up either by HP or Microsoft. 

If I spent a lot more time experimenting and observing this I might be able to figure out specifically which one did it (or both), but I don't really care enough to fight with it any more. Suffice it to say, for those who want to know if Linux-only installation with UEFI boot is possible, the answer is yes.

Step Four: Restore the original Windows 8 from the HP recovery media 

I removed the existing disk partitions again, so it was starting with an empty disk, and then booted the USB stick that HP support had sent me. The difference in time required here was really astounding.  Installing either Fedora or openSuSE from scratch required less than 30 minutes, but the Windows 8 "recovery" has been running for over two hours now, and it is still not done.  It just finally asked me for the user name and password, so at least it is getting close.  Wow.

OpenSuSE 12.3: In-depth and hands-on

Finally, I got a bit more evidence that someone is "fiddling with the knobs in the back" when Windows is installed. After the Windows installation finally finished, I reduced the size of the C: partition and installed openSuSE into the free space. 

When that had finished, but before rebooting, I checked the EFI boot configuration again and as expected, I saw that it had added its usual two entries, one for Secure Boot and one for normal boot. 

Unexpectedly, though, the Windows installation had created the entry for its Boot Loader with number 0002 (no idea why it did this, there was nothing else in the list at that time), and now openSuSE had created the non-secure entry with number 0001 and the Secure Boot entry with number 0003. 

Hmmm.  If this works as I would expect it to, the system should now boot openSuSE. 

But of course it didn't, when I rebooted it came up with Windows 8.  I have no idea why - it certainly isn't because of the sequence of the numbers, and it isn't because of the BootOrder configuration, so there must be some kind of hidden priority for the Windows Boot Loader.  Sigh.

Editorial standards