Thank you very much, I have read it already but there are problems posted in this thread which I would like to avoid. Can I just normally update the through the Apple Store then? Which OS should I use, i.e. which does work the best at the moment?
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
Use Monterey or BigSur. Myself, I use BigSur because I know that will get security updates until September 2023. I do not know if something will happen to Monterey that makes it impossible to use with OpenCore. The day Montery gets replaced by a new MacOS I upgrade to Monterey.
The problems with Monterey outlined the last weeks are solved. Just follow this guide if you want to use Monterey. It might be smart to ask @tsialex in a separate thread to make a clean and reconstructed backup of your firmware before you take the step.
the pink display is a common effect.
I get it if I use DVI to HDMI on an old flatscreen TV. If I use HDMI to HDMI it's all ok.
Honestly, Monterey has been far better for me than Big Sur. Just make sure you keep a clean copy of your BootROM, but you should be doing that anyway these days.
Just updated Monterey to 12.4 beta on my 12 cores with opencore 0.7.9 and everything is working perfectly as it should be ??
Evening. I feel I should know enough not to ask stupid questions now, but anyway. What's the deal with spoofing BIOSVersion on MP5,1 vs. this new update problem with MP7,1 firmware? I saw @cdf that you mentioned a while ago "Spoofing BIOSVersion is a superfluous practice" - with evidence - but e.g. on my own MBP10,2, it really does make the difference between getting the black screen semi-brick (requires partial disassembly and battery removal) or not. I do not mean to imply that it would definitely work in this different context, but just wondering, has it definitely been confirmed that spoofing high BIOSVersion (in an attempt to prevent firmware update being detected as necessary in the first place) does not help with this issue?
During installations and updates on MacPro5,1 (at least with the 7,1 board ID), macOS will stage firmware updates and bless the updaters regardless of firmware version. The process involves large amounts of data being written to the NVRAM. The problem for MacPro5,1 is that an unhealthy flash chip (with broken garbage collection) can result in bricking. The problem has always been there, but with NVRAM being used more and more, the problem is becoming increasingly apparent.
On MacPro5,1, we have confirmed (experimentally, as far as I know) that the staging of firmware updates occurs with or without BIOSVersion spoofing. What is effective at preventing the staging, however, is the VMM flag. That's why the current recommendation is to turn it on before proceeding with macOS updates.
Now, the staging of firmware updates doesn't affect more modern systems (which are designed for heavier NVRAM use), but the actual updates still can. Fortunately, BlacklistAppleUpdate deletes the BootNext updater entries, so the updates never go through.
It's not entirely clear to me why BIOSVersion spoofing makes a difference on other machines. Maybe the "semi-bricking" you mention is a different problem. Maybe the staging on some machines does depend on firmware version. Or maybe BlacklistAppleUpdate fails on some machines.
I think the issue deserves further investigation. Whether VMM or BIOSVersion, I find these solutions ugly, and if BlacklistAppleUpdate can really fail, then all the more reason to further investigate.
Thank you for the summary. Basically, I agree! (And understand! ;-) ) Except on the one key issue I raised, where I understand, and what you say may well be right, but I'd remain unsure, at this stage...
For me, when I came into the whole Hackintosh for unsupported Macs scene, it was via the "Big Sur on Unsupported Macs" thread, and _the_ key issue there was that BlacklistAppleUpdate had stopped working, hence updates were getting staged, failing, and resulting in the semi-brick I described. I believe it was @khronokernel who came up with the idea of simply spoofing the BIOS version, which is definitely what made the difference on the machines that had the problem.
Work-around to BIOS updates with macOS Big Sur · Issue #1427 · acidanthera/bugtracker
With macOS Big Sur, Apple will now apply BIOS updates regardless of run-efi-updater variable presence. For PCs, we simply block MultiUpdater.efi however on legacy Macs running OpenCore with SMBIOS ...
github.com
As you recall, we did a lot of work, which both you and I were involved in, to make sure that when SMBIOS (or other section) spoofing is used in OC, as much as possible will inherit the machine's default values, if left at the default values in the config file (i.e. making it easier to just spoof one value in the OC SBMIOS options, without needing to manually specify the correct value for the other ones).
I don't have a machine in a state to run the re-test of this idea, I so far didn't find the time to use my purchased second-hand MP4,1 for anything other than testing sound issues on old OS, so I'd have the entire test, clean (if needed) and backup BIOS to do, before I could test any updates on it!
I remember this. But during that time, there was also an issue with supported Macs bricking.
macOS Big Sur Update Bricking Some Older MacBook Pro Models
A large number of late 2013 and mid 2014 13-inch MacBook Pro owners are reporting that the macOS Big Sur update is bricking their machines. A MacRumors forum thread contains a significant number of users reporting the issue, and similar problems are being reported across Reddit and the Apple...
forums.macrumors.com
So perhaps macOS was actually at fault.
My understanding is that "run-efi-updater" is what stopped working (as described in the link you provided). This NVRAM variable, which was discovered by osy, had momentarily replaced BlacklistAppleUpdate after @vit9696 had noticed that BlacklistAppleUpdate could sometimes result in the installer volume not being selected for booting during updates, especially with Windows being present.
Incorrect default boot option choice in OpenCore during updating · Issue #948 · acidanthera/bugtracker
It seems that OpenCore 0.5.9 actually failed to fully resolve the problems caused by accidental Multiupdater booting during the macOS upgrade process. If macOS and Windows are installed on the same...
github.com
In fact, I believe this issue persists today as people regularly report having to manually select the installer volume from the OpenCore picker during macOS updates.
While "run-efi-updater" guaranteed a smoother update experience (all the way back to Yosemite!), the variable was unfortunately discovered too late in the game. It stopped working in Big Sur, and so (an improved?) BlacklistAppleUpdate was reintroduced.
run-efi-updater flag no longer works in macOS 11, Big Sur · Issue #1255 · acidanthera/bugtracker
With macOS Big Sur, it seems that even though the NVRAM variable is set macOS will still bless the firmware update during both install and update processes: 15:835 00:005 OCB: Perform boot EFI to d...
github.com
Just to clarify: BlacklistAppleUpdate will not prevent the staging of firmware updates. A directory with the updaters is still created on the ESP, and payload data is still written to the NVRAM. But BlacklistAppleUpdate is generally effective at preventing the updates from going through (otherwise, hackintoshes would surely brick more often).
To my knowledge, the idea was first mentioned by @h9826790 in this thread (see post #4,524), and picked up by @jackluke shortly thereafter:
run-efi-updater flag no longer works in macOS 11, Big Sur · Issue #1255 · acidanthera/bugtracker
With macOS Big Sur, it seems that even though the NVRAM variable is set macOS will still bless the firmware update during both install and update processes: 15:835 00:005 OCB: Perform boot EFI to d...
github.com
Indeed! And your ensuing contributions to OpenCore really cleaned things up!
Maybe it will be useful for someone
I use both OC config made by
Martin Lo 52sec ,
CDF (with hybridization spoofing MAC Pro 2019 board ID) 3min35sec
early versions of cdf opencore did not have such long loading times
I replaced broadcom BT/WiFi card a few years ago (Chipset: BCM_20703A1)
apple universal control not working in both config (with iPad Pro 2017)
but apple handoff ok
airdrop ok
A whole month of real work in real 3D programs (Twinmotion2022, Ue4.27, UE5.0, Blender3.1) showed no difference in performance between the two configurations
MacPro 4.1/5.1, 96Gb samsung RAM, 2Tb nvme Crusial, 1Tb nvme 970EvoPlus, AlpineRidge thunderbolt3 pcie card, OC 0.7.9, MacOS Monterey 12.3.1
I use both OC config made by
h9826790
and bycdf
the loading time from crime for 0.7.9 is:Martin Lo 52sec ,
CDF (with hybridization spoofing MAC Pro 2019 board ID) 3min35sec
early versions of cdf opencore did not have such long loading times
I replaced broadcom BT/WiFi card a few years ago (Chipset: BCM_20703A1)
apple universal control not working in both config (with iPad Pro 2017)
but apple handoff ok
airdrop ok
A whole month of real work in real 3D programs (Twinmotion2022, Ue4.27, UE5.0, Blender3.1) showed no difference in performance between the two configurations
MacPro 4.1/5.1, 96Gb samsung RAM, 2Tb nvme Crusial, 1Tb nvme 970EvoPlus, AlpineRidge thunderbolt3 pcie card, OC 0.7.9, MacOS Monterey 12.3.1
I suspect a misconfiguration. My result from chime to login screen is 25s. Perhaps others could chime in.
TRIM with Samsung SSDs also can add minutes to the boot time.
PCIe SSDs - NVMe & AHCI
Besides the Samsung 980 series problems with PCIe v2.0, there are also issues with the TRIM timeout at boot time when using APFS because the Samsung controller takes too much time to clean/dealocate blocks, a problem that is happening since SM951-AHCI and affect several models with different...
forums.macrumors.com
Right. In Monterey, the timeout doesn't work, so if TRIM is taking too long, it can be disabled by setting SetApfsTrimTimeout=0.TRIM with Samsung SSDs also can add minutes to the boot time.
PCIe SSDs - NVMe & AHCI
Besides the Samsung 980 series problems with PCIe v2.0, there are also issues with the TRIM timeout at boot time when using APFS because the Samsung controller takes too much time to clean/dealocate blocks, a problem that is happening since SM951-AHCI and affect several models with different...
Edit: That must be it because Martin's package sets the timeout to 0. Note that setting the timeout to 0 will effectively disable TRIM, even though macOS reports it as being enabled! However, for drive longevity, it is preferable to keep TRIM enabled, provided that boot times are reasonable.
Last edited:
my MAC OS SSD is Crusial P1 2TB, it should work since the drive is in the list of TRIM supported, so if i use Martin's config do i risk breaking my ssd?TRIM with Samsung SSDs also can add minutes to the boot time.
PCIe SSDs - NVMe & AHCI
Besides the Samsung 980 series problems with PCIe v2.0, there are also issues with the TRIM timeout at boot time when using APFS because the Samsung controller takes too much time to clean/dealocate blocks, a problem that is happening since SM951-AHCI and affect several models with different...
I have been using Your config since 2020 (from OC 0.5.9 updating every month). I use simple config with hybridization and only with NVME made as internal. This long booting I got only this month with 0.7.9 and Monterey 12.3.1
Or maybe it's because, in Martin's config there is SurPlus and Monterand, which somehow conducts the boot process more correctly in my case?
Don't really matter if it's your boot drive or not, TRIM runs at boot time is for all disks that have it enabled.
When I install my SM951-AHCI with HighSierra in my Mac Pro, the boot times of my main disk, a 970 PRO with BigSur jump to over 3 minutes to arrive at the login screen and even more for my PM961 with Monterey.
Last edited:
It's strange that this only appeared with 0.7.9 and macOS 12.3.1. Is the long boot time before or during the Apple loading bar? Could you post your config so that I can take a look? Also, maybe you could try with SetApfsTrimTimeout=0.
I resized and shrinked my Samsung Apple_APFS Containers by 10% on each disk to get a raw unallocated space so maybe the controller takes care of the Trim on the disks. This is the recommended 'Over Provisioning' size Samsung Magician software makes in Windows.
Use 'diskutil list' to find your Apple_APFS Container(s) on a physical disk, e.g 'Apple_APFS Container disk2 2.0 TB disk0s2'
You would use 'sudo diskutil apfs resizecontainer disk0s2 1814G' to resize this container by 10% on this 2TB drive.
If disk is 1TB drive you would use 'sudo diskutil apfs resizecontainer disk0s2 907G' to shrink it 10%.
Make sure you find your correct 'diskXsX' with diskutil.
Edit: You can do this even on your main live booted OS disk.
Use 'diskutil list' to find your Apple_APFS Container(s) on a physical disk, e.g 'Apple_APFS Container disk2 2.0 TB disk0s2'
You would use 'sudo diskutil apfs resizecontainer disk0s2 1814G' to resize this container by 10% on this 2TB drive.
If disk is 1TB drive you would use 'sudo diskutil apfs resizecontainer disk0s2 907G' to shrink it 10%.
Make sure you find your correct 'diskXsX' with diskutil.
Edit: You can do this even on your main live booted OS disk.
Last edited:
Apple loading progress bar stopped at half and nothing happend about 2 minutes, then black screen 15sec, and then system desktop login
There are 3 config files: _cdf- my standard, _nvme_ext - i removed internal nvme and disable thunderbolt3 card and with surplus and monterand, the third my Martin's config.
now i loaded config with deleted paths for nvme ssd - loading time the same!
BUT ALL SSDs are shown as internal!
Last edited:
I'm confused. Are you saying that without adding the built-in property, the drives still appear as internal? Could you boot in verbose mode (press Command-V before selecting your boot drive in the OpenCore picker) to see where the hanging is occurring?
Last edited:
when I copied surplus along with it, I accidentally copied a patch that makes nvme internal.
Now I set the timeout to 0, the download is almost instantaneous - less than a minute.
But You and tsialex not recomend to set it to "0".
what shell i do?
OK. So it was TRIM then. The OpenCore manual states that an alternative is to "use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller". Post #10,792 may be helpful in this regard.
my boot drive is disk0
/dev/disk0 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk12 2.0 TB disk0s2
I try to resize but get message
Started APFS operation
Aligning shrink delta to 186 189 180 928 bytes and targeting a new physical store size of 1 813 999 996 928 bytes
Determined the minimum size for the targeted physical store of this APFS Container to be 1 984 006 455 296 bytes
Error: -69521: Your APFS Container resize request is below the APFS-system-imposed minimal container size (perhaps caused by APFS Snapshot usage by Time Machine)
Enable TRIM and use SetApfsTrimTimeout=4294967295, the TRIM process will take the time that is needed to fully complete at boot time and you won't have any slowdowns later when using your Mac Pro, a major problem for years with the drives that had problem with the standard macOS timeout.
How to interpret the OC 0.7.9 changelog which says 'Fixed SetApfsTrimTimeout on macOS 12 (only works when set to zero)'?
Did it previously only work when set to 0, or does it only work set to 0 after the fix for macOS 12? Will SetApfsTrimTimeout=4294967295 work on macOS 12?
Did it previously only work when set to 0, or does it only work set to 0 after the fix for macOS 12? Will SetApfsTrimTimeout=4294967295 work on macOS 12?
Good point. My understanding is this: Previously, TRIM would be enabled but would timeout after 10 seconds (natively) or after a custom value specified by SetApfsTrimTimeout (in OC) to allow the operation to complete. Now, in Monterey, the custom value doesn't work (though it's unclear if it's fixed at 10 seconds, especially given the long boot times), but SetApfsTrimTimeout=0 (through a different patch that is applied conditionally) can still be used to disable the trimming.