Secureboot : Grub error "shim_lock protocol not found"

[vernetroyer]

When installing Ventoy on USB with GPT and SecureBoot, upon first boot I need to install keys, just as explained on the website.
The second boot however does start up Ventoy correctly, but when selecting SystemRescue 9.01, and Grub starts, I get the following Grub error:

shim_lock protocol not found, you need to load the kernel first

Rebooting with secure boot disabled does not give the error, and boots SystemRescue successfully.
Booting with secureboot gives a black (?) grub screen, booting without secureboot gives a green (?) grub screen.

Does anyone know a solution on how to solve this that it will work under SecureBoot?

[2Torr]

#metoo with SystemRescue 9.02

I just found this earlier post from @ventoy:
"Ventoy use https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk as the secure boot solution.
... You can make an issue in this project and hope the author @ValdikSS
ValdikSS can fix it."

[vernetroyer]

That's very helpful indeed! I could not find anything about this, other than that Grub2 itself seemingly doesn't want to support SecureBoot. Ventoy seemed like the logical next thing to try, but doesn't work with Grub2 in a SecureBoot context. It's unclear where the issue is at, but I didn't hear anything from the Ventoy devs, it's been awkwardly silent...

---

https://forum.manjaro.org/t/grub-fails-t...ed/62522/6

Has a similar observation, with no solution.

[2Torr]

@ValdikSS just released a new version of Super-UEFIinSecureBoot-Disk (v3-2) with updated keys for the shims 8 days ago.

https://github.com/ValdikSS/Super-UEFIin...es/tag/3-2

@longpanda, would you please update Ventoy with this new release?

Hopefully, it will help fix the secure boot issues with Grub 2 which still exist, even in Ventoy v1.0.74 CI #776.

Thanks!

[2Torr]

@longpanda, thank you very much for releasing Ventoy v1.0.75 today with many great improvements!

I just tried the latest version with both systemrescue 9.02 and 9.03 images, and unfortunately, this issue still exists.
Would you please try booting a systemrescue image from ventoy v1.0.75 to help reproduce and track down the issue?

Thanks!

[2Torr]

@longpanda, @vernetroyer,

I believe I figured out how to workaround this issue.
It turns out that I needed to enable a Ventoy option using VentoyPlugson app:

Under Global Control Plugin:
VTOY_LINUX_REMOUNT: changed to 1 (from default 0)

After I did that, I'm now able to boot Ventoy USB memory stick and run systemrescue images!
Hope this helps.

[longpanda]

VTOY_LINUX_REMOUNT option has nothing to do with secure boot.

[alive]

VTOY_LINUX_REMOUNT option has nothing to do with secure boot.

https://man7.org/linux/man-pages/man7/ke...own.7.html
> Only validly signed modules may be loaded

> On an EFI-enabled x86 or arm64 machine, lockdown will be
      automatically enabled if the system boots in EFI Secure Boot
      mode.

[longpanda]

VTOY_LINUX_REMOUNT option has nothing to do with secure boot.

https://man7.org/linux/man-pages/man7/ke...own.7.html
> Only validly signed modules may be loaded

> On an EFI-enabled x86 or arm64 machine, lockdown will be
      automatically enabled if the system boots in EFI Secure Boot
      mode.

Then VTOY_LINUX_REMOUNT  should be 0 not 1. Only VTOY_LINUX_REMOUNT=1 will load an unsigned module, VTOY_LINUX_REMOUNT=0 will do nothing.
Besides, the module loading is at when the kernel finished boot, this issue is when loading the kernel.

So it's wierd that make VTOY_LINUX_REMOUNT=1 solved the issue.

[longpanda]

OK, I see.

When secure boot is enabled in BIOS:
1、By default, Ventoy by pass the secure boot check before boot any ISO file. (using https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk)
2、When VTOY_LINUX_REMOUNT=1, Ventoy completly disable secure boot before boot any ISO file.

That's the difference.
That means systemrescue can boot OK only if we completly disable secure boot (in the BIOS or by Ventoy).