MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr

[osxfr33k]

Well, the setup is flexible and you can mash it as you please but the general idea, if wanting to leverage the OCLP, is to *ADD* the OCLP config by replacing the OC_EXP instance as described earlier.

This is moreso the case when you want to keep using OpenCore to boot stuff the OCLP is not designed for:

• OCLP: Covers 11.x Big Sur to 13.x Ventura
• ConfigFactory: Covers 10.5 Leopard to 12.x Monterey

PS: For ConfigFactory and OCLP configs to coexist without friction, you want to limit the OCLP, and its associated Rigid Patching, to Ventura and to use unpatched installations for Monterey/Older. So, OCLP instance to boot "Rigidly Patched" Ventura and ConfigFactory instances to boot "Vanilla" Monterey/Older.

This makes perfect sense, thanks. I only placed OCLP into OC because I was unsure how to have only Ventura SSD boot from OC_EXP, which would have the OCLP instance. Oh wait when I boot OC it will see both Catalina and Ventura so only use the config factory built OC to boot only Catalina what is it meant for. Into OC_EXP just replace Opencore contents with OCLP and only boot Ventura from that launcher even though you see both Catalina and Ventura from that instance of Opencore. I don't know why I didn't think more about this and do it this way to begin with, I'll fix this tomorrow most likely run the installation process again from the Catalina native boot since I will need to bless etc. I am book marking this post for future reminders when I run new installs.

I ran into a Opencore boot Coup thank goodness I was able to fix it. This is why you remind to make sure LauncherOption is changed from Full to Disabled especially if one decides to install their own instance of OC, looks like this is set to FULL by default while Config Factory makes the default Disabled.

 

[Dayo]

So use a ConfigFactory configured instance to boot Catalina and use the OCLP configured instance to boot Ventura although both instances will show Catalina and Ventura.

Correct. The controls on what boot options are shown in the OpenCore picker are currently limited and therefore, you cannot trivially hide Ventura in one instance and hide Catalina in another in a manner that will cover all possible/likely setups.

I ran into an OpenCore boot coup

Post 1 >> Hints and Tips:

 

[osxfr33k]

I decided to run the Catalina installer so it would install over the Dosdude1 patched Catalina for a native Catalina install and everything went smooth. Re-Ran ConfigFactory prior to the MacOS re-install and deployed it and blessed RF+ in EFI. For some odd reason I cannot get the MACOS Catalina to boot. It gets to the OC boot screen but when I click on the MacOS (Catalina) icon it looks like it wants to start to boot but then it comes right back to the same OC boot screen. Please find attached the OC config and logs. I did enable OpenCanopy but fairly sure this is not the issue. Thanks

Edited:

It boots natively from RF+ just won’t boot from OC. I wonder if the re-install did copy over the patches because if it did not I can see why OC won’t boot.

I will re-run CF and this time choose system was patched just to see if OC will boot if so then Catalina re-install didn’t copy over the patches.

 

[Dayo]

when I click on the MacOS (Catalina) icon

Your OpenCore log says you were trying to boot the 22.3.0 Kernel (Ventura) instead:

I did enable OpenCanopy but fairly sure this is not the issue.

That doesn't seem to be the only thing changed but in any case, you need to set things up without making modifications and see if it works first when putting stuff together.

If it fails, there will be no point going forward with mixing other stuff in and you can go to the source for resolution.
If on the other hand it works unmodified but falls over after you muck with it later, you will know where the issues arose.

 

[osxfr33k]

Your OpenCore log says you were trying to boot the 22.3.0 Kernel (Ventura) instead:

View attachment 2174483​

That doesn't seem to be the only thing changed but in any case, you need to set things up without making modifications and see if it works first when putting stuff together.

If it fails, there will be no point going forward with mixing other stuff in and you can go to the source for resolution.
If on the other hand it works unmodified but falls over after you muck with it later, you will know where the issues arose.

Yes I did when it would not let me part from the OC picker screen, so I chose Ventura so it would reboot the Mac instead of just powering the mac off and back on.

I left everything as default in OC config not one change still won't boot using OC. Log files and Config attached. The only other thing I can think of is the re-install has left some in place. I am going to run the CF again but this time I will choose yes to Dosdude or any patching, if t boots OC then there must still be patching laying around interfering.

Edited please note:

rEFInd+ natively boots Catalina from either scenario after building using CF with choosing patching or no patching scenarios. I am able to boot Catalina without BT support as expected in OC_EXP. Still unknown reason as to why OC will not boot Catalina.

New Update:

I tried the other two of 4 OC choices and OC_VMM and OC_LEG boot fine everything working including BT. Does that mean possibly either OC_VMM or OC_LEG should have been configured at OC instead?


Final Update:

Something seems not right that gets configured for the OC's some inconstancies unless it was meant to be like this?

OC Config versus OC_LEG
SMBIOS different

OC = Mac-27AD2F918AE68F61

OC_LEG = Mac-7BA5B2D9E42DDD94

UpdateNvram Yes OC versus No OC_LEG

Kernel driver ASP-Override.kext Yes OC but I don't see the kext for this? OC_LEG not included in config.

These two additional drivers found in OC and not in OC_LEG yet both enabled in each of their configs?
BigSurSDXC.kext and NoAVXFSCompressionTypeZlib.kext.

In the end when I make the changes in OC config to match that of OC_LEG config it still won't boot from OC so I might be overlooking something else.

I will just use OC_LEG until this gets all sorted out.

Thanks

 

[Dayo]

Something seems not right

Well, the warnings that ConfigFactory should not be run from Catalina that you went past are not there for fun. Some AppleScript bugs were added in Catalina and AFAIK, many of them were never fixed. Some were fixed in Big Sur and others in Monterey, but the last time I checked, they were still there in Catalina.

This was not likely to have been a factor but can't definitely say. It is just a currently unsupported situation that will not be looked into at this time.

I will just use OC_LEG

OC_LEG, when it is included, is set up for for "Legacy" Mac OS such as Catalina and is what is meant to used for such.

There is an implicit assumption that anyone running Ventura would also be running Big Sur and/or Monterey and those are what the OC instance is primarily aimed at (when OC_LEG is also present). That is (Legacy + Monterey + Ventura). I might add stuff to set thing out better for a ((Legacy + Ventura) - Monterey) setup such as yours.

Having said that though, the OC instance *SHOULD* run Catalina when OC_LEG is also present but this is mainly an afterthought there.

For now, you want to comment the disable_amfi token in the RefindPlus config file out, reboot, trigger the CleanNVRAM tool in RefindPlus and bless RefindPlus afterwards.

 

[Dayo]

These two additional drivers found in OC and not in OC_LEG yet both enabled in each of their configs?
BigSurSDXC.kext and NoAVXFSCompressionTypeZlib.kext.

Took a look at this and it pointed at a quite nasty bug in the code that syncs the kext instances between the OC instances.

I have done a temporary patch for this and re-uploaded v090 as the code base is again in flux.

This item is related to an earlier issue reported with Innie but unfortunately, requests for info, which would have allowed for an earlier structured fix, were ignored (as usual). Anyway, thanks for reporting the issues and providing info to allow fixes.

Proceed with the "remove disable_amfi and reset" thing and get the updated 090 package and use this. The amfi thing was also patched out. Will sort the ((Legacy + Ventura) - Monterey) setup out in the next release.

 

[osxfr33k]

Looks like new OCLP v0.6.3 and/or new version of Ventura v13.3 has broken the EFI boot into Ventura from rEFIndplus boot. It’s saying incompatible AHCI controller port error 0xe0030005. I have rEFIndplus on the 3.5 inch spindle drive I wonder if this is causing incompatibilities or it’s just the new version on Ventura AHCI protocols not backward compatible with Catalina AHCI/APFS?

Never mind above I tried the scenario will all SSD environment no issues.

Edited: I chose Retina display because I go back and forth between a regular monitor and a retina based one. Where in the config file can I change this so the resolution is lower all the icons etx are very large. Sorry to bother.

 

[Dayo]

Apple might have removed some or all AHCI support. You need to refer this to OCLP support channels.

Loading OpenCore via RefindPlus ( not rEFInd+, rEFIndXYZ etc btw) is not a factor in what happens down the boot chain.

 

[osxfr33k]

Apple might have removed some or all AHCI support. You need to refer this to OCLP support channels.

Loading OpenCore via RefindPlus ( not rEFInd+, rEFIndXYZ etc btw) is not a factor in what happens down the boot chain.

How does one install a native installer of Catalina via rEFInd+

Edited:

I keep getting the message once in the installer and clicking on the disk to install to. This version of MacOS 10.5.7 cannot be installed on this computer.

 

[Dayo]

I have no idea about rEFInd+ but as for RefindPlus, you connect the USB Installer icon you created beforehand, restart your Mac and click on the icon for this on the RefindPlus screen.

Please direct general RefindPlus related queries to GitHub as linked in Post 1.

 

[Dayo]

I keep getting the message once in the installer and clicking on the disk to install to. This version of MacOS 10.5.7 cannot be installed on this computer.

That's because Catalina is not supported on CMP. You can run it from RefindPlus but you cannot install a vanilla version from RefindPlus.

With a MyBootMgr setup, you need to use the relevant OpenCore instance for installing stuff. After installation, it can be booted from RefindPlus.

For a USB installer to show up in OpenCore, you need to select the option to allow booting from external disks in ConfigFactory. This will be set by default as from the next version of MyBootMgr.

 

[osxfr33k]

That's because Catalina is not supported on CMP. You can run it from RefindPlus but you cannot install a vanilla version from RefindPlus.

With a MyBootMgr setup, you need to use the relevant OpenCore instance for installing stuff. After installation, it can be booted from RefindPlus.

For a USB installer to show up in OpenCore, you need to select the option to allow booting from external disks in ConfigFactory. This will be set by default as from the next version of MyBootMgr.

Yep tried that I still get that message it’s all good I’ll just use the dosdude1 installer but not use it’s patch with post patching.

To unset Retina display resolution, is that the HiDP token setting in Refindplus config?

Btw I when I type rEFInd+ I am referring to Refindplus.

 

[Dayo]

In my modest experience of fielding support requests for stuff over the years, I have come to find that statements such as "I tried all that" ranks alongside "I'm running the latest version" in being major wild goose chase inducers. So please spell what you did out exactly.

On the RefindPlus display, if you find that this is not working as you expect it to, then please raise an issue on GitHub.

PS: RefindPlus is best referred to as "RefindPlus"!

 

[Dayo]

The "I'm running the latest version" problem

Reflecting on this, the whole logging infrastructure was originally set up to avoid this.

RefindPlus is best referred to as "RefindPlus"!

Reflecting on this one, I was pushing one commit away from changing the name about a year or so ago before pulling back. Might revisit. Perhaps better to just grit my teeth each time though ;-)

 

[osxfr33k]

In my modest experience of fielding support requests for stuff over the years, I have come to find that statements such as "I tried all that" ranks alongside "I'm running the latest version" in being major wild goose chase inducers. So please spell what you did out exactly.

On the RefindPlus display, if you find that this is not working as you expect it to, then please raise an issue on GitHub.

PS: RefindPlus is best referred to as "RefindPlus"!

I had everything working perfectly Ventura on its own SSD and installed on its own without any other SSD or MacOS instance. Then removed the drive and installed
Mojave and Refindplus. Installed both SSDs and everything worked smoothly no issues what so ever. I think the mistake is when I installed Catalina I should have pulled out the Ventura SSD drive because that AHCI error has come back. I need to find out why so I am installing everything fresh again tomorrow. I sure hope I don’t have an intermittent host controller issue on the backplane. Also after installing Catalina on the same drive with Mojave when I boot into Mojave I would see a message about disk incompatibility so the Catalina install is the Culprit. I will do a fresh install of Mojave only on the one SDD and Ventura on the other with Refindplus on the Mojove SSD EFI.

 

[Dayo]

Updated MyBootMgr to v091
See change log in Post 1 for details

 

[thrush]

Updated MyBootMgr to v091
See change log in Post 1 for details

Sorry, for me this results in a KP when running BS (after some initial verbose lines haven't seen previously).
Bootcamp works fine though.

v090 works fine after reconfig/deploy

 

[Dayo]

results in a KP when running BS. v090 works fine after reconfig/deploy

I see. First thing though, is that to rollback in future, you do not need to reconfig/redeploy and can simply mount your ESP, delete the EFI folder, empty the trash and rename EFI_BAK. This is explained in Post 1.

As for verbose output, please read the change log in Post 1.

On the KP, please zip up the OpenCore plist file from the instance that was booted, along with the debug logs for ConfigFactory, RefindPlus and OpenCore, and share this.

Note that the last logs now present are probably not from that run. You can either figure which was from the failed run out or just take the last two or so in each case.

You might also want to clear out log files from your ESP as advised in Post 1 if not done.

Thanks

 

[thrush]

On the KP, please zip up the OpenCore plist file from the instance that was booted, along with the debug logs for ConfigFactory, RefindPlus and OpenCore, and share this.

I see this when I open the EFI:

I've shared the log file previously on GitHub. Where do I find the other files you want?

TT

 

[Dayo]

Where do I find the other files?

Nevermind. Just stay on v090 which works for you.
You can look into an update again on the next iteration.

 

[thrush]

Nevermind. Just stay on v090 which works for you.
You can look into an update again on the next iteration.

Whatever I can do to help troubleshoot, let me know. Thanks for continuing to improve MyBootMgr-

TT

 

[ahihi]

today i updated my ancient MyBootMgr v067a configuration to v091, hoping to enable booting from NVMe. the following drives are involved:

A - SATA SSD with my original Mojave installation
B - new NVMe drive attached to PCIe adapter (compatibility checked against https://forums.macrumors.com/threads/pcie-ssds-nvme-ahci.2146725/)
C - blank SATA SSD for native El Capitan
D - SATA HDD for MyBootMgr ESP

the process goes as follows:

1. clone my Mojave installation from drive A to B using Carbon Copy Cloner
2. remove all drives, put in an Apple GPU (HD 2600 XT), reset PRAM
3. insert drive C and install El Capitan on it
4. add drive D, initially with an empty ESP, and set up MyBootMgr v091 on it

at this point i put in drives A,B,C,D and check the boot pickers. RefindPlus shows all three macOS volumes. OpenCore (OC_LEG) does too, but the Mojave volume on drive B appears with the same name as the original installation on drive A. the volumes have different names and UUIDs, so not sure why this happens.

i remove drive A, but now drive B does not appear in the boot pickers at all! i try again a few times and confirm that i can only get B to show up if A is also connected.

i leave A,B,D connected and swap in my usual GPU (non-mac GTX 760). i no longer get any video from RefindPlus or OpenCore, although this worked fine in v067a. by navigating the boot pickers blindly i can boot from both A and B, though again if i remove A then B also becomes unavailable.

so the good news i can indeed run Mojave from NVMe now but i am wondering:

- can i get my boot picker video back?
- what could be causing drive B to depend on A in this way?

attached are logs from two boots, one with drives A,B connected and the other with B only.

 

[Dayo]

I updated my ancient MyBootMgr v067a configuration to v091.

You need to take a step back and tackle some basic stuff first.

OpenCore updates are not all equal and a few need a complete NVRAM reset. Not common and been a while since last needed but there is likely to have been such a requirement between OpenCore 0.6.7 and 0.9.1.

If you had run MyBootMgr v091 while booted into OpenCore set up by v067, it would have insisted that you run it while natively booted into Mac OS and advised that you reset your NVRAM. So first thing you want to do, is to follow the installations steps in Post 1 as if you are installing for the first time. The first item in those installation steps is to execute a full system reset.

As for the cloned volumes appearing with the same name, this is from a bug in early APFS versions. Older versions of MyBootMgr came with a copy of OpenCore that I patched to address this issue. I cannot recollect, but presumably was still doing this for 0.6.7. I stopped applying the patch at some point as I found that OpenCore had started working for me without it somewhere along the line. Follow this guide to fix: https://forums.macrumors.com/threads/2323684.

Your drives A & B are not codependent. Just that you have had a common issue that I have found where a user is convinced of what an issue is that they are blinded to other stuff going on.

In this case:

1. You had both drives in and they both showed up.
2. You then ran instances where Drive A was not connected and Drive B does not show up

Makes sense to conclude that Drive B showing up is linked to Drive A presence but this is only the case if the presence/absence of Drive A is the ONLY difference between when Drive B shows up or not. However, your logs show that the GPUs used for the tests were also different (if not a totally different Mac).

I would wager that the GPU used when Drive B did not show up was a flashed GPU and if you had read Post 1, you would have seen this under Requirements >> Bootscreen Support:

If you were running a flashed GPU when Drive B did not show up and Drive B only contains an APFS volume, then it was likely that the GPU caused the disappearance.

Anyway, as there are quite a few things, sort the three items discussed out first and report back so we can tackle the others.

1. Make sure you had done a full NVRAM reset
2. Fix the cloned drive naming by following the linked guide
3. Redo the "AB" and "B" test without introducing any other variables

Cheers

 

[ahihi]

You need to take a step back and tackle some basic stuff first.

OpenCore updates are not all equal and a few need a complete NVRAM reset. Not common and been a while since last needed but there is likely to have been such a requirement between OpenCore 0.6.7 and 0.9.1.

If you had run MyBootMgr v091 while booted into OpenCore set up by v067, it would have insisted that you run it while natively booted into Mac OS and advised that you reset your NVRAM. So first thing you want to do, is to follow the installations steps in Post 1 as if you are installing for the first time. The first item in those installation steps is to execute a full system reset.

As for the cloned volumes appearing with the same name, this is from a bug in early APFS versions. Older versions of MyBootMgr came with a copy of OpenCore that I patched to address this issue. I cannot recollect, but presumably was still doing this for 0.6.7. I stopped applying the patch at some point as I found that OpenCore had started working for me without it somewhere along the line. Follow this guide to fix: https://forums.macrumors.com/threads/2323684.

Your drives A & B are not codependent. Just that you have had a common issue that I have found where a user is convinced of what an issue is that they are blinded to other stuff going on.

In this case:

1. You had both drives in and they both showed up.
2. You then ran instances where Drive A was not connected and Drive B does not show up

Makes sense to conclude that Drive B showing up is linked to Drive A presence but this is only the case if the presence/absence of Drive A is the ONLY difference between when Drive B shows up or not. However, your logs show that the GPUs used for the tests were also different (if not a totally different Mac).

I would wager that the GPU used when Drive B did not show up was a flashed GPU and if you had read Post 1, you would have seen this under Requirements >> Bootscreen Support:

View attachment 2186420​

If you were running a flashed GPU when Drive B did not show up and Drive B only contains an APFS volume, then it was likely that the GPU caused the disappearance.

Anyway, as there are quite a few things, sort the three items discussed out first and report back so we can tackle the others.

1. Make sure you had done a full NVRAM reset
2. Fix the cloned drive naming by following the linked guide
3. Redo the "AB" and "B" test without introducing any other variables

Cheers

thanks for your reply. i did install MyBootMgr completely from scratch, including a full system reset (see steps 2-3 of my previous post) and took care to ensure i was changing one variable at a time, though it is possible i got my log files mixed up.

i do not own a flashed GPU. the only two GPUs that have been inside the system are the Apple HD 2600 XT which i used to set up El Capitan, and the unflashed GTX 760.

i changed the name of the volume on drive B (it previously had a temporary name of "nvmeee") and, following the link you posted, edited .contentDetails on the preboot volume to match. the volume on drive A (SATA) is called "Polyrhythm" and the one on drive B (NVMe) "Serenia".

i then did the following tests:

TEST1: HD 2600 XT, drives A,B: RefindPlus and OC_LEG both show Polyrhythm and Serenia

TEST2: HD 2600 XT, drive B: RefindPlus shows no volumes, OC_LEG only shows System Restart, System Shutdown, and Reset NVRAM

TEST3: HD 2600 XT, drive A: RefindPlus and OC_LEG both show only Polyrhythm (just to prove that Serenia is not on this drive)

for the next tests i swapped in the GTX 760, which again no longer gives me RefindPlus or OpenCore screens with v091. i have RefindPlus configured to automatically load OC_LEG, which in turn has a timeout of 10 minutes to allow me to select a volume blindly.

TEST4: GTX 760, drives A,B: i press down followed by return in an attempt to select Serenia. after a long wait Polyrhythm boots in safe mode

TEST5: GTX 760, drive B: i press return and the system reboots, suggesting no volumes are available again

so the volume name change worked, but regardless of the GPU, drive B does not show up unless drive A is also connected.

attached are the logs for each of these test cases.

after this i experimented some more with the TEST4 configuration and confirmed that both volumes are available, but i can not figure out how to consistently select one. not sure if the default selection and/or order of volumes is changing. safe mode also seems to be activating more or less randomly - in these cases the OpenCore log says "Shift means -x" but i am not pressing shift at any point...