UEFI and opensuse Leap 42.1
Leap 42.1 started out with some UEFI problems. The last of those were fixed in an update yesterday. However, the fix only solves the problem for already installed systems. The install media still have these problems. Since opensuse usually does not re-release install isos, it is unlikely that install problems will completely go away.
In this post, I’ll describe what were the problems and how to deal with them on a fresh install.
I’ll describe these problems in terms of the associated bug number.
- bug 950569: with this bug, the computer would seem to lockup during boot, though CTRL-ALT-DEL did work to retry the boot. Disabling secure-boot allowed the system to boot.
- bug 954126: this bug prevented booting Windows in a UEFI box, unless secure-boot was disabled.
- bug 917427: if you installed into an encrypted LVM, and if you did not use a separate unencrypted “/boot”, then the secure-boot method of booting did not work.
Boot files for UEFI
I’ll start by describing what the various files do during booting.
In a normal UEFI setup, the EFI partition of your hard drive is mounted as “/boot/efi”. The directory “/boot/efi/EFI/opensuse” is in that EFI partition. That opensuse directory contains the files:
boot.csv grub.cfg grub.efi grubx64.efi MokManager.efi shim.efi
The first of those, “boot.csv”, is not used in normal booting. It’s a recovery file. It gives information on how to recreate the NVRAM entry to boot opensuse. It is invoked by “fallback.efi” which might have been placed in “/boot/efi/EFI/Boot”. Or maybe not.
The file “grubx64.efi” contains the grub2 code that is used when you are not setup for secure-boot. That file contains information about the partition containing “/boot” and knows how to access your normal boot menu in “/boot/grub2/grub.cfg”.
In a default install, UEFI boot entries are created with the names “opensuse” and “opensuse-secureboot”. If you use the NVRAM entry for “opensuse”, then you will be using “grubx64.efi” and booting will only work if secure-boot is disabled in your firmware. If you use the NVRAM entry for “opensuse-secureboot”, then you will be using the secure-boot procedures even if secure-boot is disabled.
The files “shim.efi”, “grub.efi”, “grub.cfg” and “MokManager.efi” are all used with secure-boot. The UEFI firmware verifies the signature of “shim.efi” and then runs that as an efi application. Usually, “shim.efi” has a digital signature from Microsoft, which allows it to pass this check. Next, “shim.efi” verifies the signature on “grub.efi”. The “grub.efi” file usually has a signature by opensuse. The signature validation by “shim.efi” accepts the opensuse signature and also accepts a signature by a machine owner that has been installed using “MokManager.efi”. The main grub2 boot code is in “grub.efi”. The file “grub.cfg” is a very small configuration file that points to the “/boot” partition of your opensuse system. This is not the file with your boot menu. The boot menu will still be in “/boot/grub2/grub.cfg”.
This was a bug in “shim.efi”. It does not affect all computers. If affected my Dell Inspiron 660 desktop. But it did not affect my Lenovo TS140 ThinkServer. Whether it affects a particular computer depends on how UEFI is implemented in the computer firmware.
I noticed this first in Tumbleweed. When the new shim was released in Tumbleweed, my computer failed to boot. It just hung there with a black screen. This was before the release of Leap 42.1. Unfortunately, that bad shim was also used in the released 42.1
My normal practice on this computer had been to use the grub2-efi installed by opensuse 13.2. But a shim update for Tumbleweed overwrites that, until I restore 13.2 as the main booting system. In this case, I instinctively disabled secure-boot in the firmware, and was able to boot. I then restored using the 13.2 boot setup, and was able to turn secure-boot back on. Further testing showed that if I used the Tumbleweed booting setup, with the exception of taking “shim.efi” from opensuse 13.2, that also worked.
This bug was fixed for Leap 42.1 in late December. It was fixed a little earlier in Tumbleweed. The fix had to wait for Microsoft to sign the fixed “shim.efi”.
I did not notice this bug at first. I was mainly booting with the opensuse 13.2, and occasionally with Tumbleweed. Neither is affected by this bug. I did test boot using the boot code installed for Leap, but I never tested boot Windows.
A few weeks later, I switched to making Leap my main system and allowing it to control the booting. That’s when I noticed. On booting Windows, there was a message about “unsupported image”. Booting opensuse was not affected. I immediately recognized the bug as one that had been reported in opensuse forums. And since booting windows with opensuse 13.2 still worked, I quickly tried using “grub.efi” from 13.2, which “fixed” the problem.
This is really an older bug. As far as I know, the bug still exists for opensuse 13.2, and will probably never be fixed there. With opensuse 13.2, they enabled the ability of grub2 and grub2-efi to boot when “/boot” is part of an encrypted LVM. For this, grub2 asks for the encryption key. And the encryption key is requested again for booting the kernel. This is not the most convenient way to boot, since you have to provide the key twice.
This worked in opensuse 13.2 and in Tumbleweed, provided that you were not using secure-boot at all. That is, it worked when using the “opensuse” UEFI boot entry, but not when using the “opensuse-secureboot” entry. The code for handling encryption had not been included in “grub.efi”.
I reported this as a bug in Tumbleweed, where it was fixed, though part of the fix was delayed. The fix was not initially included in Leap 42.1, until someone asked for it. This fix was part of the updates yesterday.
Why would anyone want to have “/boot” part of the encrypted LVM, when that requires entering the encryption key twice? It turns out that if you want to use “btrfs” for the root file system, then you need “/boot” to be part of the root file system if you want to be able to boot from snapshots. So, if using “btrfs” in an encrypted LVM, then this is now the recommended setup.
Doing a fresh install of Leap 42.1
If you are doing a clean UEFI install, you cannot completely avoid these bugs. For they are in the install media. So you will need to disable secure-boot before installing.
If you are not using an encrypted LVM, then it is fairly simple. After you have completed the install, apply all updates before you enable secure-boot.
If you are using an encrypted LVM and intend to have “/boot” within that encrypted LVM, then it gets a bit more tricky. The additional problem is that you cannot apply updates until you can boot the system. And bug 917427 makes it difficult to boot the newly installed system.
On my computers, the trick would be to hit F12 during boot, to get the BIOS boot menu. And then I would have to select “opensuse” rather than “opensuse-secureboot” for booting. That should get me booted the first time. And I should make sure that I install updates before I reboot again. After testing another reboot, this time using “opensuse-secureboot”, I could turn secure-boot back on.
There’s another alternative that may be a lot easier. During install, it is possible to configure online repos to be used for the installation. This is optional when installing from the DVD installer, and is standard when using the NET installer. When on the screen for configuring online repos, make sure that you tell the installer to use the update repo. If you use the update repo during install, then the updated grub2-efi is what will be installed. And everything should work from the first boot after install.