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

[EdMun]

Finally makes sense.

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.

It makes no sense to me, I can find no evidence of any OCLP installer Rigid Patching, what leads you to believe this?
There's but one post install WiFi root patch for this machine currently installed and booted OCLP OC ...and MyBootMgr OC is still booting.
Trying an 'appropriate' patched system ConfigFactory build resulted in a hang and subsequently other working builds also hung. After NVRAM reset to no avail recovery Disk Utility seemed to rectify the problem.

 

[Dayo]

I can find no evidence of any Rigid Patching ... There's one post install patch installed

Sigh

Trying an 'appropriate' patched system ConfigFactory build resulted in a hang

ConfigFactory asks the question early in the setup flow so that it will try to minimise such conflicts but ...

1. All it does is try to minimise the conflicts

You can try the option in ConfigFactory but the chances of it generating an OCLP compatible config are slim.

Sigh

Post 1 makes a pledge:

Post 1 makes a recommendation (Repeated while running ConfigFactory):

You ignored the recommendation and while you might be keen to continue debating the outcome and banging your head against the wall on this, my take is that enough of my time has been wasted.

Sincere apologies in advance, but I will not be responding to further posts on this track. Goes without saying that this does not apply to anything that does not work as set out in Post 1; although you would probably be better off trying an alternative way altogether instead.

 

[Macschrauber]

In my experience OCLP does not make physical patches to the file system - as long as the post install patch was not done by the user.

This post install patch adds for example Wifi support for the stock Wifi module or adds Keppler support to Monterey.

So I guess that an oclp installation is native as long as noone runs the post install patch.

 

[Dayo]

I guess that an oclp installation is native as long as noone runs the post install patch.

This point has basically previously been covered actually:

It could be that OCLP rigid patching is a specific additional option that is not always used though.

The wordings used in Post 1 and in the ConfigFactory prompts are always precise and deliberately chosen.

Hence, if you consider them, you will not find the OCLP described as a rigid patcher in a blanket manner anywhere. The terms used for such are always along the lines of "DosDude Type" and the OCLP only definitely becomes a DosDude Type rigid patcher when the post install patches are run as was not sure whether it does any direct install patches.

That is why the ConfigFactory dialogue that triggers the warning in my previous does not say NB: This includes OCLP instances for instance, as that would mean all OCLP instances. Instead it says NB: This includes instances with OCLP 'System Volume' patches.

Anyway, the OCLP instance in question did have such patches in place. One mentioned in passing, WiFi, is something ConfigFactory sets OpenCore up to inject kexts for ... more or less guaranteed to be in conflict. There is likely to be BT patches for Monterey in play as well, which would also be in conflict with a ConfigFactory setup.

Anyway, things seemed to be going nowhere so thought it best to cut things short.

 

[EdMun]

I don’t know what part of 'I can find no evidence of OCLP rigid patching' you don’t understand.
The post install root patching and unpatching is patently obvious and the WiFi patch was installed to try and induce the intermittent bug and did not.
I guess that didn’t register either when you cropped it changing the context to sigh, being evasive and boorish when pressed for details of OCLP install rigid patching you claim responsible is very lame and makes you sound like a precious drip under pressure talking through his hat.
As your '4th largest donor ever’ I thought you were better than that and obviously appreciate I the time and effort , you might recall you asked for my help when I responded to the person struggling with the bug/s peculiar to ConfigFactory OC, I could have been more helpful and suggested they trash the buggy ConfigFactory OC and install OCLP OC (and try not to engage the cranky dev)

 

[freqrider]

Dayo, I'm having an issue on my 3,1 with latest openCore builds, (8.0 and above) with MyBoot MGR, OCLP and Martin Lo's latest version, where Monterey boots normally but any Python CLI tools I try I get an 'illegal hardware instructions' error. This does not happen with 0.7.9 and the manually added Monterey patches. Very strange! And only happens in Monterey. Same Python version in Mojave and no issue. The 'illegal hardware instructions' error screams AVX issue to me but I could be wrong. No matter what config I use with 0.8.0 I get this error. Is the 3,1 done for openCore updates or is there something else going on? Any input would be appreciated as I consider you the 3,1 OC master!

I'm on Monterey 12.4 with Python3.10.6 but other versions exhibit the same error as well. I noticed several Brew installs no longer worked on 0.8.0 but resumed working on 0.7.9. Bizarre... My only thought is something with CPUID, perhaps?

 

[Dayo]

I don't think your issue is MacPro3,1 specific (would most likely affect any cMP) and despite your v0.7.9 report, I don't think it is OpenCore version related either (the OpenCore version was most likely not the only difference in your test). It is almost certainly down to one or more AVX optimised Python modules tied to Monterey and this is probably behind the Homebrew failures.

I don't think there is a current Monterey based solution and that you need to run versions of those modules developed for older versions of Mac OS ... which could actually be older versions of Monterey.

If you want to take the Monterey angle further, I'll suggest you ask for insights on a Python related forum; perhaps somewhere like StackOverflow. I think it is most likely futile myself but who knows?

 

[freqrider]

I tested extensively and only change is openCore version. 0.8.0 and newer is causing the issue. Even in your changelog I see some Python optimizations were made. Not saying this is the cause, btw. Reverting to O.7.9 build fixes the issue and python3.10 launches fine now. I agree it is most likely AVX trap that is slipping by somewhere. I will check configs and see if any of the Monterey patches differ and if so, copy them over to the O.8.0, 0.8.5 version.

Also, I meant to ask you for some time. Is there anywhere/anyway I could download older versions of MyBootMgr? Any archives? Especially since I'm not sure newer versions will be suitable for me in the future. Thanks Dayo!

 

[Dayo]

Well, if you are certain that changing from OpenCore 0.7.9 to 0.8.0, without any other changes or differences whatsoever, causes Python to start generating "illegal hardware instruction" errors, then what you are in effect saying is that a bug was introduced in OpenCore 0.8.0 and you need to report this on the OpenCore BugTracker so that it can be fixed.

Simply rolling back to v0.7.9 without informing the developers of such would not be cricket.

PS: MyBootMgr is a flowing stream. No archive of old versions

 

[gtackett]

I'm setting up my 5,1 with MyBootMgr to add some flexibility to controlling what gets booted and how.

I've installed OpenCore successfully before, so some of what ConfigFactory asks is familiar, but my memory is fuzzy on details of OpenCore.

My OpenCore configuration specified the paths to my PCIe-connected drives to make them appear as internal drives. So this step in ConfigFactory looked familiar:

Would you like to have drives connected to PCIe Slots in your
Early 2009 Mac Pro identify as internal drives?

Enables a kext that typically makes such drives identify as internal drives.

I clicked Yes. But at the next screen I was uncertain which kext to choose:

Which kext would you like to activate:
* Innie v1.2.1
* Innie v1.3.0
* ThirdPartyAHCI v1.0.1

I've seen a comment, I think in @Dayo 's repository, about rolling back from Innie v1.3.0 to Innie v1.2.1 and the absence of any development activity on innie. But I'm not familiar with ThirdPartyAHCI, so I'm not sure what the best option is here.

 

[JedNZ]

I’m using Innie v1.3.0 and it works perfectly - never had an issue.

When previously testing the three options in ConfigFactory, I’ve never had boot success using ThirdPartyAHCI over either of the Innie choices. I searched on ThirdPartyAHCI and couldn’t find a descriptor for it anywhere, however stumbled across this post which talks about using it for Windows on PCIe SATA SSD drives. Maybe @Dayo can describe the use-case for it over using Innie.

 

[Dayo]

I'm not sure what the best option is

Relatively Short and Sweet:
You can just select the kexts in turn until you find one that hopefully works for you. Very broadly, Innie is focused on NVME and ThirdPartyAHCI on SATA drives in PCIe adaptors.

In your case however, given that you already have the DeviceProperties setup in an older OpenCore config, you should select "NO" to using kexts and after running ConfigFactory, manually update the OpenCore config files with your existing settings before deploying.

A good exercise for you, if you do not already know how, would be to do some web searches on how to use tools like PlistBuddy to edit plist files. You can then put a simple bash script together to edit the OpenCore config files with your settings.

If you paste this script into WrangleConfig, or put it somewhere and add a line to WrangleConfig to run it, you will be able to select the option to run it in ConfigFactory to automatically modify the default setup with your settings each time. Any scripting added to WrangleConfig is preserved between MyBootMgr updates.

Some of the Gory Details:
ConfigFactory initially just came with Innie (v1.2.1) but this did not work for all setups, including mine at the time. I later found that the ThirdPartySATA kext did work for me (after amending it ... new devices can be added to the list of those it works with), so I added this as an option to ConfigFactory.

Innie was later updated to v1.3.0, after some Mac OS update IIRC, so I updated ConfigFactory to use this updated version accordingly (I don't use Innie myself and actually no longer have any PCIe drives in place). Might have been a fluke at the time, but it seemed most users found that the new version of Innie did not work for them but that the old one did. I therefore rolled ConfigFactory back to using Innie v1.2.1.

From what I could understand however, Innie v1.2.1 only worked reliably up to a certain Mac OS version while Innie v1.3.0, when it works, works for newer Mac OS versions. So I later updated Configfactory to provide the option to select between the two versions.

As mentioned in the summary earlier, "best" is to use DeviceProperties. ConfigFactory therefore defaults to trying to set this up and only degrades to offering the kexts when it is unable to do so.

Failures are when one of the following happens:

1. ConfigFactory could not find any PCIe drives present
   • From the dialogue you posted, this may have been the case for you
2. ConfigFactory could not get the ACPI path for any one PCIe drive present
   • When more than one PCIe drive is present, failing for one is taken as failing for all
3. ConfigFactory got an exception when trying to get the Device Paths
   • Euphemism for a bug known to be present in the Configfactory detection code
   • It has been limited to a certain chunk of code but not yet specifically identified
   • Currently just isolated by trapping the error to stop it crashing the app
   • Will ultimately identify and fix it at some point
     • Not actively looking at it as currently not running such drives and not critical given the kext option
     • Been slowly narrowing it down as I get ConfigFactory debug logs; which is once in a blue moon

EDIT
Checked and the dialogue you got is actually from when PCIe drives are detected and Condition 3 is met
Please share the ConfigFactory debug log to give more insight

 

[gtackett]

Relatively Short and Sweet:
You can just select the kexts in turn until you find one that hopefully works for you. Very broadly, Innie is focused on NVME and ThirdPartyAHCI on SATA drives in PCIe adaptors.

In your case however, given that you already have the DeviceProperties setup in an older OpenCore config, you should select "NO" to using kexts and after running ConfigFactory, manually update the OpenCore config files with your existing settings before deploying.

A good exercise for you, if you do not already know how, would be to do some web searches on how to use tools like PlistBuddy to edit plist files. You can then put a simple bash script together to edit the OpenCore config files with your settings.

If you paste this script into WrangleConfig, or put it somewhere and add a line to WrangleConfig to run it, you will be able to select the option to run it in ConfigFactory to automatically modify the default setup with your settings each time. Any scripting added to WrangleConfig is preserved between MyBootMgr updates.

Some of the Gory Details:
ConfigFactory initially just came with Innie (v1.2.1) but this did not work for all setups, including mine at the time. I later found that the ThirdPartySATA kext did work for me (after amending it ... new devices can be added to the list of those it works with), so I added this as an option to ConfigFactory.

Innie was later updated to v1.3.0, after some Mac OS update IIRC, so I updated ConfigFactory to use this updated version accordingly (I don't use Innie myself and actually no longer have any PCIe drives in place). Might have been a fluke at the time, but it seemed most users found that the new version of Innie did not work for them but that the old one did. I therefore rolled ConfigFactory back to using Innie v1.2.1.

From what I could understand however, Innie v1.2.1 only worked reliably up to a certain Mac OS version while Innie v1.3.0, when it works, works for newer Mac OS versions. So I later updated Configfactory to provide the option to select between the two versions.

As mentioned in the summary earlier, "best" is to use DeviceProperties. ConfigFactory therefore defaults to trying to set this up and only degrades to offering the kexts when it is unable to do so.

Failures are when one of the following happens:

1. ConfigFactory could not find any PCIe drives present
   • From the dialogue you posted, this may have been the case for you
2. ConfigFactory could not get the ACPI path for any one PCIe drive present
   • When more than one PCIe drive is present, failing for one is taken as failing for all
3. ConfigFactory got an exception when trying to get the Device Paths
   • Euphemism for a bug known to be present in the Configfactory detection code
   • It has been limited to a certain chunk of code but not yet specifically identified
   • Currently just isolated by trapping the error to stop it crashing the app
   • Will ultimately identify and fix it at some point
     • Not actively looking at it as currently not running such drives and not critical given the kext option
     • Been slowly narrowing it down as I get ConfigFactory debug logs; which is once in a blue moon

EDIT
Checked and the dialogue you got is actually from when PCIe drives are detected and Condition 3 is met
Please share the ConfigFactory debug log to give more insight

Attached is a zip of the most recent log file from the EFI folder. I hope I picked the right one. Let me know if it doesn't look like what you expect.

 

[Dayo]

That's a RefindPlus log from the ESP.

I should have been specific and stated that I wanted the ConfigFactory log which is saved in the Users/Shared/MyBootMgr folder.

In any case, the current ConfigFactory is now outdated as a new version of MyBootMgr will be issued when I get a minute later today. You can share the ConfigFactory log from running that version.

Thanks

 

[Dayo]

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

 

[gtackett]

That's a RefindPlus log from the ESP.

I should have been specific and stated that I wanted the ConfigFactory log which is saved in the Users/Shared/MyBootMgr folder.

In any case, the current ConfigFactory is now outdated as a new version of MyBootMgr will be issued when I get a minute later today. You can share the ConfigFactory log from running that version.

Thanks

I just ran your new version of MyBootMgr. Here's the ConfigFactory log.

!!** START LOGGING **
MyBootMgr v086 ... ThisAPI:- 34 ... Mode:- Dual
Seek Python 3.7 to 3.10:- Found Python 3.9.15 in /usr/local/bin/python3.9

** START: Primary Settings **
Host_Unit:- Early 2009 Mac Pro ... Host_OS:- MacOS 10.14.6
Firmware:- MacPro5,1 ... ROM_Type:- BootROM4,1a ... Use_Defaults:- true
Dual_CPU:- true ... Westmere/Gulftown:- true
Has_APFS:- true ... Has_NVME:- true
Has_UEFI:- true ... Has_WiFi:- true ... Has_BT:- true
Mac_OS_11:- false ... Mac_OS_12:- false
Mac_OS_13:- false ... Mac_OS_14:- false
Win_OS:- false ... Lin_OS:- false
Win_UEFI:- false ... Win_HyperV:- false
-- GET_STORAGE_PATHS:- NONE
-- CHK_FOR_NVME:- INDEX%ERROR
-- FALLBACK_STORAGE_PATHS:- PciRoot(0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)
Set_Drives:- true ... Slot_PCI:- true ... Alt_Path:- true
PCI_Drives:- true ... Skip_NVMeFix:- false ... PCI_Count:- 1 ... Internal_Tag:- No
Innie_Active:- false ... Skip_Innie:- false ... Use_Innie:- true|v1.3.0 ... Use_ThirdPartyAHCI:- false
PathGPU:- SKIPPED
Card_Nvidia:- false ... Card_AMD:- true ... Cape_Verde:- false ... Direct_GOP:- false
Legacy_AMD:- true ... Tweak_AMD:- NotSet ... Model_GPU:- AMD Radeon R9 280
GPU_DisplayPort:- NotSet ... GPU_Count:- 1 ... Legacy_MacOS:- true ... OC_Legacy:- false
External_Boot:- false ... Use_FireWire:- false ... Set_XHCI:- false ... Set_TB3:- false
FileVault:- true ... ForceSIP_OC:- false ... Respect_RP:- false

** START: Secondary Settings **
OC : DRM/GPU_Accel:- false ... VMM:- No ... SBM:- Disabled ... Spoof:- None
OC_VMM : DRM/GPU_Accel:- false ... VMM:- Yes ... SBM:- Disabled ... Spoof:- None

* START: Sundry Settings *
BG_Type_RP:- Self Defined ... BG_Type_OC:- Syrah Black
RGB_Data_RP:- 40 109 172 ... RGB_Mean_RP:- 107 ... BG_Dark_RP:- true
BG_Red_RP:- false ... BG_Green_RP:- false ... BG_Blue_RP:- true
Hide_Aux:- true ... DosDude:- false ... Use_Other:- NotSet
Boost_PCI:- false ... Spoof_SSE42:- false

** START: Tertiary Settings **
MacOS_Cap:- true ... MacOS_Count:- 5
Wrangle_Config:- false ... Skip_AVXpel:- NotSet
Target_Disk:- EVO ... Start_Disk:- Hitachi 2TB MojaveImage

** START: Create Setup **
* SETUP: OC/config.plist
- Boot_Args:- nvram_paniclog=0 mbasd=1 -no_compat_check -lilubetaall debug=0x100 keepsyms=1 no32exec=0
* SETUP: OC_VMM/config.plist
- Boot_Args:- nvram_paniclog=0 mbasd=1 -no_compat_check -lilubetaall
-- GET_WIFI_PATCH:- IO80211Mojave ... TypeWIFI:- Broadcom4331

** START: Global Kext List **
* USB-Map-MacPro51.kext
* AppleALC.kext
* FeatureUnlock.kext
* NVMeFix.kext
* AppleMCEReporterDisabler.kext
* Innie.kext
* WhateverGreen.kext
* Lilu.kext
** END LOGGING **!!

When I tried to deploy this to my NVMe boot drive, I got this:

Earlier today I was able to build and deploy a configuration to a thumb drive and to boot from EVO using the refind that got deployed to that thumb drive.

 

[Dayo]

Thanks.

Bit of a mixed bag. The good part is that it seems the "exception" is now sorted and ConfigFactory can get the device path without tripping up.

The bad part is with the 'Virtual' disk thing. I will look at this later but may be related to changes I made to better support Yosemite and older. This may have cost some reliability in certain cases.

You can overwrite with the previous DeployConfig app and use that instead. Otherwise, mount the ESP manually and copy the generated EFI folder there (don't drag and drop).

EDIT: Actually, the error might have come from BootBlesser and you might be able to deploy if you do not select the option to bless at the same time. You can then either manually bless or use an older version of that app.

 

[Dayo]

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

 

[Dayo]

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

 

[Dayo]

Updated MyBootMgr to v087

There may have been a compilation issue with the initial upload which has now been addressed.

 

[Dayo]

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

 

[strupp3003]

Hey Dayo and all the people still not willing to let the cMP die,

Thanks for the great Idea - exactly what I was looking for to use with my 2008 MacPro 3,1... !
My Goal is running Monterey via Opencore and Windows 10 in Legacy Mode.

So far, I set up the myBootMgr and rEFIndPlus as well as Opencore work fine. I've got an internal PCIe SSD (Kingston HyperX AHCI) with Monterey and Windows 10 on a separate SSD in one of the drive bays. I configured rEFInd & Opencore to boot Monterey by default, which works fine, but I can't get rEFInd to detect my Windows installation....

If I hit alt during boot, the native Mac BootPicker shows the Windows Disk and I can boot it without problems. I'd just like to have it showing up in rEFInd!

Already tried all kinds of adjustments to the rEFInd config according to the manual, but I just can't get Windows to show up...

Is there any way to manually create an entry in the rEFInd Config pointing it to the specific partition / Disk?
I have no clue how legacy Windows booting works...

And another Question:
I noted, that my wireless Keyboard & mouse (not Apple Bluetooth, but a cheap Microsoft 2,4Ghz with a USB Dongle) don't work in the bootPicker if plugged into a USB hub, but does work if plugged directly into the MacPro's Front USB. Due to the USB1.1 Issue with Monterey, however, once the OS is booted, it only works when plugged into the Hub...
Plugging the Dongle around is no big deal, just doesn't fit my ambition to make it perfect... 🙃
Any Idea how I could get the hub to work with rEFInd?

Thanks!
And again: Awesome to see so many people still putting work into these old but beautiful machines!

 

[Dayo]

If I understand you, no issues with RefindPlus -> OpenCore -> Monterey but Legacy Winodws is not showing up in RefindPlus.
If so, that sounds like a RefindPlus specific issue that is best dealt with on GitHub.

I suspect you are running BootCamp and there can be issues with this sometimes. If BootCamp, give the issue you raise on GitHub a title like "Legacy BootCamp Windows does not appear" so that the issue tracker can link previous similar issues raised for reference. Drop "BootCamp" if not applicable.

As for the USB thing, it does seem the hub is not yet initialised when RefindPlus is running while the native ports are disabled when the OS is running later.

There is a USB1.1 injector kext in ConfigFactory but it is not activated as tests are pending.
You could try adding the file (attached) to the relevant kexts folder and updating the associated config plist with the items below to see if it helps.

Spoiler: USB1-Injector Kext Config

            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>USB1-Injector.kext/Contents/PlugIns/AppleUSBOHCI.kext</string>
                <key>Comment</key>
                <string>USB1.1 Injector Plugin - AppleUSBOHCI</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/AppleUSBOHCI</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string>21.0.0</string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>USB1-Injector.kext/Contents/PlugIns/AppleUSBOHCIPCI.kext</string>
                <key>Comment</key>
                <string>USB1.1 Injector Plugin - AppleUSBOHCIPCI</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/AppleUSBOHCIPCI</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string>21.0.0</string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>USB1-Injector.kext/Contents/PlugIns/AppleUSBUHCI.kext</string>
                <key>Comment</key>
                <string>USB1.1 Injector Plugin - AppleUSBUHCI</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/AppleUSBUHCI</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string>21.0.0</string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>USB1-Injector.kext/Contents/PlugIns/AppleUSBUHCIPCI.kext</string>
                <key>Comment</key>
                <string>USB1.1 Injector Plugin - AppleUSBUHCIPCI</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/AppleUSBUHCIPCI</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string>21.0.0</string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>

Since you used MyBootMgr, I presume you must have a natively bootable MacOS version available should you need to get in to remove the addition if it causes a failure to boot Monterey via OpenCore.

I'll pick the GitHub issue up at some point tomorrow.

Finally, it's spelt RefindPlus!

 

[strupp3003]

Hey Dayo,

Thanks for your reply!

If I understand you, no issues with RefindPlus -> OpenCore -> Monterey but Legacy Winodws is not showing up in RefindPlus.

That's it!

I suspect you are running BootCamp

Exactly!

--> I'll raise the issue on the RefindPlus GitHub.

There is a USB1.1 injector kext

Thanks for the hint, I'll give it a try!

 

[osxfr33k]

Hi Dayo thanks for the latest version. I get a error when trying to install Dual no issues with Solo. See attached.