Bug#966554: how to apply the workaround?

quixote quixote at greenglim.com
Wed Aug 5 10:26:47 BST 2020


Thanks very much for your answers. There's something bizarre going on. 
Yes, my /sys/firmware/efi/efivars/ said it was full and had dump-* files 
in it. I removed those a few days ago. But after your comment I went to 
look if there were new ones cluttering the place up. No, there weren't, but

df -h /sys/firmware/efi/efivars returned:

Filesystem      Size  Used Avail Use% Mounted on

efivarfs           0     0     0    - /sys/firmware/efi/efivars


Why would it think it was full? Especially after I'd removed about fifty 
dump files, which have not reappeared.

Yes, I have a /boot/efi partition. I did get the size wrong: it's 512 MB 
, of which 7.97MB is used. The root partition is 30GB.)

I tried

apt-get install --reinstall grub-efi

which eventually returned:

Unpacking grub-efi (2.02+dfsg1-20+deb10u2) over (2.02+dfsg1-20+deb10u2) ...

Setting up grub-efi (2.02+dfsg1-20+deb10u2) ...

As far as I can tell, that's the correct, new version. I also 
reinstalled grub-common and grub2-common, also seemed to be up to date.

But, given the "no space available" in efivars dir, I'm not too 
surprised that an attempt to

grub-install /dev/nvme0n1

just says no space left on device.

I've seen instructions on manually removing obsolete entries in the 
efivars dir, but I don't think that would help since manually removing 
dump-* files didn't solve the problem.

(I changed "stable" to "buster" in sources.list. The computer is a 
Lenovo Thinkpad X1 Carbon, with three Debian versions on it in separate 
partitions. No windows. Separate /home partition. In case any of that is 
relevant.)

So, it seems it's somehow stuck on efivars being full, when it isn't?!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20200805/8a11823b/attachment-0001.html>


More information about the Pkg-grub-devel mailing list