http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c48 --- Comment #48 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Gary Ching-Pang Lin from comment #45)

I guess the update of kernel triggered the enrollment of new signkey and the deletion of the old signkey. But somehow MokNew was gone, so MokManager thought that there was a reset.

How would MokNew go away? The scriptlets in the kernel rpm are written so that the keys won't be deleted as long as the system still has one kernel installed that needs them. Why do we have different signkeys for Leap 15.2, anyway?

~ # rpm -qlp /var/cache/zypp/packages/repo-oss/x86_64/kernel-default-5.3.18-lp152.19.2.x86_64.rpm | grep crt /etc/uefi/certs/F1C08E27.crt ~ # rpm -qlp /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.33.1.x86_64.rpm | grep crt /etc/uefi/certs/F1C08E27.crt ~ # rpm -qlp /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.33.1.x86_64.rpm /var/cache/zypp/packages/repo-update/x86_64/kernel-default-5.3.18-lp152.36.1.x86_64.rpm | grep crt /etc/uefi/certs/F1C08E27.crt /etc/uefi/certs/33CEA71B.crt

We've got two signkeys here with the same subject and slightly different serial number and validity. I guess it depends on the OBS project the kernel's built in, but it's intransparent and confusing for users. == /etc/uefi/certs/33CEA71B.crt == issuer=CN = openSUSE Secure Boot CA, C = DE, L = Nuremberg, O = openSUSE Project, emailAddress = build@opensuse.org serial=FABED8BF409A5E63 subject=CN = openSUSE Secure Boot Signkey, C = DE, L = Nuremberg, O = openSUSE Project, emailAddress = build@opensuse.org notBefore=Aug 3 12:35:39 2020 GMT notAfter=Jun 12 12:35:39 2030 GMT SHA1 Fingerprint=33:CE:A7:1B:A1:6A:67:BA:D8:6B:93:CB:DA:2E:19:A7:E9:DF:95:66 X509v3 Subject Key Identifier: C8:BD:C7:AC:1A:1D:85:96:62:17:FD:93:EB:FC:14:F4:A2:00:B8:14 == /etc/uefi/certs/F1C08E27.crt == issuer=CN = openSUSE Secure Boot CA, C = DE, L = Nuremberg, O = openSUSE Project, emailAddress = build@opensuse.org serial=FABED8BF409A5E60 subject=CN = openSUSE Secure Boot Signkey, C = DE, L = Nuremberg, O = openSUSE Project, emailAddress = build@opensuse.org notBefore=Jan 8 16:25:54 2020 GMT notAfter=Nov 16 16:25:54 2029 GMT SHA1 Fingerprint=F1:C0:8E:27:F3:5F:3F:39:C5:5C:CB:F8:58:18:C6:27:DF:49:4E:34 X509v3 Subject Key Identifier: 03:32:FA:9C:BF:0D:88:BF:21:92:4B:0D:E8:2A:09:A5:4D:5D:EF:C8

...

I forced Yast to reinstall them, rebooted, and its now working (not SecureBoot).

The forced reinstall may have caused harm. When you reinstall (and the version number of the nvidia-gfxG05-kmp-default package is the same as before), the installation procedure will generate a new key with the same file name, overwriting the previous one. Because of rpm scriptlet ordering (%postun is executed after %post), this might lead to the old key remaining present and the new one not being enrolled. I'm not 100% certain about this, but I guess it could happen. It's safer to delete the package and install it again. I'm not saying this is the user's fault. It's rather a corner case that we may have overlooked. It does not apply to the kernel packages.

Reinstalling OS won't change MokList. The most reliable way is to reset the firmware to factory default. You'll need to restore the boot entries after that.

Isn't this is an overkill recommendation? It should be only a last resort measure. Perhaps MokManager should have an option to reset the MokList only. -- You are receiving this mail because: You are on the CC list for the bug.