9

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% /
guiverc
  • 30,396
Shinu Thombikkodan
  • 91
  • 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 06 '18 at 05: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 06 '18 at 05:51
  • lab@lab:~$ df -hi Filesystem Inodes IUsed IFree IUse% Mounted on udev 234K 471 234K 1% /dev tmpfs 241K 804 240K 1% /run /dev/sda2 30M 579K 29M 2% / /dev/sda1 0 0 0 - /boot/efi

    lab@lab:~$

     – Shinu Thombikkodan Sep 06 '18 at 05:56
  • we have a separate /boot partition, its showing /dev/sda1 511M 4.7M 507M 1% /boot/efi and we have enough space on it. – Shinu Thombikkodan Sep 06 '18 at 05:58
  • i have run teh command for checking inodes, its showing the output is 0, /dev/sda1 0 0 0 - /boot/efi – Shinu Thombikkodan Sep 06 '18 at 05:59
  • 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 06 '18 at 05:59
  • changed the question – Shinu Thombikkodan Sep 06 '18 at 06:13
  • 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 06 '18 at 06:16
  • /dev/sda1 0 0 0 - /boot/efi – Shinu Thombikkodan Sep 06 '18 at 08:53
  • this is teh output when i am running df -i , and i have tried to cd /boot/efi , getting the message as no permission even i am logged in as root – Shinu Thombikkodan Sep 06 '18 at 08:54
  • 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 06 '18 at 10:08
  • See this bug report, looks like same thing. https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1776271 If so please say it effects you, the more with an issue the sooner someone will look at it. – oldfred Sep 11 '18 at 03:45

4 Answers4

11

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!

Pablo Bianchi
  • 15,657
tudor -Reinstate Monica-
  • 7,288
  • 3
    On Debian Stretch it's not /sys/fs/efi/ but /sys/firmware/efi/ – Daniel Böhmer Jan 15 '19 at 09:19
  • 2
    On Ubuntu 18.04 it's /sys/firmware/efi/ as well – Tanachat Feb 14 '19 at 09: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 04 '20 at 05:23
  • 1
    @4xy /sys is a “pseudo file system”. It's not an actual folder on the hard disk, there's a special filesystem mounted there that consists of entries that refer to properties of the system or other devices. (If you say mount, you'll see an entry something like sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime).) In this case it lets you access content in the NVRAM of your system's UEFI chip, which is not on any hard drive. – Soren Bjornstad Oct 07 '22 at 02:16
  • /sys/firmware/efi on Manjaro as well. – Soren Bjornstad Oct 07 '22 at 02:17
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.

user906466
  • 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.

Philip Tzou
  • 101
0

In BIOS, selecting Load Defaults did it for me.

adabru
  • 230