1

In the Arch Wiki I see that the two kernel variables CONFIG_EFIVAR_FS & CONFIG_EFI_VARS should be set =y and =n respectively. Arch says, "This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled." In Ubuntu 20.04, they are both set to =y. If I am understanding correctly, it appears that as a result, I have both dump-* files in /sys/firmware/efi/efivars and dump-* directories in /sys/firmware/efi/vars.

$ ls -l efivars/dump*
-rw-r--r-- 1 root root 644 Feb 27 00:12 efivars/dump-type0-10-1-1645912016-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
[& etc.]

$ ls -l vars/dump*
vars/dump-type0-10-1-1645912016-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0:
total 0
-r-------- 1 root root 4096 Feb 27 00:48 attributes
-r-------- 1 root root 4096 Feb 27 00:48 data
-r-------- 1 root root 4096 Feb 27 00:48 guid
-rw------- 1 root root 4096 Feb 27 00:48 raw_var
-r-------- 1 root root 4096 Feb 27 00:48 size
[& etc.]

As my NVRAM has been filled up with these (see here and here for troubles due to the acpi-call package, particularly in aging Thinkpads - mine is a W530), I am wondering if my understanding is correct, and that therefore I need to remove both the files and the directories with their contents?

Edit1: Following user1686's answer, I tried deleting ../efivars/dump*. Even after a reboot, the ../vars/dump* directories remain. Worse, the ../efivars/dump* files are back!

Edit2: I deleted ../efivars/dump* for a second time and after reboot they are now gone, along with the ../vars/dump* directories.

Improve this question

1 Answer 1

Reset to default
1

Both locations represent the same thing – they're different views into the same EFI "variable" store, and there's only one copy of that variable under the hood.

So whichever one you remove first, the kernel will ask the EFI Runtime Services to delete the exact same EFI variable either way, and the entry should disappear from both locations at once.

(If it doesn't disappear from both locations, don't try to delete it from the other, instead reboot.)

Improve this answer
6
  • Alright, thank you, but it has not yet been deleted from both locations. I will try a reboot, though I am a bit anxious because others have reported bricked machines due to full NVRAM even after deleting .../efivars. I won't reboot right away, but will report back after I do.
    – Diagon
    Commented Feb 28, 2022 at 0:32
  • Ok, so that didn't work. I rebooted and not only do the ../vars/dump-* directories remain, but the ../efivars/dump-* files are all back! Do you have any other thoughts?
    – Diagon
    Commented Mar 1, 2022 at 10:26
  • Try deleting it from the other location instead (though I'd be surprised if it gave different results...), or if you can start the EFI Shell (whether built-in or downloadable), try its dmpstore command to delete variables. In the worst case, reset all firmware settings.
    – grawity_u1686
    Commented Mar 1, 2022 at 10:48
  • EFI shell - I think you're referring to getting into the interface at post time, yes? There is no way to delete via the BIOS (which is what Thinkpads of this era provide). What would it mean to download an EFI shell? (Oh, and when I try deleting from the other location, I should be rm -r dump*, yes? Deleting the whole directory and its contents?)
    – Diagon
    Commented Mar 1, 2022 at 10:52
  • I mean it's literally a command-line shell, much like bash or Cmd, only running in the "raw" EFI environment. Depending on manufacturer, it's sometimes embedded in the firmware, but more commonly you have to download the .efi file for it.
    – grawity_u1686
    Commented Mar 1, 2022 at 11:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .