![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
29.12.2019 23:52, Bjoern Voigt пишет:
The last snapshot 20191228 again updated Grub2.
My problem is, that the %posttrans script 'grub2-i386-pc-2.04-3.2.noarch.rpm' fails.
/usr/sbin/grub2-install --target=x86_64-efi Installing for x86_64-efi platform. Could not prepare Boot variable: No space left on device
efibootmgr is just the messenger here. It reports what kernel returns.
/usr/sbin/grub2-install: error: efibootmgr failed to register the boot entry: Input/output error.
Many users from different distributions had this problem too. The error message "No space left on device" is misleading.
Really?
The real problem is, that there is a problem with the UEFI variables.
Show your debugging results - you must have debugged it before jumping to this conclusion, no?
Some users suggest to remove "dump" variables, but I have no such variable.
# ls /sys/firmware/efi/efivars/ | grep dump # ls /sys/firmware/efi/efivars/ | wc -l 85 (source https://unix.stackexchange.com/questions/379774/grub-installation-failed)
My work-around was to copy the new Grub2 EFI boot code. My PC boots with this change.
Of course it does, call to efibootmgr is needed just once; after that it is enough to copy new binary. ...
My UEFI (Intel DH55TC mainboard, TCIBX10H.86A.0048.2011.1206.1342 from 12/06/2011, no updates available) is old and buggy. But what else could I try?
If you fully debugged this problem on your firmware and are absolutely sure the problem is not insufficient space, you can boot with efi_no_storage_paranoia. But be sure to read comments and actually understand why this option was added in the first place: * Some firmware implementations refuse to boot if there's insufficient space * in the variable store. Ensure that we never use more than a safe limit. https://mjg59.dreamwidth.org/22855.html
My fear is, that one of the next Grub2 or Windows 10 updates will break the boot process.
On my Dell Latitude E5450 efiboomgr (run as part of grub-install) only succeeds immediately after boot. If run after system was up for some time it fails (with different error, I was not able to track origin of this error). So this is another option you can try - run grub update immediately after reboot. Firmware may do some housekeeping in this case. I still believe that running efibootmgr every time is wrong - the less we touch firmware variable store the better. grub-install should check whether definition already exists and skip call to efibootmr it nothing is changed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org