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
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?
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!
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).
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.
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.