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?:

-rwx------ 1 root root 1334816 Sep 13 09:39 bootx64.efi
-rwx------ 1 root root 1213032 Sep 13 09:39 fbx64.efi

-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
  • Here's another wrinkle. That BOOTX64.CSV file names shimx64.efi as the 'boot entry for ubuntu': shimx64.efi,ubuntu,,This is the boot entry for ubuntu And I verified that Boot/bootx64.efi is the same file as ubuntu/shimx64. Again, I don't have secure boot enabled, and shouldn't be using the shim bootloader - but ubuntu has set it up as my default anyway. It didn't do that on initial install - only on whatever grub update happened on September 13. – littlenoodles Oct 1 '18 at 13:20
  • I just got another update to grub2 today (Oct 11, 2018), and it once again installed shimx64.efi as my default bootloader. I verified this prior to booting this time, so i was able to patch the BOOTX64.CSV file before it caused any problems. But this seems to be a ubuntu bug. Wonder why it's not affecting more people. – littlenoodles Oct 11 '18 at 13:54

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.


| improve this answer | |

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.

| improve this answer | |
  • I don't know. Boot-repair seems to address MBR booting, and my system uses EFI. Grub on my system works - it's just that there are a bunch of EFI bootloaders present, and the wrong one runs by default when i make 'ubuntu' first in my BIOS's boot order. For now, I'm just using refind, which let's me choose the working grub64.efi loader. It's just annoying to have to do that when the 'ubuntu' loader used to work. I was hoping someone could tell me if it's safe to copy the 'good' bootloader to the 'default' location - and comment on why a grub update would've changed my boot setup at all. – littlenoodles Oct 1 '18 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.