Impossible to Delete UEFI Dump Files - CONFIG_EFIVAR_FS & CONFIG_EFI_VARS both =y

Bug #1962572 reported by DiagonalArg
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

See this bug for where this issue appears:
https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1953261/+login

I am seeing in the Arch UEFI documentation:

    UEFI Runtime Variables Support (efivarfs filesystem - /sys/firmware/efi/efivars). This option is important as this is required to manipulate UEFI runtime variables using tools like /usr/bin/efibootmgr. The configuration option below has been added in kernel 3.10 and later.

    CONFIG_EFIVAR_FS=y

    UEFI Runtime Variables Support (old efivars sysfs interface - /sys/firmware/efi/vars). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.

    CONFIG_EFI_VARS=n

In Ubuntu 20.04, both of these are set =y. This appears to be the cause of my inability to delete /sys/firmware/efi/efivars/dump* variables. These variables are mirrored as directories of the same name in /sys/firmware/efi/vars/dump*. If I delete the files ../efivars/dump*, they reappear on reboot.

Systems have been bricked this way, when people thought they had cleared out the variable storage, but had not, and then found it full on the next boot. Some Thinkpads of the W530 vintage do not have a way to clear out that storage at post time.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-02-05 (389 days ago)
InstallationMedia: Ubuntu 20.04.2 LTS "Focal Fossa" - Release amd64 (20210204)
MachineType: LENOVO 2436CTO
Package: linux (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.13.0-30-generic root=UUID=5d036090-3f9e-4adf-a198-e0db3da45582 ro rootflags=subvol=@ luks.crypttab=no intel_iommu=on quiet
ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
RelatedPackageVersions:
 linux-restricted-modules-5.13.0-30-generic N/A
 linux-backports-modules-5.13.0-30-generic N/A
 linux-firmware 1.187.26
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: yes
Tags: focal
Uname: Linux 5.13.0-30-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm btrbk cdrom debian-tor dip libvirt lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 06/11/2018
dmi.bios.release: 2.72
dmi.bios.vendor: LENOVO
dmi.bios.version: G5ETB2WW (2.72 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2436CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.ec.firmware.release: 1.13
dmi.modalias: dmi:bvnLENOVO:bvrG5ETB2WW(2.72):bd06/11/2018:br2.72:efr1.13:svnLENOVO:pn2436CTO:pvrThinkPadW530:rvnLENOVO:rn2436CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:skuLENOVO_MT_2436:
dmi.product.family: ThinkPad W530
dmi.product.name: 2436CTO
dmi.product.sku: LENOVO_MT_2436
dmi.product.version: ThinkPad W530
dmi.sys.vendor: LENOVO

Revision history for this message
DiagonalArg (diagonalarg) wrote : AlsaInfo.txt

apport information

summary: - CONFIG_EFIVAR_FS & CONFIG_EFI_VARS both =y - Impossible to Delete UEFI
- Dump Files
+ Impossible to Delete UEFI Dump Files - CONFIG_EFIVAR_FS &
+ CONFIG_EFI_VARS both =y
tags: added: apport-collected focal
description: updated
Revision history for this message
DiagonalArg (diagonalarg) wrote : AudioDevicesInUse.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : CRDA.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : CurrentDmesg.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : IwConfig.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : Lspci.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : Lspci-vt.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : Lsusb.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : Lsusb-t.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : Lsusb-v.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : ProcInterrupts.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : ProcModules.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : PulseList.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : UdevDb.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : WifiSyslog.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote : acpidump.txt

apport information

Revision history for this message
DiagonalArg (diagonalarg) wrote :

Is there a workaround right now for me to clear out the NVRAM dump files?

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
DiagonalArg (diagonalarg) wrote :

As reported above, I tried deleting ../efivars/dump*, but even after a reboot, the ../vars/dump* directories remain. Worse, the ../efivars/dump* files returned.

I repeated the deletion of ../efivars/dump* and again rebooted. On second reboot, those files are gone, along with the ../vars/dump* directories.

If I had not removed tlp and acpi-call-dkms after that first boot, then rebooting may well have filled the NVRAM and bricked the machine!

Revision history for this message
Matthew Bradley (mwbradley) wrote :

This is related to https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1953261 which HAS NOT BEEN FIXED.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.