grub loaders in /boot/efi/EFI can't boot windows, /boot/efi/EFI/ubuntu/grubx64.efi can, grub installs the one that can't

Question

I'm running ubuntu 18.04 (kubuntu, but who's counting) on a dual-boot system. Its grub menu was always able to boot windows 7, but suddenly, the windows entry in grub no longer works. When I select windows from the grub menu, the screen goes black and nothing happens. I can still boot windows directly from my system's boot menu if I'm quick enough on the trigger to bring that up. But something has happened to my grub setup.

I tried running 'sudo update-grub', which seemed to rerun the probe successfully, but the behavior is the same.

I don't have Secure boot enabled (don't even see it as an option in my BIOS), and I've made sure to shutdown Windows 7 completely (no hibernation or sleep mode).

More info:

I also have the refind boot manager installed on this machine, and if I switch that to be first in the boot order, it's able to boot windows 7 or grub. But the Refind menu shows multiple entries for ubuntu, and the first one it shows launches EFI/Boot/fbx64.efi and the second one launches EFI/Boot/bootx64.efi. Neither of those can boot Windows. In fact, when I select one of them and launch ubuntu from there, it puts ubuntu back into the first position in my BIOS's boot order - and I'm back where I started.

But if I arrow over in Refind to the ubuntu entry for /ubuntu/Boot/grubx64.efi, not only is that one able to boot ubuntu or Windows 7, it also leaves Refind in place at the top of my boot order. So this problem seems to be caused by the new efi modules having been put into /EFI/Boot and having become the default grub loader. I don't know what fbx64 is, but is it supposed to be the primary grub boot loader? If not, how do I get grubx64.efi to be the default? Is it simply a matter of copying the grubx64.efi module into /EFI/Boot? Is that safe - would I need to rename it bootx64.efi to match what's there?

Here's what's in my /boot/efi (all the ubuntu stuff seems to be dated Sep 13 09:39 - presumably the last time ubuntu updated grub). Bootx64 matches shimx64 in size - I don't need the shim bootloader. Could the ubuntu update have mistakenly copied that there?:

/boot/efi/EFI/Boot
-rwx------ 1 root root 1334816 Sep 13 09:39 bootx64.efi
-rwx------ 1 root root 1213032 Sep 13 09:39 fbx64.efi

/boot/efi/EFI/ubuntu
-rwx------ 1 root root     108 Sep 13 09:39 BOOTX64.CSV
drwx------ 2 root root    1024 Jan 30  2017 fw
-rwx------ 1 root root   71400 May 22 10:48 fwupx64.efi
-rwx------ 1 root root     126 Sep 13 09:39 grub.cfg
-rwx------ 1 root root 1116024 Sep 13 09:39 grubx64.efi
-rwx------ 1 root root 1269496 Sep 13 09:39 mmx64.efi
-rwx------ 1 root root 1334816 Sep 13 09:39 shimx64.efi

Answer 1

Found the answer (or at least an explanation of what's happening). BOOTX64.CSV is used by the 'fallback' EFI loader, when the EFI VRAM entry has been corrupted. And the fallback loader re-points the EFI VRAM entry to whatever the CSV file names as the default loader - in my case shimx64.efi. That's why whenever I let the EFI system run the bogus 'ubuntu' shim entry, it reinstalls itself at the head of the list.

I don't know how my VRAM got corrupted to use the fallback, but that's why it persists when I attempt to fix it. The link below describes this process, in case you're interested.

http://www.rodsbooks.com/efi-bootloaders/fallback.html

Answer 2

I've dealt with problems like this before. What I've always had to do is boot from a Ubuntu Live USB, install a package called Boot-Repair (or something like that, my memory sucks), and use that to essentially "refresh" the list of things GRUB sees.

More on the Boot-Repair package: https://help.ubuntu.com/community/Boot-Repair (Note that because it does stuff to the boot loader, you need to be root in order to install and run this program.)

Make sure you read the above web page entirely, as it will explain the process significantly better than I can. Please let me know if this helps.