What | Removed | Added |
---|---|---|
Flags | needinfo?(stuart@stella-maris.org.uk) |
Please refrain from UEFI/NVRAM experiments on self-paid hardware, it may well break... (does anybody remember Samsung laptops or intel motherboards?) Looking at the comments above, brings me to the following "remarks": 1. your system apparently has trouble with garbage collection in the NVRAM management. That "no space left on device" in fact refers to NVRAM, which "suffered" one addition of a variable (the refreshed boot entry #0000), followed by one replacement (BootOrder +1), plus one removal (the now obsolete old boot entry #0003) and then another replacement (BootOrder -1) during that grub2-update. Obviously the last step failed. 2. This state persists until after a reset/reboot. UEFI garbage-collection is performed and write operations can succeed again -- unless a buggy firmware and careless OS/apps conspire and leave less free NVRAM available than necessary, in which case all NVRAM write operations fail (even vital ones by UEFI itself). Usually an external programmer and firmware+ documentation unavailable to mere mortals) is needed to revive such a motherboard. (IIRC linux has patches to not touch the last 5% (or was it 10%) of NVRAM for exactly that reason.) 3. I'm convinced that "booting from file" (or via EFI shell) and running that 'efibootmgr -o 0000,0001,0002' from the initial comment would have restored the system, without ever touching TW rescue. 4. Can you tell how much NVRAM is in your system, and how much of that is occupied? Is there anything eating up precious space? I've seen issues like yours only on systems used for heavy testing with lots and lots of boot entries, or back then when that UEFI pstore-backend was active, or on buggy firmware (even from "big players")... 5. If you encounter the same issue again, e.g. after another grub2-update, could you please try remark 3 -- if that would fail, while efibootmgr from TW rescue succeeds... but you actually did not *run* efibootmgr from TW rescue, did you?