MP 1,1-5,1 SurPlus - The Big Sur/Monterey fix you've been waiting for.

[Syncretic]

I've posted my findings about the MacOS 11.3+ "race condition" bug, along with a patch I'm calling SurPlus, in a github repository. All the details are there, and I'm not sure there's any benefit in reposting them all here. (Yes, I had to write my own debugger; the boot hangs generally happened before the boot was far enough along for MacOS' remote debugging facility to work, so drastic measures were required.)

This thread will serve for questions (hopefully with answers), comments, and discussion regarding SurPlus.

In a nutshell: our Classic Macs will live to fight another day. As of now, latebloom is deprecated. Install the three-byte SurPlus patch in your OpenCore config.plist and boot Big Sur or Monterey just as you would Catalina or Mojave.

PLEASE: If you're going to post in this thread because you're having trouble getting the patch to work, please include your OpenCore config.plist file as an attachment. Without that, it's very difficult to offer assistance.

EDIT (30oct21): If you're trying to install Monterey 12.1 Beta 1 (or, presumably, later), please read this thread as well.

EDIT (20dec21): It appears that the released Monterey 12.1 does not require either the SurPlus or MonteRand patches. This may change in a later release, but for now, the race condition addressed by SurPlus is no longer an issue in 12.1. (Note that SurPlus is still required for Big Sur 11.3-11.6.2 and Monterey prior to 12.1; MonteRand seems to only be required for 12.1b1 and no other version/beta.)

 

[Syncretic]

Frequently Asked Questions

• Does the patch work with the MacOS installer?
  While I have not personally tested it, I have received reports that SurPlus does work during the installation process (assuming, obviously, that you're using OpenCore).
• Does the patch work during an upgrade from below 11.3 to 11.3+?
  While I have not personally tested it, multiple user reports say that when using SurPlus, upgrading from below 11.3 to above 11.3 works properly.
  NOTE: There have been some reports of difficulties upgrading using the patch. In at least one case, it looks like the installer was bypassing OpenCore, so the patch wasn't being applied, which allowed hangs to occur. If you do manage to upgrade successfully, please verify that your OpenCore installation is still properly blessed (i.e. that your system will boot through OpenCore and not directly into MacOS).
• If I am upgrading, can I install the patch before the upgrade?
  Yes. The patch includes a MinKernel value, meaning that it won't be applied to older versions of the MacOS kernel. If you install the patch in your config.plist and then boot Mojave or Catalina or Big Sur 11.2.3, the patch won't do anything at all. When you do the upgrade and the reboots start, the newer kernel will be patched automatically.
• How do I install the patch?
  If you're using a packaged OpenCore installation, your best bet is to check to see if that package has been updated to include SurPlus. At a minimum, the OCLP nightly builds and Martin Lo's latest package include SurPlus, so your easiest route is to update to their latest versions. (Other packages are also incorporating SurPlus, but I'm not going to try and keep up with the status of each one - please check the latest release or nightly build of the package you're using.)
  
  If you're ready and willing to make the changes yourself:
  Every OpenCore config.plist file follows the same basic template (its XML schema), but each user's particular config.plist is potentially unique, so these instructions are not precise. If you're not comfortable with your XML skills, you're probably better off waiting for someone to automate the process for you (I'm sure that will happen fairly quickly). Remember to back up your config.plist file before making changes.
  
  Search your config.plist file for the word Kernel, and you should see something like this:

          </dict>
          <key>Kernel</key>
          <dict>
                  <key>Add</key>
                  <array>
                          <dict>

  (keeping in mind that the details might vary). From there, search for >Patch< (note the '>' and '<'), and you should see something like:

                  <key>Force</key>
                  <array/>
                  <key>Patch</key>
                  <array>
                          <dict>
                                  <key>Arch</key>

  You want to paste the patch at the beginning of the line after the <array> tag that appears just below <key>Patch</key>, and before any existing <dict> tag. (For the XML-savvy: you can place the patch anywhere in the Patch array, it doesn't need to be first.)
  NOTE: If your config.plist never had any kernel patches before, instead of the above, you'll see something like this:

                  <key>Patch</key>
                  <array/>

  If that's the case, the <array/> line is telling OpenCore that there are no patches; before you try to insert the SurPlus patch, you'll need to change <array/> to:

                  <key>Patch</key>
                  <array>
                  </array>

  and then paste the SurPlus patch between the <array> and </array> lines.
  
  Save the file, then in Terminal, use plutil -convert xml1 config.plist && plutil config.plist to validate your changes. (Please refer to the OpenCore thread for details on editing and validating your config.plist file.)
  
  If you have trouble finding these tags, or your config.plist file doesn't resemble what's shown here, or you're not sure about what you're seeing, please ask for help, or wait for an automated process to be created. Making a mistake editing your config.plist file can create unnecessary headaches for you.
• I just installed a new Monterey beta (or the GA release), and the patch stopped working. Why?
  The patch in the github repository has a MaxKernel value of 21.1.0, which matches Monterey Beta 7, the highest Monterey release at the time the patch was posted. Until Beta 8 or a Release Candidate or the official Monterey release actually comes out, there's no way to know if this patch will work on that release, so they're effectively "turned off" for safety. Once the new release has been tested and verified, the MaxKernel value will be updated accordingly. (Advanced users can just update it themselves.)
• How do I disable latebloom?
  That depends on how you have it installed. If you're not using OpenCore to inject latebloom, post the details of your setup in this thread and ask for help.
  
  If you're injecting latebloom using OpenCore, you can disable latebloom by editing your config.plist file and searching for latebloom. You should see something similar to this:

                          <dict>
                                  <key>Arch</key>
                                  <string>x86_64</string>
                                  <key>BundlePath</key>
                                  <string>latebloom.kext</string>
                                  <key>Comment</key>
                                  <string>Work-around PCI race condition</string>
                                  <key>Enabled</key>
                                  <true/>
                                  <key>ExecutablePath</key>
                                  <string>Contents/MacOS/latebloom</string>
                                  <key>MaxKernel</key>
                                  <string></string>
                                  <key>MinKernel</key>
                                  <string>20.4.0</string>
                                  <key>PlistPath</key>
                                  <string>Contents/Info.plist</string>
                          </dict>

  Just below <key>Enabled</key>, change <true/> to <false/>, save the file, and you're done. latebloom will be disabled when you next reboot.
  
  If you want to permanently remove latebloom from OpenCore, do the following: Edit your config.plist file, search for latebloom, you should see something similar to this:

                          <dict>
                                  <key>Arch</key>
                                  <string>x86_64</string>
                                  <key>BundlePath</key>
                                  <string>latebloom.kext</string>
                                  <key>Comment</key>
                                  <string>Work-around PCI race condition</string>
                                  <key>Enabled</key>
                                  <true/>
                                  <key>ExecutablePath</key>
                                  <string>Contents/MacOS/latebloom</string>
                                  <key>MaxKernel</key>
                                  <string></string>
                                  <key>MinKernel</key>
                                  <string>20.4.0</string>
                                  <key>PlistPath</key>
                                  <string>Contents/Info.plist</string>
                          </dict>

  Delete all of those lines (starting with <dict> and ending with </dict>, being careful not to delete or change any other adjacent lines. Save the file. You can now delete the latebloom kext itself from your EFI partition (probably at /Volumes/EFI/EFI/OC/Kexts/latebloom.kext, although that path could be different on your system).
  
  If you're permanently removing latebloom, you will probably also want to remove the latebloom boot-args. Leaving them in place won't hurt anything, but they might cause confusion later on, so it's probably best to get rid of them. Depending on your setup, your boot-args either come from your OpenCore config.plist file or directly from nvram.
  
  If your boot-args are in your config.plist file: edit config.plist, search for boot-args. You should see something like this (your specific boot-args will almost certainly be different):

        <key>boot-args</key>
        <string>keepsyms=1 debug=0x100 latebloom=1 lb_range=0 lb_debug=1 shikigva=128 unfairgva=1 agdpmod=pikera -wegtree -v</string>

  Carefully edit the line below <key>boot-args</key>, and remove any instances of the following (where 'N' indicates a decimal or hex number):
  * latebloom=N
  * lb_range=N
  * lb_debug=N
  * lb_delay2=N
  * lb_range2=N
  * lbloom=(a series of comma-separated numbers)
  Save the file. The latebloom boot-args will disappear after your next reboot.
  
  If your boot-args are in nvram (and NOT in config.plist), do the following: in a Terminal window, type nvram -p and press Enter. You'll see several (possibly many) lines of output; the one you're interested in will start with boot-args and look something like this (your specific details will be different):

  boot-args -no_compat_check amfi_get_out_of_my_way=1 keepsyms=1 debug=0x8044 kdp_match_name=en0 -v latebloom=1 lb_debug=1 lb_range=0 lb_delay2=200 lb_range2=50

  Use your mouse to select everything after boot-args, to the end of the line (which might wrap to the following line(s) on your screen, depending on how wide your Terminal window is). In the example above, you'd start the selection at the beginning of -no_compat_check and end the selection at the end of lb_range2=50. Carefully right-click on the selection and choose Copy (make sure the selection doesn't change - if you accidentally right-click outside the selection, it will change). Now type sudo nvram boot-args=" (but do NOT press Enter), right-click in the Terminal window, and choose Paste. Your command line should now contain sudo nvram boot-args=" followed by the boot-args you copied. Type another " (and do NOT press Enter) to close the quote. Now, using the left/right arrow keys and the Delete/Backspace keys, edit that command line and remove the latebloom instances listed above, being careful not to change anything else on the line. After editing the example line above, you'd end up with:

  sudo nvram boot-args="-no_compat_check amfi_get_out_of_my_way=1 keepsyms=1 debug=0x8044 kdp_match_name=en0 -v"

  Once you're done editing, press Enter (after which you should be prompted for your root password - type it in and press Enter). If there are no error messages, you should be done. (If you get an error message, ask for help.)

 

[Syncretic]

(Reserved)

 

[avro707]

Superb! Well done indeed!

I'm looking into what I need to do to get rid of Latebloom and then applying this. I'm on 11.2.3 so far.

 

[Kmilot]

 

[startergo]

@Syncretic Just brilliant. Thank you for the hard work and dedication. I am sure Apple is monitoring this and latebloom thread. Of course it is up to them, but they could easily fix this by changing the code. You gave them the problem and the solution. They should pay you R&D royalty . Reading through the explanation on github quickly I am surprised that this deadlock is not present on the newer Apple devices (or the newer PC hardware).

Yes, I had to write my own debugger

Interesting.

 

[Ausdauersportler]

First Confirmation:

SurPlus patches included into OCLP 0.2.5 and latebloom disabled (manually by editing the config.plist) allows me to boot the affected iMac11,3 straight into Monterey Beta7 and Big Sur 11.6.

EDIT:
Works on my iMac12,2 (which was not affected) too. Just booted into Big Sur 11.5 (20G71).
I will add long term experiences to this post later on to avoid cluttering the thread as we did before

 

[KvR]

Second Confirmation:

SurPlus patches included into OCLP 0.2.5 and latebloom disabled (manually by editing the config.plist) allows me to boot the affected cMP4,1 > cMP5,1 straight into Big Sur 11.6.

Also noticed the donation link and acted on it .

 

[moonmage]

KUDOS!

 

[Dayo]

Nice one! The cMP lives to fight another day and quietly, often forgotten and mostly disregarded, the cMP 3,1 simply refuses to die ... thanks to sterling work such as this.

 

[Perana]

Just tested on my 5,1 on 11.6, working great so far!

Awesome work, so much appreciation!

 

[Enricote]

Hi! Thank you so much for your amazing job!

I have just a very silly question.
I see clear how to implement the patch following your explanation above in "How do I install the patch"?
Could you please answer a question like "How do I disable latebloom"?

I guess I need to erase latebloom.kext from OC>Kexts folder. But What do I exactly need to erase in the config.plist?

This whole line?:
boot-args -v -lilubetaall -wegbeta agdpmod=pikera shikigva=80 unfairgva=1 mbasd=1 -wegtree -no_compat_check no32exec=0 latebloom=30 lb_range=10 lb_debug=1 lb_delay2=200 lb_range2=50

Thank you again.

 

[chdrsto]

Hi! Thank you so much for your amazing job!

I have just a very silly question.
I see clear how to implement the patch following your explanation above in "How do I install the patch"?
Could you please answer a question like "How do I disable latebloom"?

I guess I need to erase latebloom.kext from OC>Kexts folder. But What do I exactly need to erase in the config.plist?

This whole line?:
boot-args -v -lilubetaall -wegbeta agdpmod=pikera shikigva=80 unfairgva=1 mbasd=1 -wegtree -no_compat_check no32exec=0 latebloom=30 lb_range=10 lb_debug=1 lb_delay2=200 lb_range2=50

Thank you again.

I guess you need to remove this latebloom=30 lb_range=10 lb_debug=1 lb_delay2=200 lb_range2=50 part from the boot-args.
There is a block in the Kernel array section which you need to remove as well

<dict> <key>Arch</key> <string>x86_64</string> <key>BundlePath</key> <string>latebloom.kext</string> <key>Comment</key> <string>Work-around PCI race condition</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/latebloom</string> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string>20.4.0</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict>

 

[PeterHolbrook]

I’m away from my trusted cMP 5,1 these days, and I might not be back in one or two weeks, but I’ve read Syncretic’s explanation and am truly impressed and thankful. Awesome work.

 

[irayet]

Bloody amazing work you've done here. Congrats on finding such an elegant solution to the problem.

 

[anklebiter]

I'm afraid it didn't work for my MacPro 5,1 running macOS 11.5.2. I edited the OpenCore config to remove the latebloom boot args and the <dict> entry in the kernel section. I then deleted the latebloom kext file and validated the config file. After that most reboots resulted in a hang. It took quite a while to get back into the system so I could restore the previous late bloom setup.
I'm using Martin Lo's OpenCore config. Perhaps that has something in it that doesn't work with SurPlus.

 

[Syncretic]

I'm afraid it didn't work for my MacPro 5,1 running macOS 11.5.2. I edited the OpenCore config to remove the latebloom boot args and the <dict> entry in the kernel section. I then deleted the latebloom kext file and validated the config file. After that most reboots resulted in a hang. It took quite a while to get back into the system so I could restore the previous late bloom setup.
I'm using Martin Lo's OpenCore config. Perhaps that has something in it that doesn't work with SurPlus.

Please post your config.plist as an attachment, or PM it to me. 11.5.2 should definitely work.

 

[startergo]

I'm afraid it didn't work for my MacPro 5,1 running macOS 11.5.2. I edited the OpenCore config to remove the latebloom boot args and the <dict> entry in the kernel section. I then deleted the latebloom kext file and validated the config file. After that most reboots resulted in a hang. It took quite a while to get back into the system so I could restore the previous late bloom setup.
I'm using Martin Lo's OpenCore config. Perhaps that has something in it that doesn't work with SurPlus.

From your post it is not evident weather you put the new code in or not.

 

[Enricote]

I guess you need to remove this latebloom=30 lb_range=10 lb_debug=1 lb_delay2=200 lb_range2=50 part from the boot-args.
There is a block in the Kernel array section which you need to remove as well

<dict> <key>Arch</key> <string>x86_64</string> <key>BundlePath</key> <string>latebloom.kext</string> <key>Comment</key> <string>Work-around PCI race condition</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/latebloom</string> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string>20.4.0</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict>

The "How do I disable latebloom?" question is now included in #2 by @Syncretic.
Thank you so much!
The SurPlus patch works in my computer too, without latebloom and without race condition! Amazing!

 

[mangombia]

On my 5,1 Workstation, using OpenCore Configurator, I disabled (read: unchecked) the LateBloom kext in the Kernel, then using Text Editor pasted the recommended Patch into the config.plist. Reboot to 11.6 was as smooth as silk. Need to test a cold boot, as on cold boots I was having Bluetooth issues (as in, Bluetooth wasn't loading at all), and needed a warm boot following cold to get it to load (sometimes more than 2x warm boots).

 

[h9826790]

So, at this moment, we can safely assume that the drive corruption problems were the results of APFS kext affected by the racing condition between zalloc and corecrypto. And if we apply this patch, drive corruption (which seems happen randomly on unsupported Mac) should not happen anymore (assuming this is the only racing condition that we need to fix).

Is this correct?

 

[Syncretic]

So, at this moment, we can safely assume that the drive corruption problems were the results of APFS kext affected by the racing condition between zalloc and corecrypto. And if we apply this patch, drive corruption (specifically due to this bug) should not happen anymore (assuming this is the only racing condition that we need to fix).

Is this correct?

Boot hangs due to this race condition (as opposed to the other random things that occasionally happen) occur very early in the boot process. If I hadn't seen reports of data corruption related to these hangs, I'd be tempted to assume they wouldn't happen - APFS shouldn't have time to do anything destructive before the system stalled. However, there are so many moving parts to this, I have to assume that it's possible for this race condition to produce data corruption under some set(s) of conditions.

To answer your question, with the patch in place, the system should behave more or less exactly as pre-11.3 systems do. All the patch does is avoid using corecrypto for random number generation during the early part of the boot process - random numbers are still generated, just using a different method (which doesn't cause a deadlock), and corecrypto isn't disabled system-wide, only during early boot. With the patch, 11.3+ systems should be just as stable as (and not produce any more data corruption than) a pre-11.3 system. Using the patch, the entire "boot hang/possible data corruption" episode should be behind us. (Let's hope there isn't a second ugly race condition lurking somewhere in the dark corners of MacOS. This one provided enough frustration for one lifetime.)

 

[avro707]

I guess you need to remove this latebloom=30 lb_range=10 lb_debug=1 lb_delay2=200 lb_range2=50 part from the boot-args.
There is a block in the Kernel array section which you need to remove as well

<dict> <key>Arch</key> <string>x86_64</string> <key>BundlePath</key> <string>latebloom.kext</string> <key>Comment</key> <string>Work-around PCI race condition</string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/latebloom</string> <key>MaxKernel</key> <string></string> <key>MinKernel</key> <string>20.4.0</string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict>

This is what I did as well on my 11.2.3 install of Big Sur but I didn't install the other part yet because it's obviously not needed so far.

With that patch applied, I should theoretically be able to run the 11.6 update that Mac OS keeps informing me about now.

From what I'm reading this new change should be safe to apply in 11.2.3?

 

[cjvegas]

@Syncretic thank-you very much, incredible work. I hadn't been able to boot into anything above 11.2.3 even with late bloom due to the number of drives I have connected. As soon as i updated my OC files (used Martin Lo's 0.7.1 and added in the patches. It booted perfectly in a couple of seconds.

I am now in the process of upgrading from 11.2.3 to 11.6. Again thank-you for your tireless effort. A donation is coming your way in appreciation for the massive effort you have put in.

 

[ses2008]

@Syncretic WOW thank you a hundred times.
I updated sucessfully from 11.2.3 >>> 11.6 in less then 17 minutes with 2 restarts.
Cheers