Windows boot not starting after Fedora installation

Hi, I needed specific help to solve my issue, as I’ve seen in other post, this seems to be a recurring issue, I installed fedora 39 via the usb key and windows boot manager disapeared, while my bios is set to UEFI. I don’t know how to fix this problem

On startup, you should see a GRUB bootloader menu with several Fedora options (different kernel versions) and also a Windows option. Do you see it? It should display automatically, but you can also make it show up by pressing F8 during startup.

Alternatively, you can press a one-time boot key (different for each BIOS vendor, often F11 or F12) directly after starting the PC, where you should see both Fedora and Windows boot options.

On GRUB there isn’t the Windows option, only two Fedora options and the bios one

Please run the command sudo ls /boot/efi/EFI/ then post it here.
Also run sudo fdisk -l and post that.
If, by chance, windows was installed in MBR mode and fedora was installed in uefi mode then fedora grub would not be able to boot windows. Those 2 commands should allow us to see if that might be the case. It also would allow us to see if there are 2 different ESP partitions active.

These are the returns:

sudo ls /boot/efi/EFI/
BOOT fedora

sudo fdisk -l

Disk /dev/nvme0n1: 476,94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: WDC PC SN520 SDAPNUW-512G-1014          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 31B160AF-39E2-4234-B532-4ECBDCAA04D9

Dispositivo        Start       Fine   Settori   Size Tipo
/dev/nvme0n1p1 861716480  862945279   1228800   600M EFI System
/dev/nvme0n1p2    206848     239615     32768    16M Microsoft reserved
/dev/nvme0n1p3    239616  861716479 861476864 410,8G Microsoft basic data
/dev/nvme0n1p4 998117376 1000214527   2097152     1G Windows recovery environmen
/dev/nvme0n1p5 862945280  865042431   2097152     1G Linux filesystem
/dev/nvme0n1p6 865042432  998117375 133074944  63,5G Linux filesystem

Partition table entries are not in disk order.

Disk /dev/zram0: 7,43 GiB, 7975469056 bytes, 1947136 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Is this windows 10 or Windows 11? Do you have a health system with the same version of Windows you might copy things from?

It seem like the directory is missing for Windows uefi boot, either meaning windows is set up only for legacy boot, or somehow that got clobbered.

Online all the instructions for fixing that seem to assume you are switching from mbr to gpt at the same time you are switching to uefi boot. But you are already gpt, so I don’t know if those instructions (using mbr2gpt.exe) would work.

What I would do in that situation is copy the EFI/Microsoft/boot directory from a healthy system (using a live USB to access it) to /boot/efi/EFI/ on this system.

Edit: Jeff noticed something I should have but didn’t, indicating your original EFI partition was destroyed. That makes it less likely any tool like mbr2gpt.exe could help and more likely that it can be fixed by copying the lost directory from a different Windows system (then fixing grub, which I would do by hand editing grub.cfg, but Jeff likely will tell you the correct command to automatically fix grub once /boot/efi/EFI/Microsoft/ has all its correct contents (especially its subdirectory boot

Edit2: do you have a Windows recovery USB? I expect it would be hard to boot into your Windows recovery partition. But a Windows recovery USB would likely make the repair of Windows pretty easy, likely breaking grub, then there are instructions online (involving chroot from a live Linux USB) to repair grub without breaking the repaired windows. I would never do it all that way (vs. copying from a healthy Windows system and editing grub.cfg). But My approach isn’t the common one.

That shows windows as probably efi installed, but the original nvmeon1p1 which would have been at the beginning of the disk (before p2) seems to be missing. The microsoft efi boot manager seems not to be in that listing of /boot/efi. Fedora apparently created its own efi partition beginning right after the end of the microsoft OS partition.

To check that, what happens when you access the bios boot menu? (often accessible with F8 or similar during power on, or directly from the main bios menu). Are you able to see the windows boot option there? Is bios set for CSM or UEFI ONLY booting?

As you can see from my dual boot laptop the efi partition is at the beginning of the drive

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     534527    532480   260M EFI System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296  199752334 199185039    95G Microsoft basic data
/dev/nvme0n1p4 998473728 1000214527   1740800   850M Windows recovery environment
/dev/nvme0n1p5 199753728  201404415   1650688   806M Linux filesystem
/dev/nvme0n1p6 201404416  998473727 797069312 380.1G Linux LVM

Partition table entries are not in disk order.

It appears the original efi partition should have been 400 MB between sectors 2048 and 206848

At this point it appears you may need to do a windows recovery to restore the windows efi partition data, then ensure the efi partitions are merged into one partition for simplicity going forward.

Also please add the output of sudo efibootmgr. Let’s see if you actually have the Windows boot option stored in UEFI.

In bios boot menu there isnt a windows option and it is set in UEFI.

BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,2001,2002,2003
Boot0000* Fedora	HD(1,GPT,7d40d4d7-cdb0-4b24-8feb-d5f5f7ba4e3c,0x335cc000,0x12c000)/File(\EFI\fedora\shim.efi) File(.䍒)
Boot0004* Fedora	HD(1,GPT,7d40d4d7-cdb0-4b24-8feb-d5f5f7ba4e3c,0x335cc000,0x12c000)/File(\EFI\fedora\shimx64.efi)
Boot2001* EFI USB Device	RC
Boot2003* EFI Network	RC

I don’t understand this, what does it mean?

Overall it seems that your Windows is not installed in UEFI mode (not part of efibootmgr, not part of the bios boot menu), but in BIOS mode. I don’t know whether that’s the reason why GRUB doesn’t detect Windows.

Do you have the windows original media? Or you can download the same version from MS and try to repair your windows install first. Then you will need to use the BIOS to select the boot (likely) for Fedora the first time. once in Fedora booted the Grub menu can be cleaned up. Get your windows going first then come back and someone can help you the rest of the way I am sure.

It means the boot mode in the BIOS is selected as UEFI, as opposed to legacy or compatibility or whatever else that BIOS offers as a choice. The two actual boot modes are legacy and UEFI. But many BIOS’s offer some choice that means decide dynamically between legacy and UEFI based on some flawed test of the media contents.

That seems unlikely given what Jeff explained about the positions of the partitions.

I don’t have a guess at what deleted the original EFI partition, but likely that contained the EFI/Microsoft/ directory. It is common for a BIOS to clean the boot menu data to remove references to locations that don’t exist. So it is plausible (but I’m not sure) that the boot entry went away as a result of the partition going away.

There are a couple subdirectories and a lot of files in EFI/Microsoft/ but I think the only file you really need is EFI/Microsoft/Boot/bootmgfw.efi which could be copied from another Windows system, if you have one and can boot a USB Linux on it (So far as I know, while Windows is booted you can’t access that partition).

My dual boot system has the following in /boot/grub2/grub.cfg

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-301F-38B5' {
	insmod part_gpt
	insmod fat
	search --no-floppy --fs-uuid --set=root 301F-38B5
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi

If I were fixing that system, I would copy the bootmgfw.efi file and edit that section into /boot/grub2/grub.cfg changing the 301F-38B5 to the correct UUID of your EFI partition.
I use the command


to get a clear view of partitions including UUID.


It looks like the original EFI partition created by Windows was formatted when you installed Fedora. Window has a couple of tools on their boot ISO you can use to fix the EFI partition. If you are using Windows 10 you can download a iso from Microsoft Website or you can download from computer manufacturer if you are using a OEM image.

This guide seems to be a good guide for restoring a Windows UEFI directory using Windows bootable iso. You should backup you Fedora EFI directories before attempting to restore the windows EFI directory.

Microsoft documentation for the bcdboot command.

Take care

I agree with this statement.

It just happened to me a similar situation but it was my own fault, I’ll elaborate and probably this can help the OP:

  1. I had Windows 11 installed in a computer (UEFI)
  2. I installed Fedora Server 39 using default configurations (UEFI)
  3. Everything worked well, in BIOS setup I changed the boot order to Fedora so I could decide with Grub the OS
  4. I realized I wanted Fedora Workstation instead of Server.
    4.1. I used GParted and I wanted to remove every partition that belonged to Fedora Server, I did it but the first EFI was listed as Fedora (this did not make sense to me but still decided to remove it and trust the program)
    4.2 Continue with the installation of Fedora and it was successful
    4.3 I realized I could not boot to Windows anymore, only to the new Fedora Workstation.
  5. I had to recreate the EFI system partition of Windows, I used some of the steps from this guide (skipped everything concerning msr partition): How to Restore Deleted EFI System Partition in Windows | Windows OS Hub (Note: in my case the partition is there, just that it is as unallocated because I removed it)

I recommend you @dade6x6 to check with GParted if there is a unallocated partition of 100Mb somewhere, it seems it was supposed to be the /dev/nvme0n1p1 and it was overwritten by Fedora but it would not hurt to double check with a different program.
When installing Fedora did you allow the automatic installation and had unallocated space on your disk? or did you delete and shrink the existing Windows installation from that menu of Fedora to provide with enough space for Fedora installation?

“formatted” is an odd word to use. The original EFI partition was deleted and a larger one created, which did not fit in the place the original had been, so the new EFI went elsewhere and the place the old one occupied is just a gap.

I still don’t know how exactly that happened. The old one was deleted before the new one was created, so (unlike all the situations I had) there were not two EFI partitions existing at once.

As described in another post, maybe cleanup from a first try at installing Fedora, followed by specifying a larger size for EFI when installing it again.

I found those Windows recovery instruction confusing, maybe partly obsolete, and likely a very roundabout path to where you would want to be for dual boot controlled by grub. But they do imply the file I suggested finding on another Windows system is stored in other places on the existing system. So in Linux, it should be easy to mount the NTFS partition(s), find the file (or files) you need and copy them to /boot/efi/EFI/Microsoft/boot. That is not quite enough to enable BIOS boot of Windows, but I think is enough that you could enable grub boot of Windows. Done that way, should be easier and won’t need repair of grub after a Windows repair breaks grub.

On my dual boot system, (in Fedora) I created a directory /mnt/c and mounted the Windows C: partition there, then found the directory /mnt/c/Windows/Boot/EFI/ contains all the files that belong in /boot/efi/EFI/Microsoft/Boot/

If the Microsoft part of my efi partition had been trashed for any reason, I could just create the directories /boot/efi/EFI/Microsoft/ and /boot/efi/EFI/Microsoft/Boot/ then copy everything from /mnt/c/Windows/Boot/EFI/ to /boot/efi/EFI/Microsoft/Boot/.

After that, I’m pretty sure grub could be made to include Windows using the usual method Jeff has posted often:


To fix the issue I would shrink the /dev/nvme0n1p3 to have the enough space to recreate the EFI System partition of Windows, I do not think you would need to recreate the msr partition as it is likely this one: /dev/nvme0n1p2.
Do not touch the /dev/nvme0n1p1, it seems to be the EFI one used by Fedora.
With this you should be able to access your Windows system by selecting it from Boot options of the menu (i.e. F10, F7, Delete, the one used by your system) then you can follow the instructions provided by John to fix the Grub

In my opinion, this is a terrible suggestion.

If you are going to use drastic Microsoft tools to recreate its whole EFI partition (which I think is likely a bad idea), you should first delete Fedora’s EFI partition, then after doing so you would repair the Fedora contents within the Windows EFI. That is messy and difficult, but the above suggestion creating a second EFI occupying an unusual position in the GPT (which confuses some BIOSs) and contending against another EFI partition (confusing most BIOSs) is just as difficult and much messier.

I think my suggestion above is much easier and produces a safer and cleaner result than anything using Windows recovery tools. But if you insist on using Windows recovery tools, try to do so correctly.

1 Like

Hi John,
Thanks for sharing your thoughts, in my case when installing Fedora 39 as dual boot with an existing Windows system I ended up with two EFI partitions, if you check in my previous post here that is what happened in my case and differs from the one shared by Jeff here, it would be great to know the specific steps OP performed, in my case I basically allowed Fedora to decide what to do with the “Storage Automatic” option.
I would not mess with the working EFI partition of Fedora, OP is free to try with your suggestion and it would be great to see the outcome of that.

In the other hand, I do not consider those Windows tools that drastic considering most likely their EFI is created in the first place with their tools.
Here is the output of fdisk -l in my disk:

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     206847    204800   100M EFI System
/dev/nvme0n1p2    206848     468991    262144   128M Microsoft reserved
/dev/nvme0n1p3    468992  586993663 586524672 279.7G Microsoft basic data
/dev/nvme0n1p4 586993664  588222463   1228800   600M EFI System
/dev/nvme0n1p5 588222464  590319615   2097152     1G Linux filesystem
/dev/nvme0n1p6 590319616  996593663 406274048 193.7G Linux filesystem
/dev/nvme0n1p7 996593664 1000214527   3620864   1.7G Windows recovery environment

Here a screenshot from GParted:

I know the order is not ideal but it is working good so far.