Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found
71 views
Skip to first unread message
S. R. Wright
Dec 18, 2015, 10:40:03 PM12/18/15
to
Package: grub-efi-amd64
Version: 2.02~beta2-33
Severity: serious
> 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.
Version: 2.02~beta2-33
Severity: serious
> 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.
Colin Watson
Dec 19, 2015, 10:30:03 AM12/19/15
to
Control: severity -1 important
On Sat, Dec 19, 2015 at 09:11:09AM -0600, S. R. Wright wrote:
> >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.
Well, I'm afraid it's still going to need you to investigate along those
lines, because there's basically only one cause for symbol mismatches
like this and it's an incorrect installation of GRUB, rather than a
fault in the new version per se. Perhaps you could start by providing
the output of "find /boot/efi -ls", as well as all the information you
have on the way your system boots? If you have the terminal transcript
from the last time GRUB was updated (it will probably be in
/var/log/apt/term.log somewhere), then that would also be of some help.
--
Colin Watson [cjwa...@debian.org]
On Sat, Dec 19, 2015 at 09:11:09AM -0600, S. R. Wright wrote:
> On 12/19/2015 09:03 AM, Colin Watson wrote:
> >>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,
> >>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.
> >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.
Well, I'm afraid it's still going to need you to investigate along those
lines, because there's basically only one cause for symbol mismatches
like this and it's an incorrect installation of GRUB, rather than a
fault in the new version per se. Perhaps you could start by providing
the output of "find /boot/efi -ls", as well as all the information you
have on the way your system boots? If you have the terminal transcript
from the last time GRUB was updated (it will probably be in
/var/log/apt/term.log somewhere), then that would also be of some help.
--
Colin Watson [cjwa...@debian.org]
Ian Campbell
Dec 19, 2015, 10:40:02 AM12/19/15
to
On Sat, 2015-12-19 at 09:11 -0600, S. R. Wright wrote:
> 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.
Is it at all possible that you answered yes to the grub-installer/force
> 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.
-efi-extra-removable question during installation (see below[0] for the
text of that option) or since then using the rescue mode?
If so then perhaps you have tripped over
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792247 which caused
this setting not to be correctly propagated into the installed system,
which in turn would lead to that copy of grub not being updated on
package upgrade.
What do:
debconf-get-selections | grep grub
and (needs to be run as root):
debconf-get-selections --installer | grep grub
report? (FYI using reportbug to file bugs automatically includes this
and other useful information).
What files to you have under /boot/efi? In particular anything in
/boot/efi/EFI/boot? Do the timestamps on /boot/efi/EFI/*/* indicate
things are getting updated during upgrade? (It might be easiest to
answer all of those by posting the output of "find /boot/efi -ls")
Ian.
[0]
Template: grub-installer/force-efi-extra-removable
Type: boolean
Default: false
# :sl1:
_Description: Force GRUB installation to the EFI removable media path?
It seems that this computer is configured to boot via EFI, but maybe
that configuration will not work for booting from the hard
drive. Some EFI firmware implementations do not meet the EFI
specification (i.e. they are buggy!) and do not support proper
configuration of boot options from system hard drives.
.
A workaround for this problem is to install an extra copy of the EFI
version of the GRUB boot loader to a fallback location, the
"removable media path". Almost all EFI systems, no matter how buggy,
will boot GRUB that way.
.
Warning: If the installer failed to detect another operating system
that is present on your computer that also depends on this fallback,
installing GRUB there will make that operating system temporarily
unbootable. GRUB can be manually configured later to boot it if
necessary.
Ian Campbell
Dec 19, 2015, 11:10:03 AM12/19/15
to
> [...]
> grub-efi-amd64 grub2/force_efi_extra_removable boolean false
> root@mi6:# debconf-get-selections --installer | grep grub
> [...]
> grub-installer grub-installer/force-efi-extra-removable boolean false
> root@mi6:# find /boot/efi -ls
> [...]
> 193 117 -rwx------ 1 root root 119808 Dec 12 04:48 /boot/efi/EFI/Boot/bootx64.efi
> 226 117 -rwx------ 1 root root 119808 Dec 18 21:28 /boot/efi/EFI/debian/grubx64.efi
> [...]
> 386 117 -rwx------ 1 root root 119808 Dec 12 04:48 /boot/efi/EFI/Boot/bootx64.efi
> 389 117 -rwx------ 1 root root 119808 Dec 19 09:43 /boot/efi/EFI/debian/grubx64.efi
I can't explain how it got there, but I think that this
Boot/bootx64.efi
is what your system is booting from and it doesn't appear to be being
updated.
I expect that the reason this is present at all is that your BIOS is
bug
gy in the way the extra removable option is intended to workaround,
if
it wasn't you could likely convince your BIOS to boot the
debian/grubx64.efi
by playing with efibootmgr etc but I think you best
bet would be to
set grub2/force_efi_extra_removable=true, try (as root):
echo "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | de
bconf-set-selections
and then upgrade or reconfigure the package and it should be updated.
Do you have any idea what might have happened at 04:48 on Dec 12?
Ian.
S. R. Wright
Dec 19, 2015, 11:20:03 AM12/19/15
to
On 12/19/2015 10:04 AM, Ian Campbell wrote:
> On Sat, 2015-12-19 at 09:52 -0600, S. R. Wright wrote:
>> Ian:
>>
>> Attached is the info you suggested, pre- and post-upgrade. Was never
>> prompted to answer any questions or than to continue the upgrade.
> On Sat, 2015-12-19 at 09:52 -0600, S. R. Wright wrote:
>> Ian:
>>
>> Attached is the info you suggested, pre- and post-upgrade. Was never
>> prompted to answer any questions or than to continue the upgrade.
> I can't explain how it got there, but I think that this
> Boot/bootx64.efi is what your system is booting from and it doesn't
> appear to be being updated. I expect that the reason this is present
> at all is that your BIOS is bug gy in the way the extra removable
> option is intended to workaround, if it wasn't you could likely
> convince your BIOS to boot thebconf-set-selections debian/grubx64.efi
> Boot/bootx64.efi is what your system is booting from and it doesn't
> appear to be being updated. I expect that the reason this is present
> at all is that your BIOS is bug gy in the way the extra removable
> option is intended to workaround, if it wasn't you could likely
> by playing with efibootmgr etc but I think you best bet would be to
> set grub2/force_efi_extra_removable=true, try (as root): echo
> "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | de
> bconf-set-selections and then upgrade or reconfigure the package and
> it should be updated. Do you have any idea what might have happened at
> 04:48 on Dec 12? Ian.
Ian, your suggestion appeared to have worked. Ta! As far as what
> set grub2/force_efi_extra_removable=true, try (as root): echo
> "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | de
> bconf-set-selections and then upgrade or reconfigure the package and
> it should be updated. Do you have any idea what might have happened at
> 04:48 on Dec 12? Ian.
happened @ 4.48a on the 12th, I really cannot say as I was asleep.
Thanks again!
-- srw
0 new messages