Control: reassign 891434 src:grub2 Control: forcemerge 891434 923839 On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote: > But I'm reassigning this bug to grub2, because I think the right answer for > nearly all efibootmgr write failures on update of the bootloader packages is > that grub should not be writing to nvram at all. Rather, in the common case > of a bootloader upgrade, the contents being written to nvram will match what > is already there. By detecting that there are no changes, we save ourselves > a write, which in the exceptional cases sidesteps a write failure, and in > the common case, reduces wear on the nvram which may have limited write > cycles.
This is the same as #891434, which I've been working on recently, and at a high level you and I have reached the same conclusions about what's needed. (I've also been discussing it with Steve McIntyre, again reaching similar conclusions.) The problem that's been delaying this is that efibootmgr doesn't expose the interfaces we need. There's no way to ask it to write a variable only if it's changed, or even (any more) to write a new variable to a test file so that it can be compared with the existing contents in order to determine whether to set the variable. I initially thought that we might be able to ask efibootmgr to delete all but one entry from the same distributor and then to modify that one, but even that doesn't seem to be possible at the moment. And even if we did change efibootmgr to provide something along these lines (it might separately be a good idea to get it to minimise writes, at the very least), (a) it would be difficult to guarantee that we have a new enough version in an upstreamable way, and (b) having to fork efibootmgr several times in a single grub-install operation is annoying anyway. So, I've been working on converting grub-install to use libefivar and libefiboot directly, which are libraries used by modern-ish versions of efibootmgr. In many ways this is much nicer: we can say what we mean about exactly how variables are to be manipulated rather than operating at arm's length via a command-line interface that wasn't designed to offer this sort of fine control. In some ways it's uglier: we have to duplicate more of efibootmgr's logic than I'd like in order to build Boot* variables, such as EDD version detection, and it's possible that it will increase the maintenance burden for the future a bit. But regardless, this is the only approach I can think of that stands any chance of fixing this bug in the medium term, so it's what we've got. I got this almost working at the Cambridge BSP today before I ran out of time (very nearly bricking my own laptop in the process ...). I need to add suitable --debug messages, finish getting it working, ensure that it's only rewriting variables where needed, and generally tidy up the fairly large pile of code involved, so there's still probably at least four hours of work left to do on it, not to mention upstream review. However, I'm reasonably hopeful that I'll have this done for buster. -- Colin Watson [cjwat...@debian.org]