[issue]: Booting Ventoy with Secure Boot support fails on Lenovo ThinkPad X280

[voltrina]

Official FAQ

• I have checked the official FAQ.

Ventoy Version

1.0.96

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

No. I didn't try these alternative boot modes.

BIOS Mode

UEFI Mode

Partition Style

MBR

Disk Capacity

64GB

Disk Manufacturer

SanDisk

Image file checksum (if applicable)

None

Image file download link (if applicable)

No response

What happened?

Booting Ventoy with Secure Boot enabled on BIOS (and support enabled on Ventoy) fails with the following message:

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

The laptop is on latest BIOS (1.52 N20ET67W) and latest Ventoy (1.0.96)

[PikuZheng]

same issue with dell xps13 9343

[lithedress]

Same issue with ASUS TUF Gaming A15.
Solved by this way .

[PikuZheng]

Same issue with ASUS TUF Gaming A15. Solved by this way .

Thanks for sharing, does this mean Ventoy needs to support the new SHIM?

[markox92]

This happened to me just now,

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

7 days ago I was use ventoy to install windows 11 on my PC, after that I didn't change anything , now I was try to boot some Linux to test and I have this error, why this happened if all is same bios, configuration ?

[Rednax35]

I'm on a Lenovo Ideapad 5 15iil05, running both Fedora 39 and Windows 11 with Secure Boot on and the latest BIOS installed. Having the same problem where booting into Ventoy with Secure Boot on (yes, the key is enrolled) just throws the SBAT self-check failed error and shuts the laptop down. I remember booting into Ventoy a few weeks ago so I'm not sure what changed.

I followed the instructions on the openSUSE help page that were sent here and that fixes it fine, but the moment I boot back into Fedora it updates the shim revocation list and I can no longer boot into Ventoy.

[chalybesmith]

Having the exact same problem!
Hardware: Lenovo Thinkpad P14s Gen4 AMD.
Ventoy version: 1.0.97
Tried creating the ventoy usb from Fedora 39 and from Windows 11. In both cases the same problem persists.
The same usb worked on my older T480 thinkpad though.
Edit: grammatical errors.

[markox92]

I have fixed this. Now everything is working fine. I cleared CMOS and reflashed the BIOS with the same (latest) version. After that, I installed Windows 11 and all updates. I checked again to see if any Windows update messed with Secure Boot, but it looks all fine. Ventoy is working.

[Rednax35]

Warning, wall of text (sorry!): Here's what I've learned: Ventoy needs to update to Shim 15.8 because some systems were updated to that.

I did a ton of research and from what I've found, it seems that in early February, Shim 15.8 was pushed out to address some security problems, and one of the things it does when installed is that it makes the system not be able to boot older Shim versions because they have security problems.

The only way to get around this block list is to reset it using mokutil as detailed here or disable Secure Boot. The only distro I found that shipped Shim 15.8 is Fedora, so that means my hardware was updated with the new revocation list by Fedora (Fedora shipped it on March 12th, that's why I was booting a few weeks ago but not a few days ago). Not sure if Windows would do the same thing too. Not saying this happened to everyone, this is just my scenario. YMMV.

I also did some testing, openSUSE Tumbleweed uses Shim 15.7 and despite supporting Secure Boot, I couldn't boot the latest ISO on my hardware too. So I am assuming that Ventoy uses Shim 15.7 as well and as such, I can't boot it with Shim 15.8 updating my Revocation List.

TLDR: Shim 15.8 was released. Addresses security vulnerabilities. Part of the thing it does is when installed is to make the system not boot older Shims because security. This means you can't boot Ventoy if you installed the update since it uses an older Shim version. Some operating systems pushed out this update (but not all, Fedora is a definite yes).
Correct me if I am wrong please, this is what I've gathered from an evening of research.

I mostly used these three sources to get my info:
https://www.suse.com/support/kb/doc/?id=000021080
https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996
https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_string_for_booting_to_old_shim_in_old_Leap_image
https://koji.fedoraproject.org/koji/buildinfo?buildID=2423319

[catherinedoyel]

Warning, wall of text (sorry!): Here's what I've learned: Ventoy needs to update to Shim 15.8 because some systems were updated to that.

The secure boot bypass was not created by Ventoy (longpanda)
It was documented here years ago.
https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
From the readme: "Super UEFIinSecureBoot Disk is a proof-of-concept (not actively maintained or enhanced)"

Not sure if Windows would do the same thing too.

Windows update can push revocation of software but not as quickly updated as the Linux updates.
Microsoft bundles them into the dbx which is a level lower than the recent Fedora update.
https://uefi.org/revocationlistfile

It could be possible to find a new way to get secure boot on a newer shim, but I can't confirm or deny.

[engin-karakurt]

I got the same error on my pc, it has worked just fine a week ago and I am on Windows 11. I did not change the configuration in UEFI, only thing that could probably have impacted this is updating Windows 11 is my guess?

[onenowy]

I got also same problem after boot with fedora iso and have found a workaround to fix it.

1. mount VTOYEFI partition of ventoy usb. (If you do it on windows, you need to install ventoy as MBR partition and manually assign letter.)

2. prepare signed shim (v15.8) files, I got these files from a fedora package (https://kojipkgs.fedoraproject.org/packages/shim/15.8/3/x86_64/shim-x64-15.8-3.x86_64.rpm)

3. copy BOOTX64.efi and mmx64.efi from the shim package to /EFI/BOOT in VTOYEFI partition.

4. rename grub.efi in /EFI/BOOT as grubx64.efi.

5. reboot and enroll ventoy key using mok manager.

(If you want to restore ventoy, use update in ventoy gui)

I tested fedora (40 daily build), arch, win 11 image with secure boot.
But I'm not sure it works with other boot images.

[catherinedoyel]

2. prepare signed shim (v15.8) files, I got these files from a fedora package (https://kojipkgs.fedoraproject.org/packages/shim/15.8/3/x86_64/shim-x64-15.8-3.x86_64.rpm)

I am going to try a make a PR that includes the x64 as well as aarch64 & ia32.
Does MIPS use secureboot? If so I can't find a matching shim.

[catherinedoyel]

4. rename grub.efi in /EFI/BOOT as grubx64.efi.

This a temporary measure for amd64 architecture. Can it still function with grub named grubx64.efi?

[onenowy]

2. prepare signed shim (v15.8) files, I got these files from a fedora package (https://kojipkgs.fedoraproject.org/packages/shim/15.8/3/x86_64/shim-x64-15.8-3.x86_64.rpm)

I am going to try a make a PR that includes the x64 as well as aarch64 & ia32. Does MIPS use secureboot? If so I can't find a matching shim.

Because ventoy don't support secure boot for arm and mips (https://www.ventoy.net/en/doc_aarch64.html, https://www.ventoy.net/en/doc_mips64el.html), I think ia32 is enough.

4. rename grub.efi in /EFI/BOOT as grubx64.efi.

This a temporary measure for amd64 architecture. Can it still function with grub named grubx64.efi?

grub.efi is not real grub, it's preloader for 64bit. Real grub efi files are grubx64_real.efi and grubia32_real.efi.
Probably old shim had been hardcoded to find grub.efi, so maintainer named preloader as grub.efi. But 15.8 shim is hardcoded to find grubx64.efi.

[keetha1011]

I had this same issue in Zephyrus G16.
Did what's mentioned here https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_string_for_booting_to_old_shim_in_old_Leap_image,
and then did what @onenowy did.

copy BOOTX64.efi and mmx64.efi from the shim package to /EFI/BOOT in VTOYEFI partition.
rename grub.efi in /EFI/BOOT as grubx64.efi.

It worked and the Key enroll page appeared!

[robin-thoni]

I was able to install Ubuntu 24.04 using Ventoy, but hit that problem after booting the new system, then trying to boot Ventoy again.

As @onenowy suggested, upgrading Ventoy's shim to 15.8 worked. But instead, I picked it from my newly installed Ubuntu 24.04, in /boot/efi/EFI/BOOT.

[PikuZheng]

I was able to install Ubuntu 24.04 using Ventoy, but hit that problem after booting the new system, then trying to boot Ventoy again.

As @onenowy suggested, upgrading Ventoy's shim to 1.58 worked. But instead, I picked it from my newly installed Ubuntu 24.04, in /boot/efi/EFI/BOOT.

are you meaning 15.8? I tried fedora 15.8 with no luck
with files from ubuntu 24.04, the enroll page appeared. but still can not boot any image after select

[robin-thoni]

are you meaning 15.8? I tried fedora 15.8 with no luck

Yes, typo, my bad.

but still can not boot any image after select

I was able to boot from Ventoy and reinstall Ubuntu twice in row using shim 15.8 from Ubuntu 24.04. What's your error once you try to boot your iso?

[PikuZheng]

I was able to boot from Ventoy and reinstall Ubuntu twice in row using shim 15.8 from Ubuntu 24.04. What's your error once you try to boot your iso?

Tried PE and windows server 2022 iso, just a cursor flashing.

[robin-thoni]

Here's what I have:

EFI/BOOT$ sha1sum *
3874085c8db41b48dbf29ce23b647feeb89b342f  BOOTAA64.EFI
a9d468686be854bc40bb964c623e2368b1ce1d2e  BOOTIA32.EFI
0d66084eed62fa4112c71d5147311410d3a6b04e  BOOTMIPS.EFI
57bd685cd10578ddfbbc29f872e8dffc28cbce14  BOOTX64.EFI
19e997ac4b8b848a357520e8a38b0ec7cb5b0934  grub.efi
c18fc6f8cbe03bae95c73cdb58eae3c709a20b30  grubia32.efi
b0c95ae83302db23457dbb40c2554866ec29dd88  grubia32_real.efi
19e997ac4b8b848a357520e8a38b0ec7cb5b0934  grubx64.efi
d793229e156f74c969f1ea2f396ef7c6662b0501  grubx64_real.efi
1648c6015e4ad6c056ce31fba93da201da0a255c  mmia32.efi
a57a083b21939c47d8606090ec0ff7395aad726c  mmx64.efi
874ce4cf97ae45bff5758dd78029baef642c86d9  MokManager.efi

signal-2024-04-28-101410-compressed.mp4

[PikuZheng]

from ubuntu-24.04-desktop-amd64.iso

BOOTX64.EFI 52688f28743a51f2624dff7bc55933ef18049b8e
mmx64.efi 5515be07b05aa0740bcd0ce0dec0b45d7d5267bb

But I think it doesn't matter since the ventoy menu is correct. There must be other problems in my environment.
thanks for your sharing @robin-thoni

there are 3 submenu after select iso file. with "boot in normal mode" and "boot in memdisk mode", it always failed. with "boot in wimboot mode", it works fine.
no submenu with wim file so it always failed.

[kmanwar89]

Hi,

Same error on my Lenovo X1 Carbon Gen 12. What's weird is the first boot out-of-the-box was fine after enrolling the key in the MOK, and I was able to install Ubuntu 24.04 without issues. I want to switch back over to Ubuntu 22.04 (for a few compatibility reasons) but I can no longer boot from the flash drive.I followed the steps mentioned by @onenowy and the clarification provided by @PikuZheng and can now successfully boot into Ventoy again. To summarize:

• Create a flash drive with Ventoy, and enroll the initial key in the MOK when prompted (typically a blue screen with prompts, use ENROLL_THIS_KEY_IN_MOK when prompted)
• Install OS of choice - in my case, Ubuntu 24.04 LTS
• Upon reboot, if the USB no longer boots and presents a Verifying shim SBAT data failed: Security Policy Violation error, then continue
• Copy the shim files from the installed OS over to the flash drive - you may need to create a mountpoint and mount the partition if it isn't auto-mounted (mine wasn't, for some reason)
• Summary of commands below

# Create a mountpoint and mount the partition
sudo mkdir /media/$USER/VENTOYEFI && mount /path/to/efi/partition/on/flash/drive /media/$USER/VENTOYEFI
# Copy shim files from existing Ubuntu 24.04 install to the flash drive
cp /boot/efi/EFI/BOOT/BOOTX64.efi /media/$USER/VENTOYEFI
cp /boot/efi/EFI/BOOT/mmx64.efi /media/$USER/VENTOYEFI
mv /boot/efi/EFI/BOOT/grub.efi grubx64.efi (This step may or may not be needed??)

After rebooting, I was able to successfully boot from the flash drive.

[robin-thoni]

What's weird is the first boot out-of-the-box was fine after enrolling the key in the MOK

That's by design. IIRC, Shim>=15.8 (or Ubuntu itself, not sure) will blacklist shim<15.8 for security reasons upon boot/installation. That's why you have to upgrade shim on Ventoy for it to boot again

[PikuZheng]

After newly installing ventoy1.0.97 and replacing the BOOTX64.EFI and mmx64.efi files ( sha1 verification is the same as @robin-thoni), the boot menu appears, but the wim or iso file cannot be booted (normal mode).

and copy or move grub.efi to grubx64.efi is necessary because only grubx64.efi will be searched by BOOTX64.EFI.

and find this ValdikSS/Super-UEFIinSecureBoot-Disk#21. Hope this helps and gives me some advice on my issue.

So....it works, but not completely?