Dual Booting Windows 10 and Fedora 34


On Dual Booting Installation, I had Windows 10 Pro preinstalled.
Windows Disk Management program shows EFI boot partition then Windows BitLocker encrypted partition. (Machine is UEFI bootable, Legacy mode not available. (AMD processor))
I used Windows disk management to shrink the Windows partition and left available space unformatted free space.

Used Fedora 34 Live USB and Anaconda installer. The Blivet GUI disk format discovered EFI partition, then tiny 16MB unidentified partition, then the ntfs and finally the unformatted free space. (1TB size ssd)

Setting the EFI partition from windows to /boot/efi mount point and free space to btrfs and / mount point succeeded in installation.

BUT I want to encrypt my btrfs partition. Since /boot is on btrfs, it cannot be encrypted, according to anaconda error checking.

How can I dual boot with windows AND have encrypted btrfs?
is /boot designation necessary on EFI / UEFI booting?
I have not looked, but presume MBR is NOT present at all, since Legacy mode is not available on this BIOS.
IF it matters, hardware is Lenovo L15 AMD and Ryzen 7 graphics, 1 TB ssd, 64 GB RAM
{No swap partition created, swap space details left at discretion of anaconda installer.}


I’m sure there is more than one way to do it. To keep the number of partitions to be managed to a minimum, my personal preference would be to mount the ESP partition to /boot so that the kernel and initramfs would be copied to that partition on installation/upgrade. Unfortunately, grub does not work with that layout (it wants to put a special “symlink” file under /boot, but because the ESP (and therefore /boot) has to be formatted with a FAT file system, symlinks do not work. If you are willing to switch to another bootloader (i.e. systemd-boot), it can be done. I haven’t done a dual-boot with MS Windows configuration with systemd-boot, but it looks like systemd-boot does support that:

Excerpted from systemd-boot - ArchWiki

systemd-boot will automatically check at boot time for Windows Boot Manager at the location /EFI/Microsoft/Boot/Bootmgfw.efi, UEFI shell /shellx64.efi and EFI Default Loader /EFI/BOOT/bootx64.efi, as well as specially prepared kernel files found in /EFI/Linux/. When detected, corresponding entries with titles auto-windows, auto-efi-shell and auto-efi-default, respectively, will be generated. These entries do not require manual loader configuration. However, it does not auto-detect other EFI applications (unlike rEFInd), so for booting the Linux kernel, manual configuration entries must be created.

You would need to be sure that the ESP is sufficiently large for the bootloaders and the kernels and initramfses, but other than that, it shouldn’t be too difficult to create such a layout. It would have to be done by hand though. Here is a video that I made a while back demonstrating a systemd-boot with Fedora Linux installation that might give you some ideas about how to create such a system:

P.S. I have no experience with LUKS encryption. But it appears that it simply requires passing a few extra parameters to the kernel/dracut, so I think it should work fine with systemd-boot.

P.P.S. In the video demo above, I deleted all the contents of the ESP before installing the systemd-boot boot loader. You wouldn’t want to do that if your ESP contains your MS Windows boot loader :slightly_smiling_face: .

1 Like

Back up the existing EFI partition, remove it, create a larger one from free space, then restore the content.

I fixed it another way, I read the installation instructions and followed them… /boot was placed on its own partition formatted ext4. Now encryption of btrfs and swap is allowed, and most conveniently Windows does NOT ask for bitlocker key everytime I reentered windows after using fedora…

Placing /boot within btrfs is strongly discouraged in fedora wiki on booting procedures…

In modern UEFI scenario /boot partition does NOT need to be within the first few cylinders of the system “disk.” (BTW, with SSD’s does “cylinders” and “heads” have any actual meaning anymore??)


1 Like

That is correct. CHS terminology is completely meaningless on SSDs. Where you reading some old Fedora Linux documentation that referred to that?

CHS terminology is meaningless on HDDs as well. LBA does the translation to physical location and CHS terminology is a carry over from when drives were tiny.

Oh, my AT&T PC7300 had a HUGE hard drive, 10 MEGA BYTES. I couldn’t imagine ever filling that up. So from not trying something new I left Anaconda on “Simple” partitions instead of LVM. And GRUB seems to work fine.