SBAT self-check failed: Security Policy Violation AFTER moving Tumbleweed to new SSD

English Install/Boot/Login
1

Hi guys,

I have just experienced the infamous

Verifying shim SBAT data failed: Security Policy Violation
Something has gone serously wrong: SBAT self-check failed: Security Policy Violation

boot error.

I wanted to write down my case, so if anyone has a similar situation, could get their system fixed.

In my case there was no Leap 15.x involved, I had only Tumbleweed on my system.
What I did was running an existing Tumbleweed install from an external hard drive, with Secure Boot on, without problems.

But later on decided to move this install to a new SSD that was placed inside the machine, inside a free slot.

I moved the partitions using Clonezilla, then I booted into openSUSE Recue from a stick and chrooted into the new install to regenerate the initrd using dracut.

I still could not use secure boot at this stage, but I could boot if secure boot was in audit mode or off.

I have followed several forum threads and these instructions:
https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_string_for_booting_to_old_shim_in_old_Leap_image

But somehow nothing seemed to be working.
Following the article above, I tried several times to delete the SBAT policy, or load the previous policy, or reset everything, nothing worked.

Until I noticed the shim version difference between Leap and Tumbleweed. My brain somehow ignored everything that was related to Leap, as I had no Leap involved in my setup.

I checked the version of shim under Tumbleweed, and it is still 15.4 :expressionless: a version which will not help with any policy deletion.

So I downloaded a Live Leap 15.6, which has a newer shim version, which is needed for any policy deletion.

As it seems, it was enough to only boot into the live system and the SBAT policy was deleted/reset.

Previously I had something like:

localhost:~ #  mokutil --list-sbat-revocations
 sbat,1,2023010900
 shim,2
 grub,3

And when booted into Leap 15.6 Live, it changed into:

localhost:~ #  mokutil --list-sbat-revocations
 sbat,1,2021030218

I rebooted into the internal Tumbleweed and everything was the same, so I rebooted into BIOS and enabled Secure Boot and the Security Policy Violation was not there anymore, Tumbleweed booted without problems.

I am not sure if this will happen again in the future, but I’ll keep the Live Leap stick at hand, just in case.
I really hope shim will get an update on Tumbleweed soon, I’m not sure about the difficulty of this update, but it is strange to have everything on the bleeding edge with Tumbleweed and then have something with so much potential to cause disruptions like shim stuck at a problematic version.

Any advice for the future is welcome :slight_smile:

4 Likes
2

It should not as long as SbatLevel variable (mirrored after boot as SbatLevelRT) is present.

3

THAAAANKS ! It finally worked as easy as that on a HP EliteDesk 800 G4.
I installed and keep Leap 15.6.
Is it as stable as 15.4 I had before and was satisfactory?
All the best and thanks again for sharing your experience.

4

Thank you so much was having issues to install tumbleweed/aeon/kalpa with secure boot and saw this one and it works like a charm now I have leap 15.6 with secure boot and next to run aeon/kalpa

5

Why isn’t SHIM updated to the latest version in ROLLING Tumbleweed, but it is in lazy Leap ? I don’t get it. Is there a reason ?

6
2 Likes
7

Thank you so much!! Thanks for sharing this, it solved my problem.

My situation was:
Desktop-PC with dual-boot Leap 15.6 and Win11
I wanted to:
replacing Leap with Tumbleweed
=> and you will run into the above described problem!

No matter if you want to do a fresh install (you cannot boot into the Tumbleweed install USB-stick) or an upgrade from inside Leap to Tumbleweed (you cannot boot anymore into the upgrade), both ways will come to the same error:

 Verifying shim SBAT data failed: Security Policy Violation
 Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation

All efforts to delete or reset the ‘list-sbat-revocations’ didn’t work.

So what I did was following your solution:

  1. deactivate secure boot
  2. do the fresh-install or upgrade (from Leap to Tumbleweed)
  3. boot into the new Tumbleweed (leave secure boot untouched/inactive)
  4. check status as root (it looked something like this):
localhost:~ #  mokutil --list-sbat-revocations
 sbat,1,2023010900
 shim,2
 grub,3
  1. set to delete:
 localhost:~ # mokutil --set-sbat-policy delete
  1. exit and restart into the Leap 15.6 live USB-stick or into the Leap 15.6 install USB-stick
  2. exit the live session or abort the installation procedure (somewhere in the middle) and restart
  3. start the installed Tumbleweed (leave secure boot untouched/inactive)
  4. check again (and it looked like this):
localhost # mokutil --list-sbat-revocations 
sbat,1,2021030218
  1. shut down Tumbleweed
  2. activate secure boot
  3. start Tumbleweed again and you’re done!
    ==>Voilà, Tumbleweed worked fine and all ok (in my case).
1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.