This never happened when I ran Fedora, but it happens every time a new kernel is installed in openSUSE Tumbleweed. During the first boot after the new kernel install, I am asked for the MOK password. I used mokutil to set a password, but that password and the root password never work. All that works is to hit return until the failure limit is reached, then it successfully boots. This is ludicrous! If the boot is going to succeed, why have all those failed password checks? Has anyone ever filed a bug about this?
The root password is supposed to work. And it works here.
It won’t happen for every kernel. When you install a new kernel, “mokutil” is used to add the key that signed this kernel. But if the key is already there, you won’t have to do it again.
I’ll note that I am booting with grub2-efi installed by openSUSE. I do not know what happens if you are booting with a bootloader from Fedora or Ubuntu (to mention two examples).
Interesting, I’ll keep trying the root password. It’s a fresh install using the Tumbleweed boot loader with Windows 10. When the root password didn’t work, I used mokutil to set the same password. It hasn’t worked yet, however.
I had it now and then, can’t really point it to a minor or major update, did not have it for last few months though (touching wood) but always did use root password to enroll it (or what ever the option is called)
It has nothing to with kernel version. Kernel RPM includes certificate used to sign it (public part of course) and automatically submits enrollment request in its postinstall script. It first checks whether certificate is already enrolled, so it is normally done only once. Certificates change very infrequently. I have (had) two on TW VM installed about an year ago; one issued in 2013 valid through 2023 and one issued in 2020 and valid through 2029 so I do not expect any change until around 2026.
You can see it by explicitly removing all enrolled certificates and then reinstall/update kernel RPM. You get prompted on next reboot but not on subsequent updates.
I see two certificates there (I’m running Leap 15.2).
When I search for those in Yast Software Management, with “File list” checked for search, I see that one of those certificates was provided by “shim” and the other was provided by “kernel-default”.
I assembled my first machine supporting secure boot in 2014. Since then I did dozens installations and always uncheck “Enable Secure Boot Support”. Sometimes I make a mistake. The fix is invoking “yast2 bootloader”, unchecking “Enable Secure Boot Support” and clicking “Ok”.
This only currently installed kernels. If last year kernel had different certificate, it is already gone from /etc/uefi/certs, but it likely still remains in firmware (unless you reset it).
I think it is removed from firmware, too (with user permission). I recall seeing the prompt to remove a certificate. (I remember choosing to not remove).
For some reason, I can’t edit my previous post. After checking out yast2 bootloader, I see no option to change Secure Boot Support. But I did try adding a password, so I can see what happens next kernel update. BTW, this happens even for updates like today’s, kernel 5.6.14-1.5 to 5.6.14-1.6.