Bug#923839: shim-signed: setup of shim-signed failed with 'Could not delete variable: No space left on device'

[Colin Watson]

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                                       [cjwatson at debian.org]