Talk:Fwupd
fwupd doesn't detect UEFI ESP partition mounted to /efi
I just did a fresh install on my machine, and put my UEFI ESP directory at /efi as suggested in https://wiki.archlinux.org/index.php/installation_guide#Mount_the_file_systems . When I went to set up fwupd I ran `fwupdmgr refresh` and received a warning directing me to this url: https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found
Not wanting to deal with moving my ESP partition's mount point, I use the solution mentioned there by setting OverrideESPMountPoint directly.
I wonder if there is another problem with my system that this wasn't detected properly? If not, should we 1. the installation instructions 2. add a message to this article to avoid this problem?
—This unsigned comment is by Idbentley (talk) 00:25, 22 November 2020 (UTC). Please sign your posts with ~~~~!
- I have now added the issue to the troubleshooting section. Adrian5 (talk) 14:58, 19 February 2021 (UTC)
Why not just add a simple comment like, "Ensure udisks2 is installed, otherwise fwupdmgr will fail to detect your esp"? This can be added in the main section Setup for UEFI upgrade. Since it's not, I spent too much time reading the main instructions, thinking I was doing something wrong. Pound Hash (talk) 23:06, 24 December 2021 (UTC)
- Thanks. Page is now updated. And some TroubleShooting sections should be merged into Installations/Configurations in other pages too. Please help identify and fix them if you can. --Fengchao (talk) 13:26, 21 December 2022 (UTC)
Using sbctl to sign fwupd EFI files
I have a plan to use sbctl to generate keys and certificates for my new ThinkPad X1 Carbon, 11th gen, and enroll them along with the Microsoft certs when I install Arch on it in a little over a week. Instead of managing keys separately, and using sbsign, I was going to try to use sbctl sign to sign the fwupd EFI executables. Since I'm not ready to test whether this will work yet, I didn't want to edit section 3.2.1 to mention this method.
Once I'm able to test this, I'll update section 3.2 with this method, and move the older method down. Ectospasm (talk) 22:28, 16 December 2023 (UTC)
symlink and EXTRA_SIGN confuse me
The current documentation for 3.2.1 says
"Instead of a pacman hook, you can also create a symlink from /usr/lib/fwupd/efi/fwupdx64.efi to /usr/lib/fwupd/efi/fwupdx64.efi.signed, and add the file to the EXTRA_SIGN list in /etc/sbupdate.conf"
How does this work when usr/lib/fwupd/efi/fwupdx64.efi
is an actual file? Is a hard link meant instead of a symlink?
Or do you have to delete fwupdx64.efi first?
"Add the file"...? Which file....fwupd64.efi I guess, but how do you add it exactly to /etc/sbupdate.conf, i.e. what kind of formatting does /etc/sbupdate.conf require in order to properly add it to the EXTRA_SIGN list? Sparrow (talk) 08:09, 22 August 2024 (UTC)
RFC: new section about auto-update checking
I made this for myself, but I think it may also be useful for others.
I accomplished it like this, using a systemd timer:
/usr/local/lib/fwupd-check/firmwarecheckoutofdate
#!/usr/bin/bash set -euo pipefail fwupdmgr get-updates --json | jq -e '.Devices != []' > /dev/null
/usr/local/lib/fwupd-check/firmwareoutofdatenotify
#!/usr/bin/bash set -euo pipefail notify-send -a "Firmware Updater" -i dialog-warning -u critical "A firmware update is available." "Run <i>sudo fwupdmgr upgrade</i> to resolve this issue."
/usr/local/lib/systemd/user/fwupd-check.service
[Unit] Description=Weekly firmware update check with notification Wants=graphical-session.target After=graphical-session.target ConditionUser=!@system ConditionPathIsDirectory=/home/%u [Service] Type=simple ExecCondition=/usr/local/lib/fwupd-check/firmwarecheckoutofdate ExecStart=/usr/local/lib/fwupd-check/firmwareoutofdatenotify
/usr/local/lib/systemd/user/fwupd-check.timer
[Unit] Description=Weekly firmware update check with notification ConditionUser=!@system [Timer] OnCalendar=weekly Persistent=true [Install] WantedBy=timers.target
This was based on work done by secureblue, which is licensed under the Apache 2.0 license. Many thanks to them. See:
- https://github.com/secureblue/secureblue/blob/live/files/system/desktop/usr/libexec/secureblue/firmwarecheckoutofdate
- https://github.com/secureblue/secureblue/blob/live/files/system/desktop/usr/libexec/secureblue/firmwareoutofdatenotify
- https://github.com/secureblue/secureblue/blob/live/files/system/desktop/usr/lib/systemd/user/secureblue-firmware-check.service
- https://github.com/secureblue/secureblue/blob/live/files/system/desktop/usr/lib/systemd/user/secureblue-firmware-check.timer
Then, we use sudo systemctl daemon-reload && systemctl --user --now enable fwupd-check.timer to enable it.
Note that this requires notify-send, jq, fwupdmgr and a notification daemon to work, which would be clarified in the article, of course. And it is only meant for graphical sessions such as KDE Plasma. In doubt, I think this also requires sudo systemctl enable --now fwupd-refresh.timer, as to have up-to-date metadata available.
So, I have a few questions:
1. Is it a good idea to include this in the article? If not, why so?
2. The way I presented it, is it good to fit in the article? Should anything be changed? For example, should those files be created in the user's home rather than /usr/local? If so, where would we store the non-systemd files? Is there a FHS-compliant way to store them?
Thanks for your attention, fellow editors. --TheSleuth (talk) 18:49, 8 February 2026 (UTC)
- It has come to my attention that
~/.local/lib/may also be used to store the files that reside in/usr/local/lib/. --TheSleuth (talk) 21:06, 8 February 2026 (UTC)