Comment # 57 on bug 1175626 from Martin Wilck

(In reply to John Shaw from comment #43)

> This seemed to be working on my machine after the last round of grub2
> updates went through, then this morning a new nVidia driver update came
> (along with about 20 other updates). On reboot with SecureBoot enabled, the
> machine hung after post with a black screen. I rebooted with SecureBoot
> disabled (ie, selected OtherOS in the ASUS bios), and it brought up the MOK
> Manager. However, unlike before the options are now different. There is no
> "enrole MOK", just: Continue, Reset MOK, Delete MOK, and enrole key and
> enrole hash from disk.

I think I understand this now, at least partially. The explanation is similar
to what I wrote in comment 48. Can you confirm that the *version* of the Nvidia
driver was different, with only the *release* differing? Because the driver
package was using only the *version* (and not the release) in the certificate
file name, the package update would create both an import and a deletion
request for the same (new!) key at the same time, rather than a delete request
for the old and an import request for the new one. Not sure how MokManager
would deal with that, but your comment shows that it offered the key only for
deletion. The latest Nvidia package fixes this by adding the release to the
certificate file name.

If it's only that, you should be able to recover from the problem by booting
into a non-graphical environment, uninstalling the nvidia-gfx0$X package, and
installing it again.

I don't understand why any of this would cause your GRUB menu not to be shown.
Normally these keys wouldn't be used until user space tries to load the nvidia
driver. By that time, you should be past grub and past lots of boot messages
from the kernel. The only explanation I have for that is that mokmanager might
crash while trying to deal with the "contradictory" mok requests.

(In reply to John Shaw from comment #37)
> (In reply to Martin Wilck from comment #36)
> > The question is if the BIOS fails to verify the shim, or shim fails to
> > verify any of the follow-up binaries. Can you check this e.g. with the UEFI
> > shell?
> 
> I don't know how to check this in the UEFI shell. Can you explain?

If you don't have an existing UEFI shell boot entry already, grab one. See e.g.

> https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obtaining_UEFI_Shell

Next you need to copy this to your EFI boot partition, and find a way to make
your BIOS boot it. Either the BIOS has a way to boot a specified EFI binary
directly, or you could use efibootmgr to craft a suitable entry for it.

Once in the shell, you can move around and run commands a bit like on good old
DOS. You may have to enter a "drive" first, which would look like "fs0:". The
"map" command can be used to see drives that the shell has recognized. The test
would look roughly like this:

> fs0:
> cd \EFI\BOOT
> bootx64.efi # or whatever else you want to boot

The advantage is that you would see some error messages in this environment,
e.g. if the binary's signature can't be verified by the BIOS.