Attempts of installing grub2 failed

Question

Recently I got my laptop back from warranty service because the hard disk was fried unexpectedly. It just had Windows 10.

I tried uninstalling the previous distro of Linux I was using before the catastrophe, ElementaryOS, but when I installed it in a dedicated partition the boot menu was missing. After trying many times to fix it, and asking around stackexchange with no success, I gave up and decided to try installing Ubuntu, maybe the way it installed grub worked. Nope, it didn't.

I remember choosing /dev/sda as the installation location for grub when installing Ubuntu from the Live USB, if this information helps.

So once again I tried multiple times to fix this issue to no success.

First I followed this guide but when executing this command grub-install /dev/sda I got an error message saying cannot find EFI directory.

Looking for solutions for this problem led me to this other guide but I got stuck at this point: grub-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sdX because there was an error that said that such directory didn't exist and something else.

Which led me again to this question here in askubuntu. I did as instructed in the answer and everything could be executed with no errors. However, when restarting the laptop the grub menu still wouldn't show up.

Honestly I don't know what else to do. I have been looking everywhere for weeks and asking for help as well, but my problem persists.

What can I do?

Answer 1

If Ubuntu is installed on the computer but you can't boot it because it lacks a boot loader, you must first ascertain whether it's installed to a GPT disk or an MBR disk. The former are generally used in EFI-mode boots and the latter are generally used with BIOS-mode boots, although that linkage is not nearly as strong as it is with Windows. If you've got an MBR disk but want to boot in EFI mode, or a GPT disk and want to boot in BIOS mode, you should re-assess your situation to decide what to do -- proceed with an unusual configuration, change the partition table type, or change the boot loader type.

Assuming you've got (or convert to) a GPT disk and want to install an EFI-mode boot loader, there are many options. The two easiest are:

• GRUB/Boot Repair -- Boot the Ubuntu installer in EFI mode, install the Boot Repair program, and run it. This should set up GRUB correctly on your disk. The biggest caveat is that, although Boot Repair usually works, sometimes it doesn't, and on rare occasion it can actually make matters worse. Of course, since you're unable to boot now, the risk of it getting worse seems pretty remote.
• rEFInd -- You can disable Secure Boot (if it's active), download the USB flash drive or CD-R version of my rEFInd boot manager, and boot from it. rEFInd should enable you to boot Ubuntu. If this works, install the PPA or Debian package version. rEFInd will then become your default boot manager, enabling you to boot without GRUB. This approach is a little more incremental -- the risk at each step is quite low, since you're either not changing the disk or you know that the program is almost certain to work when you make on-disk changes.

If you continue to have problems, or if you don't have a GPT/EFI setup, you should post back with details. The URL provided by Boot Repair will show us details about your system, which may be necessary to give a better answer. Alternatively, you can run Boot Info Script, post the RESULTS.txt file that it generates to a pastebin site, and post the URL to your document here.

---

EDIT:

Your symptoms are consistent with a buggy firmware; some manufacturers are known to release computers with buggy EFIs that "forget" or ignore their boot entries. Your question, though, implies that this all worked fine with your Elementary OS installation. That, in turn, suggests that the firmware's NVRAM entries are damaged in some way, thus preventing new entries from being recorded. This is also a bug, but it might be overcome.

One thing to try is entering your firmware's setup utility and selecting the option to reset all the settings to their default values. Unfortunately, I can't tell you exactly where that option is, since it varies from one firmware to another. (It's even possible that yours won't have such an option.) When this is done, you can try running Boot Repair again or install rEFInd as described above, and with any luck the repair will succeed.

Another thing you might try is the EasyUEFI program in Windows. You can use this to re-order existing entries, delete existing entries, and create new entries. You should be able to create an entry for Ubuntu (\EFI\ubuntu\shimx64.efi -- note the use of Windows-and-EFI-style backslashes as directory separators) and test it. You could also use EasyUEFI to clear out any extra or redundant entries -- but the efibootmgr output in your Boot Repair run makes it look like there's nothing suspicious or redundant to be cleared out. Still, checking with another tool (that is, EasyUEFI) may be worthwhile.