openSUSE Leap 42.1, Windows 10 and secure boot

openSUSE Leap 42.1, Windows 10 and secure boot

I installed openSUSE Leap 42.1 in my laptop with an already installed Win10. When I tried to boot Win10 using the grub2 menu it failed and showed me the following message:

file path: /ACPI(a0341d0,0)/PCI(2,1f)/Sata(0,0,0)/HD(2,e1800,32000,31aa31b24532e34a,2,2)/File(\EFI\Microsoft... /EndEntire
error: Not supported image.

Press any key to continue...

Then I installed openSUSE 13.2. In this case, the boot menu worked perfectly.

After that I upgraded 13.2 to Leap but I had the same problem with boot menu as in the first case.

Finally I reinstalled Leap again, clean install as in my first try and the same problem appeared. After all of that, I turned off secure boot in my laptop BIOS/UEFI menu. Then all worked perfectly.

So, after all of that. Do somebody knows if there is a solution to boot both systems using grub2 without problems and secure boot turned on?

With secure boot enabled?

Do somebody knows if there is a solution to boot both systems using grub2 without problems and secure boot turned on?

You need to open bug report on (use the same user/password as in forums). Please mention bug number here.

I’m using grub2-efi with secure boot on. However, I am using the “shim.efi” from opensuse 13.2. There are known to be problems with the newer “shim.efi” used by 42.1. The problem that I know about is reported as bug 950569. However, you seem to have a different problem (different symptoms of a problem). So I agree that you need to open a bug report on your specific problem.

If you want to try again, you could install 13.2. Then save a copy of the content of “/boot/efi/EFI/opensuse”. You can save that in a subdirectory. Make sure that you have updated “shim” to the latest version for 13.2 before you save that.

Then, after upgrading to 42.1, try copying back your saved copy of “shim.efi”. I cannot guarantee that this will work, but it is worth trying if you have the time and patience.

Did you maybe over write win10?

Will that work from a 13.2 install on a different machine (desktop when problem is on laptop)? – I rather doubt it though.

I’m not quite sure what you are asking.

The file “shim.efi” should be on any 64-bit 13.2 system, even a system installed for legacy booting. You can find it at “/usr/lib64/efi/shim.efi”. And using that in place of the installed “shim.efi” for 42.1 should be okay (it works for me).

The installed “shim.efi” – the one that needs replacing – is usually at “/boot/efi/EFI/opensuse/shim.efi”.

I’m having this very same problem as well. Both Win 10 and 8/8.1. This is pretty bad.

The referenced bug report is rather different, and seems to not be this issue.

I’ve found an identical problem with Ubuntu that should shed some light on this.

Somehow this rings the bell … there was a bug in SUSE-specific patches for secure boot support; this bug was exactly in chainloader command. It was should have been fixed long ago, but as grub2 in leap comes from SLES, I have no idea whether this fix was included there.

Whoever has this problem and is willing to assist in fixing it (meaning - testing patches) - please open bug report and mention number here. No amount of “me too” on this forum is going to change anything,

Yes, with secure boot enabled.

I will create the bug report and let you all know the bug number when it’s done.

Nice idea, but right now I have my system working with grub2 but without secure boot enabled :(. I was playing around with the boot for a while after I installed my system (a few times) trying to make it work, but I didn’t try using the 13.2 shim.efi because I don’t really know if a grub2 update will overwrite the shim file and broke it, so for this time I will stick to the non secure boot option for a while.

Nope :cool:, I made a backup of win10 boot before I started messing around with the boot trying to fix it with secure boot enabled (unsuccessfully). The boot menu provided by my laptop, the BIOS/UEFI one, worked ok all the time.

Sorry but at this time I only have my laptop, not other options for me to try.

You made me think: I could give a try getting the “shim.efi” of 13.2 and overwriting my current one. I suppose I can get it from the 13.2 rpm instead of reinstalling my whole openSUSE one more time.

I checked and this patch is in Leap; also symptoms were different. Must be something else.

Bug was already created from yesterday. Here is the link: Bug 954126: Unable to boot Windows partition when SecureBoot is enabled

Hi nrickert. You told me to make a copy of the 13.2 “shim.efi”. I am not reinstalling my system to get it from boot directory, but I will try to get the files from the 13.2 rpm package if that is possible. Could you please make an “ls -l /boot/efi/EFI/*” and paste the output here? I will be great to have also the sha1sum of the files.

I assume you want “/boot/efi/EFI/opensuse”.

# ls -l *.*
-rwxrwxr-x 1 root root      58 Nov  1 06:19 boot.csv
-rwxrwxr-x 1 root root     150 Nov  1 06:19 grub.cfg
-rwxrwxr-x 1 root root  915832 Nov  1 06:19 grub.efi
-rwxrwxr-x 1 root root  119808 Nov  1 06:20 grubx64.efi
-rwxrwxr-x 1 root root 1161312 Nov  1 06:19 MokManager.efi
-rwxrwxr-x 1 root root 1286112 Aug  8 07:32 shim.efi

I used “.” to exclude subdirectories where I keep backup copies for various versions.

Note that the date on “shim.efi” is earlier than the others. That’s because “shim.efi” comes from 13.2.

# sha1sum *.*
c9a1d5674e661a14f660df89ceb0a26e9b5067ec  boot.csv
7acd9dbfc83c3398369c07b212edea2d622d38cb  grub.cfg
a0892cbbd386c9de52fe520160ce158f3586fa65  grub.efi
80551eadbba492ffd61aa5db0cd028c11a812bee  grubx64.efi
d5cd2c284d64f3274d366df03fa71c8a28afb1e5  MokManager.efi
2ca442d20a710c5125c207d743297b9d375ed08d  shim.efi

And, for completeness, here is the information on the “shim.efi” that was installed by 42.1

# ls -l 42_1/shim.efi
-rwxrwxr-x 1 root root 1157056 Nov  1 06:19 42_1/shim.efi
# sha1sum 42_1/shim.efi

3cf8beb1e2885f51ca04002425c4f3c796d105bc  42_1/shim.efi

Looking at the 13.2 install DVD image (loop mounted), I find a directory EFI/BOOT.

In that directory, there is a file “bootx64.efi”

# ls -l bootx64.efi
-r-xr-xr-x 1 root root 1286112 Oct 26  2014 bootx64.efi
# sha1sum bootx64.efi
2ca442d20a710c5125c207d743297b9d375ed08d  bootx64.efi

If you check the sha1sum, you will see that this file is identical to the “shim.efi” from 13.2 (the one I am currently using). So if you still have the install iso around (maybe on a DVD), you can actually get “shim.efi” from there without reinstalling.

I hope this helps.

And another note. I have a second UEFI computer which works just fine with the “shim.efi” that came with 42.1. It’s seems clear that there’s a bug in “shim.efi”, but whether it affects you depends on your BIOS (UEFI firmware).

(Added in edit): The files “boot.csv” and “grub.cfg” will vary from computer to computer. So ignore their sha1sums, which I gave only for completeness. Hmm, “grubx64.efi” will also vary from computer to computer, and is not normally used anyway.

I recovered the shim.efi file from openSUSE 13.2 rpm (here, with the same sha1sum) and copied it to the /boot/efi/EFI/opensuse directory. Without secure boot enabled it worked as the 42.1 shim.efi version. After enabling secure boot, my system loaded Win10 directly; I suppose this happened that way because my /boot/efi/EFI/Boot/bootx64.efi was the same as my /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi (same sha1sum both of them), so I copied the contents of /boot/efi/EFI/opensuse directory into my /boot/efi/EFI/Boot directory and copied shim.efi to bootx64.efi. After I enabled secure boot again, the same problem appeared as it was the 42.1 shim.efi version, so not luck yet. Maybe not a bug from shim.efi but from other part of the boot process…