16

I had a good running installation of Debian Jessie, but then I ran apt-get update && apt-get upgrade && apt-get dist-upgrade.

And then after rebooting, it came directly to the BIOS. I realized that Grub was missing, so I ran a live cd and entered Rescue mode, mounted my root partition, + the boot partition and ran these commands:

Grub finds the linux image:

root@debian:~# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.9.0-3-amd64
Found initrd image: /boot/initrd.img-4.9.0-3-amd64
Found linux image: /boot/vmlinuz-4.9.0-0.bpo.3-amd64
Found initrd image: /boot/initrd.img-4.9.0-0.bpo.3-amd64
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found Ubuntu 16.10 (16.10) on /dev/sdb2
Adding boot menu entry for EFI firmware configuration
done

And then grub-install :

root@debian:~# grub-install /dev/sda
Installing for x86_64-efi platform.
Could not prepare Boot variable: No such file or directory
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.

lsblk :

root@debian:~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 223.6G  0 disk 
├─sda1   8:1    0  92.6G  0 part /
├─sda2   8:2    0 130.4G  0 part 
└─sda3   8:3    0   573M  0 part /boot/efi

Did I do something wrong? Is there too little space on my /boot/efi partition?

root@debian:~# ls -l /boot/efi/EFI/debian/
total 120
-rwx------ 1 root root 121856 Jul 20 20:29 grubx64.efi

efibootmgr doesn't show a Debian installation:

root@debian:~# efibootmgr --verbose | grep debian

Edit :

I keep getting this error every time I try and create a boot loader using efibootmgr :

grub-install: info: executing efibootmgr -c -d /dev/sda -p 3 -w -L grub -l \EFI\grub\grubx64.efi.
Could not prepare Boot variable: No such file or directory
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
1
  • Exactly same problem here with ASUS laptop.
    – Aubin
    Commented Aug 26, 2018 at 11:08

3 Answers 3

41

Fixed the efibootmgr errors by mounting the Boot variables for efibootmgr :

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars

And then efibootmgr gave me errors about space :

Could not prepare Boot variable: No space left on device

Fixed that by deleting dump files :

# rm /sys/firmware/efi/efivars/dump-*

And then ran the usual

update-grub 
grub-install -v --target=x86_64-efi --recheck /dev/sda

and it ran successfully!

3
  • 1
    This worked for me, except that I also had to reboot between the step rm /sys/firmware/efi/efivars/dump-* and running grub-install.
    – Nick ODell
    Commented Sep 11, 2019 at 18:24
  • i was having exact problem installing galliumos onto chromebook pixel 2013.Had to clear NVRAM using mrchromebook.tech's firmware_utility.sh and then problem went away.
    – FrontENG
    Commented Jun 29, 2020 at 5:20
  • The dump-* files were tiny, only like 25Kb total,yet this worked for me. Commented Aug 10, 2020 at 13:35
2

Try to specify the disk containing the loader if your disk is not /dev/sda:

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label Ubuntu
1
  • this option worked for my, excute before sudo apt install efibootmgr , and create to end the boot option , i got to delete other boot options .
    – Diego Mesa
    Commented Apr 16, 2020 at 4:29
0

I had the same issue on Ubuntu with my Asus motherboard. I did not find any dump files to delete. Or anything big that felt safe to delete.

I was able to fix the issue by rebooting the system with efi_no_storage_paranoia kernel command line option. I had already lost the Ubuntu UEFI boot entry. Luckily I could still boot to my Ubuntu partition by going to boot selection in BIOS settings. After that I used the "e" key in grub menu to add that option to the kernel command line. Then I was able to finish my previously failed system upgrade by running apt -f install.

If the system is in un-bootable state, one option is to boot from Ubuntu USB stick and fix the issue from there.

If the problem reappears later on I will consider adding that kernel option permanently in /etc/default/grub.

The kernel is very paranoid about filling up the UEFI variable space. It reports that it is full even if there is space left. This is intentional to prevent permanently filling up the space on some motherboards. I suspect that with my motherboard this might be too paranoid. Maybe the BIOS does not start garbage collection unless the space gets more full.

Previously I was able to recover from the same situation by using the "Clear CMOS" header on my motherboard. Good to find a software solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .