Dear Maintainer,

Today I attempted to upgrade several security and non-security updates
(must have been a point release) as usual. This system is not new, but was
installed in September 2021 (huh, a year ago), and has rebooted fine ...
probably not every week, but every month or so?

This system was installed using mini.iso and telling it to encrypt the
disk. This is all done the traditional way, with an unencrypted separate
/boot partition (which debian-installer stupidly hard-codes to a tiny size
so blocks kernel upgrades occasionally unless you aggressively prune them),
and I've always done this in the past and never had any troubles
before. I also had no problem with grub-pc 2.04-20 which ... hm, looking at
dpkg.log that was the original version I first installed with?

My desktop, which does not use an encrypted disk, accepted the grub-pc
upgrade without error. (for that matter, why is grub getting upgraded at
all on stable? It didn't come through the security ...)

I can't even quit out of aptitude right now? It just keeps prompting in
a loop ...

Based on that prompt I just read from reportbug, it said grub shouldn't
ever be trying to reinstall itself at all??? But it clearly is, and is
failing.

If I manage to hit ^S in the brief moments between fullscreen prompts, the
last messages were:

Then this repeats starting with "Installing for" in an infinite loop if the
default/sane options are chosen in the menus.

The popup screen says:

It sounds like the safe answer is "No" but that's what leads to the
infinite loop. The next screen (with no choice) is:

And then (clearly /dev/sda is the only possible option here):

(not shown: sda2 is the MBR extended partition, and sda5 is the logical
partition just inside it, containing the encrypted LVM container thing. The
installer, as always, is dumb and permanently calls it "sdb5", but this is
just a harmless name. /dev/dm-2 is swap, and is (like dm-1) part of dm-0.
Most of this is in the automatic data dump below, but it seems like
encryption-related setup stuff is not dumped directly)

One oddity I noticed is that if I run `cfdisk /dev/sda` (but not `fdisk` or
`sfdisk`), it gives a strange warning:

I have no idea why it thinks my hard drive has an iso9660 signature on it,
but this is the closest thing I can imagine to why GRUB thinks it has
"multiple partition labels".

This hints that the root bug might actually be in some library becoming
overaggressive in its autodetection (isn't ISO9660 is a terribly sloppy
standard like TGA?). But GRUB is the only program I've seen that *exhibits*
the bug.

My *guesses* for how to allow `aptitude` to continue would be either:

* use `cfdisk` and issue a write without changing anything, in hopes that
  whatever it thinks is an ISO9660 label will get wiped out and not lose
  anything important.
* answer "yes" and hope that means my previously-working system gets left
  unchanged.

With this bug, I have officially had more boot problems with Debian stable
than I have on testing/sid machines. (though still nowhere near as much as
trying to make EFI work for install in the first place).

Thanks,
- Ben