1. Please describe the problem: Installed Fedora 42 with all updates, using kernel-6.14.0-0.rc3.29.fc42 and got notified that there was a firmware update available. Trying to install it led to an error, repeatable: failed to write-firmware: could not set DP_BUF with EFI/fedora/fw/fwupd-b0c018c8-9230-4bb5-b4a3-b1849957e068.cap: failed to set /sys/firmware/efi/efivars/fwupd-b0c018c8-9230-4bb5-b4a3-b1849957e068-0-0abba7dc-e516-4167-bbf5-4d9d1c739416 as mutable: failed to open: No such file or directory 2. What is the Version-Release number of the kernel: 6.14.0-0.rc3.29.fc42 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes, I downgraded the kernel to version 6.12.0-65.fc42.x86_64 and it worked. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes, just try to install (or reinstall) a firmware update using fwupdmgr 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Yes, nvidia kernel module is loaded (package from rpmfusion). But it is reproducible the same without the nvidia module, so not related. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
Created attachment 2077237 [details] Boot messages
I bisected it to: commit 908af31f4896f2c0645031f8b74a89d3a8beb5b9 Author: James Bottomley <James.Bottomley> Date: Sun Jan 19 10:12:12 2025 -0500 efivarfs: fix error on write to new variable leaving remnants Make variable cleanup go through the fops release mechanism and use zero inode size as the indicator to delete the file. Since all EFI variables must have an initial u32 attribute, zero size occurs either because the update deleted the variable or because an unsuccessful write after create caused the size never to be set in the first place. In the case of multiple racing opens and closes, the open is counted to ensure that the zero size check is done on the last close. Even though this fixes the bug that a create either not followed by a write or followed by a write that errored would leave a remnant file for the variable, the file will appear momentarily globally visible until the last close of the fd deletes it. This is safe because the normal filesystem operations will mediate any races; however, it is still possible for a directory listing at that instant between create and close contain a zero size variable that doesn't exist in the EFI table. Signed-off-by: James Bottomley <James.Bottomley> Signed-off-by: Ard Biesheuvel <ardb> I've emailed James and he's come up with a fixup patch that I'm just building and testing now. I can work around the behaviour in https://github.com/fwupd/fwupd/pull/8500 (which is also the arguably correct thing to do) but it's going to cause some personal panic as I have to get an updated fwupd out on all distros so we'll need releases for multiple branches.
The fixup branch has been merged upstream now, so hopefully we'll pick this up for the next rc.