1

I recently installed Ubuntu 16.04 into my LG gram 17 laptop alongside with Windows 10.

It worked well until i decided to change the boot priority - instead of going to windows default, going to ubuntu default directly.

Then ubuntu boot manager is gone as well as window boot manager, and the screen says

Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found 

I keep using boot-repair. but it is just only a temporary fix the problem and then both boot manager are gone very soon.

Here is my BOOT-INFO SUMMARY

MiJyn
  • 3,336
  • the correct location is /EFI/ubuntu/grubx64.efi. the system default is /EFI/BOOT/bootx64.efi. rename a copy of grubx64.efi to bootx64.efi and put it in /EFI/BOOT/ – ravery Jun 29 '17 at 16:26
  • Ubuntu entry in UEFI is now missing. Re-installing grub using Boot-Repair will re-add it. Or you can use efibootmgr to add an entry. Boot-Repair may have copied shimx64.efi to bootx64.efi as ravery above suggests since you have bkpbootx64.efi which normally is only the Boot-Repair backup of the original bootx64.efi. But not sure if any of UEFI boot entries boot that hard drive or fallback entry. See also: http://askubuntu.com/questions/486752/dual-boot-win-8-ubuntu-loads-only-win/486789#486789 – oldfred Jun 29 '17 at 16:46
  • The Boot Repair output indicates that the EFI/BOOT/bootx64.efi file does exist; but that output does not indicate whether or not that's the correct file. In any event, since the file exists, the Not Found message indicates likely filesystem damage or filesystem driver incompatibility (between Linux and the EFI), not an actual missing file. – Rod Smith Jun 30 '17 at 13:34

1 Answers1

1

The files that the message claims are missing are present, according to the Boot Repair output. This type of inconsistency can result from use of FAT16 or an undersized FAT32 on some computers with not-so-great FAT filesystem drivers. Most such EFIs are fairly old (from 2012 or before, at a guess). More often, though, the cause is a failure to disable Fast Startup and Hibernate in Windows. When active, these Windows features cause filesystem damage on shared partitions, including the EFI System Partition (ESP), where boot loaders reside. Disabling these features (as described in the preceding links) and rebooting to Windows a couple of times may fix the problem. Note that the Windows Fast Startup feature is not the same as a feature with a similar name in many EFIs; the EFI feature takes shortcuts on hardware initialization but does not affect how Windows handles its shutdown operations (which is what Fast Startup and Hibernate do; they turn shutdown operations into suspend-to-disk operations, which speeds up the boot process at the cost of making dual-boot configurations much riskier).

If the problem persists, then you may need to take more radical corrective measures. As a first step, I recommend you back up the ESP (/dev/sda2 in your case). You can do this in Windows or in Ubuntu, but I describe only the Ubuntu procedures, because I'm more familiar with them and I want to minimize clutter in this answer. You can boot to Ubuntu by either using my rEFInd boot manager on a USB flash drive or CD-R to boot your existing installation or boot the Ubuntu installer in its "try before installing" mode. In the former case, the ESP should be mounted at /boot/efi; in the latter, you'll need to mount the ESP manually. However you do this, a file-level backup (using cp, zip, tar, or similar file-level tools) should be adequate -- but be sure the files noted in your boot failure are backed up.

With the backup in place, the first-level repair attempt is to do a filesystem check and repair. You'd do this with dosfsck in Ubuntu. The filesystem must be unmounted and you must pass the -a option, as in sudo dosfsck -a /dev/sda2. This should fix the problem, but in rare cases it may do further damage, which would necessitate going further; and if it doesn't work, you may need to go further, too....

If a filesystem repair doesn't work, then the next thing to try is to create a new filesystem and restore the backups to it. In Ubuntu, the partition must be unmounted, and you'd use sudo mkdosfs -F32 /dev/sda2 to create a filesystem. (Be very careful with this command; if you specify the wrong device filename, you could wipe out your Windows or Ubuntu installation!) Once the filesystem is re-created, you'd then restore the backup you created earlier. Note that if you do this and it works, you should edit /etc/fstab in Ubuntu: Locate the /boot/efi line and change the UUID= value for the new filesystem. (You can discover this value by typing sudo blkid /dev/sda2.) If you don't make this change, the ESP won't be automatically mounted, which means that future updates to GRUB may not be installed.

Using Boot Repair, as oldfred suggested, is another approach; but if you do this without first disabling the Windows Fast Startup and Hibernate features, the problem may recur. Worse, any attempt to write to the ESP from Ubuntu before those features are disabled could result in further filesystem corruption, which could cause even worse problems (maybe nothing will boot, for instance). If the filesystem already has serious problems, using Boot Repair might make matters worse. Thus, no approach to fixing the problem is entirely risk-free and easy. IMHO, it's probably best to start with disabling Fast Startup and Hibernate (that part is relatively safe) and doing a filesystem check (also relatively safe). If that's not enough, you'll have to decide which risks to take -- backing up and re-creating the ESP or using Boot Repair. Having a backup of your user files is a good idea; although the chances of damaging them are pretty slim, the consequences if you do would obviously be devastating.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105