Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Windows_dual_boot

"and install a bootloader which can boot into ... Windows"

The intent of the criterion is that Windows is bootable, which it isn't. In that sense, the bug is a blocker.

However, this isn't a bug per se, nor is it a regression in GRUB. TPM measured boot is working as designed. This is in effect a request for enhancement for GRUB. From this point of view, it's maybe not a blocker because the criterion itself is prescribing a solution that won't work.

The current work around is to use the firmware's boot manager to choose to boot Windows.

This is probably a good candidate for common bugs documentation, and as a prioritized bug though.

Discussed during the 2022-02-07 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora" in the case of Windows being installed with Bitlocker enabled (as is increasingly common).

We recognize this is technically difficult to fix and may change or defer.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-07/f36-blocker-review.2022-02-07-17.00.txt

> The current work around is to use the firmware's boot manager to choose to boot Windows.

One can manipulate this from Linux using efibootmgr to set BootNext to the Windows entry as well.

I recommend either changing the criteria or deferring.

See also:
https://pagure.io/fedora-workstation/issue/278
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00073.html

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

For sd-boot we solved it by using BootNext [1]. That code will be available in rawhide
after the next release (~one or two weeks). It's reported to work, though I haven't
tried it myself due to lack of appropriate wall fixtures.

[1] https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe

At the 2022-03-28 blocker review meeting, we agreed to waive this bug to Fedora 37 according to the process:

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.html
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.log.html

This is considered a "difficult to fix" bug - as indicated by Robbie above, there is no realistic prospect of it being fixed during the Fedora 36 timeframe.

Accordingly, it is waived to Fedora 37. If upstream still doesn't consider this addressable during that timeframe, we'll consider amending the release criteria to not require dual-boot to work with BitLocker-enabled Windows installs.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Since this doesn't seem to be moving, here's a release criteria amendment proposal: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/YT24WA7W6HYHOENBKDJ66PMZ4CHBTBMM/

The criterion proposal was approved and implemented, so bumping this back to proposed blocker. I expect it should now be rejected, since the criterion specifically exempts this exact situation.

Discussed during the 2022-10-03 blocker review meeting: [1]

The decision to classify this bug as an RejectedBlocker was made:

We reject this as a blocker per the rewritten criterion: "The installer must be able to install into free space alongside an existing clean Windows installation. As long as the Windows installation does not have BitLocker enabled, the installer must also install a bootloader which can boot into both Windows and Fedora."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-10-03/f37-blocker-review.2022-10-03-16.00.log.txt

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Is there any progress here? It's such a shame if Fedora can't play nicely with modern Windows installations: it'll really put people off making the switch.

I only use grub as bootloader. When grub gets updated, I need to key in the bitlocker key once. Afterwards, it is fine. I can boot Fedora or Windows 11 fine from grub with secure boot enabled and bitlocker on.

Proposing as a Prioritized bug as mentioned in comment 1. This is a long-standing bad situation for our dual-boot users.

In today's prioritized bugs meeting, we agreed to accept this as it makes dual boot with some Windows installations more difficult 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-04-19/fedora_prioritized_bugs_and_issues.2023-04-19-14.00.log.html#l-82

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

As I recall, there is some experimental support in systemd-boot for windows bitlocker support (reboot-for-bitlocker) which has been stated that it is intended to be reworked at some point.  Moving to systemd-boot from grub is not going to be viable to all (and the systemd shim is not yet signed, although there is the open bug 2268695 to do so in the future), but it may be something to keep an eye on to see when/if it can provide a path forward.

(In reply to Bas Mevissen from comment #14)
> I only use grub as bootloader. When grub gets updated, I need to key in the
> bitlocker key once. Afterwards, it is fine. I can boot Fedora or Windows 11
> fine from grub with secure boot enabled and bitlocker on.

If you boot Windows through GRUB, that means you're using Bitlocker on alternate PCR0/2/4/11 right? Since from my understanding, the PCR7 binding will fail if you not boot directly from UEFI boot menu

I did not setup anything on Windows/Bitlocker/UEFI "BIOS"/Fedora/TPM, so the defaults are fine for me. I've not seen any mention on which PCR is used.

(In reply to Bas Mevissen from comment #21)
> I did not setup anything on Windows/Bitlocker/UEFI "BIOS"/Fedora/TPM, so the
> defaults are fine for me. I've not seen any mention on which PCR is used.

Hmm so if I get it right, then the windows on your device have Bitlocker enabled, and secure boot also enabled by default. After that, you just install Fedora, and the first time you boot Windows through GRUB (and after each update), you have to enter Bitlocker Recovery Key exactly once.

Yes, indeed. Although I don't recall the exact order of installing Fedora and Windows (10 at that time, now 11). It went back and forth a few times until I added a second disk for WIndows. Fedora and grub are on the same (first) disk with the Grub chainloader (I think) starting Windows. I can switch between Fedora and Windows and reboot without having to enter the Bitlocker key.

is it possible for say, the user to put the bit locker key in the grub config file, then when grub is regenerated, it has the bit locker key and when it chainloads, it forwards t=he key to windows to unlock the volume? this may be be good for users who arent *too* security concerned, but they might as well have removed the encryption too

Check whether upstream GRUB has already landed anything for this before proposing a fix.

Who cares about Windows 10 and TPM 2.0?

As I understand it, it is a cryptographic hardware platform designed to block competing operating systems to boot on the hardware.

Claude has written a patch that implements the approach from the description, but have no Windows 10 and TPM 2.0 system to test this on.

GRUB sets BootNext to the firmware's Windows Boot Manager entry and
resets, so the firmware boots Windows directly and BitLocker sees the
measurements it expects.

Patch (attached): 0001-efi-Add-bootnext-command-and-use-it-to-boot-Windows.patch
Against rhboot/grub2 current master, applies with git am.

What it does:

- Adds a new EFI module/command, "bootnext":
    bootnext [--set-only] --path FILE
    bootnext [--set-only] --description TEXT
    bootnext [--set-only] XXXX
  It walks BootOrder, parses each active Boot#### load option, matches
  the loader file path (case-insensitive, / or \) or description, writes
  BootNext and calls grub_reboot(). If nothing matches it returns an
  error without resetting.

- 30_os-prober emits, for Windows EFI entries:
    if insmod bootnext; then
        bootnext --path '/EFI/Microsoft/Boot/bootmgfw.efi'
    fi
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
  So when there is no matching NVRAM entry, or the module is missing,
  behaviour is unchanged (chainload).

- GRUB_DISABLE_WINDOWS_BOOTNEXT=true in /etc/default/grub restores
  plain chainloading. Both are documented in grub.texi.

BootNext is consumed by the firmware, so BootOrder and the next normal
boot are unaffected.

Testing so far (QEMU q35 + OVMF, GPT ESP, NVRAM entries created with
HD()/FilePath() device paths as a Windows install would):

- Windows entry present: GRUB set BootNext and reset; firmware log shows
  'BdsDxe: starting Boot0001 "Windows Boot Manager"' directly, chainloader
  never reached. BootNext was cleared afterwards.
- Windows entry absent: bootnext fails with "no active UEFI boot entry
  matches '/EFI/Microsoft/Boot/bootmgfw.efi'" and the entry falls back
  to chainloader as before.
- Menu entry generated by the patched 30_os-prober script itself.

Not yet tested: real hardware with TPM 2.0 and BitLocker. Testers with a
BitLocker dual-boot setup would be very welcome.

Packaging note: with Secure Boot, the signed grubx64.efi only has the
modules built into it, so "bootnext" needs to be added to the EFI module
list in grub.macros for this to take effect on Fedora. Without that, the
"if insmod bootnext" guard just falls back to chainloading.

I'll also send the patch to grub-devel, since upstream has the same open
request (https://savannah.gnu.org/bugs/?61522).

October 2025 was end-of-life (EOL) date for Windows 10.

Closes.

This bug tries to sabotage the Fedora 45 Release.

See https://qa.fedoraproject.org/blockerbugs/milestone/45/final/buglist

What the hell is wrong with Microsoft and TSM 2.0?

TPM 2.0 (Trusted Platform Module). Your frustration is widely shared. Here’s the short version of what’s going on.

Microsoft won’t budge. In a blog post titled “TPM 2.0 – a necessity for a secure and future-proof Windows 11,” Microsoft made clear it won’t relax Windows 11’s hardware requirements to get people off Windows 10. Their reasoning is that the chip underpins features like Credential Guard, Windows Hello for Business, BitLocker encryption and Secure Boot. TPM isn’t the only hurdle, though. Even a PC with a working TPM 2.0 can be rejected, because the installer also checks the CPU against Microsoft’s internal list.
Microsoft closes the door on Windows 11 supporting older hardware +2

The timing makes it worse. Windows 10 support ended in October 2025. Windows 11 also keeps moving: version 26H2 became generally available on September 29, 2026, and 24H2 Home and Pro stopped getting updates on October 13, 2026. If you’re seeing new trouble this week, it may be this: a Microsoft support thread updated October 27 warns that a BIOS change can make Windows stop detecting a TPM it previously saw. There’s also Pluton news. Windows Report wrote on October 26 that Microsoft’s documentation now says Pluton no longer acts as the TPM 2.0 implementation on processors released in 2026.
How to Enable TPM 2.0: 13 Steps, 30 Min [2026] +2

Why people object:

    It turns millions of perfectly usable PCs into e-waste, or into unsupported machines.
    Microsoft’s messaging has been inconsistent over the years. TPM 2.0 was originally planned as a requirement for Windows 8.1, then made optional after hardware vendors pushed back.
    techradar
    From a digital-rights angle, hardware roots of trust are double-edged. They protect keys and boot integrity, but they also enable remote attestation and tighter vendor control over what runs on your own machine.

Your realistic options:

    Enable fTPM (AMD) or PTT (Intel) in the firmware. Many boards ship with it switched off.
    Use the known install workarounds, accepting that Microsoft will nag you and may withhold updates.
    On the business side, Windows 11 LTSC 2024 makes TPM optional, though it still enforces the CPU list.
    boorghani
    Move older machines to Linux, which doesn’t care whether there’s a TPM.

If something specific broke for you, like an update failing or BitLocker suddenly asking for a recovery key, tell me what you’re seeing and I’ll help narrow it down.

Sources:

    Microsoft closes the door on Windows 11 supporting older hardware
    https://rss.boorghani.com/?p=261486

    KitGuru: Microsoft refuses to drop the TPM 2.0 requirement
    https://www.kitguru.net/page/131/!https:/www.kitguru.net/gaming/joao-silva/microsoft-refuses-to-drop-the-tpm-2-0-requirement-for-windows-11/

    Tech Insider: How to Enable TPM 2.0 (2026)
    https://tech-insider.org/?p=45741

    KluczeSoft: TPM 2.0 requirements 2026
    https://kluczesoft.pl/wiedza/bezpieczenstwo/tpm-20-wymagania

    TechRadar: Hardware vendors can avoid TPM 2.0
    https://www.techradar.com/news/hardware-vendors-can-avoid-tpm-20-for-windows-11-if-needed-heres-how

Created attachment 2162544 [details]
0001-efi-Add-bootnext-command-and-use-it-to-boot-Windows.patch

https://file.savannah.gnu.org/file/0001-efi-Add-bootnext-command-and-use-it-to-boot-Windows.patch?file_id=59158

We appreciate the effort to help, but pointing an AI agent at a downstream Bugzilla bug and reposting all its output isn't the best way to go about it.

I'm surprised this is still an issue, at the FC45 blocker level. I'm able to dual boot Windows 11 (pro, presumably 26H1) and Fedora with secure boot, Bitlocker and TPM 2.0 using the chain loader for years. Can I help by showing something around the setup I have? I did not setup anything particular, just installed both. The only thing I need to do is to manually re-enter the Bitlocker key everytime GRUB is updated. As I boot Windows way less often than GRUB gets updated, that is not an issue to me.

Apply https://file.savannah.gnu.org/file/0001-efi-Add-bootnext-command-and-use-it-to-boot-Windows.patch?file_id=59158

Thanks, Frayer.

Adam Williamson is fired.

You don't question Claude.
You don't delay Fedora 45.

I am changing to Debian GNU/Linux 13.

See https://www.aamot.io/software/skolelinux/

If Fedora 45 won't boot, first try an older kernel. Hold **Shift** (BIOS) or press **Esc** (UEFI) right after power-on to show the GRUB menu, then pick the previous kernel entry. If that works, the problem is probably the new kernel or a driver, and you can stay on the old kernel while you sort it out.

If nothing in GRUB boots, a live USB lets you start the machine anyway, rescue your files and read the logs. Here's how to make one on **another** working Linux PC. These steps use Fedora 44 and the Debian 13.6.0 Live GNOME image, but any Linux machine and any live image will do. A Fedora Live image works just as well and is handy if you want to repair the install with `dnf`.

**You need:** a USB stick of at least 8 GB (it will be erased), about 4 GB of free disk space, and sudo access.

**1. Download the image and checksum**
```
mkdir -p ~/Downloads/debian && cd ~/Downloads/debian
wget https://cdimage.debian.org/cdimage/archive/13.6.0-live/amd64/iso-hybrid/debian-live-13.6.0-amd64-gnome.iso
wget https://cdimage.debian.org/cdimage/archive/13.6.0-live/amd64/iso-hybrid/SHA512SUMS
sha512sum --check --ignore-missing SHA512SUMS
```
You should see `debian-live-13.6.0-amd64-gnome.iso: OK`.

**2. Find the USB stick.** Run this before and after plugging it in:
```
lsblk -o NAME,SIZE,TRAN,MODEL,MOUNTPOINTS
```
The new line with `usb` in the TRAN column is your stick, for example `sdb`. **Don't** pick `nvme0n1` or `sda`, which are usually the internal disk.

**3. Write the image** to the whole device, not a partition:
```
sudo umount /dev/sdX?*
sudo dd if=debian-live-13.6.0-amd64-gnome.iso of=/dev/sdX bs=4M status=progress conv=fsync
sync
```
If you prefer a GUI, Fedora Media Writer ("custom image") or GNOME Disks ("Restore Disk Image…") do the same thing.

**4. Boot the broken PC from the stick.** Open the one-time boot menu right after power-on. The key is usually F12 on Dell and Lenovo, F9 on HP, F8 on Asus, or Esc. Then choose `UEFI: <stick name>` and **Live system**. Secure Boot can stay enabled.

**5. Get at your Fedora install.** Fedora uses Btrfs by default, and the root filesystem is the `root` subvolume. Find the partition with `lsblk -f`, then:
```
# If the disk is encrypted, unlock it first:
sudo cryptsetup open /dev/nvme0n1p3 fedora
sudo mount -o subvol=root /dev/mapper/fedora /mnt
# If it isn't encrypted:
sudo mount -o subvol=root /dev/nvme0n1p3 /mnt
```
Your files are under `/mnt/home`, which is a separate `home` subvolume you can mount the same way. Copy anything important to another drive before trying fixes.

**6. Look at why the boot failed:**
```
journalctl -D /mnt/var/log/journal --list-boots
journalctl -D /mnt/var/log/journal -b -1 -p err
```
If you post the errors from the last failed boot here, it'll be much easier to narrow down the cause.

CLOSED