Bug#945001: grub-efi-amd64: GRUB-EFI messes up boot variables

[Colin Watson]

Control: tag -1 moreinfo

Sorry for our long delay in replying to this.

On Mon, Nov 18, 2019 at 10:16:43AM +0100, Heinrich Schuchardt wrote:
> I have multiple disk with different operating systems each with its own
> bootloader.
> 
> Updating GRUB delete all existing UEFI variables BOOTxxxx and put in
> some values that do not make any sense for my system. I had a lot of
> trouble to get my system running again.

If possible, the output of "sudo grub-install --debug" would be the most
helpful thing you could provide here.  I understand if that is difficult
due to the work needed to get back to a working state afterwards, but
it's really what we need to see.

Could you also please provide a dump of /sys/firmware/efi/efivars/ (or
at least all the Boot* entries there) as well the output of "sudo
efibootmgr -v", ideally both before and after running grub-install?
Even if you can't provide grub-install --debug output, a snapshot of
this information may still be helpful.

I notice that you say "BOOTxxxx", rather than "Bootxxxx" as I see on my
system.  Does this match how your variables are named?  If this is a
case-sensitivity issue, that could possibly be interesting.  (However, I
think such firmware would be non-compliant; the latest version of the
UEFI spec that I have to hand specifies "Bootxxxx" and has no indication
that it may be case-insensitive.)

Even so, the only Bootxxxx entries that grub-install might intentionally
delete are second and subsequent entries with the label "debian".
Anything else is definitely unintentional and indicates something quite
odd going on.

> I do not expect GRUB to ever touch my UEFI variables without my explicit
> consent. Please, provide a dialogue.

I don't think this is an expectation we can fulfil given the stated
purpose of the grub-efi-amd64 package, which is to be your system's
active boot loader: it may have to edit the boot order to achieve that.
You can remove grub-efi-amd64 and leave only grub-efi-amd64-bin if you
want to deal with the step of installing GRUB manually.

All the same, what you're seeing would certainly be a bug, just not one
whose cause I can identify without more information.  Adding a dialogue
to work around such a bug is probably not the right answer.

(Release team: the code likely to be responsible for this hasn't
significantly changed since 2.02+dfsg1-14, which predates buster.  Since
I don't yet understand the bug I can't say for sure, but you might wish
to draw the conclusion that this bug probably existed in buster as well
and thus shouldn't block bullseye.)

> Bug report 913916 seems to be related but I am not sure if it is
> reporting the same issue.

That was against 2.02~beta3-5+deb9u1, and I essentially rewrote
grub-install's UEFI boot variable handling in 2.02+dfsg1-14.  It could
probably only be the same issue if it turns out to be a problem in the
efivar userspace library or in the kernel (or I suppose perhaps in the
firmware).

Thanks,

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