I have been dual booting Linux mint 19 and Windows 10 on my laptop for 3 years with no problem. Today, I ran an apt-get upgrade command on Linux, and had grub, os prober etc. authentication errors. Purging grub/* and reinstalling grub-efi fixed the package upgrade problem. However, after booting into Windows, I cannot boot into Linux again (grub screen does not appear, laptop boots into Windows directly)

  1. Following several forum suggestions, I ran

    bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi

with admin privileges from Windows cmd. Now, restarting the laptop gives "Selected boot image not authenticated" error.

  1. I turned on legacy boot from the BIOS. This made ubuntu back up (with no grub screen). From the ubuntu terminal, I ran sudo update-grub The terminal display showed that grub was able to find the Windows Boot Manager image. This time, I rebooted, the grub screen was shown, but there was no Windows option on it.

  2. I booted into ubuntu and ran boot-repair with option "Backup and rename Windows EFI files" on. After all the changes are applied, the Windows option appeared on the grub screen, but pressing enter on it just brings me back to the grub screen. Opting F11 from BIOS (system recovery) also brings me back to grub. I haven't found another post with the same problem here. This step was also all under legacy mode. Turning off legacy mode gives image authentication error and nothing can be booted still. The paste bin is here: http://paste.ubuntu.com/p/96jHFRfYBF

Any suggestion would be greatly appreciated. I would do anything to recover my Windows system at the moment (including purging the Linux Mint system, since my Linux filesystem is more organized and I was able to back everything up during step 2).

1 Answer 1


However, after booting into Windows, I cannot boot into Linux again (grub screen does not appear, laptop boots into Windows directly)

This is most likely Windows 10 detecting that its UEFI NVRAM boot entry has been tampered with, and "self-healing" it with no regard to other OSs that might exist on the system. That is something Windows 10 will do, and as far as I know, there is no way around it.

The current state of the UEFI NVRAM boot entries can be viewed in the Boot-Repair output in your pastebin:

===================================== UEFI =====================================

BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.
SecureBoot disabled.

efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0000,0001,0003,9999
Boot0000* Windows Boot Manager  HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)/File(\EFI\ubuntu\grubx64.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.}...a................
Boot0001* ubuntu    HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)/File(\EFI\ubuntu\grubx64.efi)
Boot0003* Internal Hard Disk    PciRoot(0x0)/Pci(0x17,0x0)/Sata(2,32768,0)/HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)..BO
Boot9999* USB Drive (UEFI)  PciRoot(0x0)/Pci(0x1d,0x0)/USB(16,0)..BO

Note that the Boot0000 entry is currently the first in the BootOrder, and while its human-readable name is "Windows Boot Manager", the actual boot file it executes has been changed to \EFI\ubuntu\grubx64.efi.

This is probably caused by your bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi, as this is literally what the command tells Windows to do.

Since Windows 10 will automatically change this back to its standard \EFI\Microsoft\boot\bootmgfw.efi as soon as it boots, and the Boot0000 entry is specified to be the first in the BootOrder, Windows' "self-healing" will effectively make the system boot directly into Windows as soon as you get into Windows.

What you can do is changing the boot order so that the boot entry for Ubuntu (Boot0001) will be the first instead. This is something Windows doesn't seem to be inclined to tamper with, as long as the Boot0000 entry is left unmodified. You could do this in several ways:

a.) Access the BIOS boot order settings, and move the entry that is (hopefully) labeled ubuntu as the first in the boot order.

b.) In Windows elevated command prompt, run bcdedit /enum FIRMWARE, find the boot entry with a description set to ubuntu and note its identifier: it will be a long UUID string in curly brackets. Then run bcdedit /set {fwbootmgr} DEFAULT {UUID of the ubuntu entry}. Note: it is important to use {fwbootmgr} instead of {bootmgr} here.

c.) in Linux, you could redefine the boot order with:

sudo efibootmgr --bootorder 0001,0000,0003,9999

This should place the ubuntu entry first in the boot order, then Windows Boot Manager, then the other existing entries in the same order they currently are.

But please read on...

Your pastebin also indicates Boot-Repair successfully did this:

mv /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi /boot/efi/EFI/Microsoft/Boot/bkpbootmgfw.efi
cp /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

In other words, it moved the Windows bootmgfw.efi aside, and replaced it with a copy of UEFI GRUB. This is sometimes necessary to work around UEFI firmware bugs, but since your system previously worked, this probably wasn't necessary in your case. You'll need to undo this. In Mint, just sudo cp /boot/efi/EFI/Microsoft/Boot/bkpbootmgfw.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi should do it.

Alternatively, if you get into Windows, it will probably replace the bootmgfw.efi with Windows version immediately and without even telling you, in the name of "self-healing".

It appears your BIOS settings are lying to you: the "legacy mode" seems to be more like "either MBR or UEFI, but apparently UEFI is preferred".

Turning off legacy mode gives image authentication error

That would suggest "turning off legacy mode" will also automatically enable Secure Boot.

Since Windows bootmgfw.efi has now been replaced with a copy of grubx64.efi and it's being loaded directly by the firmware without shimx64.efi, it would be expected to fail the Secure Boot checks... and "image authentication error" would seem to be just that.

So, to make your ubuntu boot entry use the shimx64.efi for Secure Boot compliance, you would need sudo efibootmgr -b 0001 -l \\EFI\\ubuntu\\shimx64.efi. If Secure Boot is not in use, shimx64.efi will just directly run grubx64.efi in the same directory it's in, so this should not be harmful even if Secure Boot is not in effect.

Doing this on the Windows side is a bit trickier: again, use bcdedit /enum FIRMWARE, identify the UUID of the ubuntu entry, and use:

bcdedit /set {UUID of the ubuntu entry} path \EFI\ubuntu\shimx64.efi
  • Thanks for the tips and the detailed explanations! I'll go back to the post that originally suggested manually reinstalling grub to fix the package upgrade problem and make a note that this may trigger Windows "self-healing" on a dual-booted system. I guess the correct way in the first place is doing update-grub or running boot-repair (something that will look at UEFI settings)? Jul 13, 2021 at 20:58
  • Undoing the bootmgfw.efi backup successfully fixed the dual boot without Secure Boot!(Thanks again) I attempted to change the load path as suggested in the last part of your answer. This all makes sense based on the documentations. However, it appears that neither efibootmgr -b nor bcdedit are doing the job. (I checked using efibootmgr -v and bcdedit /enum FIRMWARE, and the load path is still set to \EFI\ubuntu\shimx64.efi after the respective operations). Do you have any guess why this could happen? Jul 13, 2021 at 21:02
  • That might have something to do with the Error: NVram is locked messages in your pastebin. If your system firmware chooses to block run-time write access to NVRAM boot settings for some reason, that could complicate all types of changes to UEFI boot settings. As a wild guess, maybe it has something to do with whether or not your BIOS settings are password-protected?
    – telcoM
    Jul 14, 2021 at 6:13

You must log in to answer this question.

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