Bug 950569

reassign to shim maintainer

(In reply to Neil Rickert from comment #0)
> User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.21 (KHTML,
> like Gecko) konqueror/4.14.9 Safari/537.21
> Build Identifier: 
> 
> After updating to snapshot 20151012, I get a blank screen on reboot.
> 
> If I try booting the install DVD (written to a USB), I also get a blank
> screen.
> 
> If I disable secure-boot in the firmware, I then get a normal boot menu and
> am able to boot.  If I re-enable secure-boot, I again get a blank screen.
>
So there is nothing but a blank screen? That's bad...
I have to find a way to get more information.
 
> As a work-around, I have switched to using the "shim.efi" from opensuse
> 13.2, which works normally.
> 
Did you use shim.efi from openSUSE 13.2 DVD or the updated one?

>  ---
> 
> On a different computer (a Lenovo ThinkServer TS140), I am not having any
> problems with shim-0.9-3.2
> 
> Reproducible: Always

>So there is nothing but a blank screen? That's bad...

Right.  Sometimes there's a cursor at the top left, if I remember correctly.

>Did you use shim.efi from openSUSE 13.2 DVD or the updated one?

The updated one.  This was from 13.2 installed in a different partition on the same computer.

To be more precise, I used "shim.efi", "grub.efi" and "MokManager.efi" from 13.2.  I took those to be a matched set.  But I can experiment with just one of those at a time if that would be useful.

When I first booted after the update, it looked to me as if the firmware was freezing.  So I powered off, powered on, and hit F2 to get into BIOS settings.  That's when I tried turning off secure-boot.  When that worked, it suggested a "shim" problem.  So I experimented booting the DVD iso (on USB) with secure-boot on and off.  And then I put back the ".efi" files from 13.2 to get things working.

During my tests, I found that CTRL-ALT-DEL does reboot when the system is sitting on that blank screen.

I'm not sure how to test what is going on.  I think you would need a debugging version of "shim.efi" and it would need to be signed by Microsoft to be able to test with secure-boot -- unless there's a way of chaining a debug version from a working shim.efi, and have the debug version signed with a MokManager key.  (I do have my own key installed, though I am not currently using it on this machine).

I am having the same problems on a Dell T20 (both with BIOS version A05 and A06).  The previous boot entry grub-secureboot works without problems.  I have not tried non-secure boot yet since that requires changing some more settings in the BIOS.

> ll /boot/efi/EFI/*
/boot/efi/EFI/boot:
total 1204
-rwxrwxr-x 1 root root 1157056 15. Okt 22:29 bootx64.efi
-rwxrwxr-x 1 root root   71672 15. Okt 22:29 fallback.efi

/boot/efi/EFI/grub:
total 3456
-rwxrwxr-x 1 root root      50  8. Okt 22:29 boot.csv
-rwxrwxr-x 1 root root     155  8. Okt 22:29 grub.cfg
-rwxrwxr-x 1 root root  965472  8. Okt 22:29 grub.efi
-rwxrwxr-x 1 root root 1276328  8. Okt 22:29 MokManager.efi
-rwxrwxr-x 1 root root 1286112  8. Okt 22:29 shim.efi

/boot/efi/EFI/opensuse:
total 3416
-rwxrwxr-x 1 root root      58 15. Okt 22:29 boot.csv
-rwxrwxr-x 1 root root     155 15. Okt 22:29 grub.cfg
-rwxrwxr-x 1 root root  965472 15. Okt 22:29 grub.efi
-rwxrwxr-x 1 root root  200704 15. Okt 22:29 grubx64.efi
-rwxrwxr-x 1 root root 1161312 15. Okt 22:29 MokManager.efi
-rwxrwxr-x 1 root root 1157056 15. Okt 22:29 shim.efi

> cat /boot/efi/EFI/grub/boot.csv 
shim.efi,grub-secureboot

> cat /boot/efi/EFI/opensuse/boot.csv 
shim.efi,opensuse-secureboot

> efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,0008,0009,000A
Boot0000  opensuse-secureboot   HD(1,GPT,12345678-9abc-def0-1234-56789abcdef0,0x800,0x4e000)/File(\EFI\opensuse\shim.efi)
Boot0001* grub-secureboot       HD(1,GPT,12345678-9abc-def0-1234-56789abcdef0,0x800,0x4e000)/File(\EFI\grub\shim.efi)
Boot0008* Onboard NIC(IPV4)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(0123456789ab,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)AMBO
Boot0009* Onboard NIC(IPV6)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(0123456789ab,0)/IPv6([::]:<->[::]:,0,0)AMBO
Boot000A* UEFI: Crucial_CT1024M550SSD1  PciRoot(0x0)/Pci(0x1f,0x2)/Sata(4,32768,0)/HD(1,GPT,12345678-9abc-def0-1234-56789abcdef0,0x800,0x4e000)AMBO

The symptoms are as described in the other reports: the screen goes blank and nothing happens.  I can Ctrl-Alt-Del most of the time to get another reboot, but if I pre Enter or do anything else on the keyboard (based on the assumption that I just don't see anything on the screen) I'll have to switch off.  The grub.cfg is identical for both versions.  The only other notable difference is the presence of a grubx64.efi, but I don't think it's even used.

Responding to c#4

Yes, in your setup, "grubx64.efi" is not used.  It would be used if you did not install support for secure-boot.  That would have given a boot name of "opensuse", which you don't seem to have.

Thanks for confirming a problem with a Dell BIOS.

Responding to c#5, re c#4

I have the same with an ascer aspire iv which does not have a dell bios

Previous had two efi boot entries, 
 grub-secure-boot
 Microsoft-secure-boot

I now have three
 opensuse-secure-boot

opensuse-secure-boot is default and provides blank back-lit screen with blinking cursor in upper left corner.  45 minutes later the same display

Selecting the second, grub-.., successfully boots.

If it is a dell bios problem, it is also an acer bios problem.

I'm changing the status to "confirmed".

That "grub-secure-boot" entry is actually a mistake (see bug 948866 ).  However, it should work to avoid the latest problem.

You can probably change which entry is default, using

efibootmgr -o 2,1,3

(but use the boot entry numbers that are shown for you).  This sets the boot order.  You probably want that grub-secure-boot to be first, and Windows second, at least for now.

(In reply to Neil Rickert from comment #3)
> >So there is nothing but a blank screen? That's bad...
> 
> Right.  Sometimes there's a cursor at the top left, if I remember correctly.
> 
> >Did you use shim.efi from openSUSE 13.2 DVD or the updated one?
> 
> The updated one.  This was from 13.2 installed in a different partition on
> the same computer.
> 
> To be more precise, I used "shim.efi", "grub.efi" and "MokManager.efi" from
> 13.2.  I took those to be a matched set.  But I can experiment with just one
> of those at a time if that would be useful.
> 
Ok, it narrows down the scope a bit.

Could you use the TW shim type the following command?

# mokutil --set-verbosity true

If everything goes right, two or three notification dialog will show up while shim loads grub2 so I can know which stage goes wrong.

> When I first booted after the update, it looked to me as if the firmware was
> freezing.  So I powered off, powered on, and hit F2 to get into BIOS
> settings.  That's when I tried turning off secure-boot.  When that worked,
> it suggested a "shim" problem.  So I experimented booting the DVD iso (on
> USB) with secure-boot on and off.  And then I put back the ".efi" files from
> 13.2 to get things working.
> 
> During my tests, I found that CTRL-ALT-DEL does reboot when the system is
> sitting on that blank screen.
> 
> I'm not sure how to test what is going on.  I think you would need a
> debugging version of "shim.efi" and it would need to be signed by Microsoft
> to be able to test with secure-boot -- unless there's a way of chaining a
> debug version from a working shim.efi, and have the debug version signed
> with a MokManager key.  (I do have my own key installed, though I am not
> currently using it on this machine).

Actually, started from shim 0.9, it's possible to attach the gdb to do step-by-step debugging, but I only know how to do it with QEMU and am not sure if it's possible with the normal machine.

I'll work on the for-test shim to force the signature verification when secure boot is disabled and see if it also crash the system.

(In reply to Neil Rickert from comment #7)
> I'm changing the status to "confirmed".
> 
> That "grub-secure-boot" entry is actually a mistake (see bug 948866 ). 
> However, it should work to avoid the latest problem.
> 
> You can probably change which entry is default, using
> 
> efibootmgr -o 2,1,3
> 
> (but use the boot entry numbers that are shown for you).  This sets the boot
> order.  You probably want that grub-secure-boot to be first, and Windows
> second, at least for now.

This does work, but command is incorrect.  Should be issued w/o options
to see current numbering of boot options and those used to correct the issue.

Correcting order provides proper boot as expected but boot screen image
has reverted to three ascii chars center of screen instead of displaying an
image.

tks,

(In reply to patrick shanahan from comment #9)
> (In reply to Neil Rickert from comment #7)
> > I'm changing the status to "confirmed".
> > 
> > That "grub-secure-boot" entry is actually a mistake (see bug 948866 ). 
> > However, it should work to avoid the latest problem.
> > 
> > You can probably change which entry is default, using
> > 
> > efibootmgr -o 2,1,3
> > 
> > (but use the boot entry numbers that are shown for you).  This sets the boot
> > order.  You probably want that grub-secure-boot to be first, and Windows
> > second, at least for now.
> 
> This does work, but command is incorrect.  Should be issued w/o options
> to see current numbering of boot options and those used to correct the issue.
> 
> Correcting order provides proper boot as expected but boot screen image
> has reverted to three ascii chars center of screen instead of displaying an
> image.
> 
> tks,

Note that this was done after the shim update included in 
openSUSE-release-20151014-1.2

(Replying to Gary Lin, comment #8)

># mokutil --set-verbosity true

With the good shim.efi (from 13.2), I get a blue window that says "Verification succeeded" (or similar -- I didn't write that down)

With the bad shim.efi from 20151012, I get:

UEFI SHIM
$Version: 0.9
Build Machine: GNU/Linux$
$Commit: c340e8ce10ada28b30927e703cb62e9368cc1b9d

That was manually transcribed, so I could have miscopied a character or two.

I also tried with "grub.efi" and "MokManager.efi" from 20151012, but "shim.efi" from 13.2.  That works.  But "shim.efi" from 20151012 doesn't work, even if the other files are from 13.2.  And "shim.efi" from 20151014 behaves the same as the one from 20151012.

(Replying to Patrick Shanahan at comment #9)

>Correcting order provides proper boot as expected but boot screen image
>has reverted to three ascii chars center of screen instead of displaying an
>image.

Yes, I'm getting that.  But I don't think it is related to the "shim" problem.  It's probably an issue with Plymouth.  When this last happened, it was said to be a problem with the Intel graphics driver (I am using Intel graphics).  And for me, it is intermittent -- I sometimes get the graphic plymouth screen and sometimes the text screen (with 3 green blobs).

Created attachment 652254 [details]
unsigned shim which forces the signature verification

Hi Neil,

Could you try the attached shim and see if it also crashes?

Please note it's for test and supposed to crash the system, so don't overwrite the working shim with this one. Just create a new boot entry for the test shim and see how it works.

(replying to Gary Lin at comment #13)
>Could you try the attached shim and see if it also crashes?

It doesn't actually do anything.

The firmware says "Secure Boot violation", and then it boots the next boot choice in the boot order.

I could turn off secure-boot if you want me to try that.  But since shim works with secure-boot disable, I don't know if we would be testing anything useful.

(In reply to Neil Rickert from comment #14)
> (replying to Gary Lin at comment #13)
> >Could you try the attached shim and see if it also crashes?
> 
> It doesn't actually do anything.
> 
> The firmware says "Secure Boot violation", and then it boots the next boot
> choice in the boot order.
> 
> I could turn off secure-boot if you want me to try that.  But since shim
> works with secure-boot disable, I don't know if we would be testing anything
> useful.

Sorry, I forgot to mention that you should disable secure-boot. The test shim always verifies the signature of grub2 even if secure-boot is disabled. I want to know if I can reproduce the bug without secure-boot, so we can debug in an easier way.

Okay.  I now understand what you are trying to do.

With secure-boot disabled, it behaves exactly like the bad tumbleweed shim.  I still have that verbose setting on, and it gives the same 4 lines of output, then hangs.

If I'm understanding, then that's what you wanted.  So you can now add some debugging output for the next try.

(In reply to Neil Rickert from comment #16)
> Okay.  I now understand what you are trying to do.
> 
> With secure-boot disabled, it behaves exactly like the bad tumbleweed shim. 
> I still have that verbose setting on, and it gives the same 4 lines of
> output, then hangs.
> 
> If I'm understanding, then that's what you wanted.  So you can now add some
> debugging output for the next try.

Thanks! I'll make a new shim to print more messages.

Created attachment 652296 [details]
unsigned shim without openssl patch

Hi Neil,

Could you try the attached shim?
I removed a patch from the original shim and would like to know if the crash is caused by the patch or not.

(repling to Gary Lin at comment #18)
>unsigned shim without openssl patch

Yes, that one works fine.

I'm testing with secure-boot disabled, which I take to be what you wanted.

(In reply to Neil Rickert from comment #19)
> (repling to Gary Lin at comment #18)
> >unsigned shim without openssl patch
> 
> Yes, that one works fine.
> 
> I'm testing with secure-boot disabled, which I take to be what you wanted.

Thanks! So the crash was caused by the openssl update patch. It's a huge patch and will take me a while to figure out what could be wrong.

Created attachment 652528 [details]
unsigned shim which prints verification steps

Hi Neil,

The attached shim will print several steps of the signature verification process. Could you try it and see which step crashes the system?

I am getting:

Parse PKCS#7
Check PKCS#7 signed data
Compare OID
Verify PKCS7

and then it hangs at that Verify step.

(In reply to Neil Rickert from comment #22)
> I am getting:
> 
> Parse PKCS#7
> Check PKCS#7 signed data
> Compare OID
> Verify PKCS7
> 
> and then it hangs at that Verify step.

Is the crash after "Check whitelist" or "Check vendor key"?

Could you also attach the following files?

/sys/firmware/efi/efivars/db-<a bulk of numbers>
/sys/firmware/efi/efivars/dbx-<a bulk of numbers>

>Is the crash after "Check whitelist" or "Check vendor key"?

I didn't see those.

I copied the test-shim to another computer where I am not having problems, and ran it there to see what you were expecting.

My guess is that the "mokutil --set-verbosity true" was somehow hiding some of the output.  So I reran that with "false" in place of true.

On the Dell where the problem shows up, I now see:

Check blacklist
Check whitelist
Parse PKCS#7
Check PKCS#7 signed data
Compare OID
Verify PKCS7

and then nothing.  I did not see a "Check vendor key" as best I can recall.

(there are message to hit enter key to continue, which I did not write down).

Created attachment 652734 [details]
requested file /sys/firmware/efi/efivars/db-*

Created attachment 652735 [details]
requested file /sys/firmware/efi/efivars/dbx-*

(In reply to Neil Rickert from comment #24)
> >Is the crash after "Check whitelist" or "Check vendor key"?
> 
> I didn't see those.
> 
hmmm, that's weird, so it didn't show a blue screen with those words?

> I copied the test-shim to another computer where I am not having problems,
> and ran it there to see what you were expecting.
> 
> My guess is that the "mokutil --set-verbosity true" was somehow hiding some
> of the output.  So I reran that with "false" in place of true.
> 
> On the Dell where the problem shows up, I now see:
> 
> Check blacklist
> Check whitelist
> Parse PKCS#7
> Check PKCS#7 signed data
> Compare OID
> Verify PKCS7
> 
> and then nothing.  I did not see a "Check vendor key" as best I can recall.
> 
> (there are message to hit enter key to continue, which I did not write down).

Anyway, I'll analyse db and dbx and see if I can reproduce the crash with those certificates.

(In reply to Gary Ching-Pang Lin from comment #27)
> (In reply to Neil Rickert from comment #24)
> > >Is the crash after "Check whitelist" or "Check vendor key"?
> > 
> > I didn't see those.
> > 
> hmmm, that's weird, so it didn't show a blue screen with those words?
> 
Ah, never mind. I found that you already mentioned "Check whitelist".

Created attachment 652754 [details]
unsigned shim which prints the details of pkcs7verify

Hi Neil,

I cannot reproduce the crash with your db and dbx, so I still need your help.
Could you try the attached shim? This one will print (almost) every step in Pkcs7Verify(), and hope that we could find out which step causes the crash.
Sorry for that I have to make it pause after every print, otherwise the message may be lost when the system crashes.

I'll just give the last few lines of output:

X509_verify_cert
X509_STORE_CTX_cleanup
ERR_add-error_data
 unable to get local user certificate

That's it.  There's a final "Press any key to continue".  But nothing happens after that (after hitting enter, for example).

(In reply to Neil Rickert from comment #30)
> I'll just give the last few lines of output:
> 
> X509_verify_cert
> X509_STORE_CTX_cleanup
> ERR_add-error_data
>  unable to get local user certificate
> 
> That's it.  There's a final "Press any key to continue".  But nothing
> happens after that (after hitting enter, for example).

That's good enough. I was suspecting ERR_add_error_data() and now got a hard evidence. Now it's time to figure out a proper fix.

Created attachment 652920 [details]
unsigned shim with the possible fix

Hi Neil,

Could you try the attached shim?
If my fix is right, you'll see something like "ERR_add_error_vdata: Verify error:" and the verification will continue.

>If my fix is right, you'll see something like "ERR_add_error_vdata: Verify error:" and the verification will continue.

Yes, that's exactly what happens.  There are several "ERR_add_error_vdata:" line, including the "Verify error".  Then it repeats (probably checking another certificate.  Then I get "Welcome to grub" and the boot menu.

And then the "ERR_add_*" lines repeat again (probably checking the kernel signature).  And then it boots.

Created attachment 653148 [details]
unsigned shim with the final fix

Hi Neil,

Could you try the attached shim?
I figured out the correct fix and this one should directly load grub2 without crash. It's not signed so please disable Secure Boot before testing it.

>Could you try the attached shim?

Yes, "shim-final-fix.efi" works fine.  It goes straight to the grub2 menu, and successfully boots the selected entry.

(In reply to Neil Rickert from comment #35)
> >Could you try the attached shim?
> 
> Yes, "shim-final-fix.efi" works fine.  It goes straight to the grub2 menu,
> and successfully boots the selected entry.

Thanks! I'll send my patch to upstream for review and then request a new shim signature.

I reported problems starting Tumbleweed in the forum:
https://forums.opensuse.org/showthread.php/510524-DVD-and-LiveCD-wont-start

I try to boot TW 20151022 KDE Live from a USB key on a PC based on Asus H87M-E mainboard and i5-4570 CPU, with UEFI.

I captured some boot error messages which show up for a fraction of a second just before the GRUB menu. And I was asked to posted them also in this bug report:

Failed to set MokListRT: Not found
Welcome to GRUB!

error: file -/EFI/BOOT/x86_64-efi/linux.mod' not found.
error: file -/EFI/BOOT/x86_64-efi/ls.mod' not found.

See also:
http://susepaste.org/12067695

Frank

(In reply to Frank Stulle from comment #37)
> I reported problems starting Tumbleweed in the forum:
> https://forums.opensuse.org/showthread.php/510524-DVD-and-LiveCD-wont-start
> 
> I try to boot TW 20151022 KDE Live from a USB key on a PC based on Asus
> H87M-E mainboard and i5-4570 CPU, with UEFI.
> 
> I captured some boot error messages which show up for a fraction of a second
> just before the GRUB menu. And I was asked to posted them also in this bug
> report:
> 
> Failed to set MokListRT: Not found
This message is another bug: https://bugzilla.opensuse.org/show_bug.cgi?id=950801

> Welcome to GRUB!
> 
> error: file -/EFI/BOOT/x86_64-efi/linux.mod' not found.
> error: file -/EFI/BOOT/x86_64-efi/ls.mod' not found.
> 
> See also:
> http://susepaste.org/12067695
> 
> Frank

openSUSE Tumbleweed 20151111
shim-0.9-3.20.x86_64

Still incorrectly adds opensuse-secureboot efi entry which
fails to boot.  Selecting grub-secureboot entry boots successfully.

# efibootmgr 
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0000,0002,0001
Boot0000* opensuse-secureboot
Boot0001* Windows Boot Manager
Boot0002* grub-secureboot


Is more information needed?

Replying to c#39 (Patrick Shanahan)

>Still incorrectly adds opensuse-secureboot efi entry which
>fails to boot.

It is difficult to see that as incorrect.  Perhaps they should have reverted to the previous "shim" until there is a fix available, but that's not for me to decide.

You only have that "grub-secureboot" entry because of bug 948866 -- so be happy that you have it at the moment, but once a fixed "shim" is available you should probably delete that boot entry.

The new shim just landed in Tumbleweed today and I can confirm that my T20 can again boot with this new version in secure mode.  Thanks!

I also can boot my acer aspire 5 w/o rearranging order
but still have an "extra" entry:

acer: ~ # efibootmgr
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0003,0002,0001
Boot0001* Windows Boot Manager
Boot0002* grub-secureboot
Boot0003* opensuse-secureboot

I confirmed that 0002 would also boot and then removed 
0002:

acer: ~ # efibootmgr -b 2 -B
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0003,0001
Boot0001* Windows Boot Manager
Boot0003* opensuse-secureboot

and now have:
acer: ~ # efibootmgr
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0003,0001
Boot0001* Windows Boot Manager
Boot0003* opensuse-secureboot

fwiw, I do not care which should have remained but whichever
was added unintentionally or incorrectly *should* have been 
automagically removed.  The incorrect situation was aleviated
but not completely corrected.  One *should* clean their trash.

>I do not care which should have remained but whichever
was added unintentionally or incorrectly *should* have been 
automagically removed.

Can't be done.

The problem is that other distros (arch, for example) use that "grub" directory.

It's bad enough that opensuse put something there, though perhaps not a big problem since arch normally doesn't do secure-boot.  A cleanup could delete the arch boot setup.  Not a good idea.

By the way, the new shim.efi from Tumbleweed 20151209 does seem to work for me.

OK. Since we got the confirmation that the new shim fixed the issue, I am going to close this bug. If anyone found the similar problem again, feel free to reopeon this bug.

Gary, thank you very much for this fix of shim.  It did work for me on my Asus Z97-PRO(Wi-Fi ac) motherboard (AMI BIOS, ASUS version Z97-PRO BIOS 2702).  The shim boots tumbleweed, openSUSE Leap 42.1, and openSUSE 13.2.

openSUSE-RU-2015:2343-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 950569,950801
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    shim-TW-0.9-4.1

Just a note.

I've installed today's update.  However, it did not reinstall shim.  So the updated "shim.efi" is in "/usr/lib64/efi", but it is not in "/boot/efi/EFI/opensuse".

Not a problem.  I can copy it there (I have done that, actually).

I think there's another update due shortly for bug 954126 so I hope that
one at least updates the EFI boot entries.

I seem to have the same issue on Leap 42.1, so just re-opening this bug. If I start a new bug, please let me know and I will do so. However, I have the same symptoms, a Dell machine that does not boot with secure boot enabled.

However, one additional note is that if I get to the BIOS boot menu in time, and boot into Windows and reboot, then the grub menu appears correctly.

If I do not use the BIOS boot menu, grub never appears and the machine seems to hang. Using `# mokutil --set-verbosity true` shows me that UEFI SHIM is loading, but hanging and just showing the commit ID. I'll attach a pic with that info to this bug report.

Created attachment 660634 [details]
shim hanging at boot

Responding to Marcus c#48

This bug really is fixed, though with some residual problems.

Take a look at the output from the command:
     ls -lL /usr/lib64/efi/shim.efi
If that shows a file date of Dec 14 (give or take a day), then you have the fixed shim on your system.  As a further check, you could try:
     md5sum /usr/lib64/efi/shim.efi
I get a checksum of "22462d4a946d9233ef6115dfcb31320b" on that file.

If you get the same checksum, then you have the fixed shim.efi.  I just retested within the last 30 minutes, on the machine where I originally found (and reported) this bug.

But they made a mistake (see c#47).  They failed to install that new shim after the update.

If you have the fixed shim, then (as root) you can either run:

     shim-install

or

     cp /usr/lib64/efi/shim.efi /boot/efi/EFI/opensuse/.

Either of those should fix your boot problem (assuming that you have the fixed shim.efi on your system).

There's another bug that affects booting Windows, but does not affect booting opensuse.  That's bug 954126 and we have not yet received an update to fix that bug (though they do have a fix that is being prepared to send out).  Hopefully, they will run "shim-install" with that update.

Thanks, also following that bug :-)

Indeed, manually running shim-install installs the new shim and the original issue does not occur.

Something was wrong in the leap shim. Installing shim should trigger update-bootloader and it'll copy shim.efi to /boot/efi/EFI/boot.

I filed another bug to track the missing %post script: boo#960529.

For anyone was hit by the not-updated shim.efi, a test package is available in boo#960529#c5.

This is an autogenerated message for OBS integration:
This bug (950569) was mentioned in
https://build.opensuse.org/request/show/702795 Factory / shim