<< Solved >> Can't Boot with OpenCore Vault

[Gobias]

I have UEFI Secure Boot enabled in BIOS, and I'm able to boot as long as I don't vault OpenCore.

If I set Misc -> Security -> Vault to Secure or Basic and then run sign.command, OpenCore won't boot. It actually opens the BIOS menu instead of displaying an error or falling back to the next disk in my boot order.

I don't have Insyde firmware, but I also tried setting Booter -> ProtectSecureBoot to YES to see if it might fix the issue. It didn't.

I'm running OpenCore 0.8.4 and used the copy of sign.command that was bundled with OC 0.8.4.

Does anybody know what I might be doing wrong?

 

[Gobias]

When I compare the output in Terminal after running sign.command to the screenshot of the output in the OpenCore Post-Install Guide, I see that I don't have two lines:

Issuing a new private key...
Getting public key based off private key...

Maybe that's the problem, but I'm not sure why those lines are missing.

Screenshot from OC Guide on the left, my Terminal on the right:

 

[Middleman]

When I compare the output in Terminal after running sign.command to the screenshot of the output in the OpenCore Post-Install Guide, I see that I don't have two lines:

Issuing a new private key...
Getting public key based off private key...

Maybe that's the problem, but I'm not sure why those lines are missing.

Screenshot from OC Guide on the left, my Terminal on the right:

View attachment 555546

@Gobias,

If it helps there is a guide available online to resolve this if you google 'How do you sign opencore binaries with Secure boot keys?' and check out the link provided. It describes a 6-step process adding keys into your bios and using Ubuntu to sign your drivers. You have to sign everything first before doing the Opencore ones to enable secure boot.

 

[Gobias]

@Gobias,

If it helps there is a guide available online to resolve this if you google 'How do you sign opencore binaries with Secure boot keys?' and check out the link provided. It describes a 6-step process adding keys into your bios and using Ubuntu to sign your drivers. You have to sign everything first before doing the Opencore ones to enable secure boot.

Yes, I’ve actually done that part already. I've had UEFI secure boot working for a couple of weeks now.

It's just vaulting I can't get to work.

 

[Middleman]

Yes, I’ve actually done that part already. I've had UEFI secure boot working for a couple of weeks now.

It's just vaulting I can't get to work.

Right. Well I did notice one thing - there was a Keys folder in the Opencore screenshot, do you have that?

Anyways I found this detailed guide on the process, maybe it can help you

> https://github.com/profzei/Matebook-X-Pro-2018/wiki/Enable-BIOS-Secure-Boot-with-OpenCore

 

[Gobias]

Right. Well I did notice one thing - there was a Keys folder in the Opencore screenshot, do you have that?

I totally missed that. I don't have a Keys folder, but I can't find any mention of a Keys folder (or those files in the folder) in the OC Post-Install Guide or the Configuration.pdf, so maybe that's an outdated screenshot?

Anyways I found this detailed guide on the process, maybe it can help you

> https://github.com/profzei/Matebook-X-Pro-2018/wiki/Enable-BIOS-Secure-Boot-with-OpenCore

Yeah, I used that guide and miliuco's guide to set up UEFI Secure Boot, but neither details the vaulting process.

Someone on another forum recommended I follow the process in the Configuration.pdf, which is different than what's in the OC Post-Install Guide. It gives commands to use create_vault.sh and RsaTool instead of running sign.command. However, this didn't work for me either.

I had been using a dummy USB drive to test vaulting, which is how I usually test making changes to OpenCore. Since vaulting still isn't working, I tried vaulting OpenCore directly in the EFI partition of my macOS drive. When I did that, I got these errors:

OCM: Failed to load image - Access Denied
BS: Failed to start Opencore image - Access Denied
BS: Failed to load Opencore from disk - Access Denied

 

[Middleman]

I totally missed that. I don't have a Keys folder, but I can't find any mention of a Keys folder (or those files in the folder) in the OC Post-Install Guide or the Configuration.pdf, so maybe that's an outdated screenshot?



Yeah, I used that guide and miliuco's guide to set up UEFI Secure Boot, but neither details the vaulting process.

Someone on another forum recommended I follow the process in the Configuration.pdf, which is different than what's in the OC Post-Install Guide. It gives commands to use create_vault.sh and RsaTool instead of running sign.command. However, this didn't work for me either.

I had been using a dummy USB drive to test vaulting, which is how I usually test making changes to OpenCore. Since vaulting still isn't working, I tried vaulting OpenCore directly in the EFI partition of my macOS drive. When I did that, I got these errors:

OCM: Failed to load image - Access Denied
BS: Failed to start Opencore image - Access Denied
BS: Failed to load Opencore from disk - Access Denied

Looks like you may have locked some part of your setup early, that's why it's not recognising.
You're only meant to sign off when everything has been set (including setting the config file).
You will have to disable the Secure Boot first somehow to get back in. Have you disabled CSM?
According to one of the posts I've read, you need to sign the boot loader with an authorized
Secure Boot key - if it isn't then it shows Access Denied. There's a post on AskUbuntu on this 'How to fix Secure Boot error "Image failed to verify with *ACCESS DENIED*" on startup?' you can check out to resolve your issue. You may need to repair the boot sector using a Linux tool.

 

[Gobias]

Looks like you may have locked some part of your setup early, that's why it's not recognising.
You're only meant to sign off when everything has been set (including setting the config file).

When you say, "sign off," do you mean signing for UEFI Secure Boot or signing as a part of vaulting? The way I understood it, this should be the order of things:

1. UEFI Secure Boot Setup
   1. Sign OpenCore files (OpenCore.efi, BOOTx64.efi, Drivers, and Tools) with private keys in Linux (or in my case, WSL)
   2. Create Secure Boot keys in Linux
   3. Add Secure Boot keys to BIOS
2. Vaulting OpenCore
   1. Set Vault to Secure in config.plist
   2. Run either sign.command or create_vault.sh + RsaTool to create vault.plist and vault.sig as well as sign OpenCore.efi
3. Enable UEFI Secure Boot in BIOS

If anything is modified in the EFI folder after vaulting (such as editing config.plist or signing OpenCore files for UEFI Secure Boot), then OpenCore won't boot.

However, there's a UEFI Secure Boot Troubleshooting section in Configuration.pdf that has a different order:

6. Sign all the installed drivers and tools with the private key. Do not sign tools that provide administrative access to the computer, such as UEFI Shell.
7. Vault the configuration as explained Vaulting section.
8. Sign all OpenCore binaries (BOOTX64.efi, BOOTIa32.efi, OpenCore.efi, custom launchers) used on this system with the same private key.

Step 8 coming after vaulting doesn't make sense to me because modifying those files after vaulting would prevent OpenCore from booting, right?

Also, step 6 says not to sign UEFI Shell, but profzei's and miliuco's guides say to sign it.

You will have to disable the Secure Boot first somehow to get back in.

I put a copy of my last working EFI folder on a dummy USB before vaulting OpenCore on my macOS drive, so I used the dummy drive to get back in.

Have you disabled CSM?

Yes, CSM is disabled.

According to one of the posts I've read, you need to sign the boot loader with an authorized
Secure Boot key - if it isn't then it shows Access Denied.

I'm pretty sure I did that as a part of the UEFI Secure Boot setup.

There's a post on AskUbuntu on this 'How to fix Secure Boot error "Image failed to verify with *ACCESS DENIED*" on startup?' you can check out to resolve your issue. You may need to repair the boot sector using a Linux tool.

I'm going to take a look at that post when I get a chance.

 

[Gobias]

Solution: There is a very specific order in which OpenCore files must be signed for UEFI Secure Boot and vaulted:

1. In Linux: Digitally sign all OpenCore files ending in .efi (BOOTx64.efi, Drivers, and Tools) except OpenCore.efi.
2. In macOS: Vault the EFI folder with the signed files, including OpenCore.efi, which isn't signed yet.
3. In Linux: Sign OpenCore.efi, which already has Vault applied, with the same key from step 1.

If you follow a different order, OpenCore won’t boot.