[issue]: Update to latest Shim (Verifying shim SBAT data failed) #2947
Comments
|
I found same problem on my mom's PC with Windows 11 |
|
Same here |
|
Same issue here. Seemed to have occurred randomly, it worked one week but failed the next. I have also tried formatting the USB and reinstalling Ventoy 1.0.99 again, no dice. Only thing that works is disabling secure boot. Restoring platform keys and bios CMOS resets do not seem to help. Running a b550 AM4 motherboard from MSI, with AGESA ComboAm4v2PI 1.2.0.C |
|
Same here problem started when I added the fedora ISO to my usb. |
|
I think it has something to do with recent sb-related updates to Windows? Yep.
|
|
So uh... we hope that Ventoy team gives an update 2.0.0?? with also giving a fix to the 1.9.9 error? |
|
same here |
|
same issue here :( |
|
same here |
|
afaik the issue we are observing is related to BOOTX64.EFI from the hidden VTOYEFI partition |
|
Same issue on Yoga 7 |
|
I turned secure boot off and it fixes everything but still there is a security problem if we leave it disable |
|
Turning Secure boot off is only a workaround for now until a newer verison
releases patching the previous fk up they had.
*Regards*
*TechySkills*
…On Thu, Aug 22, 2024 at 2:56 AM PUNK Tiktok ***@***.***> wrote:
I turned secure boot off and it fixes everything but still there is a
security problem if we leave it disable
—
Reply to this email directly, view it on GitHub
<#2947 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATS23J6ENVJY7IMLSHLVOYLZSUEI3AVCNFSM6AAAAABMRXX5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBTGA3TMOBTHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Same here. |
|
Issue is with secure boot patch issued by Microsoft. Need Ventoy update to correct the issue. Works if you disable secure boot, but negates using Ventoy for Windows 11 installs, unless you employ the system requirements bypass hack. |
|
Hey ! Just found out that we might not need to disable the secure boot. In the bios, there was a setting about "Secure boot OS", which was either "Windows" or "Other OS". Turning this option to "Other OS" worked for me |
|
Thanks for the info. Not all BIOS has that option, specifically OEM computers, like HP, Dell, etc.
From: Kévin Lenoir ***@***.***>
Sent: Friday, August 23, 2024 1:33 PM
To: ventoy/Ventoy ***@***.***>
Cc: Snoodking ***@***.***>; Comment ***@***.***>
Subject: Re: [ventoy/Ventoy] [issue]: Update to latest Shim (Verifying shim SBAT data failed) (Issue #2947)
Hey ! Just found out that we might not need to disable the secure boot. In the bios, there was a setting about "Secure boot OS", which was either "Windows" or "Other OS". Turning this option to "Other OS" worked for me
—
Reply to this email directly, view it on GitHub <#2947 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIIKLZXLXLHSCP7H2WLIEY3ZS5W3LAVCNFSM6AAAAABMRXX5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGUZDAMZUGY> .
You are receiving this because you commented. <https://github.com/notifications/beacon/BIIKLZVDY5K4K6BKOO6JXS3ZS5W3LA5CNFSM6AAAAABMRXX5UGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUJRH3VU.gif> Message ID: ***@***.*** ***@***.***> >
|
|
Is this really a problem created by Microsoft? |
|
Just updated Ventoy to the latest 1.0.99 on another Linux machine, booted Ventoy without the shim error, booted the very same Mint 22 live image on it. Double checked with sudo mokutil --sb-state and indeed SecureBoot is enabled. Don't know what's going on. The machine is a MSI laptop from 2013. |
It seems to be specifically affecting Windows 11 users. Looks like Microsoft released a SHIM revocation update this month that caused the issues. If your PC was not running Windows 11, you wouldn't have received the revocation update. I don't believe this affected existing systems running Windows 10 either. |
|
The machine hasn't seen Windows in years but still I could see the same shim error described in this topic when tried to reinstall from Mint 22 to Mint 22 today using the same stick for both installations, hence why I'm here. It wasn't a problem for 3 days ago when I put that stick into the laptop and installed Mint 22 for the first time but today, I couldn't load Ventoy boot screen and the laptop shutdown after 3 seconds with the shim error before that. Updating the stick and Ventoy on it to the latest solved the problem for me but I was surprised that you blame Microsoft for this when the machine wasn't even been connected to the internet in more than 6 months. The last BIOS/UEFI update was done someday in 2015. Strange situation. |
Nope. Windows 10 user, this problem prevented my Ventoy USB from being booted on my PC. It worked fine on my Windows 11 laptop, but that's probably because it hasn't been turned on in a bit so didn't get the revoked SBAT update... |
|
It looks like Microsoft is playing a god role. I'm sick of this... When I find a good Linux distro with TPM-LUKS capabilities and XRDP OOBE i'm going away from this nonsense. |
|
erm... I am using arch with TPM 2.0 and LUKS so uh.. yea lol. you just need
to search for it... they dont tell you themselves that they support.
*Regards*
*TechySkills*
…On Sun, Aug 25, 2024 at 8:29 PM digital-spinner ***@***.***> wrote:
It looks like Microsoft is playing a god role. I'm sick of this... When I
find a good Linux distro with TPM-LUKS capabilities and XRDP OOBE i'm going
away from this nonsense.
—
Reply to this email directly, view it on GitHub
<#2947 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATS23J7BIKWEZA4QBLFXBZDZTHZ4BAVCNFSM6AAAAABMRXX5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYHA4TMMZQGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
obviously secure-boot signature verification complains about the shim binary used by Ventoy. |
|
ASUS TUF F17 is hit by this issue as well |
|
I took a quick look and it's not likely to be as simple as just dropping a new version in: the devs have also patched bits of grub-2.04 to suit Ventoy's needs -- lots of little changes. |
Does this matter if grub is signed by MOK? According to my investigations, they blocked shim by SBAT policy, not grub. And if I replace shim with one which cames from Fedora (see comments in this issue: #2692) - it passes the check despite of old grub. This can be fixed quickly by replacing few signed files. |
|
My bios hasnt had an update since 2020 so uh yea we are still stuck lol
*Regards*
*TechySkills*
…On Sat, Aug 31, 2024 at 9:05 PM NicknamerSRB ***@***.***> wrote:
Once the bios is updated all problems go away as I assume secure boot is
fully reset and the update from MS no longer applies. So everyone update
your bios or if you have the latest version reflash the same version it
might help.
—
Reply to this email directly, view it on GitHub
<#2947 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATS23JZSS5FDEWXCU726IOTZUHSULAVCNFSM6AAAAABMRXX5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRSHE2DMMRUGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Incredible, Microsoft managed to fuck up my Linux system inside a virtual machine...
|
|
You should be able to reset SECURE BOOT configuration in UEFI. At the end you can also disable SECURE BOOT and just use linux as intended. I don't understand how that happen from the inside of the VM guest if this is what you are saying. |
The update of Windows 10 in a VM running in a UEFI environment with Secure Boot enabled may have altered Shim or boot-related binaries, which should not directly affect the Linux host. However, if there is any state sharing between the VM and the host, this could have caused inconsistencies in the physical machine's Secure Boot. Furthermore, if the Linux host uses Secure Boot and relies on binaries like Shim, the VM update may have caused incompatibilities with SBAT or the binary signatures on the host. 🐣 🙄 How I Solved my case:
sudo apt update *If not working, also try: sudo mokutil –list-sbat-revocations To fix the virtual network of the virtualization ("Nertwork 'default' is not active"): sudo virsh net-list -all |
|
Same here. |
|
i am experiencing this issue as well on an MSI intel, 14th generation board. |
|
Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful. |
|
The answer of RENANZG is really helpful! Here is how I do the similar thing. I disable secure boot, I boot from a live linux desktop (Ubuntu 24.04 in my case), I opened a terminal and typed (see his answer): sudo mokutil –list-sbat-revocations The first and the last line are informative and they don't change. Then I do reboot and I REENABLE secure boot. After restart Ventoy is working on that machine. May be sudo apt update would help too, but I don't have a computer for now to test. |
If you use single/few Ventoy USB dongle(s) on many different PCs, it's much better to upgrade Shim on Ventoy partition itself to solve the issue for your Ventoy instance, rather than do workaround on each target machine: #2692 (comment) |
|
same here. update the embedded grub plz. |
Thank you very much @SagePtr, I found a "clean" computer to test. Your advice really works! With a "patched" Ventoy flash drive, it behaves as in normal situation. Thanks also to the original source - @onenowy . I highly recommend this variant. |
|
So far, I have seen some solutions for this problem, but none of them are applicable when trying to install actual Windows. I have downloaded a W11 ISO from here (which pulls it from actual Microsoft repositories): https://msdl.gravesoft.dev/ Installed Ventoy to an USB stick, transferred the ISO on the stick and rebooted into BIOS, selected the stick and got the error. Is there a way to overcome this issue while trying to install Windows? |
|
Same Problem. |
Disable Secure Boot in BIOS, boot from Ventoy, start Windows installation |
|
@Muzosh you can also reset the Secure Boot settings, keys, exclusions (Blacklist Database (DBX) stores certificates and SHA-256 hashes) whatever this option is available in your UEFI configuration to factory defaults. Probably you will need to re enable Secure Boot after that or change it's mode back to normal. If you are using custom mode than it's up to you to clear those added recently revocations so it won't bother Ventoy again. Basically it's all about to reset or clear the Blacklist Database (DBX) stores certificate for Secure Boot as far as I know. |
|
Hi everyone, To stop messing with EFI security, there is a solution from user Natsuru3 to try: an updated ventoy.disk.img.xz file with SHIM v15.8 > #2692 (comment) I quote:
Actually, it works for me, at least to start Ventoy. A (very) short test with a few ISOs:
Best regards, |
|
It's work for me !! Thanks |
It works but won't boot certain Linux distros: Mint < 22; Ubuntu 23.10 and prior; prob. quite a few others I haven't tried yet. They fail with the SBAT (shutdown) message. Actually one of them reports "you have to load the kernel first" rather than shutting down the PC. |
This is completely normal: with Ventoy's Normal mode, all distributions that are not up to date with SHIM v15.8 or newer will NOT boot with Secure Boot enabled. In Ventoy's Normal mode, there is nothing else to expect other than finding an update for these releases or disabling Secure Boot. Try booting them in Ventoy's Grub mode, as it worked for me with Clonezilla 20231227 (no SHIM update available for this one but Clinezilla was updated with the new SHIM) and LMDE 6 (original ISO, old SHIM). Best regards, |
|
Same problem on PC Geekom A7 and Huawei D14 with Medicat (Ventoy 1.0.99) on Sandisk Extreme 3.2 gen1 usb stick |
|
I ran into a similar problem recently with the VBS downgrade mitigations, after applying KB5042562. This mitigation never caused any issue booting into ventoy, (1.0.99), but booting the isos on the ventoy drive was another matter. Kapersky's latest release works I was able to successfully boot Macrium Reflect 10 with Ventoy by using Macrium's built in rescue media builder. Currently, the ISO's base WIM NEEDS to be WinRE, and must be created in a windows 24h2 (26100) environment. WinPE files are currently outdated (may 2024) and fails with SKUSiPolicy.P7b added. Building it in a fully updated 23H2 (22631) environment with SKUSiPolicy.P7b results in boot failure on external media, even when local system recovery environment works. There may be other methods to update the environment of external media but I found this exhaustive. To simplify, I used a 24H2 virtual machine to install Macrium and make the ISO. SKUSiPolicy.P7b must be added to work with secure boot enabled. I used PowerISO to edit and save This PowerISO method also works for Windows 11 24H2 ISO. It does not work on any currently available earlier versions of windows ISO's releases I tested (such as 23H2). |
|
"Hi everyone. After reading over the about comments I decided to try to make this a little more user friendly."... The guy who discovered this solution is a fucking genius, it works! Thanks for sharing |
|
Found a good solution on Reddit that works:
|
|
Please try this CI release: |
|
I updated my non-working 1.98 version to the CI version https://github.com/ventoy/Ventoy/actions/runs/11868854580 and it booted correctly. |
Works with this one on my Surface Book 3, thanks! |
I had the same problem with 1.0.99: After installing the Ventoy CI-version, booting Ventoy with Secure Boot enabled works again. 🙌🙌🙌 |
and others
Official FAQ
Ventoy Version
1.0.99
What about latest release
Yes. I have tried the latest release, but the bug still exist.
Try alternative boot mode
Yes. I have tried them, but the bug still exist.
BIOS Mode
UEFI Mode
Partition Style
GPT
Disk Capacity
200GB
Disk Manufacturer
Framework
Image file checksum (if applicable)
None
Image file download link (if applicable)
No response
What happened?
As far as I understand this topic, the latest Windows Update from August 13, 2024 did some changes to some UEFI tables so that there were signatures of vulnerable Shims blacklisted. Therefore, booting Ventoy now fails with the message
This topic was already discussed for a supposedly earlier Shim version in #2692 which is still open for some reason.
The recent issue was posted on forums here and here
As a temporary workaround, secure boot must be disabled until there is an updated version of ventoy with the latest Shim version available.
Edit:
As pointed out by KevinLenoir, the target OS for SecureBoot can be changed from "Windows" to "Other OS" on Machines which support this feature. This way, Secure Boot might not have to be disabled completely.
More Information on how Shim works can be found on Arch Wiki. More info on the topic of SBAT revocation lists can be found in the rhboot/shim repository here and here
The text was updated successfully, but these errors were encountered: