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 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
here? the only file mentioned in the dortania guide that i don't know how to get is Bootstrap.efi.
startergo, can i DM you? cluttering the thread with my base-level troubleshooting seems wrong.
Last edited:
Same thing I have followed for quite a while now with MyBootMgr. Decided it is best not to rely on what the developer states as being "undefined behaviour". Basically might work today and stop working tomorrow or work in a different way.
When you put a config generated by MyBootMgr through OcValidate, it passes without any comment. (that is the aim at least).
Obviously easier for an automated setup to handle than when users need to amend things manually.
Downside as developer is that you will have to keep up on the failsafes as they do change.
I have recently been pushing a few changes to the OC documentation and on one of these, the OC Dev noticed an issue with how a failsafe for one of the Patch Properties was being handled and has just changed the failsafe value.
Not particularly relevant for us but these sorts of things are why I prefer not to rely on leaving stuff undefined in the hope that the program will always fallback on the correct thing. Granted that it has done this so far but still prefer not to rely on it always doing so.
Last edited:
Do you specify actual values for SMBIOS properties such as SystemSerialNumber? Or just populate the properties and leave the values empty? In the latter case, you're still relying on the failsafe, but at least ocvalidate will not complain (for now, I suppose).
If I pre-define the failsafe values, ocvalidator will not complain. But what if one failsafe value is different than OEM value, will the OEM value take predominance or the failsafe value will be enforced? That's the part I'm missing. Should we set empty values instead of predefined failsafe ones?
If you define value there it will overwrite the OEM value, but if it is empty string or NIL integer OEM should be kept or none written.
Relying on the failsafe by leaving these empty.
Suppose there are semantic considerations involved as my reading of several statements made by the devs is that defining a failsafe value, even when an empty value, is different to not specifying anything.
Not specifying anything currently falls on the failsafe but this is what is categorised as undefined behaviour.
Having said that, I doubt they will allow several configs to fail by changing the current behaviour arbitrarily and reading between the lines of his reponse to issue by @TECK, seems they are resigned to accepting that this is how many wish to use things as it has softened a lot from previous statements.
How do you leave empty an int value? They will always be taken into consideration. Say for example ProcessorType set to 0 but Mac will report 1 (just an example).
Edit: Never mind, saw @startergo reply.
Not guaranteed. It may or may not in different places. The action taken is not consistent.
There was a recent issue opened about about this by @Bmju
0 means automatic. Basically same as OEM Specified in this example. (Read from the OC database .... not taken from the machine btw)
Part of the changes I have been pushing is to specify what exactly the failsafe does.
0 (Automatic)
0 (Ignored)
etc
That's a good question. Take, for example, the FirmwareFeatures SMBIOS property. The failsafe is 0. But is the OEM value also 0? Perhaps this needs further investigation.
At least based on my recent checks, only the custom Memory has settings that need to be determined by users with dmidecode. Which in our case, we will never play with.
All failsafe values provided by OC documentation are already empty or NIL as @startergo mentioned earlier, here it is an SMBIOS example with what I have now set (from documentation):
Code:
'SMBIOS': {
'BIOSReleaseDate': '',
'BIOSVendor': '',
'BIOSVersion': '',
'BoardAssetTag': '',
'BoardLocationInChassis': '',
'BoardManufacturer': '',
'BoardProduct': '',
'BoardSerialNumber': '',
'BoardType': 0,
'BoardVersion': '',
'ChassisAssetTag': '',
'ChassisManufacturer': '',
'ChassisSerialNumber': '',
'ChassisType': 0,
'ChassisVersion': '',
'FirmwareFeatures': Data(''),
'FirmwareFeaturesMask': Data(''),
'PlatformFeature': 0,
'ProcessorType': 0,
'SmcVersion': Data(''),
'SystemFamily': '',
'SystemManufacturer': '',
'SystemProductName': '',
'SystemSKUNumber': '',
'SystemSerialNumber': '',
'SystemUUID': '',
'SystemVersion': ''
},
'UpdateDataHub': False,
'UpdateNVRAM': False,
'UpdateSMBIOS': False,
'UpdateSMBIOSMode': 'Create',
'UseRawUuidEncoding': False
Last edited:
It makes sense to enforce the specifying of all properties in the case of PCs: their OEM values won't at all be what macOS expects. In the case of real Macs, however, macOS will work even without turning on PlatformInfo, so that none of the properties ever get set. When we just want to spoof the board ID (hybridization), we are faced with an all-or-nothing situation and hope that the failsafes will preserve everything else.
Right. But UpdateSMBIOS is false, so all those properties don't ever get applied. As I mentioned above, this would be inconceivable on a PC...
This is in the event where we switch it to True, as we do for your advanced configuration. Then all these failsafe values will still be ignored, because they are either empty or NIL and the OEM values will be used instead. That's a good outcome, which was my initial understanding from documentation: Define the failsafe value and OC will be smart enough to grab the OEM value if needed. Define a custom value and it will overwrite the OEM value.
Strictly speaking the OEM value (specified by the machine) is the failsafe (decided by OC).
Just to clarify: the same thing has always happened even without populating the properties with empty values: it's just a question of following the specification, which has definitely raised questions, especially in the case of real Macs. Functionally, there's no difference (for now). Nevertheless, I agree with this formality and will include the properties (as you have) in the next update to the sample configuration.
Let's work together on this, is quite easy to keep the properties updated with the new OC releases, but is nice to compare the findings. I was also thinking if you can use the plistlib library formatting for your config.plist, it will be a lot easier for everyone to compare the differences.
plistlib format:
Code:
<key>Patch</key>
<array>
</array>Your format, which is perfectly fine:
Code:
<key>Patch</key>
<array/>
Thank you. I've installed Lilu and WEG, but still no luck. So, just to clarify my problem:
I've got a Mac Pro 5,1 (model A1289) with GTX970 video card (and no original card) running macOS 10.12.6 with NVIDIA web drivers. Tried following guide in this thread, but had no luck with OpenCore 0.6.6 - it just not starting: no boot picker (even if I'm trying to move cursor in boot menu blindly), no OC version from NVRAM, no boot logs (after config changes), no changes in behaviour at all.
At the same time I can run OC version 0.6.5 and earlier. Because there's a warning at the original post about sample config imcompatibility with non-0.6.6 versions I tried to make my own config using dortania guide (https://dortania.github.io/OpenCore-For-Legacy-Macs/config.plist/macpro.html) and had a boot picker at start, OC version from NVRAM, but still no video during boot (no graphics, nor text mode). So I've decided to get back to this guide and made it to the end of part 2. But now I have no video during boot process and no video after macOS load. Every generated boot log contains the same text (attached). Also attached my current OC config and screenshot of "About this Mac" window.
Hope someone in this thread can help me to sort out what's wrong with my setup.
Attachments
No issues with the settings from opening posts on Prime 4K, I don't use Netflix. I cannot take screenshots because Amazon are smart to block them, I was surprised Kap is blocked also. I used the OC Plistlib Generator to build the EFI and config.plist.
Please enter the following command in Terminal, what's the return?
nvram boot-args kextstat | grep -v com.apple
Seems not so softened:
Allow non-generated, orginal machine ids? · Issue #51 · dortania/OpenCore-Legacy-Patcher
I was playing around with trying to get non-macserial-generated ids (i.e. my machine's orginal ids) when booting through OpenCore. (And latterly pestering the OC developers with some issues, and on...
github.com
@Bmju makes a good point in that discussion: changes to platform information should be as minimal as possible on real Macs. In fact, we've successfully used such a minimal approach (perhaps even more minimal than what is described, with Automatic=false) for over a year now!
Allow non-generated, orginal machine ids? · Issue #51 · dortania/OpenCore-Legacy-Patcher
I was playing around with trying to get non-macserial-generated ids (i.e. my machine's orginal ids) when booting through OpenCore. (And latterly pestering the OC developers with some issues, and on...
We also confirmed that iMessage keys do not change with only board-id and FirmwareFeatures+FirmwareFeaturesMask change. They will change though if more spoofing is applied especially changing the serial number.
Correct. That it behaves that way is not in dispute. The issue is that it behaves that way due to an undocumented "feature" the developer seems to take a dim view of.
EDIT/CLARIFICATION. The minimal approach is not my subject but the file structure. That is, what is included and what is left out. Definitely all for the minimal approach.
There are clear advantages to having a succinct file by leveraging this undocumented feature. However, as with any such feature, there is a big element of caveat emptor involved.
I suppose all that needs to be done is to keep an eye on changes bearing in mind that changes that impact on undocumented features are not typically documented themselves.
Note that this is not about more or less spoofing.
Last edited: