On Fri, 14 Dec 2018 10:22:49 +0100 Ralf Jung <p...@ralfj.de> wrote: > Hi, > > > Fixing this does seem like it would be a good idea for general > > robustness against dodgy firmware (this is not the first iteration of > > problems along these lines). It would take some development work, but > > hopefully not too much. > > > > Things that GRUB can't do, as far as I can tell: > > > > * I don't think there's a way for GRUB to check whether it will be > > possible to recreate a boot entry later; as I understand it, that > > depends on various low-level details, including firmware-specific > > quirks. > > > > * Even detecting that nothing changed would require cooperation from > > efibootmgr, since the encoding of the EFI variable is an > > implementation detail there (so we can't just read it out and > > compare), and efibootmgr doesn't expose a way for GRUB to say "set > > this configuration, but only if it's different from what's already > > there". > > > > However, I think GRUB can at least manage to delete all but one entry > > from the same distributor rather than all of them, and if it finds one > > remaining entry then it can modify that rather than writing a brand new > > variable. As I understand it, that would probably be enough to fix this > > bug? > > Assuming that modification works even when the variable storage is (close to) > full, then yes, that would at least keep the device bootable which would be a > big improvement. > > Kind regards, > Ralf > >
Hi Colin, Thanks for proposing this solution. :) I also think it would be a good solution for now that will hopefully avoid most of these errors. :) Thanks, ~Niels
