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:


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”.

Bug 950569

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”.

Bug 954126

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.

Bug 917427

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.


Tags: ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

15 responses to “UEFI and opensuse Leap 42.1”

  1. atolstoy says :

    OpenSUSE always puts itself as ‘opensuse-secureboot’ on my system, even though I don’t have Secureboot option at all. I also noticed that from some moment on, efibootmgr can’t delete old entries on certain motherboards (including mine). It was really weird – I had to prepare another USB stick with 13.2 Live system and fix my entries with the older efibootmgr from there…


    • Neil Rickert says :

      OpenSUSE always puts itself as ‘opensuse-secureboot’ on my system, even though I don’t have Secureboot option at all.

      That’s actually an install option. When installing, there’s a summary page you see just before the actual install. Click on the “Booting” heading, and you can set boot parameters. One of those is to enable secure-boot. If you uncheck that box, then the boot entry will be “opensuse” instead of “opensuse-secureboot”, and “shim.efi” won’t be used.

      I also noticed that from some moment on, efibootmgr can’t delete old entries on certain motherboards (including mine).

      I have not come across that.

      On one of my systems, if I delete an entry it will come back after the next boot. But that isn’t “efibootmgr”. Rather it is the BIOS (UEFI firmware) that is remembering what were the boot options and putting them back. To delete an entry, I have to delete the files that it refers to, and then the firmware won’t put it back.

      If you are sure that your problem is due to changes in “efibootmgr”, and not due to your firmware, then you should open a bug report.


  2. Steve says :

    When you say for a fresh install we should disable secure boot prior to install, do you mean disable it in bios or in the booting section while the installation media is running or both? When using online repositories (main and updtae) I can add them but there is no option to tell it use specifically the update repo. Other options that may impact during install under booting there is an option to mark the mbr with a flag. Also in bios I have TPM enable/disable, Virtualization enable/disable. Legacy boot disabled. I’ve tried about everything (20+ install attempts) on my new HP envy m6-p114dx, amd fx8800p cpu, 16GB ram, 2TB hard drive, wireless and bluetooth card removed. with an external dvd burner. I pulling out my hair at this point.

    I can get install to complete, 1st boot grub load, but then kernel panic or hard cpu lockups, nothing works.


    • Neil Rickert says :

      Disable in the BIOS. But leave secure-boot support selected in the install settings (boot section of install).

      The reason to turn off in the BIOS, is because secure-boot support is broken on the installer. But once you have installed and run updates, secure-boot should work properly.


    • Neil Rickert says :

      I did not notice that bit about kernel panic when writing my first reply.

      I can only guess that it has to do with hardware. Perhaps a newer kernel (from the stable kernels repo) would help. But you would have to go to rescue mode to install it, since you cannot get the system up and running.

      Have you considered trying Tumbleweed?


  3. Steve says :

    My last go round 20 minutes ago I installed with secureboot enabled in bios, and online repos enabled including main update repo, I seem to have a system, with grub2, grub2-i386-pc, grub2-x86_64-efi all ver. 2.02~beta2-83.5 — I then tried to boot first by disabling secureboot in bios and booting from opensuse (not opensuse-secure) No kernel panic passed through grub, passed through green splash with the 3 dots, but then just a flashing cursor and now I’m in a loop ending with “received request to flush runtime journal from pid 1” and a lot of othe trace info. I would have to transcribe from screen to paper then type into my desktop to report.


    • Neil Rickert says :

      I’m not sure what is causing this. Most people are not having this issue.

      Could it be a graphics driver issue?

      You can try adding “nomodeset” to the kernel boot command.

      To do that, hit ‘e’ when you see the grub menu. Then scroll down to find the line that begins “linux” (or, probably, “linuxefi”). Hit the END key to get to the end of the line. Then append ” nomodeset” (without the quotes). Then continue booting — there will be a message on the screen saying how to do that.

      If that works, then you have a graphics driver problem, and you may need to install a proprietary driver.


      • Steve says :

        Coming to the conclusion that no linuxes will boot on this machine. Tried fedora 24 live with and without secureboot enabled — no go, tails with legacy support booted once but did not funtion, second time it hung, the only thing that booted was gpartedlive (an older version not the latest) when secureboot was disabled. I think HP designed this with Microsoft to block linux. Haven’t tried debian but graphic drivers look like a pain to install whether the open source or proprietary. Very disappointing, That or I have stuxnet.


        • Neil Rickert says :

          The “gpartedlive” that worked was probably 32-bit. And it possibly used “nomodeset” to avoid video problems.

          I doubt that HP designed this to block linux. More likely, they used the latest hardware, and some of it is not yet well supported by linux.

          I would suggest that you try booting a Tumbleweed live image (64-bit) to see how that runs. Tumbleweed has a newer kernel than most distros.


          • Steve says :

            Tried tumbleweed-live 64bit it boots to a blank screen but no kernel panic. tumbleweed dvds say intel, this is an amd machine fx-8800P processor. Latest install of leap 42.1 in secureboot mode gets past the splash with 3 green dots but then starts off with stack trace

            kernel tried to execute NX-protected page – exploit attempt? (uid: 0)

            also with secureboot disabled can’t boot into runlevel 3 when editing the line …showopts radeon.modeset=0 blacklist=radeon 3

            then I just get kernel panic

            Thanks for all the responses. I always have to fall back on windows it seems.


          • Neil Rickert says :

            Intel x86-64 architecture is really the 64-bit architecture invented by AMD and licensed to Intel. Intel did have its own 64-bit architecture, but it never took off.

            It looks as if the newer kernels, as in Tumbleweed, are better able to handle your processor. But the open source radeon driver is probably not up to handling your graphics card.


          • Steve says :

            Well I was about to try Tumbleweed install then runlevel 3 and blacklist open source radeon and install the proprietary but the proprietary repo http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_Tumbleweed/ says that FLGRX is not compatible with xorg 1.18 which hints that this avenue is also blocked.


          • Neil Rickert says :

            A recent thread on the factory mailing list might be relevant to your problem. The originator tried installing to a new system with a Skylake processor. The symptoms seem similar to what you described.


  4. Pedro says :

    I have installed the updates and its still impossible to boot with “bios secure boot”, to remember and i did installed with an encrypted lvm but dont see what that can interfere with uefi secure boot. So i really dont get how u boot in ur machine with uefi secure boot.


    • Neil Rickert says :

      There are some computers that don’t boot properly if “shim.efi” has two signatures. And it has two (one by the Microsoft signing key, and one by the Opensuse signing key). It is possible that you have such a computer.

      I had that problem on one computer when it was new, but a BIOS update has since corrected the problem.

      Take a look at this page: openSUSE:UEFI

      Scroll down to the section “Booting the Machine that supports only one signature with vendor provided Keys”

      If you have that problem, then you will never get as far as the grub boot menu if you have secure-boot enabled.

      And yes, you are right that using an encrypted LVM should not be causing problems.


%d bloggers like this: