EFI variables (like Boot0000) not available in user space (since recent BIOS update)

[supermarket]

Which Linux distro are you using? Debian

Which release version? testing (trixie), fully updated to today (2025-07-11)

Which kernel are you using? 6.12.35+deb13-amd64 (2025-07-03)

Which BIOS version are you using? 3.08 (2025-05-29)

Which Framework Laptop 13 model are you using? 13th Gen Intel® Core™, i5-1340P

---

I no longer have a view of EFI variables like Boot0000 in user space. It worked correctly at some point in the past. The only recent relevant change I’m aware of is that I updated the firmware to 3.08.

Normally, efibootmgr would report on the boot order by showing variables such as BootCurrent, Boot0000, etc. Instead, I now see:

% efibootmgr
No BootOrder is set; firmware will attempt recovery

I use systemd-boot, and its bootctl status also shows evidence that it can’t access EFI variables:

% bootctl status
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (unsupported)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: not supported
[…]
No boot loaders listed in EFI Variables.
[…]

Normally, there would be values for Firmware, Secure Boot would show up as enabled (user) (since I’m using Secure Boot), Measured UKI would be yes, and Boot into FW would be supported. Additionally, it would be able to display a Current Boot Loader: section.

It’s evident that the problem is that none of the EFI variables necessary to make this work are visible in user space.

% ls /sys/firmware/efi/efivars | sed -E -e 's/-.{36}$//'
FeData
H2OFormDialogConfig
IP6_CONFIG_IFR_NVDATA
KEKDefault
MebxCfg
PKDefault
PasswordConfig
SecureBootData
Tcg2ConfigInfo
WIFI_MANAGER_IFR_NVDATA
dbDefault
dbxDefault

That looks very thin. Where are the classics like LoaderFirmwareType and LoaderInfo, to identify the firmware, and where are all of the Boot* variables? Where’s OsIndications conveying the boot-into-firmware capability/ Where’s SecureBoot to give Secure Boot information? I see Secure Boot default keys (PKDefault, KEKDefault, dbDefault, dbxDefault), but not my actual Secure Boot keys (PK, KEK, db).

The system otherwise boots and functions normally (including Secure Boot behaving properly), but I’ve lost my view of the actual EFI configuration in user space.

Were these EFI variables a casualty of the recent BIOS update?

edited: subject

[supermarket]

Oh, and I can’t use fwupdmgr downgrade to try BIOS 3.07 either:

% sudo fwupdmgr downgrade
0.      Cancel
1.      22393fc023ab027cc856e804c7ad83af5bb1a8ca (Fingerprint Sensor)
2.      d8f7c2e5ca0f897ff6d20b6e5a9945ca7c320ea9 (System Firmware)
Choose device [0-2]: 2
╔══════════════════════════════════════════════════════════════════════════════╗
║ Downgrade System Firmware from 0.0.3.8 to 0.0.3.7?                           ║
╠══════════════════════════════════════════════════════════════════════════════╣
[…]
Perform operation? [Y|n]: y
[…]
SecureBoot is not available

I definitely was able to use fwupdmgr update to update the BIOS a few days ago. Now, stuck in this situation, I won’t be able to use fwupdmgr at all to test a downgrade or even to install a future upgrade.

[supermarket]

I just found https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker/issues/76 on GitHub, so it’s not just me.

(I’m evidently not allowed to post a link to GitHub, so now it’s not a link.)

[supermarket]

Through discussion on the GitHub issue, I discovered this forum post from last year. It held the key to the problem.

When the Secure Boot DBX hash list is empty, most EFI variables, including all of the interesting and relevant ones, aren’t made available.

Originally (under earlier firmware), I had removed all DBX hashes and didn’t experience this problem. Given that I’ve entirely replaced the PK and KEK with my own, I didn’t consider the DBX list of revoked hashes that I had never signed to be worth keeping. Evidently the update to firmware 3.08 combined with my empty DBX list seems to have triggered this firmware bug. (I’m not sure if just deleting some of the DBX hashes would trigger the same bug. I just left all 33 alone.)

I just went through the process again, entering Secure Boot Setup mode by clearing the PK, 2 KEKs, and 3 DBs, and leaving all 33 DBXs alone. Sure enough, the EFI variables were back. And after setting my own PK, KEK, and DB, things are still working.

I went from a measly 11 uninteresting EFI variables visible in /sys/firmware/efi/efivars to a full complement of 141. Tools like efibootmgr and bootctl status work properly again, and I’m sure fwupdmgr would as well, although I no longer have a need to try a firmware downgrade to 3.07.

The firmware bug appears to be that with an (empty? altered?) DBX list, most EFI variables aren’t made available to user space. That’s unfortunate, given that the most common way to take ownership of Secure Boot is to erase the entire Secure Boot configuration, which…you guessed it!…deletes the DBX list. The bug appears to affect firmware for a wide variety of Framework products, and it’d be great it if could be fixed.