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

[Dayo]

RESOLVED: SEE POST 33


I am able to disable and recover from opencore by simply pulling the physical disk that contains it and rebooting but I find it a bit disconcerting that it seems to have "taken over" my setup whereby it doesn't matter about NVRAM resets etc, as long as the disk with OC is in place, it generally defaults to OC.

What I am looking for is a way to decide that when I boot, OC should respect the startup disk selected and allow this to boot as normal. Basically, an "off" switch in OC.

A list of what doesn't work:

• "sudo systemsetup -setstartupdisk /" -> Attempt to set startup disk to current volume: Ignored by OC ... Still boots OC
• "sudo mkdir /Volumes/EFI; sudo mount -t msdos /dev/OC_EFI_PARTITION /Volumes/EFI; sudo bless --unbless /Volumes/EFI/; sudo systemsetup -setstartupdisk /" -> Attempt to unbless OC and set startup disk to current volume: Ignored by OC ... Still boots OC
• "sudo mkdir /Volumes/EFI; sudo mount -t msdos /dev/REFIND_EFI_PARTITION /Volumes/EFI; sudo bless REFIND_BLESS_COMMANDS /Volumes/EFI/" -> Attempt to bless REFIND instead: Ignored by OC ... Still boots OC
• Reboot and reset NVRAM 3 Chimes" -> Attempt to zap OC Stuff: Ignored by OC ... Still boots OC

As said, I can recover as needed but a bit disconcerting how OC basically seems to be written in some permanent way in the NVRAM and that physical action is always needed ... or am I missing something?

Looking for some kind of command that wipes out all traces of OC in the NVRAM (I think that's where the issue lies).

Any thoughts?

 

[cdf]

OpenCore should leave no traces in NVRAM. What you are experiencing has to do with configuration. If you disable RequestBootVarRouting in the config file, then any startup disk that you choose will boot without OC. And if OC starts up after you reset the NVRAM, then OC is simply being detected first by your machine. Try moving it to another EFI partition.
[automerge]1586609708[/automerge]
In fact, having OC in the first-detected position is particularly useful for keeping your machine protected from UEFI Windows after an NVRAM reset.

 

[startergo]

Any thoughts?

You can disable everything in the config file and just use it for boot screen support. Also there is a section :

OpenCorePkg/Docs/Sample.plist at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

to re-enable Apple boot policy

 

[Dayo]

If you disable RequestBootVarRouting in the config file, then any startup disk that you choose will boot without OC. And if OC starts up after you reset the NVRAM, then OC is simply being detected first by your machine. Try moving it to another EFI partition.

Thanks. I had RequestBootVarRouting enabled but I guess I may be better better with it off from how I am running OC which is to chain-load it from rEFInd.

In fact, having OC in the first-detected position is particularly useful for keeping your machine protected from UEFI Windows after an NVRAM reset.

Noted. I currently don't have Windows installed but looking at a set up where it is launched from rEFInd when I do install. Also looking at using the Non-UEFI mode. This will be a Covid-Shutdown separate project as I know very little about Windows on Macs.

You can disable everything in the config file and just use it for boot screen support. Also there is a section to re-enable Apple boot policy

Thanks.
Disabling RequestBootVarRouting seems to be the way to go at this point.

 

[Dayo]

OpenCore should leave no traces in NVRAM.

I am convinced that it does.

Anyone that has simply set it up and using it will find that it works perfectly but for someone like me diving in and out of it, it definitely hijacks things ... even with RequestBootVarRouting switched off etc.

I had it in an EFI partition of the disk in Bay 2. Shouldn't be the first thing found but I then moved it out of the EFI into a volume created on the same disk and once I reset NVRAM, I get booted into OC after having used this setup a few times.

It somehow persists and takes over the boot after being used a few times.

The difference RequestBootVarRouting set to off has made is that it respects the set startup disk but once NVRAM is reset (3 Chimes), OC comes up even though it is in a /Volumes/Boot/EFI path which should not be in any normal boot search process.

I can only speculate that it does do something to the NVRAM (or some kind of proxy) to make it persist like so.

16 Mar 20 Update: Invalid Conclusion. See Post 33

 

[startergo]

I am convinced that it does.

Anyone that has simply set it up and using it will find that it works perfectly but for someone like me diving in and out of it, it definitely hijacks things ... even with RequestBootVarRouting switched off etc.

I had it in an EFI partition of the disk in Bay 2. Shouldn't be the first thing found but I then moved it out of the EFI into a volume created on the same disk and once I reset NVRAM, I get booted into OC after having used this setup a few times.

It somehow persists and takes over the boot after being used a few times.

The difference RequestBootVarRouting set to off has made is that it respects the set startup disk but once NVRAM is reset (3 Chimes), OC comes up even though it is in a /Volumes/Boot/EFI path which should not be in any normal boot search process.

I can only speculate that it does do something to the NVRAM (or some kind of proxy) to make it persist like so.

You need to enable debug mode and examine the log file to understand what is happening.

 

[tommy chen]

i had an XML entry in my bootROM
after a NVRAM reset via opencore I had 2 XML entries afterwards!

these cannot be removed even by reflashing a clean bootROM.

where is my thought error?

 

[Dayo]

You need to enable debug mode and examine the log file to understand what is happening.

Thanks. Will keep tinkering.

 

[startergo]

i had an XML entry in my bootROM
after a NVRAM reset via opencore I had 2 XML entries afterwards!

these cannot be removed even by reflashing a clean bootROM.

where is my thought error?

IASInstallPhaseList.plist is a log that macOS installer (Recovery too) creates to facilitate debug process of unsuccessful macOS installs. It's not needed for anything else and it's recreated when you run macOS installer or Recovery again. It's not permanent and can be erased if NVRAM space is needed.

 

[tommy chen]

but I did not install anything and only executed the OC nvram reset

and what should this have to do with the IASInstallPhaseList.plist?

 

[Macschrauber]

I will clean the rom for you. But it shouldnt copy the plist anyway...

 

[startergo]

but I did not install anything and only executed the OC nvram reset

What is your config file?

 

[Dayo]

I can only speculate that it does do something to the NVRAM (or some kind of proxy) to make it persist like so.

Could have been that the proxy in my case was VirtualSMC.

 

[startergo]

You don't need VirtualSMC for a mac

 

[Dayo]

You don't need VirtualSMC for a mac

I know. Saw something about it being a potential improvement on legacy implementations hence the trial.

You need to enable debug mode and examine the log file to understand what is happening.

Whatever drives this behaviour happens before OC is loaded and starts debug logging.

 

[startergo]

Whatever drives this behaviour happens before OC is loaded

WEG has a debug option too:
-wegdbg

How do I get the debug log?
Install DEBUG versions of WhateverGreen and Lilu, then add -raddbg -liludbg to the boot arguments. Once you boot run the following command in terminal:
log show --predicate 'process == "kernel" AND (eventMessage CONTAINS "WhateverGreen" OR eventMessage CONTAINS "Lilu")' --style syslog --source

Add -liludbgall to enable debug printing in Lilu and all loaded plugins (available in DEBUG binaries).

 

[startergo]

Whatever drives this behaviour happens before OC is loaded and starts debug logging

WEG cannot load without LILU and LILU cannot load without OC if they are not in /L/E or /S/L/E

 

[Dayo]

WEG has a debug option too:
-wegdbg

I suspect those would come too late as injected by OC

WEG cannot load without LILU and LILU cannot load without OC if they are not in /L/E or /S/L/E

Indeed.

OC obviously stores some info that persists between boots such as the default boot option (I.E., Boot Item selected with Ctrl + Enter). I wonder whether it stores more than just that.
Invalid Conclusion. See Post 33

Anyway, attached recent debug log just in case anything seems off there. Can't see anything that look funky there myself but may not know what to look for.

 

[tommy chen]

What is your config file?

this is the last configfile from @h9826790 with TB-SSDT from nico

after some tests i can say that it is because of the nvram reset of OC!

means, if it is set to >true< this 2nd XML is created
but if you set it to <false<, no 2nd will be created

 

[Dayo]

this is the last configfile from @h9826790 with TB-SSDT from nico

If you really need help, you should at least make the effort to attach this to your post.

 

[tommy chen]

If you really need help, you should at least make the effort to attach this to your post.

what would be the point if I didn't make any other changes?

but ok, here is the config

 

[Dayo]

So I did some experiments and here are the results:
I tried renaming config.plist to config.plist.bac with the hope that it will disable OC and I can go back to Apple boot.
That did not work and I just ended up on a grey screen (with an EFI video card). This was done after NVRAM reset opt+P+R 3 times.
The reason it did not work is because the boot loader labeled EFI (OC boot loader) is still there. If you boot with the option button pressed it is the default entry and it survives NVRAM reset.

Your post is related to the issue reported here ... difficulty in disabling OC or OC taking over boot process.

My case is slightly different in that I want to chain-load OC from rEFInd. I bless rEFInd and this works well ... for a few cycles. After a while it starts booting directly into OC without me ever blessing OC.

Basically, the chain-loading works as long as the rEFInd bless command has the nextonly flag and RequestBootVarRouting is disabled in the OC Config. Once I try to make it permanent by removing nextonly, it starts booting directly into OC and bypasses/hijacks the rEFInd bless.

What I have been able to determine so far is as follows:

• When OC is run, it somehow appears to add a persistent flag somewhere that makes it #1 in the boot order
  • It doesn't appear to matter where OC is run from ... EFI partition, Volume. It will still end up in Boot Order #1
  • It doesn't appear to matter what Drive Bay is run from. It will still end up in Boot Order #1
  • Basically, as long as there is a working OC instance anywhere on your system that has been run at least once before (I think it is only relevant to the last run instance), it will take over your boot process once a trigger condition is met.
• 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.
• The trigger condition does no appears to affected by standard NVRAM resets
  • Actually, resetting NVRAM creates the trigger condition by disabling start disk settings
• The way to get out of this appears to be to ensure that the working OC instance cannot be found on booting
  • Rename the Bootx64.efi file and reset NVRAM
  • Disconnect the OC drive and reset NVRAM
• On my system at least, if the reset is done for 3 chimes with the OC drive disconnected, I get the Apple Recovery Screen where I can select a start disk and restart

Thinking about the post by @cdf earlier ...

If you disable RequestBootVarRouting in the config file, then any startup disk that you choose will boot without OC.

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.
Invalid Conclusion. See Post 33

I believe that this mechanism is what creates the condition.

Unfortunately, I am only able to experiment by changing stuff to observe effects and can't dive into the code to actually confirm my hypothesis as I don't know the C programming language. Hoping someone with the skills can help prove/disprove the hypothesis.

Nevertheless, I need to start thinking of how to circumvent this based on my observations

PS: In case any one is wondering, if you want OC to run first and then chain-load something else, there is obviously no issue. OC appears to be geared to run first. That actually is my issue.

 

[startergo]

Your post is related to the issue reported here ... difficulty in disabling OC or OC taking over boot process.

My case is slightly different in that I want to chainload OC from Refind. I bless Refind and this works well ... for a few cycles. After a while it starts booting directly into OC without me ever blessing OC.

Basically, the chainloading works as long as the Refind bless command has the nextonly flag and RequestBootVarRouting is disabled in the OC Config. Once I try to make it permanent by removing nextonly, it starts booting directly into OC and bypasses/hijacks the Refind bless.

What I have been able to determine so far is as follows:

• When OC is run, it somehow appears to add a persistent flag somewhere that makes it #1 in the boot order
  • It doesn't appear to matter where OC is run from ... EFI partition, Volume. It will still end up in Boot Order #1
  • It doesn't appear to matter what Drive Bay is run from. It will still end up in Boot Order #1
  • Basically, as long as there is a working OC instance anywhere on your system that has been run at least once before (I think it is only relevant to the last run instance), it will take over your boot process once a trigger condition is met.
• 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.
• The trigger condition does no appears to affected by standard NVRAM resets
  • Actually, resetting NVRAM creates the trigger condition by disabling start disk settings
• The way to get out of this appears to be to ensure that the working OC instance cannot be found on booting
  • Rename the Bootx64.efi file and reset NVRAM
  • Disconnect the OC drive and reset NVRAM
• On my system at least, if the reset is done for 3 chimes with the OC drive disconnected, I get the Apple Recovery Screen where I can select a start disk and restart

Thinking about the post by @cdf earlier ...


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.

Unfortunately, I am only able to experiment by changing stuff to observe effects and can't dive into the code to actually confirm my hypothesis as I don't know the C programming language. Hoping someone with the skills can help prove/disprove the hypothesis.

Nevertheless, I need to start thinking of how to circumvent this based on my observations

PS: In case any one is wondering, if you want OC to run first and then chainload something else, there is obviously no issue. OC appears to be geared to run first. That actually is my issue.

Right, when you rename OC' s bootloader the system remains without a bless partition. You can re-bless from the Apple boot picker by hitting control+enter, from the recovery partition or probably even by the startup disk in the operating system just by selecting the requested boot entry. Most certainly from the recovery partition and the Apple boot picker should work. Resetting NVRAM on its own does not create an XML boot plist inside the firmware. I have seen the boot plist after a firmware re-flash. And it breaks at first bless of OC. Recovery startup disk selection should restore the blessed entry, but so should the control+enter at the Apple boot picker or startup disk selection providing the EFI loader for OC is renamed before that.

 

[Dayo]

Correct on those potential recovery steps @startergo. Particularly when using a GPU with Apple EFI.

Still would nice nice to be able to control the OC Mechanism that appears to independently place OC in boot order position #1.

My case is particularly affected since I want to bless something else and this OC Mechanism, if it does indeed exists as I suspect, always results in OC taking over the process in this case.

 

[startergo]

Still would nice nice to be able to control the OC Mechanism that appears to independently place OC in boot order position #1.

With OC in the system and RequestBootVarRoutingdisabled, on the next boot select your default boot entry by described methods above. Once you set another default boot entry, OC should respect that as long as the default boot entry exists in the firmware path:

OpenCore uses the primary UEFI boot option to select the default entry. This choice can be altered from UEFI Setup, with the macOS Startup Disk preference, or the Windows Boot Camp Control Panel. Since choosing OpenCore’s BOOTx64.EFI as a primary boot option limits this functionality in addition to several firmwares deleting incompatible boot options, potentially including those created by macOS, you are strongly encouraged to use the RequestBootVarRouting quirk, which will preserve your selection made in the operating system within the OpenCore variable space. Note, that RequestBootVarRouting requires a separate driver for functioning.