OpenCore Appears to "Take Over" Boot Process

[dakanji]

INTRODUCTION

Hello,

First off, thanks for the great work done on OC. It has really helped a lot of us on legacy Apple products such as my Early 2008 MacPro.

I wanted to raise a issue which is technical in nature hence the post here.

Excuse me but I don't know that much on C prorgramming and everything I will outline is based on surmising from observations and tests.

OBSERVATIONS

It appears that OC is made up of two broad parts (my own simplistic terms below):

• OC Bootstrap
• OC Main

From what I can surmise, OC Bootstrap does the following when my machine is booted:

• It is run very early in the process at a very low level
• It appears to be activated on first run of OC Main and survives NVRAM resets
• It appears to evaluate the config file
  • If RequestBootVarRoutingis true, it appears to load OC Main
  • If RequestBootVarRoutingis false, it appears to check if there is a defined startup disk
    • if there is a defined startup disk, it appears to load this
    • if there is no defined startup disk, it appears to load OC Main

REQUEST

If my summation is broadly correct, can you please consider making it such that the last situation is changed for it to hand things over to the Operating System and let this deal with the situation instead of defaulting to loading OC Main if possible?

JUSTIFICATION

The reason is that currently, having run OC for a while and deciding that I want to change to Refind for various reasons but still want to have OC on my system for various reasons again, the process of blessing Refind results in there not being a defined startup disk ... sudo systemsetup -getstartupdisk returns (null)

When I boot in the expectation that Refind would be loaded, it appears that OC Bootstrap kicks in, finds there isn't a startup disk defined, and proceeds to load OC Main ... basically taking over things in an unexpected/undesirable way.

CONCLUSION

I may of course be totally off base in my surmising but the effect of OC launching when another items is blessed with the intention of booting that instead of OC is observed.

Thanks!

[vit9696]

You cannot bless two programs at the same time. Blessing refind when started from OpenCore will only mark it as the default OS for OpenCore, which it may not even find. To get refind booting you will have to bless it when not running OC.

I don't know what you are trying to do, but things like refind are not supported in the first place. If you need a UI, why cannot you use OpenCanopy (we are aware it is still not fully powerful)?

[dakanji]

Thanks for the response.

To get refind booting you will have to bless it when not running OC.

I can confirm to you that what I called OC Bootstrap appears to still take over the boot process in such instances and it will launch OC Main.

What I am finding is that once OenCore has been run once on a system, it appears to leave something that runs on all subsequent boots and takes control of the boot process. Can you see the issue with this?

Basically, having run OpenCore for a while and liking it but wanting to go back to Refind for the time being (specific reasons are not relevant here) I can't do this.

Also, best to go get distracted by Refind as that is just a specific here and best to describe the issue in general terms.

If you try OpenCore and decide to temporarily run any other boot loader instead,  
OpenCore will always be booted as long as a working OpenCore instance can be found. 

This behaviour should not be the case but it is and that's the issue.

Please don't hastily dismiss this report as invalid. It is not a matter for supporting Refind etc but one of:

• OpenCore appearing to leave something running and taking over the boot process on any machine it has been run on, even if only once ... what I called OC Bootstrap
• Basically, every time you boot your machine ever again, it appears that this bootstrap will determine what boots.

[vit9696]

Well, let me summarise what happens really, because you really miss the idea, and fail to interpret the documentation.

1. BOOTx64.efi aka OC Bootrstrap aka does nothing by itself but loads OpenCore.efi, which resides in the same partition as itself. It does not register itself anywhere or do stuff of this kind.
2. OpenCore aka OC Main loads config.plist, drivers, and boots your operating system with optionally showing the graphics interface. It does not register itself anywhere or do stuff of this kind.
3. OpenRuntime is a driver, which splits boot options into 2 spaces as soon as it is loaded when RequestBootVarRouting is enabled: Firmware boot options and OpenCore boot options.
   • Firmware boot options remain in EFI global variable namespace, and once OpenRuntime is loaded they cannot be accessed from any operating system.
   • OpenCore boot options are empty by default, and this is where the operating systems loaded from OpenCore can specify the default operating system to load.

To make it simple, once OpenCore is loaded with RequestBootVarRouting enabled, no operating system (e.g. macOS with bless) or any UEFI application unaware of OpenCore (like rEFInd or whatever other thing) can change Firmware boot options and thus override OpenCore to not be the default one. This is required for features like Startup disk from macOS and Windows Boot Camp to work well with OpenCore boot picker.

Therefore, to make anything bypass OpenCore you need to effectively run your firmware Boot Picker before OpenCore loads and use CTRL+Enter on the entry you need or disable RequestBootVarRouting.

I hope you see now that pretty much what you posted is not really valid, and that there is no bug anywhere here. I can still answer the questions if there are more, but what I have just written is clearly explained in OpenCore reference manual, and it is strange that you confuse it that badly.

[dakanji]

I hope you see now that pretty much what you posted is not really valid, and that there is no bug anywhere here.

Thank you very much for taking the time to clarify. Really appreciated.

I apologise for my limited knowledge and perhaps very much mixing things up. I will go back and look over everything carefully but will just summarise what I have OBSERVED while noting the very clear explanation of the process you have kindly provided. This is after countless reboots doing elimination by substitution to narrow things down.

OpenCore always handles the boot process when a working OpenCore instance can be
found and sudo systemsetup -getstartupdisk returns (null)

My inference on WHY that is happening is clearly wrong/invalid as you have explained but it DOES happen.

To make it simple, once OpenCore is loaded with RequestBootVarRouting enabled, no operating system (e.g. macOS with bless) or any UEFI application unaware of OpenCore (like rEFInd or whatever other thing) can change Firmware boot options and thus override OpenCore to not be the default one. This is required for features like Startup disk from macOS and Windows Boot Camp to work well with OpenCore boot picker.

Is this a once and for ever effect? I think the answer is most likely "No" but it fits in exactly with what I am OBSERVING.

Basically, I had initially run OpenCore for several weeks (Since 0.5.6) with RequestBootVarRouting enabled. Then, I also enabled RequestBootVarFallback for a while until I realised it was the reason for Kernel Panics which disappeared once it was disabled. I then later decided to disable RequestBootVarRouting and the config sits there with this disabled.

I have since decided to temporarily go on an alternative route but OpenCore is still appears to be my default and persists through NVRAM resets.

The only way to remove it is to make sure the OpenCore location can't be found on boot, go into the Apple Recovery and select a start disk there. After this is done, The apple start disk is used and there is no sign of OpenCore anymore.

If I bless OpenCore at any point afterwards, even with the --nextonly" flag, it will handle all subsequent reboots until it is disabled by selecting a start disk from Apple Recovery.

I understand that this may not fit into how things should be but it is was is observed. Maybe at some point when things are a bit quieter, it could be tested on your side to see if it is actually happening even if not expected to be so.

I will recheck a few things here in the interim. So far, I have found that I can get Refind to boot without interference from OpenCore if I bless it with the "--nextonly" flag. This fits with the general observation as sudo systemsetup -getstartupdisk returns the path to Operating System start file. Blessing without the nextonly flag means sudo systemsetup -getstartupdisk returns (null) and OpenCore jumps in. This is my workaround for now in between Apple Recovery resets.

Thanks again and looking forward to your improvements to OpenCore.

[vit9696]

I read what you posted, and I think I understood what you observe. I believe I have several hints to you, which may help to understand what is going on.

1. EFI\BOOT\BOOTx64.efi file is something that should be found and loaded automatically by the firmware by default according to UEFI specification unless an explicit other option is written to Firmware boot options.
   • After NVRAM reset, if OC Bootrstrap happens to reside on the first partition as seen by your firmware (the order your firmware sees partitions can be any and may vary across the reboots), OpenCore will be loaded.
   • After setting an invalid firmware boot option or an option that cannot be accessed/failed to boot, if OC Bootrstrap happens to reside on the first partition … OpenCore will be loaded.
   • if the firmware iteratively fails to boot all the other partitions but the one with OpenCore, it should work as if OpenCore was the first partition found. With Apple there is an exception of a few other filenames like System\Library\CoreServices\boot.efi having priority, but otherwise it is the same.
2. I think (I cannot be sure as the tool is not open-source or well-documented) sudo systemsetup -getstartupdisk will return NULL when:
   • Something not valid was blessed (i.e. written to boot options, be they firmware or OpenCore depending on how you loaded the os).
   • Nothing was blessed (i.e. boot options are empty)
   • When it just fails to properly print an entry (I wonder if custom blessed entries are even properly supported and not bugged).
3. sudo systemsetup -getstartupdisk can be debugged by executing the following commands:

   sudo defaults write -g StartupDiskDebug -bool true
   sudo systemsetup -getstartupdisk
   sudo defaults delete -g StartupDiskDebug
   

All in all I suspect that you fail to bless rEFInd properly, and all the other things fail to give you the right hint that it failed and why it failed. This is not unlikely with how convoluted and unobvious bless utility is by itself, in fact I often misuse it and try to avoid for this very reason.

This is very unlikely, but I believe I should still mention it just in case. It may not necessarily be your fault at using bless, but that your Mac could fail to bless things when it is booted from OpenCore (with RequestBootVarRouting disabled of course). I am not positive whether this can happen, as it definitely does not happen on any hardware we have at hand, but if it does, it will be very specific to your machine. For example, it could be that NVRAM gets full, or some device path becomes different, some quirk is enabled when it should not be, OpenRuntime.efi has some incompatibility (you can e.g. try to remove it) and so on.

[startergo]

"Something not valid was blessed (i.e. written to boot options, be they firmware or OpenCore depending on how you loaded the os)."
What I have observed is if you "select" boot disk in the startup disk sudo systemsetup -getstartupdisk returns a valid path, but upon reboot it returns NULL again.

[vit9696]

I do not believe OpenCore removes any boot option, so I am afraid that is your firmware going mad. CC @Download-Fritz

[dakanji]

OK. I have managed to find out what was wrong. Very sorry for turning this into a support forum.

The critical information you gave to investigate what was looking like a Boot Coup orchestrated by OpenCore was:

sudo systemsetup -getstartupdisk can be debugged by executing the following commands:

• sudo defaults write -g StartupDiskDebug -bool true
• sudo systemsetup -getstartupdisk
• sudo defaults delete -g StartupDiskDebug

Upon using this on three bless setup cases, the issue became apparent.

CASE 1: Normal OSX Drive as Startup Disk

DEBUG OUTPUT

$ sudo systemsetup -getstartupdisk
...
GIBBERISH
...

TIMESTAMP currentBootDevice: being checked by DiskManagement
TIMESTAMP currentBootDevice found _curBootDevice: disk6s1 Macintosh HD
TIMESTAMP currentBootDevice cached: disk6s1 Macintosh HD
TIMESTAMP doesCurrentBootDeviceMatchSystemFolder: /System/Library/CoreServices
TIMESTAMP currentBootDevice matched existing cell: disk6s1 Macintosh HD
TIMESTAMP currentBootDevice: disk6s1 Macintosh HD
/System/Library/CoreServices

NOTES

The last line is what is echoed out to terminal ... All well and good

CASE 2: UEFI Application Blessed

DEBUG OUTPUT

$ sudo systemsetup -getstartupdisk
...
GIBBERISH
...

TIMESTAMP currentBootDevice: being checked by DiskManagement
TIMESTAMP currentBootDevice found _curBootDevice: disk2s1 EFI
TIMESTAMP currentBootDevice cached: disk2s1 EFI
TIMESTAMP doesCurrentBootDeviceMatchSystemFolder: /System/Library/CoreServices
TIMESTAMP currentBootDevice cached: disk2s1 EFI
TIMESTAMP doesCurrentBootDeviceMatchSystemFolder: /private/var/folders/mf/8jfrqsl55rj13tpz8718fzmw0000gn/T/AppTranslocation/19B017F8-710B-47F9-A738-2243EA05DFB8/WINNT
TIMESTAMP currentBootDevice cached: disk2s1 EFI
TIMESTAMP doesCurrentBootDeviceMatchSystemFolder: /Volumes/Clone/System/Library/CoreServices
TIMESTAMP systemsetup[974:8627] currentBootDevice: disk2s1 EFI
(null)

NOTES

The last line is what is echoed out to terminal.

Bless Command: bless --setBoot --mount /Volumes/EFI --file /Volumes/EFI/refind/refind.efi

However, note that the boot device is disk2s1 EFI and although I specify the /Volumes/EFI/refind/refind.efi target in the Bless command, it appears that Bless simply adds the target to the bottom of some order it has for /Volumes/EFI and the default higher order boot targets are always evaluated first.

Example of such default is /Volumes/EFI/Boot/BOOTx64.efi which happens to be sitting in the "correct" location because I have OpenCore in the same EFI Partition.

So basically, in order to use Refind as I wanted, I have to put it into, and bless it from, a separate location from OpenCore.

I have done this and everything is working as expected. Bless presumably checks the standard locations finds nothing suitable and picks up my specified target file.

Strange behaviour but I think that is what happens.

As mentioned earlier, when I bless Refind with the nextonly flag, everything worked before. So I tried this out to see what was happening:

CASE 3: UEFI Application Blessed as "NextOnly"

DEBUG OUTPUT

$ sudo systemsetup -getstartupdisk
...
GIBBERISH
...

TIMESTAMP currentBootDevice: being checked by DiskManagement
TIMESTAMP currentBootDevice found _curBootDevice: disk6s1 Macintosh HD
TIMESTAMP currentBootDevice cached: disk6s1 Macintosh HD
TIMESTAMP doesCurrentBootDeviceMatchSystemFolder: /System/Library/CoreServices
TIMESTAMP currentBootDevice matched existing cell: disk6s1 Macintosh HD
TIMESTAMP currentBootDevice: disk6s1 Macintosh HD
/System/Library/CoreServices

NOTES

The last line is what is echoed out to terminal.

Bless Command: bless --setBoot --mount /Volumes/EFI --file /Volumes/EFI/refind/refind.efi --nextonly

Basically identical output to the first case.

Not sure how it ends up picking up the target without going blundering into OpenCore in /Volumes/EFI/Boot/BOOTx64.efi in such cases but it does not is such cases.

Conclusion

This was not so much a Boot Coup by OpenCore as much as leaving the gate to the Presidential Palace unlocked.

Solution

Keep OpenCore in a separate EFI Partition from any non standard UEFI Applications you want to bless. The same applies if running both from HFS volume such as /Volumes/VOL_NAME/EFI

Thanks @vit9696 and sorry for taking your time on this.

[vit9696]

Makes some sense. I guess on Apple hardware AppleBootPolicy (predefined list of paths and FS attributes) is more important than custom blessed entries. Perhaps it is a bit unintuitive and tricky.

[dakanji]

Perhaps it is a bit unintuitive and tricky.

True. I prefer to keep Refind and OpenCore in one EFI and have decided to always rename BOOTx64.efi to OC_Bootx64.efi from now on.

This way, I know I will get the expected behaviour on my Mac in all instances.

Very Bad Idea ... Avoid.
Just put in separate locations

[startergo]

I do not believe OpenCore removes any boot option, so I am afraid that is your firmware going mad. CC @Download-Fritz

Strange, but when I boot with option key bypassing OC:

 sudo bless --getBoot --verbose
Password:
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>8475B9E7-22E9-4B61-B17B-9CEFEEE18667</string></dict></dict><key>BLLastBSDName</key><string>disk6s4</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'Mac OS X'
Boot option matches XML representation
Found device: disk6s4
Disk boot device detected
/dev/disk6s4

I never get Boot option matches XML representation with OC

[startergo]

This is from within OC:

sudo bless --verbose --info
Password:
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>8475B9E7-22E9-4B61-B17B-9CEFEEE18667</string></dict></dict><key>BLLastBSDName</key><string>disk6s4</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'CAT2'
Boot device path incorrect
Boot option does not match XML representation
XML representation doesn't match true boot preference
g5@G5s-Mac-Pro ~ % sudo bless --getBoot --verbose
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>8475B9E7-22E9-4B61-B17B-9CEFEEE18667</string></dict></dict><key>BLLastBSDName</key><string>disk6s4</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'CAT2'
Boot device path incorrect
Boot option does not match XML representation
XML representation doesn't match true boot preference