Open z0rgster opened 2 months ago
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? https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Yep.
[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.
So uh... we hope that Ventoy team gives an update 2.0.0?? with also giving a fix to the 1.9.9 error? https://github.com/ventoy/Ventoy/issues/2902
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 https://github.com/ventoy/Ventoy/issues/2947#issuecomment-2303076839, 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 https://github.com/ventoy/Ventoy/issues/2947#issuecomment-2307520346 , 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? I've installed Linux Mint 22 on my laptop (UEFI with Secure Boot enabled) a couple of days ago and there wasn't a single problem. I decided to reinstall the very same Mint today (again) using the same Ventoy stick with 1.0.96 on it and suddenly there is a shim problem this time. I haven't had anything with Microsoft to do. Wasn't even connected to the internet on this machine in like a half the year...
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.
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.
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.
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 https://github.com/ventoy/Ventoy/issues/2947#issuecomment-2308896304, 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. question: how can we find out which shim version is used by Ventoy 1.0.99 ?
ASUS TUF F17 is hit by this issue as well
obviously secure-boot signature verification complains about the shim binary used by Ventoy. question: how can we find out which shim version is used by Ventoy 1.0.99 ?
2.04
: GRUB2/MOD_SRC/grub-2.04
2.06
are affected.2.06
. So I think the devs needs to update the Grub2 to a version newer than version 2.06.
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.
- According to the folder structure of this repo the Grub2 version is
2.04
:GRUB2/MOD_SRC/grub-2.04
- According to MS they blocked all Grub2 versions affected by CVE-2022-2601. And the CVE says that all Grub2 version lower or equal to version
2.06
are affected.- So I think the devs needs to update the Grub2 to a version newer than version
2.06
.
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.
- According to the folder structure of this repo the Grub2 version is
2.04
:GRUB2/MOD_SRC/grub-2.04
- According to MS they blocked all Grub2 versions affected by CVE-2022-2601. And the CVE says that all Grub2 version lower or equal to version
2.06
are affected.- So I think the devs needs to update the Grub2 to a version newer than version
2.06
.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.
I don't know. Thought they blocked grub as bootloader in specific versions.
There is a way to reset Microsoft's new sbat policy to default (I'm currently using this way).
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD
According to this post, it should fix the problem. If not, go forward.Alt + =
and set all SbatLevelRT & SbatLevel data to 00According to Microsoft's article, it has something to do with recent security updates to Windows.
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2#3377msgdesc
We already know that dear Regards TechySkills
On Thu, Aug 29, 2024 at 7:19 PM Wilson.Huang @.***> wrote:
According to Microsoft's article, it has something to do with recent security updates to Windows.
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2#3377msgdesc http://url image.png (view on web) https://github.com/user-attachments/assets/2c877511-3a43-474a-86cb-f22745d051d0
— Reply to this email directly, view it on GitHub https://github.com/ventoy/Ventoy/issues/2947#issuecomment-2317835487, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATS23J2OAIISKPN3EK67MR3ZT4UY3AVCNFSM6AAAAABMRXX5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXHAZTKNBYG4 . You are receiving this because you commented.Message ID: @.***>
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 https://github.com/ventoy/Ventoy/issues/2947#issuecomment-2322946240, 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.
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 sudo apt install --reinstall shim-signed grub-efi
*If not working, also try:
sudo mokutil –list-sbat-revocations sudo mokutil –set-sbat-policy delete sudo mokutil –list-sbat-revocations
To fix the virtual network of the virtualization ("Nertwork 'default' is not active"):
sudo virsh net-list -all sudoo virsh net-start default
Same here. OEM pc (HP EliteDesk) Secure boot is disabled in BIOS.
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 sudo mokutil –set-sbat-policy delete 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 sudo apt install --reinstall shim-signed grub-efi
would help too, but I don't have a computer for now to test. Thank you RENANZG!
Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful.
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: https://github.com/ventoy/Ventoy/issues/2692#issuecomment-2031412234
same here. update the embedded grub plz.
Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful.
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)
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.
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
Is there a way to overcome this issue while trying to install Windows?
Same Problem.
@Muzosh
Is there a way to overcome this issue while trying to install Windows?
Disable Secure Boot in BIOS, boot from Ventoy, start Windows installation On first reboot, enable Secure Boot and continue 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 > https://github.com/ventoy/Ventoy/issues/2692#issuecomment-2362323248
I quote:
Hi everyone. After reading over the about comments I decided to try to make this a little more user friendly. I ended up modifying the ventoy.disk.img.xz file with the new shim so that you can use the Ventoy2Disk to update your drives without the need to mount, copy and rename files. I have tested this with my MediCat USB in both MBR mode and GPT mode. It seems to be working for me. You are welcome to give this a try. Please let me know if it worked for you.
ventoy-1.0.99 - Updated (shim-x64-15.8-3.x86_64) - ventoy.disk.img.xz.zip
Actually, it works for me, at least to start Ventoy.
A (very) short test with a few ISOs:
Best regards, Johan
It's work for me !! Thanks
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