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
