You shrink the Windows partition, install Fedora, and the boot menu vanishes
You shrink your Windows partition, boot the Fedora installer, and everything looks fine until the first reboot. The screen goes black with a Secure Boot violation message, or the GRUB menu never appears, or Windows refuses to mount the new partitions because the disk is locked. You didn't disable Fast Startup, or the bootloader chain got tangled during the install. This happens more often than you'd expect when mixing Microsoft's firmware expectations with Linux flexibility.
Disable Fast Startup before you touch the disk. A locked NTFS partition will bite you on the first mount.
The firmware chain and the locked disk
Secure Boot checks digital signatures before handing control to the bootloader. The firmware loads a binary only if it trusts the signature. Fedora ships a shim binary signed by Microsoft. This shim verifies the signature of grub2 before loading it. If the chain breaks, the firmware stops the boot.
Think of the boot process like a relay race. The firmware hands the baton to shim. shim checks the runner, then hands it to grub2. grub2 loads the kernel. If shim doesn't trust grub2, the race stops. Fedora's packages are signed with keys enrolled in the Microsoft database, so the handoff works out of the box.
Windows Fast Startup complicates things. Fast Startup hibernates the kernel on shutdown instead of powering off completely. This leaves the NTFS filesystem in a dirty state and locks the volume. Linux sees a dirty NTFS partition and mounts it read-only to prevent corruption. If you try to write to it, you get errors. The installer needs unallocated space, not a locked partition.
ntfs-3g: Failed to access volume: The disk contains an unclean file system (0x30).
Set Windows to shutdown cleanly (remove the hibernation file).
This error appears when you try to mount a Windows partition that was hibernated via Fast Startup. The disk is locked. You must disable Fast Startup in Windows to clear the lock.
Preparing Windows and the disk layout
Boot into Windows 10. Open the Control Panel and navigate to Power Options. Select "Choose what the power buttons do." Click "Change settings that are currently unavailable." Uncheck "Turn on fast startup" and save changes. Reboot Windows once to ensure the hibernation file is cleared.
Shrink the Windows partition using Disk Management. Run diskmgmt.msc from the Start menu. Right-click the Windows partition and select "Shrink Volume." Free up at least 50GB of unallocated space. Leave the space unallocated. Do not format it. The Fedora installer will use this space.
Check your disk layout from the Fedora installer environment if you want to verify the space is available.
# List block devices to identify the Windows partition and available space
# The unallocated space will appear as a gap in the partition table
lsblk -f
# Check if Secure Boot is active in the firmware before installing
# This confirms the shim will be required for boot
mokutil --sb-state
Fedora Workstation defaults to btrfs with subvolumes for the root and home directories. This gives you automatic snapshots and better space management. You can switch to ext4 in the installer, but btrfs is the standard. The installer handles the subvolume layout automatically.
Installing Fedora with Secure Boot
Boot the Fedora installer media. Select "Install to Hard Drive." Choose "Custom" partitioning if you want control, or let the installer auto-configure in the unallocated space. Create a root partition in the free space. The installer will format it as btrfs by default. Create a swap partition if your system has less than 8GB of RAM.
Do not format the existing Windows partitions. The installer will detect the Windows bootloader and install the Fedora shim and grub2 chainloader to the EFI System Partition. The ESP is a small FAT32 partition shared by all operating systems. Fedora places its boot files in EFI/fedora, while Windows uses EFI/Microsoft/Boot.
The installer will prompt you to enroll the Machine Owner Key if you are loading custom kernel modules. For a standard install, the Microsoft-signed shim handles everything. No MOK enrollment is needed unless you install proprietary drivers that require unsigned kernel modules.
If the installer fails to detect Windows, check that the ESP is mounted and accessible. The installer needs to write the boot entry to the EFI variables.
# Verify the shim and grub2 packages are installed after the first boot
# These packages provide the signed bootloader chain
rpm -q shim grub2-efi-x64
# Check the EFI boot entries to confirm Fedora was added
# The output should show a Fedora entry alongside Windows Boot Manager
sudo efibootmgr
Reboot the system. The GRUB menu should appear, listing Fedora and Windows. Select Windows to verify it boots correctly. Select Fedora to verify the Linux environment loads.
Verifying the boot chain
Run these commands after installation to confirm the system is healthy. Secure Boot should remain active. The shim package should be present. The GRUB configuration should list both operating systems.
# Confirm Secure Boot is still active and shim is handling the boot
# This ensures the firmware is enforcing signature checks
mokutil --sb-state
# Check journal for any shim or grub2 errors during the last boot
# The -xe flags add explanatory text and jump to the end of the log
journalctl -b -1 -t shim -t grub -xe
# Verify the GRUB configuration contains the Windows menu entry
# This confirms the os-prober detected the Windows installation
grep -i windows /boot/grub2/grub.cfg
If mokutil reports Secure Boot is disabled, the firmware settings may have changed. Check the BIOS/UEFI setup. Fedora works best with Secure Boot enabled. Disabling it reduces security and is rarely necessary.
Edit /etc/default/grub to modify GRUB settings. Running grub2-mkconfig regenerates the configuration. Manual edits to /boot/grub2/grub.cfg vanish on the next kernel update. Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and recovery
Windows Update can overwrite the EFI boot order. After a major Windows update, the GRUB menu might disappear, and the system boots straight into Windows. The Fedora files are still on the disk. The boot order just changed.
Check the boot order with efibootmgr. If the Fedora entry exists but is lower in the list, reorder it. If the entry is missing, reinstall the GRUB EFI binary.
# List current boot entries to see the order and labels
# Windows Update often moves Windows Boot Manager to the top
sudo efibootmgr
# Regenerate the GRUB configuration to detect Windows boot entry
# This adds the Windows menu item if it was lost
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# Reinstall the GRUB EFI binary to the ESP if the boot entry is missing
# Replace nvme0n1 with your actual disk device from lsblk
sudo grub2-install /dev/nvme0n1
Fast Startup can re-enable itself after Windows updates. If you see the ntfs-3g error again, go back to Windows and disable Fast Startup. The setting sometimes resets.
SELinux denials can appear if you mount Windows partitions with unusual options. Fedora mounts NTFS partitions with uid and gid mapping by default. If you need to access files owned by Windows, use ntfs-3g with the correct options. Check journalctl -t setroubleshoot for SELinux messages. Read the one-line summary before disabling SELinux.
If the boot menu is gone, GRUB rescue is your friend, not your enemy. Boot from the installer media, select "Troubleshooting" > "Rescue a system," and mount the root partition. Chroot into the system and run grub2-install.
Check efibootmgr before you panic. Windows Update often just reorders the boot list, it doesn't delete Fedora.
Choosing your dual-boot strategy
Use Fedora Workstation with Secure Boot when you need a standard mutable system that plays nice with corporate firmware policies. Use Fedora Silverblue when you want an immutable base that updates atomically and rolls back on failure. Use a separate disk for Fedora when you want zero risk of bootloader conflicts or partition resizing errors. Disable Secure Boot only when you are loading unsigned third-party kernel modules that cannot be signed with a MOK.
Reboot before you debug. Half the time the symptom is gone.