After a shim update yesterday, no longer able to boot with secure boot enabled

There was a package update yesterday of a shim package, and installed.

After rebooting, now I get a message:

Verifying shim SBOT: Security Violation Failure
Something went terribly wrong [...]

And laptop self shuts down, doesn’t even reboot.
Now I have to disable secure boot in firmware settings to be able to use rig.

WTF happened? Not even today’s kernel and grub updates fixed this

Is this your bugreport:

No, but it’s indeed the problem I describe.

Also, I can confirm that it may not happen in all hardware, since I have Leap 15.4 in 2 different laptops (Acer and Lenovo brands) and ran system updates today at same time, and only the first one failed with this.

So yet another n-th good screwing from suse guys… Even mr nrickert bothered to bug-report…
This is just great

Yes, it’s the same problem.

However, my computer booted after the 15.4 update. It was after a Tumbleweed update (different partition, same computer) that if failed to boot.

Please add a comment to that bug report, so that they know more than one person is affected.

My failed system is a Dell desktop system purchased in 2012. I’m wondering whether this is a problem that is specific to the Dell provided BIOS.

Neither of these messages exist in SUSE shim source. And [...] is actually important to identify location in the source code which printed this message.

What about providing at least the actual error so it can be troubleshooted? Or may be you can send your system to SUSE so they have something to reproduce it on.

What shim is used to boot - shim from Leap or shim from Tumbleweed? Did shim from Leap boot at least once after update? Did shim from Tumbleweed boot at least once after update? Which shim fails - Leap or Tumbleweed?

Can you show the content of /sys/firmware/efi/vars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23/data?

It’s written in the bugreport :roll_eyes:

My Acer ES1-512 has been running with opensuse 15.4 for months. With the update of 31.03.2023 comes only the message:
"Verifiying shim SBAT data failed: Sectity Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation "

Since he no longer booted, they can’t even fix the problem with a fix!
The PC is dead! I prefer to have no security features than such!


Yes, that one above is the exact error message I’m getting (except for the mistyped “Sectity”, of course).

But, as already mentioned, the only way to boot again is disabling secure boot in the BIOS settings.

Disable secure boot.

It seems related to this change:

I’ve done some more testing.

It looks as if the new shim from Leap has invalidated the old shim from Leap and has also invalidated the shim from Tumbleweed.

With secure-boot enabled:

The new shim from Leap can boot. The Tumbleweed shim cannot boot. The old shim from Leap cannot boot.

The Leap 15.4 install iso cannot boot. A Tumbleweed install iso cannot boot. Leap 15.3 cannot boot, unless I use the new shim from Leap 15.4. And Tumbleweed cannot boot unless I use the new shim from Leap 15.4.

I’ll add this comment to the bug report.

I have the Leap 15.4 install iso (original release) on a USB. So I mounted the EFI partition from that USB, and replaced “shim.efi” (actually “bootx64.efi” which is the name used for shim. And I replace also “MokManager.efi” and “grub.efi” from the new versions on Leap 15.4. I’m never sure if that will work, since the install USB has overlapping partitions. But it seems to boot, at least to the rescue system, though it gives an error message.

Absolutely correct as I explained in bugzilla. Except you need shim that supports and actually performs SBAT validation, not sure when it was added. As I explained in bug report you can reset minimal required shim version (but booting Leap 15.4 shim will set it again).

Ok, the Acer BIOS does not have an on/off secure boot. But I ran “Delete all Secure Boot entries,” which helped.
Thank you very much

You should be able to prevent this by using

mokutil --set-sbat-policy previous

and reboot.

I am totally out of my depth here! Is “shim” a part of the kernel? I had run into problem with kernel -----.24.49.3 and after a struggle gone back to -------.24.41.1.
Now my quandary is should I update to ----.24.55.3 or not!! My system is i3 2105 based and I do not use secure boot.


There is not enough information to decide whether this is a bug or the result of unusual or misconfiuration.

For this to happens you have to had booted at least once using new Leap 15.4 shim and then boot using older shim (or shim from some other distribution).

So you need to give much more detailed description of your environment and what exactly you did. Like

  • is it multiboot system? If yes, what other distribution are present.
  • did error happen immediately after updating shim and reboot or you did something in between
  • output of efibootmgr -v
  • output of ls -lR /boot/efi

I intentionally do not want to ask this on bugzilla because so far there is no indication of a bug here.

Is it actually a problem to update “shim”?
I have Leap 15.4, Leap 15.3 and Win10 on the same machine.
What can go wrong?
Is the update even necessary or should I wait?
I’m a bit hesitant because I’m also affected by the kernel issue.

There’s a new kernel available which should fix that problem.

If you are worried about the shim update, you can lock shim so that it is not updated.

As to whether you should update shim, that’s your decision. If you do update it, and assuming that you have secure-boot enabled, then:

  • If the boot menu from Leap 15.4 is being used, you will still be able to boot all of your systems.
  • If the boot menu from 15.3 is set as default, your system will fail on boot.
  • If you use the BIOS/UEFI firmware menu for booting, then Windows and Leap 15.4 will still boot but Leap 15.3 won’t boot that way.

Installing shim is likely to put Leap 15.4 in charge of the boot menu that you see.

For perspective, here’s what happened on my system. After installing “shim” everything still worked. That left 15.4 in control of the boot menu. I was able to boot Tumbleweed. But when I updated Tumbleweed, that update included a grub update which left Tumbleweed in charge of the boot menu. And then booting failed until I disabled secure-boot.

I’m now back to having Leap 15.4 in control of the boot menu and secure-boot is again enabled. Everything works that way. But another Tumbleweed update might cause problems if grub is updated – unless it also updates shim to the same level.

1 Like

You cand prevent Leap 15.4 from setting too high requirements in advance. If you already installed it, you would need to reset SBAT first.

The latest shim from Leap 15.4 disallows shim from Tumbleweed and possibly other distributions - openSUSE Users - openSUSE Mailing Lists