On Sunday, my computer—running Silverblue 44 with Secure Boot enabled—displayed “Invalid signature detected” and “No option to boot” error messages. The computer failed to install the subsequent bug fix, and the error message persisted when using Secure Boot. Naturally, the system boots fine without Secure Boot, but I would prefer to use it, as this is my primary operating system for all official and financial matters. Consequently, I downloaded the Silverblue 45 Prerelease, reinstalled the system, and applied all available updates. Despite this, I still receive the “Invalid signature detected, no option to boot” error message when attempting to use Secure Boot. The computer is an HP ProDesk 600 G1 model; it had been working perfectly until now. What can I do in this situation? Thank you for reply!
Did this happen suddenly, or after a change by you?
I’ve not seen this happen with no apparent reason.
Also would you please show us this:
inxi -ezzx
are there any keys shown?
mokutil --list-enrolled
And welcome to the forum @gaborujvari
Perhaps this is one of the systems where the Microsoft certificate for third party software is disabled by default. Thus can usually to changed in the firmware setup settings.
Had you updated the BIOS recently?
On Sunday evening, I restarted the computer after installing updates, and that’s when the error message appeared because Secure Boot was enabled. It boots perfectly without Secure Boot. Later, an official fix was released for the Silverblue signing keys, meaning the error was originally caused by a faulty update. The problem is that the computer failed to install this update (for the signing keys), so the error persists. The computer boots normally with Secure Boot when using a different operating system. I have another machine running Windows 10; I moved its drive to the ProDesk, and it boots with Secure Boot enabled, so the issue is specific to Silverblue. I also updated the BIOS to the latest available version to see if that was the cause, but nothing changed. I reinstalled the system using Silverblue 45 Prerelease, yet Secure Boot still doesn’t work. I don’t quite understand it; I’ve been using Silverblue for four years and have never encountered a problem I couldn’t solve on my own—this one seems a bit mysterious. Of course, it is usable without Secure Boot, but I would prefer it to work. I have attached the requested syntax details:
gaborujvari@Silverblue:~$ inxi -ezzx
bash: inxi: command not found
gaborujvari@Silverblue:~$
gaborujvari@Silverblue:~$ mokutil --list-enrolled
[key 1]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
22:39:af:04:13:0c:44:44:b3:f3:77:ed:be:1a:f7:86
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
Validity
Not Before: Jul 13 17:31:16 2020 GMT
Not After : Jan 19 03:14:07 2037 GMT
Subject: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
ab:c4:41:ad:cb:7a:50:89:66:65:f0:09:de:db:91:2b:
b7:e1:7b:1e:4b:28:c5:29:31:a5:db:15:54:44:df:f5:
c8:b2:b6:0f:8f:18:90:2a:d2:75:b6:1c:1e:57:1b:c2:
6c:8d:88:5b:55:49:0c:19:97:dc:46:c9:c5:c6:ba:8d:
70:38:87:dd:9c:cd:79:2b:e9:74:b4:87:cc:e0:6d:b7:
3a:8e:5d:58:fe:53:70:5d:ca:91:a3:52:8d:2f:ac:22:
0e:5d:8a:0e:75:fb:51:be:f4:e4:cb:a9:45:2f:a2:06:
1b:64:97:90:cd:d6:0f:a1:63:be:85:4d:f3:79:c9:09:
e6:c4:50:6a:e2:e9:e4:f2:a6:06:de:91:7b:71:54:2b:
97:57:ca:6d:32:30:05:7b:30:db:6f:8c:e4:95:2e:0c:
d1:a8:af:f6:ee:3b:9a:08:d6:64:64:94:81:6d:f2:ae:
74:f3:d0:03:82:5e:4a:f3:8f:c9:05:c5:1d:99:ce:43:
8d:d1:9b:5f:cf:8e:18:5d:eb:e0:b6:12:1e:68:de:eb:
2d:0a:85:96:67:4b:56:48:9a:9a:e4:40:ee:f5:e0:72:
77:6b:d7:72:42:cd:7f:9e:7d:0a:e6:35:f5:0f:38:4f:
d1:40:f5:66:a3:34:4c:5e:85:3b:f0:d8:83:22:8d:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
Authority Information Access:
CA Issuers - URI:Features/SecureBoot - Fedora Project Wiki
X509v3 Authority Key Identifier:
B2:80:C7:AE:6B:88:4E:0F:4D:2A:0D:87:24:C2:5E:AF:6C:65:C3:26
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
B2:80:C7:AE:6B:88:4E:0F:4D:2A:0D:87:24:C2:5E:AF:6C:65:C3:26
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
6a:ea:11:d7:96:b3:7f:ef:aa:b8:3f:dd:c7:74:c9:5c:e7:14:f5:73:5d:c4:b4:22:
b7:f1:82:d2:ff:3d:4b:55:a0:db:c2:3a:5c:d8:16:25:02:2f:64:36:b9:61:07:f5:
7d:bd:00:d0:c0:c1:ad:72:48:9c:82:c7:5a:97:47:52:61:fc:3a:8a:9f:92:e0:11:
a7:fd:89:30:e0:f7:72:42:d9:e2:7b:41:61:17:b3:e7:69:80:78:1e:3b:bb:77:52:
eb:c6:4e:80:b1:b4:2d:b6:66:a2:c0:84:59:e1:eb:bf:b1:21:2a:1a:e1:73:0a:74:
62:98:48:6e:44:ce:80:fa:e2:5b:67:85:39:86:61:6e:6b:41:1f:30:15:c4:52:4d:
6a:d7:2b:7f:0d:8d:ac:8c:a4:ea:15:c0:79:a3:e1:c1:39:3e:3a:70:d3:bc:bf:d1:
81:95:70:2b:75:c3:7c:bc:e2:f1:69:76:51:ca:cd:c9:60:86:bc:c5:2d:25:8d:43:
81:24:0c:3e:b7:ce:77:72:ad:08:83:d8:31:0f:e3:59:1d:ed:d3:29:61:e8:d7:c2:
9d:a9:dd:cf:4f:5b:61:05:1f:67:bc:6e:ee:c0:50:d3:85:80:de:69:99:a4:60:33:
90:40:7d:01:ed:82:4c:93:f3:cb:1f:dd:5f:a0:9c:c3
gaborujvari@Silverblue:~$
Please copy any errors from this, run all 3 seperatly:
sudo fwupdmgr refresh
sudo fwupdmgr get-updates
sudo fwupdmgr update
Might shed some light.
It just might be typically caused by unsigned third-party kernel modules (e.g., Nvidia drivers) or corrupted EFI signatures due to firmware updates.
Actually, the relevant certificates are inspected by mokutil --db --short. That shows the ones used to validate the shim.
I noticed you did a fresh install of 45, so the shim or grub should be up-to-date.
The requested syntax details:
gaborujvari@Silverblue:~$ sudo fwupdmgr refresh
[sudo] password for gaborujvari:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See PluginFlag:capsules unsupported · fwupd/fwupd Wiki · GitHub for more information.
Metadata is up to date; use --force to refresh again.
gaborujvari@Silverblue:~$
gaborujvari@Silverblue:~$ sudo fwupdmgr get-updates
[sudo] password for gaborujvari:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See PluginFlag:capsules unsupported · fwupd/fwupd Wiki · GitHub for more information.
Devices with no available firmware updates:
• Windows Production PCA
• Hewlett-Packard UEFI Secure Boot DB Key
• Hewlett-Packard UEFI Secure Boot Key Exchange Key
• KEK CA
• Option ROM UEFI CA
• SSD 870 EVO 500GB
Devices with the latest available firmware version:
• UEFI CA
• UEFI dbx
No updates available
gaborujvari@Silverblue:~$
gaborujvari@Silverblue:~$ sudo fwupdmgr update
[sudo] password for gaborujvari:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See PluginFlag:capsules unsupported · fwupd/fwupd Wiki · GitHub for more information.
Devices with the latest available firmware version:
• UEFI CA
• UEFI dbx
Devices with no available firmware updates:
• Windows Production PCA
• Hewlett-Packard UEFI Secure Boot DB Key
• Hewlett-Packard UEFI Secure Boot Key Exchange Key
• KEK CA
• Option ROM UEFI CA
• SSD 870 EVO 500GB
gaborujvari@Silverblue:~$
Here it is:
gaborujvari@Silverblue:~$ mokutil --db --short
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
69525b095f Hewlett-Packard UEFI Secure Boot DB Key
b5eeb4a670 Microsoft UEFI CA 2023
3fb39e2b8b Microsoft Option ROM UEFI CA 2023
gaborujvari@Silverblue:~$
All I know enable “Capsule Updates” in your HP system’s firmware setup (BIOS/UEFI) screen. If the option is not present, your hardware may be too old (pre-2015) to support the ACPI ESRT table required for fwupd-managed UEFI updates.
-
If you do not need UEFI firmware updates: You can suppress the warning by adding
DisabledPlugins=test;test_ble;invalid;biosto the/etc/fwupd/fwupd.conffile (or/etc/fwupd/daemon.confon some systems). -
If you need UEFI firmware updates: You must enable the setting in the BIOS. If the BIOS version is outdated, you may need to update it manually from HP’s support page first to gain capsule support.
I see that all the required certificates are up-to-date, so this is now eliminated as a possible cause.
By the way, I have a freshly installed test silverblue in a virtual machine and it boots fine with secure boot enabled.
This computer was manufactured in 2014, so it is likely obsolete. The latest available BIOS version - from 2020 - is installed; there is no newer one. Your are probably right, as the installer warns during the operating system setup that the HP UEFI system is no longer supported, so Secure Boot might not work. In any case, it was still working as recently as Sunday. Thanks for the help!
Unfortunately, it looks like this computer is too old (manufactured 2014) and the HP UEFI system is no longer supported - at least in Silverblue - so Secure Boot likely won’t work with it anymore. Thanks for the help!