I have been dual booting Windows 10 and linux (KDE Neon) on my computer with no problems for a few months. However, today, after booting into linux, then restarting and attempting to select windows, I got this error:

Error: file /efi/microsoft/boot/bootmgfw.efi not found

Unsure how there could be a problem with my windows boot, I went back into linux and updated grub. The effect of this was that grub didn't show up on restart or boot at all.

I then used a live USB to open boot repair, which returned the following:

GPT detected. Please create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag). This can be performed via tools such as Gparted. Then try again. Alternatively, you can retry after activating the [Separate /boot/efi partition:] option.

I'm unsure what this means and at this point worried about breaking anything further. Here's my pastebin: https://paste.ubuntu.com/p/K6qrpzmwZc//

I asked this in the Ubuntu forum and was redirected here, although I'm reasonably sure the linux distro has no effect on this issue.

  • Your disk has a GPT partition, but the GRUB message indicates that your firmware is in legacy (BIOS) mode. This is probably an error, since it is an unusual combination. The mode can be selected in the firmware setup user interface. Commented Apr 21, 2020 at 9:09

1 Answer 1


Even though the Boot-Repair is booted in native UEFI style (as it could show you the efibootmgr -v output), the fix it's suggesting is related to setting up legacy-style boot on a GPT-partitioned disk. That does not seem the right fix for your situation. Be careful!

The error message about /efi/microsoft/boot/bootmgfw.efi not being found suggests that your system was originally using UEFI native boot style. With Windows, using a GPT-partitioned system disk requires UEFI boot style; you cannot mix GPT + legacy boot, like you can with Linux. Applying the suggested fix would make it impossible to select the OS to boot from GRUB; you would have to use firmware settings ("BIOS settings") to switch the boot order and/or preferred boot style to switch between the OSs.

It looks like something may have damaged the EFI System Partition (ESP). It is usually a small FAT32 partition, identified by UUID in the firmware NVRAM settings. In Debian, Ubuntu and related distributions, it is usually mounted to /boot/efi.

When using any boot repair tools, you should be careful to boot them in UEFI mode. When the system is booted in legacy mode, UEFI NVRAM boot settings will not be accessible to the repair tools. In Linux, you can use efibootmgr -v to view the boot settings if the system is in UEFI mode.

According to the efibootmgr -v output from Boot-Repair in pastebin, the partition referred as /dev/sdb2 by Boot-Repair should contain UEFI bootloaders for both OSs (Windows Boot Manager for Windows, and a Secure Boot shim + GRUB for Ubuntu). But something looks strange:

BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0002,0000,0001,0004,0005
Boot0000* Windows Boot Manager  HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIUBUNTUGRUBX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...M................
Boot0001* Windows Boot Manager  HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIMICROSOFTBOOTBOOTMGFW.EFI)..BO
Boot0002* ubuntu    HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFINEONSHIMX64.EFI)
Boot0004* UEFI OS   HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIBOOTBOOTX64.EFI)..BO
Boot0005* UEFI: Imation Classic PMAP    PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)..BO

The Boot0000 entry is labeled as Windows Boot Manager, but refers to \EFI\Ubuntu\grubx64.efi (I'm assuming that the lack of backslashes is an artifact of the use of Pastebin?). The Boot0001 looks basically valid for Windows (again without backslashes), but it is missing the additional BCDOBJECT data that appears in Boot0000. The primary boot entry would be Boot0002, which starts the Secure Boot shim at \EFI\Neon\shimx64.efi, which would subsequently start \EFI\Neon\grubx64.efi.

If the backslashes are actually missing in efibootmgr -v output, something may have incorrectly modified your boot NVRAM settings, or you might have a pretty severe UEFI firmware bug. See if there are firmware updates ("BIOS updates") available for your specific hardware model.

But it looks like both \EFI\Neon and \EFI\Microsoft directories may be missing fron sdb2:

/boot/efi detected in the fstab of sda3: UUID=E46B-39C6  (sdb2)
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bootx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/fbx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/grubx64.efi
Presence of bkp file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi
/usr/share/boot-sav/bs-cmd_terminal.sh: line 194: warning: command substitution: ignored null byte in input

It should have detected /mnt/boot-sav/sdb2/EFI/Neon/shimx64.efi and /mnt/boot-sav/sdb2/EFI/Microsoft/Boot/bootmgfw.efi too, but didn't.

You might try booting from Windows 10 install media and using the "Repair Windows" automatic fix tool, then boot from a live Linux media, chroot into your KDE Neon installation, and then reinstall GRUB and the Secure Boot shim to the ESP (sdb2 as listed by Boot-Repair).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .