Bug#966575: grub-pc: Bailing out if the boot device from the debconf database does not longer exist might produce a more complicated issue

[Colin Watson]

On Thu, Feb 11, 2021 at 09:34:31PM +0100, Daniel Leidert wrote:
> I recently stumbled into this issue myself. Reading your explanation was very
> helpful. However the way you fixed it produces another issue as described here:
> 
> https://forum.openmediavault.org/index.php?thread/37903-grub-related-error-on-5-5-23-update/
> 
> The command suggested by the error message (dpkg-reconfigure) actually doesn't
> work if grub-pc is not fully installed.

Hm, it's true that's not entirely ideal, sorry.  I think I'd probably
meant to recommend an interactive run of "dpkg --configure grub-pc", but
I'll need to think about how to present that best.  Your reply on that
thread seems slightly overkill - there should be no reason to drop to
low priority, since the relevant questions are asked at critical.

> I don't have a technical solution myself, but bailing out creates an
> even worse situation here.

For context: every single time the GRUB core <-> modules ABI has changed
in the last ten years or so, we've had multiple critical bugs filed due
to unbootable systems as a result of incorrect configuration causing the
boot loader to be only half-upgraded.  I entirely disagree that a failed
upgrade, even on many systems, is a worse situation than that.

> Maybe instead of bailing out print a warning instead?

I simply don't think that enough people are going to see a warning in
the middle of what's often thousands of lines of dpkg output to make any
kind of difference.  The postinst already only bails out if it can't
prompt you interactively to fix the problem, and people are even less
likely to notice warnings printed in the middle of a *noninteractive*
upgrade.  They'll just find out about it when they reboot and their
system doesn't come up, which is worse.

It's also worth noting that bailing out here has apparently prompted
some bit of FAI config to be found and fixed, which has probably been
the partial cause of quite a few of those bugs.  The problem with this
whole situation is that I've always known that a large part of the fix
would have to be in installer-type code somewhere, but could never track
down where the bugs were because they were on other people's systems and
often years distant in time; that's been apparently intractable and very
frustrating.  Maybe it's just luck, but in those terms this has already
been one of the most successful interventions I've found so far.

> I was also thinking: If this cannot be handled in a technical way this should
> definitely be mentioned in the release notes.

I'm not opposed to some kind of mention in the release notes, I suppose,
but it feels like more of a general operations manual sort of thing (for
example, it might happen on the next upgrade after a subtly-botched disk
swap), and I'm not sure where would be best.  This isn't particularly
specific to any one Debian release.

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