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

[ThetaTauMan]

Hi,

The errors in ConfigFactory are because you do not have Python 3 installed.
Actually quite fortuitous as while ConfigFactory tries to work around this, it was set up a long time ago and I am unable to test that condition any longer since I do have Python 3 installed.

The errors can be overcome by installing Python 3 but if you don't mind, I'll like to fix the workaround instead. So hold off installing this.

Initially, can you share the ConfigFactory debug log? You will find it in the /Users/Shared/MyBootMgr folder. If not there, rerun ConfigFactory and select the option to run in debug mode.

Thanks

Well... I tried several times and it isn't generating a log file that I see, even though I asked for debug mode in configfactory. (sorry...) I even looked for a hidden file using terminal. Maybe the logging also relied on Python 3?

Also, to correct a couple of misstatements in my initial message (in case anyone else is following along) the second terminal error (presumably due to lack of Py3) was after the PCIe question, and I only had to quit terminal, go to ConfigFactory and press ESC to get it to continue.

Meanwhile, I have another question. For the query:

I can read this in two ways. Which do you intend: HFS+ boot volumes (non-efi) or HFS+ boot volumes with EFI folders? (or both, or something else completely?) I have OSX Extended volumes, which I think are technically also HFS+, but they are EFI booting ones.

 

[Dayo]

it isn't generating a log file that I see

OK. Nevermind.
Just run /usr/bin/python --version in terminal and share the result.
I have applied a fix to the code but want to be sure why your setup fooled the Python 3 detection logic.

Which do you intend: HFS+ boot volumes (non-efi) or HFS+ boot volumes with EFI folders?

Any HFS+ Boot Volumes.

 

[ThetaTauMan]

Just run /usr/bin/python --version in terminal and share the result.
I have applied a fix to the code but want to be sure why your setup fooled the Python 3 detection logic.

it replies:

Python 2.7.10

 

[Dayo]

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

 

[ThetaTauMan]

Success! (at least for the configFactory / python issue)😃
Upon booting through OC, and running VerifyOC, I am told that Lilu, WhateverGreen, and GPU Accel are all not detected.
Looking at the ConfigFactory log (attached), it seems like it thought it installed Lilu and WhateverGreen, but apparently something didn't happen.
Suggestions?

<editing to possibly answer my own question>
Hmmm...... the OC log files in the EFI drive seem to suggest that it might be because I haven't yet tried to install anything that requires the kexts. (I am still in ElCapitan.) If that is actually the case, then the instruction to run VerifyOC might be a bit premature, presuming that one is doing all this to get to the ability to install an unsupported OS version.


(By the way, thanks for all the help. This is a LOT further than I had managed to get on my own with OC.)

 

[Dayo]

If you went back two or so years ago, users were wont to boot outside OC while thinking they were using OC, or have some old half baked OC setup that they booted into instead of the MyBootMgr one. VerifyOC does high level checks on this.

ConfigFactory has become yet more refined in the interim and sets stuff up for only when they are needed but VerifyOC is still at the basic level.

So, whlle some kexts are present, ConfigFactory may set them up to only be actually activated when needed. So on MP31 and unflashed MP41, this is LoSierra. For MP51 and flashed MP41, this is Catalina. Basically does not load stuff when not needed.

VerifyOC does a very rudimentary check to determine if OC and some typical kexts are present to let them know if they were actually running a properly configured OC instance from MyBootMgr. It needs to be either removed since the original problem it addresses has essentially gone or be updated to reflect the nuances added to ConfigFactory over time.

Either way, you are running OC as it would have flagged this if not. It is just that the kexts listed are not activated on the supported MacOS version you are running. If you boot an unsupported version, they will be activated.

 

[ThetaTauMan]

One more thing (can’t promise it to be the last ):
I apologize if this is slightly off topic, but your thread at least recognizes MP3,1 whereas the OC thread seems focused on 5,1.
Last night I tried to install High Sierra. (Working up stepwise) I ran into what I think was issues with it not being able to do it’s APFS firmware update (I assume not designed for 3,1) and therefore failed. I remember ConfigFactory(CF) asks about DosDude, but I would prefer not to do that because of the SIP disabling requirement. However CF also asked about APFS rom updates. Is there a 3,1 APFS rom that I just haven’t found? Or am I misunderstanding something?

 

[Dayo]

Hmm, I used a DosDude patched installation for HiSierra at the time.

I think you might be best served using the DosDude process to install. Just disable all the patches, especially the APFS one, since RefindPlus provides this. Basically using DosDude as an installation vehicle that bypasses the firmware thing.

As for SIP, don't get hung up on that. If DosDude requires it disabled, then just do that. After it is installed, reinstall a vanilla version over it and re-enable SIP as you like.

Basically never tried installing HiSierra natively on MP31 myself but I know DosDude patched instance installs without issue and that this can be overwritten later.

Could be that overwriting is not needed if no patches are selected. Most likely actually.

 

[Dayo]

PS: It could also be that you have an installer with an expired certificate, which would prevent installation.

You will need to set the date on your MP31 to avoid this if so,

macOS High Sierra (10.13) Unsupported Macs Thread

Finally managed to reinstall High Sierra using the @dosdude1 patch. For anyone having similar issues, there were two problems in my case: 1. The Patcher could not be created on the USB Stick I had named my USB Drive as "HighSierraBoot" but I noticed that the creation process for the Patcher...

forums.macrumors.com

 

[Dayo]

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

 

[zzzippp]

@Dayo, I am having an issue with the release .EFI binary of RefindPlus v0.13.2.AP Pre-Release (included with MyBootMgr v079) not displaying the graphical boot selection menu, despite the debug binary of RefindPlus v0.13.2.AP Pre-Release displaying the menu just fine. I am able to interact with the RefindPlus menu just fine, only I can't see it. The version of RefindPlus included in MyBootMgr v079b appears to be the same as in v079, and when I dropped the release .EFI binary of RefindPlus from MyBootMgr v079b, there was still no display of the boot menu.

I have also tried the release .EFI binary of RefindPlus v0.13.2.AN Alt from your GitHub page with the same result, no display of the menu. If it helps to know, neither the release nor debug binaries of the non-Alt v0.13.2.AN RefindPlus displays the menu.

The machine with this issue is not the one listed in my signature, but rather a different MacPro5,1 with Dual 2.4 GHz Quad Core Xeon E5620s, and its video card is an EVGA NVIDIA GTX 760.

Attached is a .zip file containing the MyBootMgr v079 ConfigFactory debug log, the RefindPlus config.conf file, and a RefindPlus v0.13.2.AP Pre-Release log file (from the debug binary of course, since the release binary doesn't output a log file.)

Please let me know if you'd rather I add this as an issue on GitHub or if you need any further information. Thank you!

 

[Dayo]

If you can open on GitHub, then yes that works for RefindPlus specific issues.

Thanks

 

[Dayo]

OC is configured to set boot-args to debug=0x144 keepsyms=1 -no_compat_check, and based on what I see when I boot "natively" into macOS Mojave (not via OC), those arguments aren't written to the physical NVRAM. I only see -no_compat_check.

Note that -no_compat_check is not an NVRAM variable but a possible part of the value of the boot-args NVRAM variable. That is, boot-args is the variable and this might have a value that includes -no_compat_check amongst others.

RefindPlus currently always changes the boot-args NVRAM variable value to -no_compat_check if the disable_compat_check setting is on when booting into MacOS.

When you see it logging Disable Compat Check ... Already Started, it means it has not tried to change the value because the value is exactly equal to -no_compat_check. If the value had been debug=0x144 keepsyms=1 -no_compat_check, it would have changed this to -no_compat_check and logged Disable Compat Check ... Success.

In summary, current versions of RefindPlus, with disable_compat_check set, will change things when the value of boot-args is not equal to "-no_compat_check". The next release of RefindPlus will only make the changes when the value of boot-args does not contain "-no_compat_check". Furthermore, this will add "-no_compat_check" to whatever is already there in such cases, as opposed to replacing what is there with "-no_compat_check" as currently happens.

PS: disable_compat_check only acts when booting directly into MacOS from RefindPlus. It is not called when running loaders such as OpenCore or other operating systems.

 

[zzzippp]

Note that -no_compat_check is not an NVRAM variable but a possible part of the value of boot-args NVRAM variable. That is, boot-args is the variable and this might have a value that includes -no_compat_check amongst others.

Yes, sorry, I think what I wrote may have been unclear due to incorrect nomenclature. I understand that boot-args is the named NVRAM variable, and then it has a stored value (or string?) that can include -no_compat_check as well as other arguments in that stored value.

The important thing here is that I want to check whether OpenCore is writing the value debug=0x144 keepsyms=1 -no_compat_check to the boot-args variable of the physical NVRAM every time I boot into macOS Big Sur, because if it is, then that means the boot-args variable would get written to physical NVRAM twice on every (re)boot to macOS BigSur, once by RefindPlus (versions prior to the next release) and then again by OpenCore.

 

[Dayo]

1. RefindPlus only writes MacOS stuff when booting MacOS directly
2. OpenCore as set up by MyBootMgr only writes some OpenCore specific stuff needed for it to operate to the NVRAM. If these have not changed, nothing will happen as was mentioned. Other "NVRAM" stuff happens in the RAM (WriteFlash = False)

The scope of disable_compat_check is set out in the config file notes.

RefindPlus/config.conf-sample at GOPFix · dakanji/RefindPlus

A Boot Manager for Mac and PC. Contribute to dakanji/RefindPlus development by creating an account on GitHub.

github.com

Read those notes! I suppose "Only applies to MacOS" could be "Only applies to MacOS boots" or something like that.

 

[zzzippp]

Read those notes! I suppose "Only applies to MacOS" could be "Only applies to MacOS boots" or something like that.

Yes, read quite some time ago, and I actually always use the diff feature of my text editor to compare changes to the notes in the config.conf file of a new RefindPlus release compared to the previous one.

Honestly, I wasn't clear on the fact that disable_compat_check is only applied/checked when booting into MacOS directly rather than on the first RP menu load after changing the setting. Thank you for the clarification!

 

[Dayo]

You could even disable it depending on your needs.
The feature was added for Catalina back then as the flag was enough for MP51 to boot that MacOS version.

It gets too difficult to cater for all setups so it is just left active as would have otherwise had to get ConfigFactory to specifically determine whether Catalina is in play or not.

 

[Dayo]

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

 

[JedNZ]

MyBootMgr v080 is working beautifully with my system. I really appreciate your continued work wth this @Dayo

 

[malcom reynolds]

I have a MacPro 5,1, which I have set up to dual boot between MacOS High Sierra and Linux Mint 20. I have a (Mac-ready) Radeon HD5770 and an AMD RX580, both of which are plugged in. I'm not interested in running a newer unsupported version of macOS, I just want a boot menu so I can select between macOS and Linux. Everything I've read indicates that refind+ should display a boot menu on the RX580, but it doesn't.

It won't boot by selecting a number either. On my machine, 4 is Linux, 5 is macOS. If I plug the monitor into the HD5770 everything works ok. plug it into the RX580, the mac won't boot.

The card is ok, it would boot into macOS (with no boot manager screen), but after installing refind+ using MyBootMgr - nothing.

 

[Dayo]

refind+ should display a boot menu on the RX580, but it doesn't.

I don't know about refind+, but RefindPlus definitely shows a boot menu with the RX580.
If you have a problem running RefindPlus, please raise an issue on GitHub as advised in Post 1.

Thanks

 

[osxfr33k]

Hi Dayo long time since I created a post. I apologize if this question has been already asked or if there is a link you can refer me to for this question. Will refindplus chain loading work with open core legacy patch version 0.4.3 or 0.4.4 with MacOS Monterey on a MacPro 5,1? I want to install refindplus then move out the default opencore files with OCLP.

 

[Dayo]

RefindPlus can work with OC configs from any source, including from the OCLP.

As with any config from third parties, you will need to make sure the LauncherOption setting is consistent with MyBootMgr requirements before use as explained under the Post Installation Section of Post 1.

If you have been using the OCLP before, or ever booted into an OCLP OC setup without this change (even once), your Mac will be in a perpetual state of OC executing a boot coup every time you start it up and you will need to resolve this by following the instructions on recovering from OpenCore boot coups under the "Other Considerations" section of Post 1.

To repeat, every time you boot into OC via an OCLP setup without the mentioned change, the perpetual boot coup state will be reinstated.

 

[osxfr33k]

RefindPlus can work with OC configs from any source, including from the OCLP.

As with any config from third parties, you will need to make sure the LauncherOption setting is consistent with MyBootMgr requirements before use as explained under the Post Installation Section of Post 1.

If you have been using the OCLP before, or ever booted into an OCLP OC setup without this change (even once), your Mac will be in a perpetual state of OC executing a boot coup every time you start it up and you will need to resolve this by following the instructions on recovering from OpenCore boot coups under the "Other Considerations" section of Post 1.

To repeat, every time you boot into OC via an OCLP setup without the mentioned change, the perpetual boot coup state will be reinstated.

So I can see that this option key is not available in the OC default version that comes with your package well at least on my version which is older November 2020, but I need to make sure on any version of OC I put into use to make sure under Misc/Boot/launcherOption key needs to be set to disabled.

Is this option key available in later versions of OC? If this key is not there what do you suggest place the key there and change to value to Disabled.

 

[Dayo]

Nov 2020 version is like something from over a century ago in OpenCore terms and a lot of things have changed in that time. I don't believe there was anything called OCLP back then to start with. Can only discuss current versions.