Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found

[S. R. Wright]

On 12/19/2015 09:03 AM, Colin Watson wrote:
> On Fri, Dec 18, 2015 at 09:26:55PM -0600, S. R. Wright wrote:
>>> dpkg -l "grub*" | egrep "^ii"
>> ii  grub-common        2.02~beta2-33 amd64        GRand Unified Bootloader (common files)
>> ii  grub-efi           2.02~beta2-33 amd64        GRand Unified Bootloader, version 2 (dummy package)
>> ii  grub-efi-amd64     2.02~beta2-33 amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
>> ii  grub-efi-amd64-bin 2.02~beta2-33 amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
>> ii  grub2-common       2.02~beta2-33 amd64        GRand Unified Bootloader (common files for version 2)
>>
>> On a system that dual boots Linux and Windows 10, the latest grub-efi gives
>> this error:
>>
>> error: symbol 'grub_efi_find_last_device_path' not found
>>
>> when attempting to boot Windows 10 after an update-grub is performed.  Linux
>> will boot correctly;  however,  an attempt to boot Windows 10 will give this
>> error and say "press any key..." and bring one back to the OS menu.
>>
>> There is a workaround, which is to downgrade back to 2.02~beta2-32, and
>> Windows will boot correctly.
> This clearly indicates that GRUB is incorrectly installed in some way,
> because you could only get a symbol mismatch such as this if the GRUB
> image you're actually booting from doesn't match the modules it tries to
> load from /boot/grub/ at run-time.  I would suggest digging around in
> your EFI System Partition to see if there's a manually-copied version in
> there somewhere.
>
I definitely did not copy anything manually into the EFI System 
Partition;  if a rogue file got into there -- or if something didn't get 
updated there that should have -- it happened via process.  A downgrade 
back to 32 worked fine,  an upgrade to 33 broke down, bothe of these 
performed using dpkg/apt-get.  About all I can say.