Every time I use fwupdmgr to assess hardware security, it fills the security events log (found in Settings → Privacy & Security → Device Security → Security Events, or via fwupdmgr security) with erroneous/inaccurate warnings, alternating between generating ✘ CET OS Support changed: Supported → Not supported and ✔ CET OS Support changed: Not supported → Supported every 20 seconds. Where are these logs stored, and is the process to clear/reset them trivial?
I had a look at the source code for fwupdmgr and got as far as I think it’s getting the data from the kernel over a netlink socket.
As to where the kernel is getting the info I’m not sure.
I wonder if its in the UEFI BIOS - but that a wide a**** guess.
I doubt it, because the reports are not accurate to the UEFI settings. I disabled Secure Boot during testing for a different problem, and fwupdmgr failed to recognize that it was inactive. I suppose I will just wade through the spam every time as I can’t find a solution either.
I do wonder what is reported if you boot from a usb live image and run the report from it. If its the same log then I assume it coming from the motherboard bios.
It is not the same log. Unlike my full install, which contains the erroneous logs (and says that secure boot is not functioning due to an invalid key, even though it is fine), the live USB’s fwupdmgr has no logs and says that everything is in working order.
Update: Running sudo rm -f /var/lib/fwupd/pending.db and then sudo systemctl restart fwupd will clear the logs generated by fwupdmgr security and found in GNOME Settings.
As I mentioned earlier though, there is a strange discrepancy. fwupdmgr security says that everything is in working order regarding Secure Boot, and everything aside from RAM encryption is enabled, but in GNOME Settings → Privacy & Security → Device Security, it says “Secure Boot has Problems”. I originally thought that this GUI menu mirrored fwupdmgr’s analysis, but this does not seem to be the case. Does anyone have insight into where GNOME is getting this extra, inaccurate information?
1 Like
Final update for anyone else who has this problem. Resetting Secure Boot to its default configuration in my UEFI settings resolved GNOME’s complaint about an “invalid key”, even though there never was one. If anyone cares enough about fixing the cosmetic inaccuracy, that should set things right.