Boot Grub2 with Secure Boot using Shim and MOK Manager

Secure Boot is designed to prevent non-Windows OS from booting. However, you can still boot Grub2 with Secure Boot using Shim and MOK Manager. And from Grub2, you can boot into other operating systems.

Introduction

My computer does not have Secure Boot, I have not been able to test this feature in a while. Although the AIO Boot theory supports booting Grub2 with Secure Boot using Shim and MOK Manager, I have never tried it. But some users have confirmed that it works, Steve Si (author of Easy2Boot) wrote an article here. With VMware Workstation 14, I was able to try and it really works as expected.

Boot Grub2 with Secure Boot using Shim and MOK Manager

It does not work on all machines, and we can not chainload to .EFI files if it has not been signed (eg, rEFInd, Clover). You also need to perform additional steps on the MOK Manager. So the best way is to disable Secure Boot.

AIO Boot uses Shim (bootx64.efi is renamed from shimx64.efi) to boot at the first stage. Then Shim will load Grub2 (grubx64.efi) in the second stage. You can find lots of useful information about Secure Boot on Ubuntu and rEFInd.

If your computer does not have Secure Boot, you can boot from USB in VMware Workstation. Just enable UEFI mode and select Enable secure boot. Then boot Grub2 with Secure Boot using Shim and MOK Manager through the steps below.

VMware Workstation - UEFI - Enable secure boot

Boot Grub2 with Secure Boot

You only need to do the steps below once.

  1. You will see a blue screen with the following messages: ERROR – Verification failed: (15) Access Denied!. Press Enter to continue.
    ERROR - Verification failed (15) Access Denied!
  2. In the Shim UEFI key management screen, press any key to perform MOK management.
    Grub2 Secure Boot - Shim UEFI key management
  3. Perform MOK management: choose Enroll hash from disk, press Enter to continue.
    Grub2 Secure Boot - Perform MOK management
  4. You will see the partitions in the next Select Binary screen. Select a partition of the AIO Boot, which contains the file /EFI/BOOT/grubx64.efi and /EFI/BOOT/bootx64.efi.
    Grub2 Secure Boot - Select Binary
  5. Hit Enter and go to the path containing the file grubx64.efi. Select grubx64.efi in the list and press Enter to continue.
    Grub2 Secure Boot - Enroll hash from disk
  6. [Enroll MOK]: Continue.
    Grub2 Secure Boot - Enroll MOK
  7. Enroll the key(s)? Yes.
    Grub2 Secure Boot - Enroll the key
  8. Ok you will now return to the Perform MOK management screen in step 3. Repeat steps 3 through 7 again. But you need to select bootx64.efi in step 5 instead of grubx64.efi. This means that we will “enroll” both grubx64.efi and bootx64.efi.
  9. After “enroll” for both grubx64.efi and bootx64.efi files. Select Reboot to reboot the system.

Limitation

You can not load the module after booting into Grub2, error given: error: Secure Boot forbids loading module from (hd1)/boot/grub. AIO Boot has embedded all necessary modules into grubx64.efi, these modules have been preloaded.

You can not chainload .EFI files that have not been signed. Clover and rEFInd have not been signed and it will not be able to boot from Grub2. Error given: error: cannot load image. And this also happened to Microsoft’s .EFI files, specifically booting into WinPE on the AIO Boot DVD.

You should disable Secure Boot so that AIO Boot can work as expected. Finally leave a comment to let me know that it works on your computer.

 

Leave a Reply

Your email address will not be published. Required fields are marked *


15 thoughts on “Boot Grub2 with Secure Boot using Shim and MOK Manager”

  1. Hi Tu. Thanks for AIO Boot!

    I was able to successfully get UEFI to work with AIO Boot with the process you listed above. However I would like to remove those changes. How can I do that?

    1. Actually I don’t have a computer that supports Secure Boot for testing.
      But I think you can delete its key in the BIOS.

      1. Sounds good. In fact I’ve already deleted the secure boot keys from within the BIOS, however when I try to test AIO Boot again by attempting to boot via UEFI, it continues to work.

        If I deleted the keys from BIOS, why would it continue to boot under UEFI?

        Hope you don’t mind the questions, I appreciate any insight.

    2. Quick update – I think I managed to solve the problem. Within the BIOS/UEFI I had done all of the following multiple times: deleted the keys, cleared the CMOS, reloaded the keys, and resetup the BIOS/UEFI, however the drive still behaved differently than I thought it would. My last step was to reflash the BIOS/UEFI, and that thankfully that got the drive behaving like I thought it should (as if I had never enrolled keys/hashes). I’m wondering if this is a sign of the UEFI implementation on my motherboard is buggy, or if my understanding of what happened during the key/hash enrollment is lacking? Will test again more later.

      1. Thanks for the useful information. I think you should ask these questions to SHIM and MOK Management developers.

  2. This function works very well, my friend! Do I need to select the files in order? First “bootx64.efi”? Second “bootx64.efi”? Or does the order matter? Thank you!

  3. after in step 3, i cannot continue to step 4, i don’t know why, it happen in my laptop lenovo g40-80.

  4. It doesn’t work on my laptop, i think there are a few steps missing.
    The client can’t find bootx64.efi and then grubx64.efi. It’s looking in AIO folder and actually i only can find them in EFI folder. Can you tell me what am i doing wrong?