F38 Secure Boot dbx Configuration Update 190 -> 217 fails w/Invalid argument

Ask Fedora
, ,
1
  1. Freshly installed Fedora 38
  2. Running in KVM as a Standard PC (Q35 + ICH9, 2009) pc-q35-7.0
  3. edk2-20221117gitfff6d81270b5-14.fc37
  4. Secure Boot is disabled

Software has one Update: “Secure Boot dbx Configuration Update 190 → 217”
This update never succeeds through the GUI, it silently fails.

fwupdmgr update asks to “Upgrade UEFI dbx from 190 to 217”, but always fails with

failed to write data to efivarfs: Error writing to file descriptor: Invalid argument

Running this with “–verbose” doesn’t provide any extra information.

My question is: How to apply this update (or remove it from appearing to either
Software or fwupdmgr)?

And also, shouldn’t Fedora 38 ship with the latest dbx 217, instead of an older one?

Why does a fresh install of Fedora 38 in a VM require that I deal with this?

1 Like
2

Are you running that command either as root or using sudo?

3

I’ve tried as root, sudo with my ID, and just under my ID, the result is always the same, no matter how it is run.

4

I would think that when you don’t have secure boot enabled, you also don’t need the dbx updates. The dbx updates updates the list of blacklisted security boot certificates, which would only be relevant when secure boot is enabled.

5

Great! I agree! How do I get fwupdmgr and Software to stop presenting it to me, then?

6

I don’t know if this could be your issue, but I had a similar issue running Windows 11 in a VM with Fedora 37 as my hypervisor. The problem was that the UEFI variable space that KVM used was too small and there wasn’t room for a Windows update that added stuff to dbx. The fix that worked for me was to change the UEFI variable store and UEFI firmware KVM was using from the original version I used to a larger 4 Meg. version. The details of that issue and the fix are described here:

1 Like
7

Thank you, thank you, thank you, one thousand thank you’s! This was the solution to the problem! I didn’t even have to download anything, Fedora already provides the ovmf-4m files in the /usr/share/edk2/ovmf-4m directory but for some reason, defaults to the ovmf (2M) files there instead. Switching the VM to use the files in the ovmf-4m directory fixed the issue!

For those seeing this in the future, I had created my VM with the --boot uefi option to the virt-install command. On Fedora 37/38, this defaults to the OVMF 2M files. Changing the virt-install --boot option to this instead:

--boot loader=/usr/share/edk2/ovmf-4m/OVMF_CODE.secboot.fd,loader.readonly=yes,loader.type=pflash,nvram.template=/usr/share/edk2/ovmf-4m/OVMF_VARS.secboot.fd,loader_secure=yes

creates the virtual machine in UEFI mode but with the OVMF 4M files, with secure boot enabled. If you don’t want secure boot, just remove the .secboot portion of the filenames and change loader_secure=no.

The new dbx 217 update installs successfully now with no errors.

I don’t know fully what the implications are for changing the default to the 4M files, but given that Fedora 38 is already shipping with updates that require it, I think it should default to it.

1 Like
8

You’re very welcome. Glad it helped! I chased this problem for a long time, so glad to save someone else some time.

I also wonder why it doesn’t just default to using the 4M image, but my VM had been created a while ago, so I wasn’t sure if there was a more recent change to make that the default, but apparently not.

1 Like
9

You can also update existing VMs like this:

VM="fedora"
virsh shutdown ${VM}
EDITOR="sed -i -e s:/ovmf/:/ovmf-4m/:" virsh edit ${VM}
virsh dumpxml ${VM} --xpath //os
virsh start ${VM} --reset-nvram
10

Thank you Vladislav for documenting this, this is also a solution!

I have created bug report #2181840 to capture this. Hopefully, it can be addressed before Fedora 38 goes GA. I would like to make it a blocker bug, but I don’t think it qualifies given the description. Maybe someone else here has some insight on that?

1 Like