2

I am trying to sign an nVidia kernel and a virtualbox module using mokutil.

My problem is that the Shim IEFI Key Management is not showing up after reboot so that I can enroll the key.

Using mokutil --list-new, I can see that my key is scheduled to be enrolled. Also, the Secure Boot feature is enabled, alongside the mokutil validation. However, after rebooting, I expect the Shim IEFI Key Management to load, but I boot to Ubuntu, and the keys remain not enrolled (executing mokutil --list-enrolled gives: Failed to read MokListRT: No such file or directory)

My OS is Ubuntu 16.04 LTS, the nvidia driver I am trying to sign is 384.59, and my virtualbox version is 5.1.26.

Thank you in advance.

1 Answer 1

2

There are several ways you can proceed, but they might not all work equally well, depending on your hardware and needs:

  • Some EFIs provide an option to launch arbitrary programs. You can use this feature to launch MokManager (MokManager.efi or mmx64.efi in the same directory that holds shimx64.efi and grubx64.efi). This is likely to be the most direct approach, but this EFI feature is relatively rare, and even if it's present, there's no standardization on where it's located in the EFI's menu system, so you'll have to go looking for it.
  • Prepare a USB flash drive with a FAT filesystem, create an EFI/BOOT directory on that drive, and copy some files from the /boot/efi/EFI/ubuntu directory to the EFI/BOOT directory on the USB flash drive: Copy shimx64.efi and rename it to bootx64.efi in its new location and copy MokManager.efi or mmx64.efi without renaming it. (Your Ubuntu probably has mmx64.efi, but I don't recall when it was renamed.) You can then boot to the USB flash drive, which should launch MokManager.
  • You can use an EFI shell program to do the job. Some EFIs have such a program built-in, but this is just as rare as the ability to launch arbitrary programs. If yours doesn't have such a feature, you can download one from the Internet -- see this Arch Linux wiki page for some pointers. Put the program on a FAT USB flash drive, named EFI/BOOT/bootx64.efi. You should then be able to boot the USB flash drive into the shell and use it to run MokManager. Note, however, that you'll need to temporarily disable Secure Boot to run the EFI shell. You'll also need to learn enough of the EFI shell to navigate to the MokManager binary and run it. (This shell is similar to a DOS or Windows command prompt. The Arch wiki provides some tips on how to use it.)
  • You can boot using my rEFInd boot manager on a USB flash drive or CD-R. This should give you an icon to launch MokManager, or at least an EFI shell. As with launching an EFI shell directly, you'll need to temporarily disable Secure Boot for this option to work.
  • You can install rEFInd to your hard disk by using the PPA or Debian package. When you reboot, MokManager should launch, enabling you to enroll rEFInd's keys and your own keys. This is a drastic method, since it will leave rEFInd in control of your boot process. Thus, unless you're sure you want to switch to rEFInd as your main boot manager, this is not a good option. I mention it only for completeness.

I'd try the options in more-or-less this order, although you can use your own judgment and skip something if you don't like the way it sounds or know it won't work.

2
  • 1
    Thank you a lot! What I had to do was: adding the mmx64.efi and shimx64.efi to the set of trusted EFIs so that they are allowed to be executed, via BIOS, and giving them the highest boot order. Consequently, after a reboot, the SHIM IEFI launched and I was able to enroll the keys. Appreciated.
    – Rafs
    Aug 24, 2017 at 9:46
  • I experienced precisely the same issue, but the solution for me was twofold. Firstly, executing grub-install --uefi-secure-boot allowed me to see the MOK Enrollment interface during boot (not sure why GRUB was lacking EUFI support to begin with). Despite adding my MOK and rebooting, the boot process would yield a black screen (and I mean pitch-black, even though the monitor was on). Then I thought back to some of Rod Smith's other posts on this subject, and it occurred to me that this might be a video issue, and to disable CSM (Compatibility Support Module) in BIOS. BINGO! Thank you both!!! May 2, 2018 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .