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
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 
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!
rgds
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.
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.
PrakashC
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
efibootmgr -vls -lR /boot/efiI intentionally do not want to ask this on bugzilla because so far there is no indication of a bug here.
Hi!
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:
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.
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.