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) [cjwat...@debian.org]