Bugzilla – Bug 1220087
Make MOKManager to wait indefinitely for user input
Last modified: 2024-06-17 11:08:02 UTC
Repro: 0. SecureBoot is enabled and working properly, openSUSE (Tumbleweed) is installed and `mokutil --sb-state` reports "enabled" 1. NVIDIA proprietary driver is installed and kernel is upgraded OR NVIDIA proprietary driver is just got installed 2. Reboot 3. A MOKManager prompt shows up Expected: the MOKManager is waiting for user input indefinitely, or for couple of minutes at least. Instead: the timeout elapses, the PC reboots and NVIDIA driver doesn't load because the signature wasn't imported This is especially annoying when trying to do an unattended upgrade involving kernel package.
The timeout of MokManager can be set by 'mokutil --timeout <seconds>'. For example, to make MokManager wait 30 seconds: # mokutil --timeout 30 To disable the timeout, just set the timeout to '-1': # mokutil --timeout -1
(In reply to Gary Ching-Pang Lin from comment #1) > The timeout of MokManager can be set by 'mokutil --timeout <seconds>'. > For example, to make MokManager wait 30 seconds: > > # mokutil --timeout 30 > > To disable the timeout, just set the timeout to '-1': > > # mokutil --timeout -1 Thank you for the suggestion. There's the quirk though — this change is one-off, according to MokManager's source at https://github.com/rhboot/shim/blob/126a07ebc30bbd203b6966465b058da741b2654b/MokManager.c#L2170-L2175, i.e. the EFI variable (stored in NVM, I guess?) is *deleted* after reading it (if I'm reading the source correctly, of course). Which stays in line with the actual behavior — the command you provided did disable MokManager's timeout, but exactly once. That's not exactly very user-friendly behavior, especially for the unattended dist-upgrade case (offline update withe packagekit). In rare cases, one can miss importing even a kernel signing key (we had one updated recently, right?) which could render a whole system unbootable and recovery would require disabling SecureBoot, AFAIU.
There are some systems having problem to display the menu properly and just showing a blank screen. Disabling the timeout by default may be problematic for those systems.
(In reply to Gary Ching-Pang Lin from comment #3) > There are some systems having problem to display the menu properly and just > showing a blank screen. Disabling the timeout by default may be problematic > for those systems. Could you elaborate a bit further how is current behavior an improvement of their user experience? Aren't their systems borked anyway since there's no way to know the MOKManager UI expects the input with blank screen?