How do I manage the efivars directory?

brent

Axios mine too. you are right. not a variable.

silke

elfprince Any other distribution will probably have the same problem. The 128k limit is set by the Linux kernel as far as I know (and is not tunable). Depending on your firmware, the filesystem filling up is not actually an issue.

You could try to find out what the large variables are, and see what they actually do (do not delete/modify any files):

find /sys/firmware/efi/efivars -type f -exec wc -c {} \; | sort -n | tail -n10

Any safe solutions to increase the directory size or prune some things from it?

Cleaning these up is probably something that has to be done through the system firmware. Something I can think of is to see if your system has a BIOS/firmware update available, and perform that. Make notes and a backup of your customized BIOS settings and be prepared to perform a boot rescue/restore your system from backup.

Axios

silke Thanks for that command was looking for something along those lines
just what I wanted to add to my toolbox.
I think your thoughts and recommendations are correct and spot on and appears others agree to.
(Along lines I was thinking but Not being a pro am careful to what I post dont care if its my system.)
Even tho its not an issue of mine I keep learning still some fog on to why it happens But hey thats what
google is for..lol
Keep up the good work Devs.

brent

silke so something like sudo fwupdmgr get-updates may be as good as it gets here? Or is that reckless?

ps--great response! puts to bed a lot of speculation from myself and things I've read.

elfprince

silke EC:0 [10:09:12](sasha@nuc-sol): ~ $ sudo find /sys/firmware/efi/efivars -type f -exec wc -c {} \; | sort -n | tail -n10 [sudo] password for sasha: 570 /sys/firmware/efi/efivars/MaintenanceSetup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 570 /sys/firmware/efi/efivars/SetupDefault-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 570 /sys/firmware/efi/efivars/Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 686 /sys/firmware/efi/efivars/StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824 866 /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c 924 /sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 972 /sys/firmware/efi/efivars/CurrentSettingValues-6320a8c8-9c93-4a71-b529-9f79c8761b8d 1564 /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c 3147 /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 13248 /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f EC:0 [10:09:39](sasha@nuc-sol): ~ $

silke

brent Yes, that would work if the hardware vendor publishes firmware via the Linux Vendor Firmware Service. The alternatively is to go to the website of the vendor, find and download the latest firmware on a USB flash drive and flash it using the BIOS interface.

Both are not reckless, but updating firmware always has a very small risk of bricking your device. I have personally mostly seen issues where the BIOS forgets all settings and boot entries. That's why I recommend to make notes and a backup of your customized BIOS settings and be prepared to perform a boot rescue or restore your system from backup.

elfprince

silke updating firmware always has a very small risk of bricking your device. I have personally mostly seen issues where the BIOS forgets all settings and boot entries.

That is why I do not plan on doing that, ever. 😄

Axios

elfprince hmm are you using secure boot?
The last 3 entries are secure boot stuff and the PK.
And I leave it there.

brent

elfprince That is why I do not plan on doing that, ever.

I did it once via usb from the MSI mobo people's .(or whatever) and it worked. I was probably 15 years out of compliance. Went fine. Nothing changed. Sadly. Not performance, not boot log, not anything. But it didn't wreck anything, I would put your chances at 85/15 from my reading, but I agree: 15 is still a real double-digit number..

elfprince

Axios Nope, no secure boot.

elfprince

Upon a short search online, I found that people report their OS running well even with efivars 100% full. So, I will relax (somewhat) and just see what happens in my case, if and when.
Yellow alert canceled.

Axios

brent Have Done tons of firmware stuffs over the years on various electronics
never DoDo one yet. (even back in the day with Eeproms gawdddd I am old..)
The Nvram and those chips does have a limited numbers of write cycles and they do go bad in that case its just luck of the draw. (Dont think one would have issues with todays chips since they are more dense)
Otherwise one will be fine just dont interrupt the update cycle and follow instructions let it do its thing.
It does scare most people tho.

brent

Axios The Nvram and those chips does have a limited numbers of write cycles and they do go bad in that case its just luck of the draw. (Dont think one would have issues with todays chips since they are more dense)

that's interesting. hadn't thought it had X amt of cycles but hardware doesn't last forever.

Axios Otherwise one will be fine just dont interrupt the update cycle and follow instructions let it do its thing.
It does scare most people tho.

I agree. I was one of those people but not scared now. But I put myself in the right position to do that: after a new install. So I had little to lose.

@elfprince if you read positive 100% full stories than you are going to be fine. I read a lot too. And to be honest, for those worried about 100% I actually read of no side effects when they got to 100.

WetGeek

brent And to be honest, for those worried about 100% I actually read of no side effects when they got to 100.

I don't have any specific knowlege of this situation, but having considerable software design experience during my career, I strongly suspect that when that buffer is filled to 100%, subsequent additions simply overwrite older items. Thus, it continues to accept additions, it stays at 100%, and it works as expected, but the oldest data is overwritten.

That would explain why some can reach 100% and keep going as if nothing has happened.

« Previous Page