Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Based on the efibootmgr output in the pastebin link, I think this is a bug. Not user error. It might actually be more than one bug, and there might be NVRAM corruption confusing the firmware (which can act like a multi-layered bug). And it's possible it has already been fixed due to the update :-) I know that's confusing. From the pastebin, check out line 11 and line 12. Line 11 is boot entry 0003, which is the currently booted entry. Notice how it's content is totally different than the Fedora line 12 entry, boot entry 0004. And notice how all the superfluous boot entries are like boot entry 0004.

I've seen this behavior before where buggy firmware doesn't see or honor BootOrder, therefore can't find a bootloader, therefore firmware follows EFI/BOOT/BOOTX64.EFI - that is actually shim.efi which works with fallback.efi to get Fedora to boot even when there are no Fedora boot entries in NVRAM. And when this fallback is used, it adds an NVRAM boot entry for Fedora. And the bug, is that the firmware still doesn't see these added entries (yes we see them, but it doesn't), so BOOTX64.EFI keeps being run every time you boot, and you keep getting another entry added, and eventually NVRAM gets full or corrupt, and the firmware then gets really confused.

But then you did a software update and now you have this differently formed Boot0003. The fix for bugs of this sort sometimes happen in shim, or GRUB, or the kernel, or the firmware. So I have no idea what was updated that might explain the Boot0003 format change. But also, Windows won't boot which I think is a side effect of a really cluttered up NVRAM and ensuing confusion. Anyway,

  • What is the first line from dmesg | grep DMI ? That should report make/model and firmware revision for your computer. And then compare that to manufacturer support downloads, and see if they have something newer.
  • What do you get for mokutil --sb-state ? This reports the state of Secure Boot, doesn't change anything.

I think a good next step is to clean out some of these superfluous boot entries in NVRAM. Try doing this:

sudo efibootmgr -b 0,1,2,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12,13,14,15,16,18,19,1A,1B,1C,1D,1E,1F,20,24,25,26,27,28,29,2A,2B,2C,2D -B

That should delete all of them except entries 3 (current Fedora) and 17 (Windows). You can confirm with sudo efibootmgr -v and report back if it's successful or if there are errors.

Next, there is more than one way to try to boot Windows. This should bypass shim+grub and directly load the Windows Boot Manager one time.

sudo efibootmgr --bootnext 17

Now reboot.

OK that's quite a lot of things to try and gather info so I'll stop for now.

Based on the efibootmgr output in the pastebin link, I think this is a bug. Not user error. It might actually be more than one bug, and there might be NVRAM corruption confusing the firmware (which can act like a multi-layered bug). And it's possible it has already been fixed due to the update :-) I know that's confusing. From the pastebin, check out line 11 and line 12. Line 11 is boot entry 0003, Boot0003, which is the currently booted entry. Notice how it's the content is totally different than the Fedora line 12 entry, boot entry 0004. 12, Boot0004. And notice how all the superfluous boot entries are like boot entry 0004. Boot0004.

I've seen this behavior before where buggy firmware doesn't see or honor BootOrder, therefore can't find a bootloader, therefore firmware follows EFI/BOOT/BOOTX64.EFI - that which is actually shim.efi which and works with fallback.efi to get Fedora to boot even when there are no Fedora boot entries found in NVRAM. And when this fallback is used, it adds an NVRAM boot entry for Fedora. And the bug, is that the firmware still doesn't see these added entries (yes we see them, but it doesn't), so BOOTX64.EFI keeps being run every time you boot, and you keep getting another Fedora entry added, is added each time, and eventually NVRAM gets full or corrupt, and the firmware then gets really confused.

But then you did a software update and now you have this differently formed Boot0003. The fix for bugs of this sort sometimes happen in shim, or GRUB, or the kernel, or the firmware. So I have no idea what was updated that might explain the Boot0003 format change. But also, Windows won't boot which I think is a side effect of a really cluttered up NVRAM and ensuing confusion. Anyway,Anyway, I need more information.

  • What is the first line from dmesg | grep DMI ? That should report make/model and firmware revision for your computer. And then compare that to manufacturer support downloads, and see if they have something newer.
  • What do you get for mokutil --sb-state ? This reports the state of Secure Boot, doesn't change anything.

I think a good next step is to clean out some of these superfluous boot entries in NVRAM. Try doing this:

sudo efibootmgr -b 0,1,2,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12,13,14,15,16,18,19,1A,1B,1C,1D,1E,1F,20,24,25,26,27,28,29,2A,2B,2C,2D -B

That should delete all of them except entries 3 (current Fedora) and 17 (Windows). You can confirm with sudo efibootmgr -v and report back if it's successful or if there are errors.

Next, there is more than one way to try to boot Windows. This should bypass shim+grub and directly load the Windows Boot Manager one time.

sudo efibootmgr --bootnext 17

Now reboot.

OK that's quite a lot of things to try and gather info so I'll stop for now.

Based on the efibootmgr output in the pastebin link, I think this is a bug. Not user error. It might actually be more than one bug, and there might be NVRAM corruption confusing the firmware (which can act like a multi-layered bug). And it's possible it has already been fixed due to the update :-) I know that's confusing. From the pastebin, check out line 11 and line 12. Line 11 is Boot0003, which is the currently booted entry. Notice how the content is totally different differently formatted than the Fedora line 12, Boot0004. And notice how all the superfluous boot entries are like Boot0004.

I've seen this behavior before where buggy firmware doesn't see or honor BootOrder, therefore can't find a bootloader, therefore firmware follows EFI/BOOT/BOOTX64.EFI - which is actually shim.efi and works with fallback.efi to get Fedora to boot even when there are no Fedora boot entries found in NVRAM. And when this fallback is used, it adds an NVRAM boot entry for Fedora. And the bug, is that the firmware still doesn't see these added entries (yes we see them, but it doesn't), so BOOTX64.EFI keeps being run every time you boot, and another Fedora entry is added each time, and eventually NVRAM gets full or corrupt, and the firmware then gets really confused.

But then you did a software update and now you have this differently formed Boot0003. The fix for bugs of this sort sometimes happen in shim, or GRUB, or the kernel, or the firmware. So I have no idea what was updated that might explain the Boot0003 format change. But also, Windows won't boot which I think is a side effect of a really cluttered up NVRAM and ensuing confusion. Anyway, I need more information.

  • What is the first line from dmesg | grep DMI ? That should report make/model and firmware revision for your computer. And then compare that to manufacturer support downloads, and see if they have something newer.
  • What do you get for mokutil --sb-state ? This reports the state of Secure Boot, doesn't change anything.

I think a good next step is to clean out some of these superfluous boot entries in NVRAM. Try doing this:

sudo efibootmgr -b 0,1,2,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12,13,14,15,16,18,19,1A,1B,1C,1D,1E,1F,20,24,25,26,27,28,29,2A,2B,2C,2D -B

That should delete all of them except entries 3 (current Fedora) and 17 (Windows). You can confirm with sudo efibootmgr -v and report back if it's successful or if there are errors.

Next, there is more than one way to try to boot Windows. This should bypass shim+grub and directly load the Windows Boot Manager one time.

sudo efibootmgr --bootnext 17

Now reboot.

OK that's quite a lot of things to try and gather info so I'll stop for now.

Based on the efibootmgr output in the pastebin link, I think this is a bug. Not user error. It might actually be more than one bug, and there might be NVRAM corruption confusing the firmware (which can act like a multi-layered bug). And it's possible it has already been fixed due to the update :-) I know that's confusing. From the pastebin, check out line 11 and line 12. Line 11 is Boot0003, which is the currently booted entry. Notice how the content is differently formatted than line 12, Boot0004. And notice how all the superfluous boot entries are like Boot0004.

I've seen this behavior before where buggy firmware doesn't see or honor BootOrder, therefore can't find a bootloader, therefore firmware follows EFI/BOOT/BOOTX64.EFI - which is actually shim.efi and works with fallback.efi to get Fedora to boot even when there are no Fedora boot entries found in NVRAM. And when this fallback is used, it adds an NVRAM boot entry for Fedora. And the bug, is that the firmware still doesn't see these added entries (yes we see them, but it doesn't), so BOOTX64.EFI keeps being run every time you boot, and another Fedora entry is added each time, and eventually NVRAM gets full or corrupt, and the firmware then gets really confused.

But then you did a software update and now you have this differently formed Boot0003. The fix for bugs of this sort sometimes happen in shim, or GRUB, or the kernel, or the firmware. So I have no idea what was updated that might explain the Boot0003 format change. But also, Windows won't boot which I think is a side effect of a really cluttered up NVRAM and ensuing confusion. Anyway, all of that is a guess, but I need more information.

  • What is the first line from dmesg | grep DMI ? That should report make/model and firmware revision for your computer. And then compare that to manufacturer support downloads, and see if they have something newer.
  • What do you get for mokutil --sb-state ? This reports the state of Secure Boot, doesn't change anything.

I think a good next step is to clean out some of these superfluous boot entries in NVRAM. Try doing this:

sudo efibootmgr -b 0,1,2,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12,13,14,15,16,18,19,1A,1B,1C,1D,1E,1F,20,24,25,26,27,28,29,2A,2B,2C,2D -B

That should delete all of them except entries 3 (current Fedora) and 17 (Windows). You can confirm with sudo efibootmgr -v and report back if it's successful or if there are errors.

Next, there is more than one way to try to boot Windows. This should bypass shim+grub and directly load the Windows Boot Manager one time.

sudo efibootmgr --bootnext 17

Now reboot.

OK that's quite a lot of things to try and gather info so I'll stop for now.