6

getting below error. But I think available space is enough for this (use% is 9%) Can you please help us to resolve this ?

lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
  Package grub-efi-amd64-signed is not configured yet.

dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

lab@lab:~$ df -k .
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      479152840 37427836 417315612   9% /
12
  • Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read). – guiverc Sep 6 '18 at 5:29
  • lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi – Shinu Thombikkodan Sep 6 '18 at 5:51
  • 1
    Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you) – guiverc Sep 6 '18 at 5:59
  • 1
    I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :) – guiverc Sep 6 '18 at 6:16
  • 1
    @guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition. – Melebius Sep 6 '18 at 10:08
10

There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.

There are a number of potential solutions to this:

  1. Clear the dump files

    grub stores efi logs in /sys/fs/efi/efivars/dump-*

    Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.

  2. BIOS upgrade

    If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.

  3. LAST RESORT - DISABLE EFI CHECK

    It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.

    To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:

    1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub
    2. Update grub by running sudo update-grub
    3. Reboot
    4. Run apt -f install

For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!

5
  • 3
    On Debian Stretch it's not /sys/fs/efi/ but /sys/firmware/efi/ – Daniel Böhmer Jan 15 '19 at 9:19
  • 1
    On Ubuntu 18.04 it's /sys/firmware/efi/ as well – Tanachat Feb 14 '19 at 9:06
  • The only procedure that worked for me was the number 3 of of this answer – Luciano Serra Jul 23 '19 at 17:01
  • The first one worked. /sys is the folder on the /dev/sda1 and there is space about few Gb there. So why did it work? What is the reason? – 4xy May 17 '20 at 14:00
  • +1 for #3! Works like a charm! I have an Intel DN2800MT MB that has very little NVRAM (it seems). I'll leave the "no paranoia" flag there from now on. Not a critical machine (just my backup router). I have enough paranoia going on already! :D – Vinicius Dec 4 '20 at 5:23
0

I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.

1
  • This does not help for me (Thinkpad T440s). Will this delete any variables or make some room otherwise? – doak Aug 22 '19 at 12:01
0

OK I just encountered the same error and have successfully solved thanks for the helpful answer by @tu-Reinstate Monica-dor duh. His/her answer explained the exact reason of the error.

However, my way of solving this problem is by editing the built-in boot manager, which is also stored in NVRAM. In my case, I followed the steps of https://superuser.com/a/931016/672706:

  1. sudo efibootmgr -v list all boot options.
  2. sudo efibootmgr -b # -B to delete the unwanted options.

After ran these two steps, I have successfully installed grub-efi-amd64-signed.

0

In BIOS, selecting Load Defaults did it for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.