macOS 11 Big Sur on Unsupported Macs Thread

[Ausdauersportler]

I also have a Mac mini 2012 and have been using micropatcher. I’m on 11.5 and would like to go to 11.5.2 using OCLP.

Could you point me to the guide you used for the process. (450 pages and not sure what’s the latest). Thanks so much!

First post of this thread, read it, head to the OCLP download page, read the online docs of the OCLP tool, download and go for it.

 

[hvds]

1. macOS Big Sur 11.5.2 (20G95) 12.44GB
- 071-78704 - Added 2021-08-11 17:04:13

http://swcdn.apple.com/content/down...oe67yq9e1w2x0cafwjk8ofkr/InstallAssistant.pkg

MBP5,2: installed 11.5.2 over .1 from full installer. Using jackluke's BigSurBaseSystemfix plus his post-install patches (Legacy USB, Night Shift, Non-Metal Acceleration).

Edit: Installed also to a 2nd ssd, using oclp 0.2.4 and its post-install patch. - Both working fine.

 

[serafin79]

BigSur doesnot run well with Intel Graphics Hd 3000 on early 2011. I went back to Catalina. Also you will loose out the backlit keyboard if you have it. This is mentioned in the docs. If you open photos you will get rainbow effects, pixelation. The developers tried to fix acceleration but there are riders and it is not fully working. So my suggestion is to stick to Catalina as you last OS on 2011 MBP. Goodluck

when was the last time you tried running BS on a early 2011?
I run OCLP latest nightly and it works really well with 11.5.2. There are some graphic's issues but photos works for me.
only issue that bugs me is the side stuff and messages dies every so often and I need to delete the chat.* files and reload all my messages off iCloud(happens about 1 time a month and takes a min or so to fix)
I think they are doing a pretty good job of helping people use these old machines

 

[Dilli]

deleted.

 

[bobnugget]

Just installed Big Sur 11.5.2 into a partition on my 2012 non-retina 15" using OpenCore Legacy patcher. Worked a treat! Everything working so far (have checked Messages, WiFi, BT, Brightness, etc).

I'm running one of troop231's WiFi/BT adapter boards in it. Triple boot with Mojave and Windows 10.

 

[KennyW]

Successful update to 11.5.2 with OCLP 0.2.5 nightly. All hardwares work.

 

[ImpetuousRacer]

First post of this thread, read it, head to the OCLP download page, read the online docs of the OCLP tool, download and go for it.

Thanks. The process was almost identical. Instead of patching with micropatcher, I patched with OCLP instead (really the only difference). Plus I didnt have to patch the wifi drivers after either.

Looking forward to native updating through the OS here on out. Should have done sooner - expected it to be much more involved.

 

[camelia]

Successful update to 11.5.2 with OCLP 0.2.5 nightly. All hardwares work.

View attachment 1818202

Hello

Can someone please provide me the sha256 checksum of the file OpenCore-Patcher-GUI.app.zip :

https://nightly.link/dortania/OpenCore-Legacy-Patcher/workflows/build-gui/main/OpenCore-Patcher-GUI.app.zip

I am asking because OCLP 0.2.4 is a wonderful tool but very suspicious:

OpenCore Legacy Patcher - 0.2.4 - Jul 31, 2021 - VT 18/62

VirusTotal

VirusTotal

www.virustotal.com

0712c8cb80707ec67ec3c282adfd222fd1f927ca0d46257300edc7398d7bea60

Thanks
Camelia

 

[khronokernel]

Hello

Can someone please provide me the sha256 checksum of the file OpenCore-Patcher-GUI.app.zip :

https://nightly.link/dortania/OpenCore-Legacy-Patcher/workflows/build-gui/main/OpenCore-Patcher-GUI.app.zip

I am asking because OCLP 0.2.4 is a wonderful tool but very suspicious:

OpenCore Legacy Patcher - 0.2.4 - Jul 31, 2021 - VT 18/62

VirusTotal

VirusTotal

www.virustotal.com

0712c8cb80707ec67ec3c282adfd222fd1f927ca0d46257300edc7398d7bea60

Thanks
Camelia

View attachment 1818638
View attachment 1818639

I swear to all that is holy, stop relying on those horrendous antivirus services. Every single build of OpenCore Legacy Patcher is sent to Apple, and they themselves scan for malware, then sign and notarize our software with each build:

Your antivirus software is just security theatre with little logic, and only complains because it's a pyinstaller binary. All our software is public and open source.

• For those who do say it's triggered by "hackintosh software", the antivirus is too dense to parse pyinstaller files and so can't actually see what's inside. So it then throws up vague malware threats as security theatre
• pyinstaller for those curious is just a way to package up a python script with python in it, so users don't need a local python environment. pyinstaller is also open source

Would you like this resolved? File issues with the software vendor to get it to properly recognize when a binary has already has been validated and notarized by Apple or have them implement proper parsing of pyinstaller binaries

 

[K two]

I swear to all that is holy, stop relying on those horrendous antivirus services. Every single build of OpenCore Legacy Patcher is sent to Apple, and they themselves scan for malware, then sign and notarize our software with each build:
View attachment 1818659

Your antivirus software is just security theatre with little logic, and only complains because it's a pyinstaller binary. All our software is public and open source.

• For those who do say it's triggered by "hackintosh software", the antivirus is too dense to parse pyinstaller files and so can't actually see what's inside. So it then throws up vague malware threats as security theatre
• pyinstaller for those curious is just a way to package up a python script with python in it, so users don't need a local python environment. pyinstaller is also open source

Would you like this resolved? File issues with the software vendor to get it to properly recognize when a binary has already has been validated and notarized by Apple or have them implement proper parsing of pyinstaller binaries

The current TUI Nightly .zip file showed these items of concern, the OCLP v.0.2.5 payload within was clean upon unzipping. FWIW Only in the .zip file!

 

[camelia]

I swear to all that is holy, stop relying on those horrendous antivirus services. Every single build of OpenCore Legacy Patcher is sent to Apple, and they themselves scan for malware, then sign and notarize our software with each build:
View attachment 1818659

Your antivirus software is just security theatre with little logic, and only complains because it's a pyinstaller binary. All our software is public and open source.

• For those who do say it's triggered by "hackintosh software", the antivirus is too dense to parse pyinstaller files and so can't actually see what's inside. So it then throws up vague malware threats as security theatre
• pyinstaller for those curious is just a way to package up a python script with python in it, so users don't need a local python environment. pyinstaller is also open source

Would you like this resolved? File issues with the software vendor to get it to properly recognize when a binary has already has been validated and notarized by Apple or have them implement proper parsing of pyinstaller binaries

The current TUI Nightly .zip file showed these items of concern, the OCLP v.0.2.5 payload within was clean upon unzipping. FWIW Only in the .zip file! View attachment 1818691

Please forgive me 🥺🥺
I did not know

Thanks
Camelia

 

[0134168]

@h9826790 Just replaced the OC of my external SSD Big Sur 11.2.3 with your package. Works like a charm. Functionalities, like unlock with Apple Watch are restored. Thank you so much.

 

[Ungibbed]

After dropping a an old 2TB SSD in my 2012 Mini with 16GB. Running (11.5.2) and using the Patched Sur app and re-patching the kexts.

This is a first time for me in the realm of daily driving a unsupported OS install. Everything seems to be working fine so far (full feature support on ACD etc.)

 

[GhostoftheMac]

Hi all,

I have successfully installed Mac OS Big Sur 11.2.3 on my Mid 2011 27" iMac with a metal supported GTX 780M (full specs in the signature) with the Open Core Legacy Patcher v 0.2.4 but I encountered the following issue:

After booting the machine, logging into my account and opening several apps, some apps randomly close without showing an error message, which causes a chain reaction until all apps are closed and I need to force reboot the system as no app will open anymore. The reboot seems to fix everything though. Even if I open many apps simultaneously after the reboot, the system remains stable.

Has anyone had this issue before? If so, what could fix it?
Obviously it is a bit of a hassle to always reboot the computer to have a stable system.

 

[internetzel]

Hi all,

I have successfully installed Mac OS Big Sur 11.2.3 on my Mid 2011 27" iMac with a metal supported GTX 780M (full specs in the signature) with the Open Core Legacy Patcher v 0.2.4 but I encountered the following issue:

After booting the machine, logging into my account and opening several apps, some apps randomly close without showing an error message, which causes a chain reaction until all apps are closed and I need to force reboot the system as no app will open anymore. The reboot seems to fix everything though. Even if I open many apps simultaneously after the reboot, the system remains stable.

Has anyone had this issue before? If so, what could fix it?
Obviously it is a bit of a hassle to always reboot the computer to have a stable system.

I maybe had the same problem in an 11.3 installation which I then upgraded to 11.5.1 - however, I didn't use 11.5.1 for enough time in order to be able to tell whether the issue is still there.

Furthermore, I think there was one similar report here (or in a different thread here on macrumors) in the past few weeks.

So you say if you cold boot the machine into 11.2.3, you have to restart (warm boot) it afterwards in order to have a stable system?

 

[GhostoftheMac]

I maybe had the same problem in an 11.3 installation which I then upgraded to 11.5.1 - however, I didn't use 11.5.1 for enough time in order to be able to tell whether the issue is still there.

Furthermore, I think there was one similar report here (or in a different thread here on macrumors) in the past few weeks.

So you say if you cold boot the machine into 11.2.3, you have to restart (warm boot) it afterwards in order to have a stable system?

Hi internetzel,

thank you for your quick reply. Yes exactly, it seems like every time I cold boot the machine into 11.2.3, I need to restart (warm boot) in order to have a stable system. I did not upgrade to any newer version of Big Sur, because I read in the iMac Graphics Card Upgrade thread here, that 11.2.3 does not cause any kernel issues.

I will have a look through the thread to see if anyone had a similar issue before.
Also, I just realised that when putting the machine back together after the upgrades, I put the RAM into the two "lower" slots. I changed that now, so they are now displayed in About this Mac in the two upper slots. Don't know if that will have any impact but I'll post an update on the situation here soon after some testing.

 

[internetzel]

Hi internetzel,

thank you for your quick reply. Yes exactly, it seems like every time I cold boot the machine into 11.2.3, I need to restart (warm boot) in order to have a stable system. I did not upgrade to any newer version of Big Sur, because I read in the iMac Graphics Card Upgrade thread here, that 11.2.3 does not cause any kernel issues.

I will have a look through the thread to see if anyone had a similar issue before.
Also, I just realised that when putting the machine back together after the upgrades, I put the RAM into the two "lower" slots. I changed that now, so they are now displayed in About this Mac in the two upper slots. Don't know if that will have any impact but I'll post an update on the situation here soon after some testing.

You might also find something in the thread treating with the race condition - chances are that the cause of both problems is related. (Click the name of the original poster below in order to get to that thread)

I have created a kext that may provide a workaround for the Big Sur 11.3+ race condition. Alpha testing with a small group has provided encouraging results, so I'm now posting it publicly to see if those results withstand broader scrutiny.

---

UPDATE 4aug21:

• @dataid has written A Guide to Using Latebloom, which might be a good starting point if you're new to all of this.
• @khronokernel has written Getting Started with Latebloom, which provides a quick-start guide to using OCLP for latebloom installation and configuration.
• @Macschrauber has written a script to easily gather system information if you're planning to post a report to this thread.
• I have updated Post #2 with more user reports. Sorry for the long delays. I plan to reformat that data with additional fields (such as OS version, number of PCI devices, number of APFS volumes, etc.) when I have some time (i.e. don't hold your breath ;-).

---

Some important points before we start:

• THIS IS STILL EXPERIMENTAL. It's not polished, and there are no guarantees - it may work extremely well for you, or you may see little or no benefit. It could conceivably even make things worse on your system, although I have yet to see any such case, and have no reason to believe it might do so. Be aware that at this stage, trying this makes you a guinea pig.
• THIS IS A WORKAROUND, NOT A SOLUTION. As far as I know, no one has yet identified the true root cause of the race condition. Therefore, no one can offer an actual "fix," since we don't know what the real problem is. This kext helps mitigate the symptoms, but it does not address the root cause - therefore, any related problems may still be present. In particular, I've seen a few reports of disk corruption attributed to the race condition (although I have yet to see anything like that myself); be aware that using this kext probably does little or nothing to mitigate that risk.
• THIS IS STILL IN BETA TESTING. As such, I'm currently looking for somewhat more experienced Mac users to give it a try and provide feedback. If you're unsure what to do if I simply say "inject it via OpenCore or just link it directly into the kernel" without further detail, then please don't try this just yet - if it proves to be useful, I'll clean up the code and I (or some kind soul) will write up step-by-step instructions for installation and use. (Anyone is free to try this, but my availability for helping folks with installation questions is extremely limited right now.)
• IF IT AIN'T BROKE, DON'T FIX IT. If your system isn't experiencing the race condition bug on Big Sur 11.3+ or Monterey, you shouldn't bother with this kext. All it's going to do is increase your boot time.

The kext is called latebloom (see the bottom of this post if you're curious about the name). It hooks the PCI bus probe code, and inserts a pause for every iteration through the PCI bus. It does not touch the filesystem, it does not touch the network, it's only active during boot (before the login screen), and its only output is some print statements if you have verbose/debugging enabled. It won't do anything at all if it's loaded on MacOS older than Big Sur. (Let me reiterate here that this is EXPERIMENTAL - it's very much like having an old TV that flickers, so you bang on the side of the case until the picture clears up. We can't directly address the true cause, because we don't know what it is, but we can shake up the boot process and apparently improve the odds of a successful boot.)

This has been tested on various versions of Big Sur 11.3+, and on three betas of Monterey. It's primarily intended for Mac Pro 4,1 and 5,1 systems, but it should run on any Intel-based Mac (if you're so inclined). Note that while it's effective on either warm (restart) or cold (power-up) boots, testing shows it to be much more effective on cold boots, for reasons currently unknown. I welcome more test results to see if we can figure out why, and perhaps do something about it.

The kext can either be injected via OpenCore or linked directly into the kernel. (I have not tested direct kernel linking, so that's still an action item.) There's nothing special about the OpenCore injection; I have set MinKernel to 20.4.0 to ensure that it only gets loaded on 11.3+. The Kernel/Add values I used:

<dict>
    <key>Arch</key>
    <string>x86_64</string>
    <key>BundlePath</key>
    <string>latebloom.kext</string>
    <key>Comment</key>
    <string>PCI delay for BS/Monterey</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>

If you have kernel verbose/debug enabled, you'll see some startup messages that start with _____[ !!! *** latebloom *** !!! ]:, which might be informative. Notably, if you see HOOK NOT PLACED, the kext didn't actually do anything because it couldn't find the correct code to hook. PLEASE NOTIFY ME IF THIS HAPPENS. (This should not appear on any current Big Sur or Monterey releases, but new betas might trigger it.)

The kext uses three numeric boot-args for configuration. Note that unlike kernel boot-args, these values must be numeric, must be decimal, and must contain one to four digits. If a latebloom boot-arg is found but what follows the "=" is non-numeric, it will be interpreted as 0.

• latebloom=N sets the delay, in milliseconds. If latebloom=N is not present, a "safe" default of 60ms is used. If latebloom=0 is set (or if N is non-numeric, effectively making it 0), the kext will not place its hook, and will do nothing at all. This is an easy way to disable the kext (another being to set the OpenCore Enabled tag to false).
• lb_range=N sets a range for random delays. By default, every delay is exactly the same (either the latebloom=N value or the default 60ms). If lb_range is set, the delay for each PCI bus probe is random in the range (latebloom +/- lb_range) milliseconds. For example, latebloom=90 lb_range=20 results in random delays between 70..110 ms (90 +/- 20). If lb_range=N is not present, it defaults to 0 (no random changes, always use the same delay value). Using random delays may help avoid deadlocks.
• lb_debug=N enables additional debugging messages. If N is 0, or if lb_debug is not present, only some progress messages are displayed during boot. If lb_debug is set to 1, additional debugging messages are printed, including one for each iteration of the PCI bus probe, along with the actual delay value for that loop. At present, the only valid values are 1 or 0 (or no lb_debug boot-arg present).

If the kext encounters a problem trying to hook the PCI code, it will display an error message and pause the boot process for 4 seconds (to give you a chance to see the message). From there, your system will boot as usual, and the kext will do nothing. If there are no errors hooking the PCI code, the boot will proceed at normal speed (subject to whatever PCI delays you have set). Depending on your setup, there will likely be 50-100 PCI bus probe iterations; multiply that by your delay value to get a rough estimate of the impact to boot time. For example, if you set latebloom=1500, you're adding 1.5 seconds per loop - if there are 60 loops on your system, you've thus added 90 seconds to your boot time, which can feel like forever - so be careful with large values. Also note that unless you have lb_debug=1 in your boot-args, you'll see "silent" delays where your boot might appear to hang - be patient, especially if you're using large values (anything over, say, 200).

Note that if the kext is injected via OpenCore or linked directly into the kernel, it will always show up in kextstat (or other lists of loaded kexts), even if it failed to place its hook or if you've disabled it with latebloom=0. MacOS sees it as loaded, but it's not doing anything; seeing it as loaded tells you nothing about whether or not it successfully hooked or added any delays. The only evidence for that is in the verbose boot messages and the duration of your boot process.

The best results seem to be in the 50-150ms range. However, depending on your CPU clock speed, the number of PCI devices you have, the number of USB devices you have, the number of disks you have, and other configuration items, your value will likely be unique. The only way to determine what works best for you is to experiment - start with some value, see how it works, try increasing or decreasing it, see how it works, and eventually home in on the best value for your system. I'm requesting that once you've decided on an optimal (or at least "good enough") value for your system, please post in this thread with your system configuration and your latebloom parameters; I'm hoping we can collect enough of these to make a table of "best guess starting values" so that later users won't have to go through this process (or at least will have fewer steps to go through). If those parameters are consistent, and paint a fairly clear picture of which values work best on which configurations, I can incorporate that into the kext itself so it can choose a better default based on the system it's running on.

This is an unsigned kext, so you'll almost certainly need SIP disabled to link it directly into the kernel; OpenCore will apparently allow you to inject the kext without disabling SIP. As with my other kexts posted on MacRumors, the attached file is a ZIP of a TGZ file, so you'll need to extract it twice.

Good luck, and please post any results you get, good or bad. This may still prove to be yet another dead end, but it might also provide at least a narrow path past 11.2.3 (depending upon your use-case).

(Regarding the name "latebloom" - This is the 18th kext-based mitigation process I have attempted. The first one held the system in single-CPU mode until boot was completed, then enabled all the processors, creating a "late bloomer" situation. That method didn't prove fruitful, but the name stuck for every successive process.)

Version history:

12jul21   0.17   Initial public beta release
14jul21   0.19   Added support for Monterey beta 3

 

[internetzel]

Hi internetzel,

thank you for your quick reply. Yes exactly, it seems like every time I cold boot the machine into 11.2.3, I need to restart (warm boot) in order to have a stable system. I did not upgrade to any newer version of Big Sur, because I read in the iMac Graphics Card Upgrade thread here, that 11.2.3 does not cause any kernel issues.

I will have a look through the thread to see if anyone had a similar issue before.
Also, I just realised that when putting the machine back together after the upgrades, I put the RAM into the two "lower" slots. I changed that now, so they are now displayed in About this Mac in the two upper slots. Don't know if that will have any impact but I'll post an update on the situation here soon after some testing.

The following posts in that latebloom thread seem to be about something at least similar.

anybody experience instability with their mac?
I have to restart my mac 2 -3 x a day, because of apps crashing
thanks

Yes! It’s sort of a slow crash. As soon as I click an app in Dock and the menubar it crashes and won’t open again. This includes Finder. As I mainly use my Mac to SSH into and as a media server I never really notice the moment it starts to crash. Very hard to debug. I’ve now disabled SIP. This seems to help. No crashes in the last 24 hours. What are your exact symptoms?

I don’t think this is latebloom related by the way. I do think it is OCLP/OC related though: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/292.
But if more people report this, we can break out a new thread.

Exactly that
Anything that requires graphics or access to hd would accellerate the problem, ie. safari, subler, finder copy, etc

 

[KvR]

After booting the machine, logging into my account and opening several apps, some apps randomly close without showing an error message, which causes a chain reaction until all apps are closed and I need to force reboot the system as no app will open anymore. The reboot seems to fix everything though. Even if I open many apps simultaneously after the reboot, the system remains stable.

Yes! I have the same problem. I also opened thread about it on StackExchange. There you can find a full write up of my experiences so far. One very interesting thing I've found is that when I purge from the command line (or logged in via SSH) everything comes back to life.

 

[hwojtek]

Yes! I have the same problem. I also opened thread about it on StackExchange.

Well, if I were you, I'd rather use the OCLP Github issue tracker straight to OC/OCLP developers instead of looking for solutions that may come randomly or not. You may experience something resembling this, and the purge seems an interesting path.

 

[KvR]

Well, if I were you, I'd rather use the OCLP Github issue tracker straight to OC/OCLP developers instead of looking for solutions that may come randomly or not.

I opened an issue two months ago. Then I thought it was related to eficheck. That issue has been closed with commit "Work around eficheck kills". But the problem clearly still persists. Also, I can't attribute the problem to OC or OCLP.

One problem I have is I can't force the crash. I can't replicate the conditions it crashes. This makes debugging very hard. It's a waiting game and then hoping I have the time to look into it at that moment.

You may experience something resembling this, and the purge seems an interesting path.

Yes, that's my post . And I agree, purge looks interesting. I'm now writing memory stats to a log file every minute. Hopefully that can gives some clues on the next crash.

 

[m4f1050]

Just installed Big Sur 11.5.2 into a partition on my 2012 non-retina 15" using OpenCore Legacy patcher. Worked a treat! Everything working so far (have checked Messages, WiFi, BT, Brightness, etc).

I'm running one of troop231's WiFi/BT adapter boards in it. Triple boot with Mojave and Windows 10.

Has anybody tried 11.5.2 on 2012 non-retina 15" MBP stock WiFi/BT (BCM4331) board? I'm not sure I want to upgrade mine, since it works fine and it's already a dying dog... I have macOS 11.0.1 and haven't updated any further in fear of losing WiFi/BT, I'm already using the IO80211Catalina.kext. By the looks of it we are still getting macOS 12 on Intel based. Maybe I should fork the $150~ $200 for the upgrade... Any thoughts?

 

[m4f1050]

On another note... I also have a MacPro5,1 but this one I have been updating but stayed away from 11.5 lineup. Should I stay 11.4? I did upgrade video with an RX580 and the WiFi/BT board with the BCM4360.

 

[FreakyPerson01]

So I've just installed OpenCore legacy to get Big Sur running on my MBP 13" Early 2011 and I'm wondering if I fully install it to the internal drive including all the Post-Install Patches and all the other things will it run better?? Coz currently I'm in the mode where I have to have a USB flash drive in otherwise it won't boot.



Btw I followed Mr Macintoshes tutorial on the installation

 

[FreakyPerson01]

Oh and also I need help with the fact that OpenCore Legacy doesn't detect my built in 13" screen it thinks I have a 21" 1280x800 display and when I go to sleep the backlight is still on and the mouse is still there but everything is black but I can see backlight AND when I shut the lid it doesn't go to sleep it still stays on so somebody AND I can't control brightness at all plz HELP!!