I have been reading your post because I have some interest in getting Windows to run and was wondering about using bootcamp to do it in "legacy" mode. To protect from NVRAM boot rom writes. I was wondering if a "protective MBR" does this and run Windows in UEFI? Just needing a clarification. Thanks.
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
Thank you for all the info. That command took a long time to run. Here are the entries from my most recent boot yesterday evening:
Code:
2023-04-05 18:16:31.545915-0500 0x37f Default 0x0 0 0 kernel: (apfs) spaceman_metazone_init:191: disk4 metazone for device 0 of size 2693771 blocks (encrypted: 0-1346885 unencrypted: 1346885-2693771)
2023-04-05 18:16:31.545925-0500 0x37f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 56033280
2023-04-05 18:16:31.545931-0500 0x37f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 15400960
2023-04-05 18:16:31.545938-0500 0x37f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 23855104
2023-04-05 18:16:31.545944-0500 0x37f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 14581760
2023-04-05 18:16:31.645189-0500 0x75 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk4 scan took 0.099193 s (no trims)
2023-04-05 18:18:55.212482-0500 0x75 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk4 scan took 143.567278 s, trims took 143.340673 s
2023-04-05 18:18:55.212490-0500 0x75 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3156: disk4 116716482 blocks free in 323470 extents
2023-04-05 18:18:55.212497-0500 0x75 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk4 116716482 blocks trimmed in 323470 extents (443 us/trim, 2256 trims/s)
2023-04-05 18:18:55.212504-0500 0x75 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk4 trim distribution 1:53598 2+:54954 4+:105037 16+:51445 64+:20510 256+:37926So what I don't understand is that with SetApfsTrimTimeout=9999999 (9.99 seconds) in my OC config, why then do I see "trims took 143.340673" seconds? Are multiple TRIM operations performed on each drive, with each one taking 10 seconds? That's the only thing I can think of.
I was confused at first because I don't even have a physical disk4 in my system (my four blades are disk0, disk1, disk2 and disk3), but from running diskutil list it seems disk4 is basically my disk0 1TB EVO 970 "synthesized". I guess that's an APFS thing?
None of the other drives appear to have been trimmed according to the logs--but then again there are no file operations taking place on those drives yet.
The bug may have existed before Monterey, but there are a lot of people who only noticed it after installing Monterey--so it seems it got worse with that OS release (I found discussions where people "solved" the problem by reinstalling Big Sur). And apparently the problem still exists with Ventura.
I guess I will use SetApfsTrimTimeout=0 to work around this problem--at least for now.
Last edited:
I have just installed Windows 10 in legacy mode using Bootcamp assistant. The only thing you need is a 16GB USB drive and DVD ROM to write the iso image to:
Code:
hdiutil burn ~/Downloads/Win10_22H2_English_x64.iso
Last edited:
That's just a no/off switch in later macOS, you can't really make it 9.99s anymore.
Yes, it's a APFS thing.
e.g. This bug exist back in High Sierra, but if we run High Sierra with HFS+, rather than APFS. You will never see this long TRIM time issue.
Anyway, now you know that about 2.5 minutes was used to TRIM during boot. If you want to avoid that in this "setup period", you can simply set SetApfsTrimTimeout=0.
It turns out there was a real issue with GopBurstMode on this card - which was reporting its GOP memory usage in a very non-standard way - but, with thanks to @PeterHolbrook for help with debugging, this issue is now resolved, GopBurstMode can be started fine on the card, and the fix should be added to OpenCore shortly.
OCLP NVRAM variable (yes, it is a little on topic):
I just wanted to let the Dumper indicate the Version of OCLP and booted another package (MartinLo's) to compare.
OCLP NVRAM variable gets not deleted as the other packages does not know it. So if I once booted with OCLP and the next time with another package the OCLP version is still in NVRAM. So indicating it is useless.
Does it makes sense for you guys, especially @cdf, @h9826790 to clear those OCLP NVRAM variables in the default settings?
the pattern is:
I just wanted to let the Dumper indicate the Version of OCLP and booted another package (MartinLo's) to compare.
OCLP NVRAM variable gets not deleted as the other packages does not know it. So if I once booted with OCLP and the next time with another package the OCLP version is still in NVRAM. So indicating it is useless.
Does it makes sense for you guys, especially @cdf, @h9826790 to clear those OCLP NVRAM variables in the default settings?
the pattern is:
Code:
Variable: 4d1fda02-38c7-4a6a-9cc6-4bcca8b30102:OCLP-Version (OpenCore Variable)
StartID: 55aa (Valid)
State: 7f (Normal)
Unknown8: 00
Attr: 00000007 (NON_VOLATILE, BOOT_SERVICE_ACCESS, RUNTIME_ACCESS)
NameSize: 26
DataSize: 6
DataType: looks like NULL-terminated ASCII
Data:
00000000: 30 2e 36 2e 32 00 0.6.2.Seems like this has to be disabled on cMP. But just recording the version of OC or OCLP should not waste that much space?
its not about space, but if I want to report what flavor of OC (and OCLP model/setting) was booted recently an old setting what stays in NVRAM is not helpful.
So if you use new revision OCLP it does not overwrite the old one? Normally if that GUID is added to the delete section it should replace the old one.
I don’t think it makes sense for various OC packages and configs to have to account for one other. How about recommending an NVRAM reset before running the dumper?
Yes, it does. Like all NVRAM variables it gets the delete flag and a new one is stored when it changes.
But it gets not the delete flag when the user decides to change the OpenCore flavor (OCLP, MartinLo or MyBootMgr). So the benefit of showing OCLP version, model and setting is limited - if not saying incorrect.
The advice cleaning NVRAM before dumping will hide some problems what the Dumper wants to show as a side effect. People might not see problems with false headers for example. Also some will lose settings they need, for example users of non or chain loaded OpenCore bootloaders.
Okay how about deleting only the specific variable like:
Code:
sudo nvram -d 4d1fda02-38c7-4a6a-9cc6-4bcca8b30102:OCLP-VersionI think we can stay objective and factural in this matter.
First of all, what's this NVRAM variable actually means? If it only means "the last OCLP verion that's installed", but nothing about if that still exist, then your tool may only tell the user about this fact.
The problem is not only if the user switch to cdf or my way to run OpenCore, but also if they completely removed OpenCore from the cMP and fallback to some natively support OS (e.g. Mojave). Then cdf and me won't able to do anything, and your tool will still report "your Mac is running OCLP ver.xxx" which is obviously wrong in that case.
So, I don't think it's a good idea to report OCLP version base on this NVRAM variable (if this parameter won't be removed automatically even OCLP not exist anymore).
Or you may simply make your tool to report "OCLP ver.xxx singature exist in NVRAM", just like "MS cert in the NVRAM".
In fact, if the user follow my guide to install my pre-configured (for 5,1) OC package. The very 1st step is "3x NVRAM reset". So, even there is nothing in my package to remove that variable, but somehow, the installation procedures should remove that.
yep, I will think that over and check out if there is another variable what indicates last time OC boot like one of the bootx variables. OCLP does start out of a kinda faked system folder on the esp for example.
I sometimes get questions from users what install all kind of OpenCore variants and it would be nice to see from the dump what kind was booted recently.
I sometimes get questions from users what install all kind of OpenCore variants and it would be nice to see from the dump what kind was booted recently.
Last edited:
Hi - I am trying to validate the config for OC 091 but I keep getting an error when validating:
OCS: No type match for Emulate at 2 index, expected type data got dict, context <Kernel>!
Serialisation returns 1 error!
Can anyone help please? TIA
I put
<key>GopBurstMode</key>
<false/>
inside the
<key>OUTPUT</key> section at the end (before </dict>_not totally sure what the the vertical dots mean?
OCS: No type match for Emulate at 2 index, expected type data got dict, context <Kernel>!
Serialisation returns 1 error!
Can anyone help please? TIA
I put
<key>GopBurstMode</key>
<false/>
inside the
<key>OUTPUT</key> section at the end (before </dict>_not totally sure what the the vertical dots mean?
<key>Output</key>
<dict>
<key>ClearScreenOnModeSwitch</key>
<false/>
<key>ConsoleMode</key>
<string></string>
<key>DirectGopRendering</key>
<false/>
<key>ForceResolution</key>
<false/>
<key>GopPassThrough</key>
<string>Disabled</string>
<key>IgnoreTextInGraphics</key>
<false/>
<key>ProvideConsoleGop</key>
<true/>
<key>ReconnectGraphicsOnConnect</key>
<false/>
<key>ReconnectOnResChange</key>
<false/>
<key>ReplaceTabWithSpace</key>
<false/>
<key>Resolution</key>
<string>Max</string>
<key>SanitiseClearScreen</key>
<false/>
<key>TextRenderer</key>
<string>BuiltinGraphics</string>
<key>UIScale</key>
<integer>0</integer>
<key>UgaPassThrough</key>
<false/>
<key>GopBurstMode</key>
<false/>
</dict>
<dict>
<key>ClearScreenOnModeSwitch</key>
<false/>
<key>ConsoleMode</key>
<string></string>
<key>DirectGopRendering</key>
<false/>
<key>ForceResolution</key>
<false/>
<key>GopPassThrough</key>
<string>Disabled</string>
<key>IgnoreTextInGraphics</key>
<false/>
<key>ProvideConsoleGop</key>
<true/>
<key>ReconnectGraphicsOnConnect</key>
<false/>
<key>ReconnectOnResChange</key>
<false/>
<key>ReplaceTabWithSpace</key>
<false/>
<key>Resolution</key>
<string>Max</string>
<key>SanitiseClearScreen</key>
<false/>
<key>TextRenderer</key>
<string>BuiltinGraphics</string>
<key>UIScale</key>
<integer>0</integer>
<key>UgaPassThrough</key>
<false/>
<key>GopBurstMode</key>
<false/>
</dict>
I think it's OCLP's config.plist that puts the OCLP-Version in NVRAM so someone could remove that and still be using OCLP. You might want to look for stuff that is setup by the OpenCore.efi.
There's boot properties in /chosen node of IODeviceTree plane of ioreg.
nvram variables are in /options node of IODeviceTree plane of ioreg and output of nvram -p but only the Apple ones.
Switch your Open Core Configurator to 0.9.1 development branch mode.
Thanks. I have never used that app before - just following instructions in post #1 here - so I downloaded it and its a little scary tbh but I assume it is another way of setting all the options in the config file!
Anyway, I changed in Prefs to development mode 0.9.1 and opened my new config file:
"Completed validating /Users/~/Documents/config.plist in 3 ms. No issues found."
I made sure the UEFI/Output/GopBurstMode was ticked (it was) then I saved again. No error. I chacked the config with ocvalidate and now it validates OK. Bit strange because I did not change anything in the config file?
I will update the EFI now and then restart to check all is good.
UPDATE: Booted fine, all seems good then. Not sure why that was different as config is identical (text compare) to the one that failed but I'm not going to mess with something that works! Thanks.
Last edited:
It's sometimes an issue with formatting (tabs vs spaces) or a non-visible Unicode character. You're all good.
That's why I always use a tool designed specifically to edit Plist files without the worry of formatting issues as @hwojtek points out. I have been using PlistEdit Pro App for a long time and never had to worry about nor check the formatting. It's soooo easy to use.
Last edited:
The update to Monterey 12.6.5 was flawless on my cMP 5,1 running OC 0.9.1.
I messed up in my update from 12.6.4 to 12.6.5. I was in a hurry, and having just done the 12.6.4 update the night before, I thought I had all the steps in my head. Wrong!! I was using the VMM/SecureBootModel disabled approach, but I forgot to run the plutil steps to format my changes before copying back to the ESP (at least that is the one step that I'm pretty sure I screwed up, there may have been others....)
Anyway, long story short, it downloaded the update to 12.6.5 and started processing it. I got bored and wandered off while it still said it had ten minutes to go. Came back later, and the machine had re-booted into Monterey as expected, so I restored my usual config.plist (that removes VMM and restores SecureBootModel to 'Default'). I thought, I better check that it succeeded, and then found that I was still on 12.6.4!
So, I rebooted, and noted that now I have a MacOS Installer entry in the list of boot options. I tried selecting it manually and letting it do its thing, but every time after the automatic reboot it comes back in the boot list (and I'm still on 12.6.4). So, the question is, how do I get back to a state where I can try the update again cleanly? Do I have to find and delete that disk image of the MacOS Installer somewhere to make System Update recognize that I still need the 12.6.5 update? Thank you for your advice.
Anyway, long story short, it downloaded the update to 12.6.5 and started processing it. I got bored and wandered off while it still said it had ten minutes to go. Came back later, and the machine had re-booted into Monterey as expected, so I restored my usual config.plist (that removes VMM and restores SecureBootModel to 'Default'). I thought, I better check that it succeeded, and then found that I was still on 12.6.4!
So, I rebooted, and noted that now I have a MacOS Installer entry in the list of boot options. I tried selecting it manually and letting it do its thing, but every time after the automatic reboot it comes back in the boot list (and I'm still on 12.6.4). So, the question is, how do I get back to a state where I can try the update again cleanly? Do I have to find and delete that disk image of the MacOS Installer somewhere to make System Update recognize that I still need the 12.6.5 update? Thank you for your advice.
I have another question as well... I'm working my way through bringing up a second cMP 5,1 to OpenCore/Monterey. I blundered my way through installing OpenCore and upgrading from Mojave to Monterey so long ago on the original machine (March of last year, maybe?), that I no longer quite remember at what point in the OpenCore process that I made the jump. It appears that one should at least get the board ID spoofed to get offered the Monterey upgrade, but should I worry about getting the kexts all dialed in, etc? It might be nice if there were a line in the first post wiki that said something like, "this is the point at which you jump off from Mojave onto a later system."
I'm currently booting Mojave through OpenCore, and paused at the start of "Complete your setup," on the second machine.
I'm currently booting Mojave through OpenCore, and paused at the start of "Complete your setup," on the second machine.