MP 1,1-5,1 Avoiding Opencore Boot Coups

[Dayo]

OC should respect that as long as the default boot entry exists in the firmware path

Correct. The absence of this default boot entry when simply blessing another boot loader is the issue I found.

• What appears to be the trigger condition is when there is no start disk defined.
  • I.E., when the result of sudo systemsetup -getstartupdisk is (null)
  • This appears to be why the nextonly rEFInd bless works as this leaves sudo systemsetup -getstartupdisk intact as the current startup disk.
  • Once the flag is removed, sudo systemsetup -getstartupdisk returns (null) and OC takes over.

It might just be the case that chain-loading in such a matter is not supported/possible although it would be nice to be able to just disable this "feature".

 

[w1z]

The title of this thread is misleading. I suggest substituting the word 'Hijacks' with 'Overrides' if you still believe it does.

OC does not do anything you don't specifically configure it to do.

 

[Dayo]

I think for this RequestBootVarRouting feature to function, OC or some associated service most somehow be always loaded first in the boot process, even if only partially and in the background, in order to evaluate whether to allow the startup disk to load or to proceed with running OC.

I believe that this mechanism is what creates the condition.

So digging around the code, it appears that OC does have an "associated service", "Bootstrap", that runs before the main OC codebase is loaded.

Basically the bootstrap image appears to run and it allows a defined start disk to load if one is defined and it is so configured.

If none is defined, it appears to load OC proper in all instances if OC is found on the FileSystem regrdless of whether you have specifically blessed OC or not. This is the undesirable behaviour which would be nice to disable.

The title of this thread is misleading. I suggest substituting the word 'Hijacks' with 'Overrides' if you still believe it does.

OC does not do anything you don't specifically configure it to do.

I don't think it is doing what I have configured it to do but I do agree that the word may be a distraction, so I will amend the title as suggested. Thanks

 

[Dayo]

I have been able to work around this issue by using a LaunchDaemon to trigger a script that keeps rEFInd blessed with a "nextonly" flag.

So far so good.

In the meantime, I opened this issue with the devs: https://github.com/acidanthera/bugtracker/issues/847
Would be interesting to see what their take is

 

[startergo]

You can try installing refind on an HFS+ partition:

The rEFInd Boot Manager: Installing and Uninstalling rEFInd

Most of the reports of sluggish Macintosh boots I've seen note that the user installed rEFInd to the ESP rather than to the macOS root partition. Some users have reported that re-installing rEFInd to the macOS root partition clears up the problem. This is obviously a straightforward solution to the problem, if it works. (This location is not an option when using WDE or macOS logical volumes.) Note that rEFInd can launch boot loaders that are stored on any partition that the EFI can read no matter where it's installed; therefore, you'll still be able to launch boot loaders stored on the ESP (or elsewhere) if you install it in this way.

A variant of this solution is to create a small (~100MiB) HFS+ volume to be used exclusively by rEFInd. You can then install rEFInd to that volume with the --ownhfs option to refind-install, as in ./refind-install --ownhfs /dev/disk0s6 if the volume is /dev/disk0s6. This approach has the advantage that it can be managed via macOS's own Startup Disk tool in System Preferences.

Normally when I boot with OC and issue:
sudo systemsetup -getstartupdisk I get nothing in return. Which means the default boot loader is empty. You only have to select the desired boot disk in startup disks (don't need to reboot). For instance selecting the currently booted drive:

sudo systemsetup -getstartupdisk
/System/Library/CoreServices

Now I have a default option.

 

[startergo]

Wrong thread.

 

[Dayo]

You can try installing refind on an HFS+ partition:

Thanks for the suggestion but the issue is not rEFInd related and I have found a way to bypass it.

Normally when I boot with OC and issue:
sudo systemsetup -getstartupdisk I get nothing in return. Which means the default boot loader is empty. You only have to select the desired boot disk in startup disks (don't need to reboot).

Correct. When you first want to boot into OC (or any bootloader), you bless the efi file. This removes the standard startup disk as you noted as the blessed file is now the selected efi and sudo systemsetup -getstartupdisk gives a null result because that command only recognises the native setup.

What I have been able to deduce is that where OC differs from anything else is that it only needs this EFI Bless for the very first boot, and, as you noted, you can go into system settings and select a different start disk without issue. This is because OC Bootstrap Image takes care of things after the first boot when it is apparently put in place.

Actually, when you select a start disk in system settings, you are undoing the EFI Bless and blessing the selected disk instead. However, once OC has been run once, it does not need its EFI to be blessed anymore as it would have created a Bootstrap Image on your system that will control all your boots as from that point on.

This Bootstrap Image cannot be disabled by a standard NVRAM reset including a 3 Chime one. OC Bootstrap Image will handle booting according to the rules below after evaluating your config:

1. If RequestBootVarRouting is true, OC Bootstrap Image will load OC Proper
   1. OC Proper will deal with startup disk presence or absence based on other config settings but OC Proper will always run.
2. If RequestBootVarRouting is false, OC Bootstrap Image will check if there is a defined startup disk
   1. if there is a defined startup disk, OC Bootstrap Image will let the Firmware load this
   2. if there is no defined startup disk, OC Bootstrap Image will load OC Proper

Your resetting the disk in system settings just puts things into Situation 1.1 above.
This is perfectly fine if only using OC or chain-loading from OC. Basically any situation where OC is expected to be loaded first.

When trying to chain-load OC from rEFInd it is a different kettle of fish, Situation 2.2, hence my workaround, which is working perfectly well btw.

Thanks again for all your advice. I am good to go even if my request to the OC devs for a built in option is turned down.

 

[Dayo]

Following some guidance from the OpenCore Devs, it turns out that the Boot Coups are not down to any untoward stuff with OpenCore but with the quirky implementation of the UEFI Specs by Apple.

In simple terms, the specs say certain locations must be checked for bootable EFI files and these are to be booted if found. Apple complies with this requirement.

What Apple additionally does however, is to take advantage of the fact that the specs do not say you cannot also check other locations if nothing is found in the defined location.

On a default Mac setup, the EFI System Partitions are essentially empty. When checked on boot and found to be so, Macs then go on to check certain locations on the filesystem and boot Mac OS from EFI files in such locations.

One such standard location/file is /Volumes/EFI/EFI/BOOT/Bootx64.efi which is exactly what OpenCore uses. As a result, when a Mac is booted, being compliant to the letter of the spec, if not the spirit, it will invariably hit OpenCore first on most typical installations based on what we generally follow here, resulting in a Boot Coup.

This implementation also basically puts such OpenCore implementations first in the boot order after NVRAM resets and makes it typically survive such resets as the instance would be found first after a boot target search triggered by the NVRAM being cleared of defined boot targets.

In terms of it taking over after blessing rEFInd on a Disk Volume, it appears Apple puts the target EFI specified in a bless command, in a position below standard locations. Again, as OpenCore sits in a standard location, when you bless something like rEFInd (typically) in a non-standard location, the Mac will check the standard location first and boot OpenCore instead.

So a bless command like sudo bless --setBoot --folder /Volumes/VOLNAME/EFI --file /Volumes/VOLNAME/refind/refind.efi will end up booting the OpenCore instance in /Volumes/VOLNAME/EFI/BOOT/BOOTx64.efi if present

Specifying the rEFInd folder should work sudo bless --setBoot --folder /Volumes/VOLNAME/EFI/refind --file /Volumes/VOLNAME/refind/refind.efi but not tested.

This understand provides exciting insight into making rEFInd a stable Boot Manager for chain-loading OpenCore in a multi-boot environment. Testing the implementation of this better option now.

 

[EdMun]

I had to disable LauncherOption on MP 5,1 when I never saw a boot coup on 3,1 LauncherOption full.
I have RefindPlus OC on the same HFS+ data SSD bay 1 to default and negate blessing, I find it most convenient but can't help but wonder why it's not the norm and is there anything wrong with this?

 

[Dayo]

can't help but wonder why it's not the norm and is there anything wrong with this?

On the contrary, the assumption that the drive in SATA Bay 1 is a base default is in fact a widely held belief that appears to have sprung out of earlier versions of the steps outlined for implementing OpenCore in the OpenCore on the Mac Pro thread. This was a reflection of the state of knowledge at the time and the steps set out there have since been amended to remove the source items, but the misconception has taken hold and will probably live on forever.

The reality is that the drive in SATA Bay 1 is only a default under certain conditions. Your current unblessed instance in that bay just happens to work for you based on your particular setup. It may not work for others with different setups and may stop working for you if you make changes to your current setup. Even with your current setup, there is a chance that on a random Mac start up, the Disk ID allocated to SATA Bay 1 (/dev/disk#) may not be first in line and that some other disk goes in before it.

In terms of "not being the norm", I suppose what you mean is why various configuration instructions do not just simply say stick it on the disk in Bay 1 and forget about blessing but I believe you can understand that it doesn't work to base instructions to be implemented on a variety of units and setups on a condition that is not guaranteed to work in every situation.

So, there is nothing wrong with your approach as such. Some just don't like leaving things to chance and no one writing implementation instructions will knowingly leave stuff to chance.

As a side note, this thread has been dormant since 2020 and the two and a half or so years that have since passed are equivalent to two and a half or so centuries when it comes to setting OpenCore and similar up on cMP. Although there are constants that always hold true, you wouldn't be basing a lot today on the state of knowledge from the 1770s!

 

[EdMun]

Apologies for the dredge, at the time of the last post I was using Yosemite on the 3,1 believing it was the end of the road and yes it now seems like a lifetime ago.
So far this config has been 100% reliable default on both machines so the reassurance is much appreciated.
I've tried to find information on the default boot process and why disk format seems to matter with a preference for HFS on the 3,1 at least, I read HFS volume headers have a unique pathless bootable flag but found nothing on how it's used.

 

[Dayo]

the reassurance is much appreciated.

There was no intention to give any reassurance about relying on such a setup. The fact that it is possible to always drive without a seat belt and stay 100% death/injury free so far does not make it a good idea.