I later ran efibootmgr -v and successfully listed entries like:
Boot0000* Ubuntu
Boot0003* Windows Boot Manager
I would guess the certificates are not updating, because the efivarfs is almoest full and fwupdmgr can’t update UEFI CA and UEFI dbx, because there isn’t enough space. Is there any way I can make space in efivarfs or create a bigger efivarfs storage or any other solutions that might help?
Thanks, this definitely helped. I was 11 versions behind , I upgraded to BIOS version 316 now with EZ Flash.
I did multiple resets in the BIOS.
I was able to update de UEFI CA with fwupsmgr, but it wouldn’t let me update the UEFI dbx unfortunately. The size stayed 128K, and very suprising that the UEFI CA would update with the same amount of efivarfs space.
Any thoughts of next steps to take?
Here is the output after the reset and BIOS upgrade.
Running:
sudo fwupdmgr update
produces:
UEFI dbx is not currently updatable:
• Not enough efivarfs space, requested 30.7 kB and got 11.0 kB
Devices with the latest available firmware version:
• UEFI CA
Devices with no available firmware updates:
• ASUSTeK KEK Certificate
• ASUSTeK SW Key Certificate
• Internal SPI Controller (BIOS)
• Master Certificate Authority
• Option ROM UEFI CA
• Windows Production PCA
• KEK CA
• Master Certificate Authority
• SBAT
• System Firmware
• UEFI Device Firmware
• WDC PC SN530 SDBPNPZ-256G-1002
Running:
df -h /sys/firmware/efi/efivars
produces:
Filesystem Size Used Avail Use% Mounted on
efivarfs 128K 118K 5.8K 96% /sys/firmware/efi/efivars
Have you tried forcing a reboot directly after sudo fwupdmgr update with sudo systemctl reboot ? The update should still sit in EFI so on boot the UEFI will try to perform the update instead, perhaps that process uses less space …
I’m wondering how many (all?) of those revocations have been rendered obsolete by the replacement of Microsoft’s expired UEFI CA certificate. Perhaps that allows pruning the dbx list? One only needs revocations for certs signed by a trusted CA and, since MS’s 2011 cert should now be gone from OP’s UEFI, the old dbx entries — revoking certs signed by it — are thus redundant.
I wouldn’t know how to do that, though. Just throwing this out there, in case somebody can speak to the technicalities of pulling this off. Could it be as easy as rm /sys/firmware/efi/efivars/dbx-*? As we know, everything is a file in Unix.
Some variables are not visible in operating system and are only accessible at boot time. Unfortunately, to see them you would need to boot into something like EFI Shell or some bootloader allowing to list variables. GRUB does not offer commands to do it.
That won’t work. Any changes to the Secure Boot variables (including removal) must be properly signed. Besides, blindly removing EFI variables may lead to bricking your system (which is the reason why most variables are marked immutable by the current Linux kernel).
How about a factory reset of the Secure Boot keys, then? Found this in a quick search. The only thing I’d be worried about would be fwupdmgr replaying all the history to end up exactly where OP started. Perhaps the CA update should be done first thing after the reset. I don’t know, how intelligent fwupd is, though, perhaps it’s just ticking boxes on the long to-do list and one needs to manually prevent the obsolete dbx entries from being replayed.
Just after writing this, I realized that those dbx entries are probably included in the latest firmware update as well, so the reset will restore them. But it can’t hurt to try, I guess.
BTW, is this a dual boot system, @sembennard? Because, if it isn’t, you don’t actually need the MS certificate and consequently the long dbx list. I don’t know if Ubuntu is clever enough to enroll Canonical’s key which signs GRUB and the EFI shim, though, or if it’s tunnel-visioned on Secure Boot (only genuine with MS’s keys); because that is the only thing required for Trusted Boot. I think Secure Boot setup mode is required to enroll keys like that.
Some computers require a firmware update to be able to install the updated certificates.
I have a Dell laptop like this, but Dell won’t be issuing a firmware update.
From your efibootmgr entries you appear to be dual booting, so you can check what Windows thinks in the Windows Security app > Device Security.
You can read the extensive official documentation at [1], including what will happen if you cannot install updates.
I would be wary of trying random stuff, particularly if you are dual booting. See for example the warning from Dell at link [2]: “You should not reset the Secure Boot Certificates if they are updated by Windows Update as the BIOS cannot restore the new certificates.”
After upgrading the BIOS to the latest version I resetted the keys and restored to defaults, and only after this it was able to update the UEFI CA. I tried this a lot of times before and never did anything, only after the BIOS upgrade, but the enfivarfs space stayed the same strangely.
I am not using dual booth. Is there anything that makes you think I am and would it be able to remove some leftover Microsoft files that will clear up space? I would be happy to delete it.
I can only offer what the theory would suggest, no guarantees whatsoever. This post on Lennart Poettering’s blog (link should jump to and highlight the “Anything Else?” section headline) gave me the idea. Don’t mind the systemd-boot talk, focus on this:
I think the shim needs to stay in Ubuntu’s case, though, because everything is designed around it. I don’t know if it is also signed by Canonical, though, but I hope so. Any way to check, @audience? That should make it rather simple, in theory at least. Clear the key store, put the UEFI in Secure/Trusted Boot setup mode, enroll Canonical CA key.
I think I’m going to try this on my toy VM; install Ubuntu 26.04 on a squeaky clean SB key store. The only problem is that the Tianocore UEFI menu is a bit cryptic at times, so it might take me a while to figure out how to do it. If anyone reading this knows where to find a manual, post a link please.
Well, that theory didn’t last long. I attempted to install with TPM-backed encryption, which has Secure Boot as a hard requirement, but the installer then informed me that it must also be enabled (deployed mode). I checked with mokutil --sb and it was in setup mode, as intended.
In my search for Canonical’s signing certificate, I happened upon this:
It seems to contain info on how to do this manually, but I’ve only just started reading.
Then users can sign them with their own key. Should only be necessary once, and after UEFI updates.
That is incorrect. Worst case is that Secure Boot is permanently unusable, but booting will always be possible. Plus, the keys are public, so one should be able to get a copy from a working machine or from some vendor site. I’m sure MS has some place to download theirs. Or just get it from fwupdmgr, see OP.
Are you sure you are talking about the same thing as I am? Do you know how to extract drivers from a PCI card Option ROM, sign them and write back into this PCI card Option ROM?
The add-on cards may need drivers from their Option ROM. These drivers must be signed if Secure Boot is active. If signature verification fails, these cards will be unusable. If this includes your video card, you will get no output at all. If this includes the adapter controlling your boot device, the system will not boot. And you may not have chance to enter Setup and disable Secure Boot in this case.
Sorry, you cut the important part. It’s hardly a brick when one can just disable secure boot and live with it. Also, the certs are public, so they can be restored and SB re-enabled.
As for the drivers from option ROM’s, the user key can sign the signing certs of the vendor in question, if there really is no other way to get their hashes for signing. But the UEFI must verify them, so perhaps one can look over its shoulder, so to speak. I’ve only scratched the surface of the matter but I remember some mention of EFI shell, which seems to be a candidate to get the EFI to do its thing and report the hash; sign hash, enroll signature, or however this works exactly, enable Trusted Boot — can only call it Secure Boot, when MS is the root of trust, or so I’ve read somewhere.
, I upgraded to BIOS version 316 now with EZ Flash.
(only genuine with MS’s keys); because that is the only thing required for Trusted Boot. I think Secure Boot setup mode is required to enroll keys like that.
It’s hardly a brick when one can just disable secure boot and live with it. Also, the certs are public, so they can be restored and SB re-enabled.