How do I manage the efivars directory?

plutuplutu

If I remember correctly, it happened to me and I could not boot into most recent kernels because they wouldn't install, I don't remember the error. It may also have caused proprietary drivers issues.

I had like 500 Mio for my EFI system partition as named by GParted. It wasn't nearly enough for multiple boot, current and LTS Solus kernels, so I tried to remove old kernels. I don't remember the procedure. But ran into the same problem later. Then increased the EFI system partition to 1.23Gio with GParted (I read somewhere that 1Gio would be enough) and have been fine since.

(make backups if you care for your data)

stalebrim

That is NOT the EFI system partition. /sys/firmware/efi/efivars is the filesystem which gives you access to EFI variables. It's fine to leave as is.

elfprince

stalebrim Except, it is slowly growing in size. Hence my concern.

brent

elfprince that tmpfs stuff I ginormous,
Does that mean the size is 'alloted' or assigned or imaginary? Or real?
I'm trying to wrap my head around the tiny amount used of this fs system and the majority of the allotment is unused.

"tmpfs and udev are virtual file systems. They don't allocate any disk space but dynamically use RAM to store their files. As their content is lost when you shutdown the system they are used for files which should not survive a reboot."

the more I read is tmpfs they are virtual and what is allocated combined is 50% of what you have available. when I said imaginary I was accidentally right in that it's not a real (only virtual). but this is just preliminary reading. it doesn't sound like they are really growing in that sense, except for that session?

I wonder if anyone can tell me if I have that even kinda right🙂?

edit:
read so far: https://askubuntu.com/questions/914952/what-is-tmpfs-and-why-is-it-using-most-of-my-hdd-space
and
https://unix.stackexchange.com/questions/205174/what-sets-the-size-of-tmpfs-what-happens-when-its-full

elfprince

brent /sys/firmware/efi/efivars is the directory in question.

Axios

elfprince Caution Hot Surface!!!

brent

elfprince /sys/firmware/efi/efivars is the directory in question.

I read about 4 things and they all come back to picking up a crash course in efibootmgr, a tool that's always been worthless to me, but thousands sing it's praises so it will probably work.
meaning some of the gunk in that directory can be culled. all the ghosts of programs/distros past. they supposedly take up w-a-a-a-a-a-a-y more room than you have.
this was interesting https://bbs.archlinux.org/viewtopic.php?id=290493

thats twice I've posted with two radically different proposals for the same DIR....efivars seems a very elusive creature..can't get a handle on it completely.

I know someone can lay it out 10X better than me.

Axios

brent There are alot varying opinions on this around not sure myself exactly how it should be either
I think it will control itself and shouldnt be a problem (if working correctly)
Kinda the way I see it.
I am one those persons dont create a problem unless there is one..
Myself I tend to stay away from that part of Linux Os things can go south real quick
Interesting reading tho

brent

Axios been also tempted to tear out the very high-gb squashfs directories in the day but I knew things would 'go south real quick.' I've done so many things to make an OS go south real quick. I don't wanna make anything go south real quick anymore🙂

elfprince

Axios dont create a problem unless there is one..

Preventive action never hurts. Why wait till it gets to boiling point?

elfprince

brent I don't wanna make anything go south

Exactly my position.

Axios

elfprince Everybody has their point of view.
I have seen other distros that people have had issues with it
But never one with Solus.
Million ways to attack problems or apparent problems.
I guess way I look at it like fixing a flat tire when you dont have one..

Shrugs.

elfprince

Axios One way to handle this, I guess. When I see a vital directory at 88% capacity and slowly growing, I begin to start considering remedial action, while I still have time to get opinions and advice.
Because, once it is at 99-100% full, it is kind of too late to 'cry uncle'.

Axios

https://discuss.getsol.us/d/9968-what-are-the-binaries-in-the-efivars-folder

elfprince

Axios brent It says to "leave these variables alone". Ok, I will wait and see......
Thanks for helping out.

brent

both these mention you can do this removing of non-permission stuff in the efivars directory: https://bbs.archlinux.org/viewtopic.php?id=290493 and https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Disable_UEFI_variable_access as a method to thin out entries. Neither say this guaranteed not bricking the system especially in older hardware.

second thread is how to make it smaller via EFI shell (ever work in the EFI shell? I have. It sucks!)
interesting convo in first thread though you should read it:

person trying to help: "What I've realized is if I have a lot of boot entries or signed kernels saved into NVRAM it'll erroneously fill up the space on the mobo.

A few generations ago clearing close used to also clear the UEFI variables as well. But now most of them seem to be persistant.

One little trick if you have AMI bios is you can use something like

shellx64.efi

or the onboard UEFI shell and actually clear them from the UEFI environment using

dmpstore -d -all

. The system critical variables should be write protected and all others added over time should be deleted and/or re-added over time if they were important to runtime.

PLEASE NOTE: That on older boards (think pre z590/Intel 10th gen) this can actually brick your system. Particularly if you do not have a function to flash the board externally. If in doubt. DON'T do it.

With that being said I can speak for most consumer boards newer than 11th gen Intel it simply has the same function as clearing the CMOS.

Hope this helps"

OP reply: "Thanks all for your ideas!

To be fair my UEFI might very well suck; this is a rather old ASUS laptop (Intel 6th generation), and there are plenty of things that suck on it... and I wouldn't touch the vendors UEFI implementation with a 10m-long pole wink

I actually ended up solving this inadvertently when I installed a firmware update with sudo fwupdmgr get-updates — that cleared something like 40 kB of the UEFI space. I'm not sure exactly what happened there, but I'll live by "if it works don't fix it".

he decided against fixing but note how he 'solved' it--by taking off a chunk (albeit tiny at 40kb---typo??) with the firmware update command.

the second link is basically a typical Arch surgery primer of efivars w/a little background:
"UEFI defines variables through which an operating system can interact with the firmware. UEFI boot variables are used by the boot loader and used by the OS only for early system start-up. UEFI runtime variables allow an OS to manage certain settings of the firmware like the UEFI boot manager or managing the keys for UEFI Secure Boot protocol etc. You can get the list using:

$ efivar --list

UEFI variables support in Linux kernel

_Linux kernel exposes UEFI variables data to userspace via efivarfs (EFI VARiable FileSystem) interface (CONFIG_EFIVAR_FS) - mounted using efivarfs kernel module at /sys/firmware/efi/efivars - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8. "_

In the middle of the surgery primer is lists 5 tool to thin out efivars of 'manipulate' it:
"Userspace tools

There are few tools that can access/modify the UEFI variables, namely

efivar — Library and Tool to manipulate UEFI variables (used by efibootmgr)

https://github.com/rhboot/efivar || efivar

efibootmgr — Tool to manipulate UEFI Firmware Boot Manager Settings

https://github.com/rhboot/efibootmgr || efibootmgr

uefivars — Dumps list of UEFI variables with some additional PCI related info (uses efibootmgr code internally)

https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR

efitools — Tools for manipulating UEFI secure boot platforms

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools

Ubuntu's Firmware Test Suite — Test suite that performs sanity checks on Intel/AMD PC firmware

https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR"

I took the liberty of italicizing what I thought was important, not the original authors.

Looks like this: doable? hell yes. Risky as snot? another hell yes.

thatfwupd firmware update looks the most safe to me. I saw a thread on Solus forum about Forum users who regularly use that command.

becauseefibootmgr is a useless tool for me (changes NEVER stick) I've tried to make cleanup moves in the EFI shell. days of failure there, too. syntax and commands from Mars to me...

edit: to turn all those words into a couple: what you want looks dangerous unless you know one of those tools well...

brent

elfprince I hope it doesn't get to the point where the DIR gets 100% full and you have to ask forum about that...I've seen that in my reading. more surgery. If that day comes I'd be real interested in what you are told as far as steps to remedy it..
I completely agree with you I'd rather be proactive then watch the slow drip-drip-drip that may turn into a gusher. Can't see no remedy for the drip-drip-drip yet here or in my reading..which may mean the absence of more voices may also indicate lack of confidence in giving you an absolute to try in decreasing size. guessing..

elfprince

brent Harvey says to leave it. I trust that my system will not come to any harm, if and when that DIR gets full. Then we will see.

brent

elfprince I did enough reading where I think that dev/firmware co. etc can set these percentage variables, i.e., 88% may be near the real top? and 100% not in sight. that was my impression at beginning of thread that numbers not what they seem. think you will be fine as well.

I remember years ago we marveled and worried, in a thread, that the squashfs volumes were exploding into ludricous size and someone had to talk us down because some kind of Celtic Voodoo was afoot.
it was then I kinda/sorta got that not all was what it seemed 🙂

Axios

brent Your first paragraph is pretty much how I see its size prob depends alot on ones system
To have something of that importance not manage itself somewhat doesnt make sense.
These little talks keep my brain cells alive...lol