How to Dual Boot Fedora 45 and Windows 11 (BitLocker-Safe)

Pick Windows from the new GRUB menu on a laptop with BitLocker turned on, and Windows stops at a blue screen asking for a 48-digit recovery key. Nothing is broken. The TPM saw a boot path it was never sealed to, and it refused to release the key. If that key is not saved somewhere you can reach from another device, your Windows data is locked out. Find the key first, then touch the disk.

Original content from computingforgeeks.com - post 172697

This guide shows how to dual boot Fedora 45 and Windows 11 on one drive with Secure Boot left on. You’ll shrink C: from Windows, install Fedora alongside Windows with the “Share disk with other operating systems” option in the installer, and encrypt the Fedora side with LUKS. It also covers the part other dual boot guides skip: why booting Windows through GRUB trips BitLocker recovery, the two ways around it, and how to remove Fedora again without leaving a dead boot entry. Every screen and every output below came from one machine running both systems.

Tested October 2026 on Fedora 45 and Windows 11 24H2, with Secure Boot on and BitLocker protecting C:.

What changes on a Windows 11 disk when Fedora moves in

Fedora does not touch the Windows partitions. It does change the boot side, and every item in this table showed up on our test machine:

Area	Before Fedora	After the Fedora 45 install
EFI system partition	Windows Boot Manager only	Shared: EFI\Microsoft plus EFI\fedora, and the Fedora shim is copied over the fallback EFI\Boot\bootx64.efi
Firmware boot order	Windows Boot Manager first	Fedora (shim, then GRUB) first, Windows second
Boot menu	None	GRUB lists Fedora, the rescue kernel and Windows Boot Manager
Hardware clock	Local time (Windows default)	Still local time: the installer set Fedora to read the RTC as local
BitLocker	Sealed to Secure Boot state (PCR 7, 11)	Windows booted from GRUB no longer matches, so BitLocker asks for the recovery key

The last row is the one that hurts. Plan for it before you start.

Step 1: Back up the BitLocker recovery key

Windows 11 turns on device encryption by itself on most new laptops, so assume C: is encrypted until you have checked. Open PowerShell as Administrator and run:

manage-bde -status C:

On our machine the volume was fully encrypted with protection on:

BitLocker Drive Encryption: Configuration Tool version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: [Windows]
[OS Volume]

    Size:                 126.13 GB
    BitLocker Version:    2.0
    Conversion Status:    Used Space Only Encrypted
    Percentage Encrypted: 100.0%
    Encryption Method:    XTS-AES 128
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password
        TPM

“Numerical Password” is the recovery key. Print it with the command below and store it off this machine: a password manager, paper, or your Microsoft account if the PC signs in with one (it shows up at aka.ms/myrecoverykey). Don’t keep the only copy on the drive it unlocks.

manage-bde -protectors -get C: -Type RecoveryPassword

If the status shows Protection Off with no key protectors listed, device encryption is waiting for activation. There is no key to back up yet, and Windows can start protecting the drive later, for example after you sign in with a Microsoft account. Check again right before you install Fedora.

Now look at what the TPM protector is sealed to. This decides how Windows reacts to GRUB later:

manage-bde -protectors -get C: -Type TPM

PCR 7 and 11 means BitLocker trusts the Secure Boot state, which is the default on any modern UEFI machine:

BitLocker Drive Encryption: Configuration Tool version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: [Windows]
Key Protectors of Type TPM

    TPM:
      ID: {03B434DC-8899-4B5D-9C1B-5577980049E0}
      PCR Validation Profile:
        7, 11
        (Uses Secure Boot for integrity validation)

Step 2: Turn off Fast Startup and hibernation

Fast Startup is a partial hibernation. Windows shuts down with its NTFS volumes still marked in use, and anything Linux writes to them can be lost or corrupted when Windows resumes. Fedora does not mount a BitLocker-encrypted C: on its own, so the risk is highest for any shared NTFS data partition, but turn it off either way. Check whether it is on:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" -Name HiberbootEnabled | Select-Object HiberbootEnabled

A value of 1 means it is enabled, which is the Windows 11 default:

HiberbootEnabled
----------------
               1

Disable hibernation and Fast Startup in one pass:

powercfg /h off
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" -Name HiberbootEnabled -Value 0

Run the check again. It should now read 0:

HiberbootEnabled
----------------
               0

Step 3: Shrink the Windows partition

Fedora needs unallocated space. Ask Windows how far C: can shrink before you pick a size:

Get-PartitionSupportedSize -DriveLetter C | Select-Object @{n="MinGB";e={[math]::Round($_.SizeMin/1GB,2)}}, @{n="MaxGB";e={[math]::Round($_.SizeMax/1GB,2)}}

On our 128 GB disk, C: could go as low as 30.72 GB. That floor is set by files Windows can’t move, not by what you need to keep working:

MinGB  MaxGB
-----  -----
30.72 126.13

Give Fedora at least 40 GB and leave Windows enough for its own updates. We split it roughly in half. Open Disk Management (diskmgmt.msc), right-click the C: volume and choose Shrink Volume. Windows takes a while to query the free space. Enter the amount in MB, here 61440 for 60 GB:

BitLocker does not need to be suspended for this. We shrank the encrypted volume with protection on and Windows booted normally afterwards. The freed space lands between C: and the recovery partition:

PowerShell confirms the layout. Partition 4 is the Windows recovery partition, which stays where it is:

PartitionNumber DriveLetter Type     SizeGB
--------------- ----------- ----     ------
              1            System     0.29
              2            Reserved   0.12
              3           C Basic     66.13
              4            Recovery   1.45

Step 4: Boot the Fedora installer with Secure Boot on

Write the Fedora Workstation ISO to a USB stick with Fedora Media Writer, or with dd from another Linux box. The download and checksum steps are in our Fedora 45 install guide. The release changes themselves are covered in what is new in Fedora 45. Shut Windows down fully, then boot the stick from the firmware’s one-time boot menu (F12, F11 or Esc, depending on the vendor).

Leave Secure Boot enabled. The Fedora shim is signed through the Microsoft third-party UEFI CA, and our installs booted with Secure Boot on from the start. Turning it off to “make Linux easier” changes the same PCR 7 measurement BitLocker depends on, and Windows will ask for the recovery key on its next boot. Secured-core laptops are the exception to “it just boots”: they ship with the Microsoft third-party UEFI CA disabled in firmware (often a setting named “Allow Microsoft 3rd Party UEFI CA”), so shim will not start until you enable it. That change also alters PCR 7, so suspend BitLocker from Windows with manage-bde -protectors -disable C: -RebootCount 1 before you flip it.

Step 5: Install Fedora alongside Windows

Start Install Fedora Linux from the live desktop and pick your language. The installer found Windows on its own and selected Share disk with other operating systems, which installs into free space and leaves every existing partition alone:

Don’t pick Use entire disk. It removes all partitions on the drive, Windows included. Reclaim additional space lets the installer shrink or delete existing partitions for you, and we prefer doing the shrink from Windows where NTFS and BitLocker are handled natively.

On the storage page, tick Encrypt my data and set a passphrase. Windows is encrypted. A Fedora partition next to it holding SSH keys, browser sessions and a copy of your work should be too:

Click Next and the installer may stop with a warning about the EFI system partition. Windows Setup creates a small one (ours was 300 MB, and the Setup default on most drives is 100 MB), and Fedora recommends 500 MiB:

Click Next again to continue. Fedora reuses the Windows ESP rather than creating a second one, and on our machine the Fedora files took about 21 MB of it (19 MB in EFI\fedora plus 2 MB of fallback loaders in EFI\Boot), next to 32 MB for Windows. Check the free space on a 100 MB ESP before you install. Shim and GRUB updates write to it, and an update that fails halfway on a full ESP leaves a boot loader you can’t trust.

The review page shows exactly what will happen. The existing ESP is mounted, not formatted, and the new partitions only use the free space: a 2 GB ext4 /boot and an encrypted Btrfs volume for / and /home:

Set a hostname with the edit link if you want one, then click Install. Ours finished in about seven minutes.

Step 6: First boot into GRUB and Fedora

After the reboot, GRUB comes up with Windows already listed. The os-prober run during the install found it, so there was nothing to configure:

Fedora normally hides this menu on single-OS machines. With Windows detected, it showed on every boot of our test box, with the default 5 second countdown. Pick Fedora and the LUKS prompt appears next:

One delay to expect: our first two reboots out of Fedora sat at “Job dnf5daemon-server.service/stop running” for up to 5 minutes. That unit is the dnf5 daemon GNOME Software talks to, and it eventually stops on its own. Let it finish rather than cutting power.

Once you are logged in, check that Fedora sees both systems and has not touched the Windows partitions:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS /dev/sda

The Windows partition shows as BitLocker, and the Fedora root sits inside the LUKS container:

NAME                                           SIZE FSTYPE      MOUNTPOINTS
sda                                            128G
├─sda1                                         300M vfat        /boot/efi
├─sda2                                         128M
├─sda3                                        66.1G BitLocker
├─sda4                                         1.5G ntfs
├─sda5                                           2G ext4        /boot
└─sda6                                          58G crypto_LUKS
  └─luks-682df433-ebbc-4d21-ad30-042cedfc36bd   58G btrfs       /home
                                                                /

The firmware boot entries tell you who boots first:

efibootmgr

Fedora (entry 0002, which loads shim) is now first in BootOrder, and Windows Boot Manager is still there as 0004:

BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0002,0004,0003,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0002* Fedora	HD(1,GPT,a5216b5c-9bdc-4f1d-bb5f-9b3bece24186,0x800,0x96000)/\EFI\fedora\shimx64.efi
Boot0003* UEFI QEMU HARDDISK QM00013 	PciRoot(0x0)/Pci(0x1e,0x0)/Pci(0x1,0x0)/Pci(0x7,0x0)/Sata(0,65535,0){auto_created_boot_option}
Boot0004* Windows Boot Manager	HD(1,GPT,a5216b5c-9bdc-4f1d-bb5f-9b3bece24186,0x800,0x96000)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000063000100000010000000040000007fff0400

Secure Boot is still enforcing after the install:

mokutil --sb-state

It should report:

SecureBoot enabled

The shared ESP holds both boot loaders. Check how much each one takes:

sudo du -sh /boot/efi/EFI/fedora /boot/efi/EFI/Boot /boot/efi/EFI/Microsoft

The Fedora files take about 21 MB, next to 32 MB in the Windows folder:

19M	/boot/efi/EFI/fedora
2.0M	/boot/efi/EFI/Boot
32M	/boot/efi/EFI/Microsoft

Why Windows asks for the BitLocker recovery key from GRUB

We picked Windows Boot Manager from the GRUB menu with BitLocker protection on. Windows did not boot. It stopped here:

The message says “Secure Boot policy has unexpectedly changed”, and the details line names OSLoaderAuthoritySignature and EfiAuthority against PCR 7. Secure Boot itself never changed. What changed is the chain that loaded Windows Boot Manager: firmware, then shim (signed through Microsoft’s third-party UEFI CA), then GRUB, then Windows. PCR 7 records which certificate authorised each boot binary, and that list no longer matched the one BitLocker sealed the key to. Microsoft documents the same rule: boot code signed with the UEFI CA 2011 certificate prevents PCR 7 binding.

Typing the recovery key gets you in, but it is not a neutral fix. Microsoft’s BitLocker recovery process documentation says unlocking with the recovery password resets the platform validation measurements to the current configuration. We did not type the key in our lab, but by that rule BitLocker reseals to the path you just booted through, which moves the prompt to the other path: the trade-off of Option B below, made without choosing it. Pick one of the two options deliberately.

Option A: boot Windows from the firmware, not from GRUB (recommended)

Leave BitLocker sealed to PCR 7 and start Windows the way it expects: straight from its own firmware entry. Use the one-time boot menu key at power-on, or set it from Fedora before you reboot. --bootnext applies to the next boot only, so Fedora stays the default. Use the Windows Boot Manager number from your own efibootmgr output:

sudo efibootmgr --bootnext 0004

The firmware records the request at the top of the output:

BootNext: 0004
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0002,0004,0003,0000

With BitLocker protection on, Windows booted this way to the desktop with no recovery prompt, and manage-bde -status still reported Protection On. Going the other way, from Windows back to Fedora, is just a normal restart because Fedora is first in the boot order.

The Windows entry is still in the GRUB menu, and picking it out of habit brings the recovery screen back. On Option A, remove it. Turn off os-prober in /etc/default/grub:

sudo sed -i "\$a GRUB_DISABLE_OS_PROBER=true" /etc/default/grub

Then rebuild the GRUB config:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

The “Found Windows Boot Manager” line is gone from the output, and so is the menu entry:

Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done

Option B: reseal BitLocker to the GRUB boot path

If you want Windows in the GRUB menu, suspend BitLocker from Windows for two reboots, boot Windows once through GRUB, and resume protection there. BitLocker then seals to whatever path it booted through:

manage-bde -protectors -disable C: -RebootCount 2

Reboot, choose Windows in GRUB (no prompt this time, protection is suspended), then resume protection from an admin PowerShell:

manage-bde -protectors -enable C:

The TPM profile changes, and this is the cost of Option B. BitLocker can no longer use Secure Boot validation, so it falls back to PCR 0 (firmware), 2 (option ROMs), 4 (boot applications) and 11 (BitLocker access control):

GRUB boots of Windows worked without a prompt after the reseal. Booting Windows directly from the firmware entry now triggered recovery instead, this time with “your PC’s configuration has changed” and a BootApp detail against PCR 4:

PCR 4 records the hash of every boot binary in the chain, and PCR 0 records the firmware. We did not trigger it in the lab, but expect a recovery prompt on the next Windows boot after a Fedora update that replaces shim or GRUB, and after a firmware update. The counter-measure has to start in Windows: run manage-bde -protectors -disable C: -RebootCount 1, boot Fedora and install the update, then boot Windows through GRUB once so BitLocker reseals to the new files. Option A has none of this fragility, which is why we recommend it.

Step 7: Set the default OS and the menu timeout

The Fedora kernels live in BootLoaderSpec entries, so the only classic menuentry in grub.cfg is Windows. That makes its title easy to get exactly right:

sudo awk -F"\x27" "/^menuentry /{print \$2}" /boot/grub2/grub.cfg

On the test machine it printed:

Windows Boot Manager (on /dev/sda1)

If Windows is your daily system and you chose Option B, make it the GRUB default:

sudo grub2-set-default "Windows Boot Manager (on /dev/sda1)"

Read the GRUB environment block to confirm it:

sudo grub2-editenv list | grep saved_entry

The saved entry now names Windows:

saved_entry=Windows Boot Manager (on /dev/sda1)

That setting does not survive a kernel update on a default install. Fedora ships UPDATEDEFAULT=yes in /etc/sysconfig/kernel, and after dnf upgrade installed a new kernel on our test machine the default had moved back to Fedora:

saved_entry=5f8b9a6146bd415082510a275e2e1430-7.2.8-300.fc45.x86_64

Switch it off, then set Windows as the default again:

sudo sed -i "s/^UPDATEDEFAULT=yes/UPDATEDEFAULT=no/" /etc/sysconfig/kernel
sudo grub2-set-default "Windows Boot Manager (on /dev/sda1)"

With that change, a kernel reinstall left saved_entry on Windows Boot Manager. With UPDATEDEFAULT=yes the same reinstall moved it back to the kernel entry.

For a one-off boot into Windows without changing the default, use grub2-reboot instead. It writes a next_entry that GRUB clears after one use:

sudo grub2-reboot "Windows Boot Manager (on /dev/sda1)"

The rest of this step assumes Option B, where Windows stays in the menu. On Option A the rebuild output looks like the one shown there, without the Windows line, and Fedora hides a single-OS menu anyway. Five seconds is short when you are reaching for the keyboard after a cold boot. Raise the timeout and regenerate the config:

sudo sed -i "s/^GRUB_TIMEOUT=.*/GRUB_TIMEOUT=10/" /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

os-prober runs again during the rebuild and finds Windows on the shared ESP:

Generating grub configuration file ...
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

The next boot shows Windows highlighted with the longer countdown:

Clock: why Windows and Fedora agree on the time

Windows keeps the hardware clock in local time. Linux expects UTC, which is why dual boot guides usually warn about the clock jumping by your UTC offset. The Fedora 45 installer handled it: with Windows detected, it set Fedora to read the RTC as local time.

timedatectl

The warning is the standard systemd objection to local-time RTC. The time itself was correct on both systems after switching back and forth:

               Local time: Sun 2026-10-04 09:24:01 EAT
           Universal time: Sun 2026-10-04 06:24:01 UTC
                 RTC time: Sun 2026-10-04 09:24:01
                Time zone: Africa/Nairobi (EAT, +0300)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

The setting lives in /etc/adjtime, where the third line reads LOCAL. Leave it alone unless you live in a daylight saving zone and see the clock drift by an hour around the change.

If Windows boots straight up and GRUB is gone

Windows feature updates and some firmware updates can put Windows Boot Manager back at the top of the boot order. Nothing is deleted. The firmware just starts Windows first. Check the order from Fedora (use the one-time boot menu to get there):

efibootmgr | grep -E "BootOrder|Fedora|Windows" | cut -c1-80

Here Windows (0004) sits ahead of Fedora (0002):

BootOrder: 0004,0002,0003,0000
Boot0002* Fedora	HD(1,GPT,a5216b5c-9bdc-4f1d-bb5f-9b3bece24186,0x800,0x96000)/\E
Boot0004* Windows Boot Manager	HD(1,GPT,a5216b5c-9bdc-4f1d-bb5f-9b3bece24186,0x8

Put Fedora back first. Use the entry numbers from your own output, not ours:

sudo efibootmgr -o 0002,0004,0003,0000 | head -3

The first lines of the output show the new order:

BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0002,0004,0003,0000

Remove Fedora and give the space back to Windows

Deleting the Fedora partitions in Disk Management is only half the job. The firmware entry, the files in the shared ESP and the fallback boot loader all stay behind, and BitLocker needs one controlled reboot to reseal. Everything below runs from an admin PowerShell in Windows.

Suspend BitLocker for exactly one reboot first, because the boot path is about to change:

manage-bde -protectors -disable C: -RebootCount 1

Find the Fedora firmware entry:

bcdedit /enum firmware | Select-String -Context 3,0 "description\s+Fedora"

Windows lists the Fedora entry like this:

  identifier              {0822c50a-bfbb-11f1-9971-806e6f6e6963}
  device                  partition=\Device\HarddiskVolume1
  path                    \EFI\fedora\shimx64.efi
> description             Fedora

Delete it, using your own identifier:

bcdedit /delete "{0822c50a-bfbb-11f1-9971-806e6f6e6963}"

Mount the ESP as S: and remove the Fedora folder:

mountvol S: /S
Remove-Item -Recurse -Force S:\EFI\fedora

Do not stop there. The Fedora installer also replaced the fallback loader on the ESP, EFI\Boot\bootx64.efi, with a copy of shim. That is the file firmware runs when its boot entries are lost. List the folder and check the signer:

Get-ChildItem S:\EFI\Boot | Format-Table Name, Length, LastWriteTime -AutoSize; (Get-AuthenticodeSignature S:\EFI\Boot\BOOTX64.EFI).SignerCertificate.Subject

All four files carry the install timestamp, and the loader is signed by the Microsoft third-party UEFI signing identity, not by Windows:

Name          Length LastWriteTime       
----          ------ -------------       
BOOTIA32.EFI  806195 10/4/2026 8:48:54 AM
fbia32.efi     91584 10/4/2026 8:48:54 AM
fbx64.efi     119288 10/4/2026 8:48:54 AM
bootx64.efi  1036008 10/4/2026 8:48:54 AM


CN=Microsoft Windows UEFI Driver Publisher, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

With Fedora gone, that shim has nothing to load. Remove the Fedora fallback helpers your listing shows (drop any name your folder does not have) and put Windows Boot Manager back in its place:

Remove-Item S:\EFI\Boot\fbx64.efi, S:\EFI\Boot\fbia32.efi, S:\EFI\Boot\BOOTIA32.EFI
Copy-Item S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Boot\bootx64.efi -Force
(Get-AuthenticodeSignature S:\EFI\Boot\bootx64.efi).SignerCertificate.Subject
mountvol S: /D

The fallback is now signed by Windows itself:

CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

Delete the two Fedora partitions (5 and 6 on our disk, confirm yours with Get-Partition first) and grow C: back into the space:

Remove-Partition -DiskNumber 0 -PartitionNumber 6 -Confirm:$false
Remove-Partition -DiskNumber 0 -PartitionNumber 5 -Confirm:$false
Resize-Partition -DriveLetter C -Size (Get-PartitionSupportedSize -DriveLetter C).SizeMax

C: is back to its original size, and the recovery partition is untouched:

PartitionNumber DriveLetter Type     SizeGB
--------------- ----------- ----     ------
              1            System     0.29
              2            Reserved   0.12
              3           C Basic    126.13
              4            Recovery   1.45

Reboot once. BitLocker uses its one suspended boot and turns protection back on by itself; ours already showed Protection On. Running the enable command again is a harmless check, then read the profile:

manage-bde -protectors -enable C:
manage-bde -protectors -get C: -Type TPM

On our machine it was back on Secure Boot validation, the same 7, 11 profile it started with. Even if you had resealed for GRUB with Option B, removing Fedora this way puts BitLocker back on the stronger default without a recovery prompt:

BitLocker Drive Encryption: Configuration Tool version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Key protectors are enabled for volume C:.
BitLocker Drive Encryption: Configuration Tool version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: [Windows]
Key Protectors of Type TPM

    TPM:
      ID: {03B434DC-8899-4B5D-9C1B-5577980049E0}
      PCR Validation Profile:
        7, 11
        (Uses Secure Boot for integrity validation)

If you are keeping Fedora, the next stops are the post-install checklist for Fedora 45 and, on a machine with an NVIDIA card, the NVIDIA driver guide, whose Secure Boot key enrollment uses the same shim you just installed. Btrfs snapshots with Snapper and grub-btrfs add a rollback entry to the same GRUB menu. If you run Rocky or AlmaLinux next to Windows instead, the RHEL-family dual boot guide covers that installer.