Bug#966575: same error message here

[Colin Watson]

Control: severity -1 important

On Fri, Jul 31, 2020 at 10:39:22PM +0200, cacatoes at tuxfamily.org wrote:
> Don't know if it's useful but contributing infos I collected on this,
> since I ran into the same error message on a Lenovo Thinkpad T510
> running Debian Stable.

For anyone affected by this bug, the workaround is to run
"dpkg-reconfigure grub-pc" as root and follow the instructions in the
"GRUB install devices" question.  If your system has already failed to
boot, you can use a rescue image of some kind to get back in: for
example, the Debian installer's rescue mode should be suitable.


This is a long-standing problem: we get a scattering of reports of the
same general kind with every GRUB upgrade that changes the binary
interface between GRUB's core image and modules in some way, although
the exact details depend on the upgrade in question.  The situation
certainly needs to be improved.

However, the problem is not with the actual changes made in this version
of GRUB.  Rather, it's a latent configuration problem on your system
(and on the systems of other people affected by this) that is triggered
by the act of making *any* change to GRUB that causes new modules in
/boot/grub not to be compatible with old core images in the boot sector
that your firmware jumps to when booting your machine.  This problem
happens on systems that are configured to run grub-install to a target
device that is not actually the one that your firmware uses to boot your
computer.

This configuration error is normally the result of something like
changing disks around without telling the GRUB packaging about it, so it
continues to install to an old device without realising it isn't the one
that your firmware is configured to boot from any more.  Sometimes it's
the result of a bug in some kind of installation or cloning process
instead.  Unfortunately it is rarely possible to tell exactly what
caused it from any information that still exists on the systems in
question; sometimes the affected users have an idea what might have
happened and sometimes they don't.  The packaging tries to detect some
problems along these lines - I did considerable work on this way back in
2010 to try to improve the situation - and the volume of reports of this
kind is much lower than it used to be as a result, but it still happens
sometimes.

I'm going to downgrade this to non-release-critical.  It is absolutely a
problem that we need to deal with (somehow ... it may be that in some
cases we need to refuse to continue the upgrade instead, which would be
a different kind of bug that would tend to be filed as release-critical
too!), but given that it's a latent problem that would have been exposed
by any change of a similar magnitude, I don't think it makes sense for
it to block migration of this new version to testing.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]