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