[opensuse-factory] Grub2 error during grub2 update
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 /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. The real problem is, that there is a problem with the UEFI variables. 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. # efibootmgr -v Timeout: 1 seconds BootOrder: 0002,0000,0001,0004,0007,0008 Boot0000* CD/DVD Drive BBS(CDROM,,0x0) Boot0001* Hard Drive BBS(HD,,0x0) Boot0002* Windows Boot Manager HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...I_............... Boot0004* UEFI: Samsung SSD 840 EVO 250GB PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) Boot0005 CD/DVD Drive BBS(CDROM,,0x0)P2: HL-DT-ST DVDRAM GH22NS50 . Boot0007* Windows Boot Manager HD(2,GPT,60cdbfb7-e8c8-4820-aeb3-1dc2f9572921,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...d................ Boot0008* UEFI: Samsung SSD 840 EVO 250GB PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) Boot0009 Hard Drive BBS(HD,,0x0)P0: Samsung SSD 840 EVO 250GB . 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? My fear is, that one of the next Grub2 or Windows 10 updates will break the boot process. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
Andrei Borzenkov wrote:
/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? No, I have no idea how to debug firmware issues. My conclusion is based on Internet discussions about this error.
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 I will probably not try the Kernel parameter efi_no_storage_paranoia. But I wonder if I can delete some unused EFI variables. The problem is Windows here. I know the openSUSE command to create the boot entries with efibootmgr, but I do not know the correct Windows 10 commands. Windows 10 is installed on a 3 TB WD Red harddisk (/dev/sdb), but only the SSD on /dev/sda is bootable, because /dev/sdb is connected with to a PCIe extension card. In the past I had some trouble with this setup.
Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
02.01.2020 21:07, Bjoern Voigt пишет:
I will probably not try the Kernel parameter efi_no_storage_paranoia. But I wonder if I can delete some unused EFI variables. The problem is
Sure you can. The problem is this does not guarantee you get more space immediately. Firmware may wait until the last moment before doing garbage collection; actually kernel attempts to trigger such garbage collection so if it fails it probably means your firmware does not do it. Or firmware may do garbage collection only on reboot.
Windows here. I know the openSUSE command to create the boot entries with efibootmgr, but I do not know the correct Windows 10 commands.
Assuming your ESP is not destroyed, the following should be enough Bcdedit /set {fwbootmgr} displayorder {bootmgr} /addfirst Or you can run boot repair from Windows install medium.
Windows 10 is installed on a 3 TB WD Red harddisk (/dev/sdb), but only the SSD on /dev/sda is bootable, because /dev/sdb is connected with to a PCIe extension card. In the past I had some trouble with this setup.
Greetings, Björn
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
Bjoern Voigt