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

[JedNZ]

@Dayo
Just having some issues with 070a, where the disk image takes ages to verify before mounting on the desktop, and when it finally does (2mins+) it first asks if I have a cMP 2009 flashed to 5,1 (which it is, so I answer YES) and it then shows this. "Your computer does not appear to actually be a flashed Early 2009 Mac Pro".

Checks:
SIP is disabled.
Have tried another admin logon on the same cMP and get the same result.
I have downloaded the MyBootMgr package again and get the same results.

Anyone else having this issue, or have any ideas what might be going on?

 

[Dayo]

Hi, I will take a look at the message issue later. In the meantime, try running ConfigFactory when not booted via OpenCore.

Verification times etc are down to your machine ... The package is larger due to bundled Python. Could be why it takes more time but not experiencing this and was the same in v070. Will see if someone else reports the same.

EDIT:
Before rerunning outside OpenCore, please share the results of either of these commands in Terminal:

• If on Big Sur or Newer: system_profiler SPHardwareDataType | grep 'System Firmware Version'
• If on Catalina or Earlier: system_profiler SPHardwareDataType | grep 'Boot ROM Version'

That is, run while still booted in OpenCore before re-running ConfigFactory

 

[JedNZ]

I'm running Mojave with the latest security updates.

Here's the output: Boot ROM Version: 9999.0.0.0.0

And in System Information, it shows: Boot ROM Version: 9999.0.0.0.0 SMC Version (system): 9.9999 SMC Version (processor tray): 1.39f5

Update:
Okay, so I booted into Mojave outside of OpenCore and had no issues at all using ConfigFactory. Booted back in via OpenCore and get the following results:
Boot ROM Version: 9999.9.9.9.8

System Information:

Boot ROM Version:    9999.9.9.9.8
  SMC Version (system):    9.99f99
  SMC Version (processor tray):    1.39f5

When using ValidateOC I get this dialog box:

A few other checks:

VideoProc shows HW acceleration for decoding etc.

Innie is working - all PCIe drives are showing an internal.

WiFi and BT working as per usual (BCM94360CD).

Update 2:
But when re-running ConfigFactory again (and no reusing the saved settings), I get the same error as I did before upgrading to 070a.

If I choose to reuse the saved settings then I see the rebuild status bar followed by this error:

I press OK and ConfigFactory quits.

I tried to ValidateOC again, and got this error

so I checked the MyBootMgr folder and noticed the folders were hidden (preceded with a period)

I removed the period, re-ran ValidateOC and get this result

and looking inside the OC_ALT folder I see that the config.plist file is missing.

I notice the Kexts folder is missing from both the OC folders

and the OC_ALT folder

Bu there is another anomaly also:
The BOOT folders are different (left is in MyBootMgr folder, right is in my ESP)

Update 3:
When I manually copy the BOOT, OC and OC_ALT folders across from my ESP to MyBootMgr folder I still get this error when trying to ValidateOC

Let me know if I can do any other checking/testing.

 

[Dayo]

The warning message you got was a bit lazy in that it just tells you that there is a issue in vague terms assuming this would be reported and should have had the following:

1. Should have given more relevant information, and most importantly,
2. Should have given some basic initial remediation a user can attempt

TL;DR
Run it while booted via RefindPlus (outside OpenCore) or better still, download and use v070b. It will either not generate the error message or clearly tell you what you need to do first. v070b includes a few small tweaks so best to use this.

GORY DETAILS
ConfigFactory caters to a relatively broad church. It doesn't matter whether you are on 2008/2009/2010/2012 cMP or 2008/2009 Xserve, which BootROM version you have, your CPU generation, whether your firmware is flashed or not, which GPU you are using (in most cases), or whether you have a DosDude or other patched installation or not, it will set RefindPlus/OpenCore up to match and give you the same feature set across the board.

It should also work for many non cMP/Xserve units but the line was drawn there to limit complexity and the maintenance burden.

When you run ConfigFactory, it first detects your Mac model. If a 2009 cMP or Xserve model is detected, it asks users whether it has been flashed as these are capable of being flashed with cMP 5,1 firmware.

Given that a user may give an incorrect answer, it then attempts to verify the answer as follows:

• If a user indicates it is unflashed, but a cMP 5,1 BootROM is detected, it halts on a variant of the message you got.
• If a user indicates it is flashed, but a cMP 5,1 BootROM is not detected, it halts on the message you got.

If not on a 2009 cMP or Xserve model, it still detects the BootROM version and proceeds accordingly (cMP5,1 can come with any one of several BootROM versions with different capabilities). It just doesn't ask this particular question on those. If it can't detect the BootROM version accurately, it throws a message and halts.

Anyway, you fall into the scenario whereby you indicated that your cMP4,1 is flashed but ConfigFactory could not verify this and halted. Question is why?

Well, ConfigFactory has been spoofing the BootROM version in OpenCore for a while now and when it attempts to get BootROM version information for verification while booted via OpenCore, it gets the spoofed version string and not the real version string.

This is not a problem for users that have been keeping up with MyBootMgr updates as the spoofed value was later changed and was encoded to carry information about the actual BootROM version. It is however unable to do this for those who have not been keeping up with MyBootMgr updates when it is run from within OpenCore (they do not have the encoded string).

Such naughty users need to either run ConfigFactory outside OpenCore or use versions distributed with MyBootMgr v070b or later which would handle their situation better.

To be fair though, it is generally always better to run ConfigFactory outside OpenCore but this was not documented as issues arising from not doing this are expected to be rare.

 

[Dayo]

Let me know if I can do any other checking/testing.

Thanks ... Just always use the most recent version which is v070b at this point.

You should not manually edit folders or copy them across from a failed run.
ValidateOC will always fail when run against a failed (i.e. incomplete) run
Basically a bad idea to manually intervene in the process in the way done.

 

[Macschrauber]

with open core firmware Spoofing it is difficult to tell the firmware version.

in theory we could dump the firmware / the area where the Version is stored. But that would need sip (at least for kexts) disabled for loading the kext needed for flashrom.

The Mac model is readable by HID or / and the last 3 or 4 chars of the machine serial number.

So better install RefindPlus outside of OpenCore.

 

[Dayo]

with open core firmware Spoofing it is difficult to tell the firmware version.
...
So better install RefindPlus outside of OpenCore.

Not an issue if a user has been keeping up to date with updates as mentioned since the spoofed 9999.x.x.x.x version string carries this info if spoofing was done by ConfigFactory.

If switching between different implementation methods, the spoofed version string will be a different format but v070b will handle this. Basically will tell you to run ConfigFactory without OC on some models. Makes no difference with other models such as cMP3,1.

Installation of RefindPlus is not related ... just need to follow instructions in Post 1 on that. It can be installed within OpenCore .... the user will find they can't use bootblesser to Bless in such instances which is the critical item.

 

[Dayo]

BTW, spoofed version strings have interpretations that are specific to the Mac model. So, "9999.x.x.x.x" on Early 2009 cMP may not mean the same on another cMP model and another Early 2009 cMP may need a different string.

So users that decide to access items not meant for user interaction, including the settings file, with the aim of manually editing these may end up with unexpected outcomes.

Stay within the use parameters and things should work. If not, please report such issues so these can be sorted out.

 

[JedNZ]

Okay, 070b installed under RefindPlus boot (not OpenCore) with no issues encountered. ValidateOC confirms my setup is good. Thanks again @Dayo for your replies and hard work for the community. I have been hesitant to update to every new version of MyBootMgr for fear of losing any downtime if things don't go right, but I will in future.

 

[Dayo]

070b installed under RefindPlus boot (not OpenCore) with no issues encountered.

Cool. Slightly ambiguous as can mean you encountered issues when booted via OpenCore before successfully running while booted via RefindPlus or that you just ran under RefindPlus and did not try it under OpenCore. Can you clarify?

 

[JedNZ]

Cool. Slightly ambiguous as can mean you encountered issues when booted via OpenCore before successfully running while booted via RefindPlus or that you just ran under RefindPlus and did not try it under OpenCore. Can you clarify?

I booted natively to Mojave from RefindPlus - I didn’t boot OpenCore to Mojave from RefindPlus.

 

[amstel78]

Hi @Dayo. Have one question and one issue with 070b:

1. Where did /Library/Application Support/MyBootMgr folder go? I asked because I backup previous configuration files by renaming and leaving in that folder. Installing 070b seems to have deleted that folder entirely. Or, if it moved it, cannot locate it again.
2. ConfigFactory is crashing with build error at BuildStep: 28 irrespective of choosing to allow Mac 2010 default options or configure manually. See screen shot please:

 

[Dayo]

That file is no longer used. Best way to backup is to use the FetchConfig App to back your actual setup up.

BuildStep 28 happens to be a large function and been hitting the limits of "try/catch" blocks needed for more detailed error messages as the script size has grown. This is due to maintaining backward compatibility with Mac OS versions earlier than Yosemite. Might have to raise the limit.

Anyway, managed to shuffle a few around. Try this test version (EDIT: Now Removed) which should give a more precise message at least.

 

[amstel78]

Thanks. Will give it a try tomorrow and revert with the results.

Edit: curiosity got the better of me. Build still failed at 60% with the following error:

 

[Dayo]

Updated MyBootMgr to v070c
See changelog for details

 

[amstel78]

Hello Dayo. Release 070c is still borked, at least on my cMP5,1. Same error from 070b.

At this point, is it worth trying to move past 069 considering this 5,1 is stuck at 11.2.3 anyway?

 

[Dayo]

That odd as does not set this on 5,1.

On whether to move past 069, you need to make the call but updates/improvements to RefindPlus and OpenCore are not tied to a Mac OS version ... I never ran Big Sur in the first place myself.

 

[amstel78]

Well, I would like to update but can't given the build error I noted earlier.

Let me know if there's any system info I can provide on my end that might help you determine the issue.

 

[Dayo]

Currently tied up with a few things. I also need to resurrect my build machine and can't debug.

You can sit on 069 for on that machine for now (070c should run on your 3,1 and others).

 

[Dayo]

Updated MyBootMgr to v071
See changelog in Post 1 for details

 

[bowmasters]

Could you share the AppleScript source code for the applets in MyTools? Everything in has been compiled run-only and can't be opened in Script Editor.

 

[Dayo]

Could you share the AppleScript source code for the applets in MyTools?

While the apps were in plain text until recently, I later found several things work a lot better when they are partially compiled and would therefore rather not distribute plain text at this time. This may change in future.

 

[bowmasters]

I understand preferring the compiled over plain text applets for distribution. But what about putting the source code up on gitlab/hub or other such repo?

It'd be nice to know what these scripts are actually doing, and it would be invaluable in debugging when things go wrong. I've still never been able to get the scripts to run due to some error or another (most recently, that AppleALC error)

 

[Dayo]

I've still never been able to get the scripts to run due to some error or another (most recently, that AppleALC error)

Errors are fixed when reported. You haven't reported one until just now in passing.
Please provide background information so it can be looked into.

What machine are you running, which version of MyBootMgr, what error exactly are you getting etc.

Thanks

 

[Dayo]

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