TL;DR: bitlocker does not like grub
Full story:
Months ago I installed fedora on my desktop, dual booting Windows 11.
In all this time I never had the need to boot into windows. I remembered that it worked fine after install, good, and then I forgot about that.
Today I needed a specific windows only software, so at grub I chose the microsoft bootloader and… BITLOCKER.
Huh? Bitlocker? Me? What? Searched frantically for that decryption password in my keepass, did not find. What?? How???
After a few minutes staring at that screen I thought, ok let’s just wipe that shit and reclaim the space. I went back to linux, opened the partition manager, then remembered that i had something important in single copy over there. Noooooo
Went back to the boot screen to try again, still failed password.
Then I notice the error:
e_fve_pcr_mismatch
that mismatch lets me think that maybe I had something wrong in my booting.
I try to put windows first in the bios and it works! WHAT THE…???
So, if i put linux first, then launch windows from grub, bitlocker takes the windows partition under ransom, i can only access if windows is first. And of course in windows 11 x64 is no longer possible add linux partitions in their boot manager (previously it was possible)
Incompetence or maliciousness?


It’s not malicious or “ransomware”, and this is perfectly normal, default behavior for most devices - both macOS and Windows implement full disk encryption in a default install these days, and your key is almost always in your Microsoft Account on the Microsoft website. While Microsoft does a lot of crap wrong, in this case, Windows’s failure to decrypt under GRUB is security features actually kind of doing their job. Basically, trying to boot Windows through GRUB confuses the TPM, causing it to not want to give the keys in case the Windows boot partition has been tampered with by bad actors. Thus, you have to boot directly through Windows Boot Manager, not GRUB
Also, secure boot and TPM aren’t just some conspiracy by Microsoft to block Linux; they are attempts at implementing legitimately necessary security features. Full disk encryption supported by correctly implemented secure boot and an encryption chip are essential to having modern security. Linux is not blocked by TPM and Secure Boot; it is certainly possible for Linux distributions to take advantage of them to enhance their own security. I have implemented automatic LUKS full disk encryption that similarly fails to unlock if the partition has been tampered with on my Debian install. In theory, they can actually be used to help improve your security.
That is not to say I think TPM and secure boot are good, though. The really obnoxious thing about secure boot is that all the certificates are controlled by Microsoft rather than a standards body or a group of certificate authorities. While so far, Microsoft has kept it relatively open by providing the third party CA and the shim binary in order to avoid having its neck snapped by the FTC, considering the current administration, we don’t know how much longer they’ll keep it up, and they could actualize the much-feared blocking of Linux.
The other big problem with TPMs and secure boot is that often, there are so many different implementations and frequently major security flaws in their implementations that weaken their protection. A typical petty thief stealing your laptop still probably won’t be able to decrypt your drive, but a nation state can probably find a way. It doesn’t help that Windows doesn’t encrypt communication between the CPU and the TPM (luckily, the Linux kernel does that by default). Despite these issues, I’d say TPM and Secure Boot is better than nothing for most devices; not using them at least in part means your device is more vulnerable to physical access and bootkit attacks than even most Windows laptops, and they are often the only tools at your defense
There’s no “probably”, they can surely find the way, because the decryption key is saved on Microsoft servers, they just need a subpoena for getting it
Precisely. I just use probably as a catch all.