Yes, tried with AVXpel patches about 30 minutes ago. Same result: white screen with Apple logo and no progress indicator.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr
- Thread starter Dayo
- Start date
-
- Tags
- multi boot opencore refindplus
- Sort by reaction score
Okay.
So, there are three basic differences in your setup from the known working example as follows:
So rerun ConfigFactory, select "NO" to the query about WiFi modules/cards to skip applying those patches and see whether that makes a difference. AVXpel or NoZlibAVX confirmed to not matter as expected, so you can use whichever you want.
So, there are three basic differences in your setup from the known working example as follows:
- MyBootMgr version
- Patches applied by OpenCore
- Your GPU
So rerun ConfigFactory, select "NO" to the query about WiFi modules/cards to skip applying those patches and see whether that makes a difference. AVXpel or NoZlibAVX confirmed to not matter as expected, so you can use whichever you want.
No idea why switching VMM on wouldn't work right now.
Will take a closer look later.
In the interim, you could duplicate the default instance again and add the following firmware feature flags/masks to the instances in the OC_UPD config:
Will take a closer look later.
In the interim, you could duplicate the default instance again and add the following firmware feature flags/masks to the instances in the OC_UPD config:
- "FirmwareFeaturesMask" to "P/8f/wgAAAA="
- "FirmwareFeatures" to "A1QMwAgAAAA="
- "UpdateNvram" to "true"
Last edited:
Finally makes sense.
I believe your current installation may have been done with the OCLP. If so, then the
ConfigFactory asks the question early in the setup flow so that it will try to minimise such conflicts but ...
You can try with choosing the correct option in ConfigFactory, if not previously done, but the chances of it generating an OCLP based Dosdude Type compatible config are slim ... with Monterey in particular as the OCLP has a shed load of such patches, less so with BigSur, lesser with Catalina and so on.
In summary, while you can manually incorporate OCLP configs into the MyBootMgr setup, see Post 1 for details, you can't really boot an OCLP instance with a MyBootMgr config.
I should have picked up on this earlier and the original failure report is probably the same issue. I suppose I was blinded by the report that the default instance from ConfigFactory was working.
I believe your current installation may have been done with the OCLP. If so, then the
Rigid Patching it applies will be in conflict with stuff done by other means.ConfigFactory asks the question early in the setup flow so that it will try to minimise such conflicts but ...
- All it does is try to minimise the conflicts
- The efficacy of the confflict minimisation attempt wanes as you move up the release time ladder
- I don't think you selected that option in the first place
DosDude Type instances.You can try with choosing the correct option in ConfigFactory, if not previously done, but the chances of it generating an OCLP based Dosdude Type compatible config are slim ... with Monterey in particular as the OCLP has a shed load of such patches, less so with BigSur, lesser with Catalina and so on.
In summary, while you can manually incorporate OCLP configs into the MyBootMgr setup, see Post 1 for details, you can't really boot an OCLP instance with a MyBootMgr config.
I should have picked up on this earlier and the original failure report is probably the same issue. I suppose I was blinded by the report that the default instance from ConfigFactory was working.
Last edited:
I would have thought this would be apparent from the OCLP name, as "P" stands for "Patcher".
In any case, OpenCore as a whole is a patcher. The thing about OCLP is that it makes additional filesystem changes AKA
Rigid Patching while plain OpenCore only does Soft Patching (RAM only). The issue, and ConfigFactory tries to work around this to an extent, is that patches can conflict.This is explained in ConfigFactory when you select the correct response to the query on whether you intend to use it with DosDude Type stuff. Not sure if still in the CDF guide but it warned against using it with such rigidly patched instances.
It could be that OCLP rigid patching is a specific additional option that is not always used though. I am pretty sure it is difficult to avoid for Monterey but could be wrong.
Possibly so indeed. You will note I didn't say that the chances of success are zero but "slim".
FWIW, I have also consulted OpenCore's developer on your issue and his conclusion is that it must be due to something done by the OCLP. This was admittedly from a quick look at the log but either way, there is little point trying to troubleshoot failures with a known incompatible setup. To use OCLP instances with MyBootMgr and be sure of success, you need to manually incorporate it as a separate instance. See Post 1 for details.
However, you can always toss a CDF config in again and see if it still works. If it does, then the MyBootMgr one should also do so if you compare it with the CDF one and disable any additional kexts and patches until you have disabled all such extras or stumble on one that is in conflict with OCLP.
Last edited:
That they needed a rerun of the installer to remove them is what tells you they were rigid. The standard OpenCore patches just need a reboot to remove as only in the RAM.
So if you use a non-rigidly patched config to load Monterey, the next time you boot with another config, the patches the previous did would be gone. This is not the case with a rigidly patched setup as filesystem items would have been changed and these would persist unless specifically wiped out as you did.
