Selecting grub entries at boot time results in "error: symbol 'grub_efi_find_last_device_path' not found"

Perhaps similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808366

What is the output of

find /boot/efi -ls | grep x64.efi

output of

find /boot/efi -ls | grep x64.efi

is

 14 1324 -rwxr-xr-x 1 root root 1355736 Nov 2 2014 /boot/efi/EFI/ubuntu/shimx64.efi
    15 120 -rwxr-xr-x 1 root root 119296 Jan 9 13:13 /boot/efi/EFI/ubuntu/grubx64.efi
   350 0 -rwxr-xr-x 1 root root 0 Nov 2 2014 /boot/efi/EFI/Microsoft/Boot/bootx64.efi.grb
   351 120 -rwxr-xr-x 1 root root 119296 Nov 2 2014 /boot/efi/EFI/Microsoft/Boot/bootx64.efi
   358 1580 -rwxr-xr-x 1 root root 1617240 Jun 14 2014 /boot/efi/EFI/Boot/bkpbootx64.efi
   359 120 -rwxr-xr-x 1 root root 119296 Nov 2 2014 /boot/efi/EFI/Boot/bootx64.efi

Following the hints in

http://www.istitutomajorana.it/forum2/Thread-Bug-808366-grub-efi-amd64-error-symbol-grub-efi-find-last-device-path-RISOLTO

i found a solution. The goal is to revert grub to the lastest working version (in my case the version "2.02-beta2-9ubuntu1.6_amd64")

Steps:

1. Download the following files in a separate (newly created) folder

grub2-common_2.02-beta2-9ubuntu1.6_amd64.deb
grub-common_2.02-beta2-9ubuntu1.6_amd64.deb
grub-efi-amd64_2.02-beta2-9ubuntu1.6_amd64.deb
grub-efi-amd64-bin_2.02-beta2-9ubuntu1.6_amd64.deb

2. From that folder install the deb files with the following command:

sudo dpkg -i *.deb

The solution mentioned in the last comment does not explain why grub version 2.02-beta2-9ubuntu1.7_amd64 does not work on my laptop.

Another comment ;-)

Just tried to upgrade to grub "2.02-beta2-9ubuntu1.7" and experienced the same error again

"symbol 'grub_efi_find_last_device_path' not found"

I think there is really an issue with grub 2.02-beta2-9ubuntu1.7.

I suggest you create a bug report.

For the time being you can apt-pin the grub packages to the ....6 version to prevent automatic upgrade to the non-functioning version.

I'm experiencing the same bug, downgrading grub didn't help in mu case...

Just upgraded from Trusty (everything was running fine until then), same bug.
Downgrading to 1.7 has no effect.

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0000* ubuntu HD(1,GPT,45bff093-541a-4b82-8562-4ca1ec7d8ad5,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Windows Boot Manager HD(1,GPT,45bff093-541a-4b82-8562-4ca1ec7d8ad5,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....M...............

$ sudo md5sum /boot/efi/EFI/ubuntu/grubx64.efi
6d0ef432d1373bab954f6ca3d34f070d /boot/efi/EFI/ubuntu/grubx64.efi

$ sudo md5sum /boot/efi/EFI/Boot/bootx64.efi
ba8b6aff0b710de79292039b3ff21d9c /boot/efi/EFI/Boot/bootx64.efi

Although I only need to use Windos from time to time, it's really annoying when you _absolutely_ need it and you can't. Hope this bug will be solved in the 16.04.1 realease. Thanks to the devs ;-)

Hello guys, here is a workaround that worked for me.

For french reading people, this workaround is inspired by
https://doc.ubuntu-fr.org/uefi?redirect=1#installer_ubuntu_en_mode_efi

First, you need to detect which bios entry loads windows
Mine is an AMI Bios (Asus N750 series) set up with AHCI mode and SecureBoot disabled

To find out which entry to use later, you will have to check them one at a time (it should be more or less the same on other bioses)
Go to your Bios Boot menu, select ""Add new boot option"", name it, then go to "Select File System"
Your will see one or more options like "PCI(1F|2)\DevicePath(Type 3, subtype 12)HD(part1,Sig45bfff093 ...)"
Choose one then you will get a hierarchical content of your /boot directory (EFI, Ubuntu, Boot, Windows)
I finally found the right entry under Boot, so the path was \EFI\Boot\bkpbootmgfw.efi

Remember to save bios changes, reboot, then select this option in the bios to bypass the standard boot order (like for booting on CD)
Once this is OK, go back to Ubuntu

sudo cp -R /boot/efi/ ~/EFI_backup/
sudo find /boot/efi/ ~/EFI_backup/ -name "*.efi" -exec md5sum {} \; | sort
# remove any file.efi with the same checksum as /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
sudo cp /boot/efi/EFI/ubuntu/shimx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
sudo nano /etc/kernel/postinst.d/windows
 #! /bin/sh
 set -e
 sed -i -e "s/bootmgfw.efi/bkpbootmgfw.efi/" /usr/lib/os-probes/mounted/efi/20microsoft
 exit 0
sudo chmod ugo+x /etc/kernel/postinst.d/windows
sudo chown root:root /etc/kernel/postinst.d/windows
sudo /etc/kernel/postinst.d/windows
# check that we get the correct value before updating grub
sudo os-prober
sudo update-grub

You should now be able to run windows through the grub boot menu
Hope it helps. Don't forget this is ONLY a workaround

I ran into these exact symptoms recently on a cheap HP laptop that originally had Windows 8 on it. This is one of those machines that keep reverting to putting EFI/Microsoft/Boot/bootmgfw.efi first in the boot order list that is stored in NVRAM on the motherboard. This path is supposed to be the boot loader for Windows but, the only way to get Grub to run without user intervention is to copy either the shimx64.efi or the grubx64.efi from EFI/ubuntu to that name, first renaming the original bootmgfw.efi in case you need it, such as to boot Windows. The "shim" version is necessary if "Secure Boot" is enabled, but I routinely track down and kill Secure Boot whenever possible just because I don't like it. Anyway the problem is that if Grub is updated, most likely it is updated only where it is supposed to be, not where Windows' loader is supposed to be, and you can then end up with an older version of Grub trying to boot a system that is set up to be booted by a newer version of Grub, and strange errors like this one result. The other thing that can go wrong is that a Windows update (like to Windows 10) can update the windows loader (the aforementioned EFI/Microsoft/Boot/bootmgfw.efi) with the result that the machine bypasses Grub and boots straight to Windows. So the cure is basically to rename the current bootmgfw.efi out of the way and copy in the latest version of the shim or grub loader from EFI/ubuntu. As a safety net you should figure out how to get to the "boot any EFI file" interface and boot the real shim or grub manually first. On this machine, hammering ESC in the first seconds of booting, then F9 at the resulting menu, was a way to get there.