Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
@Ausdauersportler Still trying to get an understanding of what happened here. Did you run 0.0.6 OC and then apply the OTA 11.1 update ?
If you want to understand what happened to users of the OLP you visit the fitting Github pages and take a deeper look into the issues posted there. Users of older iMacs are in danger, too,

Of course I cannot repeat all this here on every new page...but you all can subscribe to the mailing list (not much traffic now) to get updated about these issues and the most interesting patcher project right now.

Over the Christmas time I am going to add an OpenCore option and packages to the iMac micro patcher fork, too. Since the iMac11,x already needs it anyway and all AMD cards too there is only a small subset of cases left where you can run Big Sur without OpenCore.

Possibly it is the most easy way to go unless the OLP supports all systems here in the same way the micro patcher does. On the long run it does not make any sense to have competing duplicates of OpenCore packages spreading around.

EDIT:
Use the latest version of OPL and OC 0.6.4, only. Get rid of older OC versions or avoid using OTA.
 
but there is no method to install 11.2 without the installer?
You can use Opencore legacy 0.0.7 to make EFI boot and replace all "xxx.EFI" files with Opencore 0.6.5 this is the only way that works with less risk and correct firmware version.

Opencore Legacy Patcher 0.0.7

Opencore 0.6.5 last Version release
 

Attachments

  • OpenCore-0.6.5-RELEASE.zip
    6.2 MB · Views: 85
  • Opencore-Legacy-Patcher-0.0.7.zip
    6.1 MB · Views: 121
Micropatcher allows me to install the system on unsupported macs, however an NVRAM reset leaves the system unusable until you have a USB stick nearby, using OpenCore, you can reset the NVRAM and whenever you start the system, it will always be available, there is no no concern with NVRAM reset, I can leave SIP enabled.
So why not using only OpenCore?
 
OpenCore: Having OTA upgrades... have a root volume with an unbroken seal.
Patcher: Having all the functionality you had before with supported OS.

Currently you cannot have both. Please check out the first post and read through this thread...
I know we can’t have both currently. So what is the reason to talk about?
 
You can use Opencore legacy 0.0.7 to make EFI boot and replace all "xxx.EFI" files with Opencore 0.6.5 this is the only way that works with less risk and correct firmware version.

Opencore Legacy Patcher 0.0.7

Opencore 0.6.5 last Version release
If people aren’t eager to upgrade early, it will be better to wait for the official release of 0.6.5 on January 4.
 
Does anybody know how to modify Barry K Nathan's MicroPatcher to add a custom made app to the Utilities menu of the USB installer?

example
I made a command file to automate the post install patch-kexts.sh without having to type in the terminal app

Volumes/Image\ Volume/patch-kexts.sh /Volumes/Big\ Sur

here is the command file below:

=====================================

#! /bin/bash

function msg {
printf "\e[1;32m>\e[m %s\n" "$1"
}
function msg2 {
printf "\e[1;34m>\e[m %s\n" "$1"
}

msg "Big Sur Post Install patch kexts"

msg2 "Please enter your password to patch Big Sur"

sudo Volumes/Image\ Volume/patch-kexts.sh /Volumes/Big\ Sur

display alert “Big Sur Post Install patch kexts done”

===========================================

save the text in textedit as as unicode and name it Post Install Patch.command


next you have to give the command script permission to run in terminal
open terminal and type

sudo chmod -R 755
and drop the Post Install Patch.command file into terminal
then enter your password

Now can anyone help me convert the command file to an app file

I found this in Github


but haven't had luck yet making an app from the command script
 
So why not using only OpenCore?
micropatcher allows me to create a robust installer without any problem, and if Apple changes something in the main partition (EFI), I don't run the risk of running out of an alternative, that's the saying: "insurance died of old age".

ref to OTA errors, OpenCore 0.6.4 allows me to update without any problem, yes, I have seen the firmware update screen, however it is not allowed and the mac is only turned off when trying to write a different firmware not compatible with your hardware.
 
If people aren’t eager to upgrade early, it will be better to wait for the official release of 0.6.5 on January 4.
We talk about it because the OLP does not support my systems as my fork of the micro patcher does. I would like to use OLP, but it does not fit and it was not save until the 2nd. update of version 0.0.7 and even now we are talking about waiting until 0.6.5 hits the road.

Give it more time...
 
I know we can’t have both currently. So what is the reason to talk about?
You don't have to use both, and it is not advisable to do so, regardless of what anyone here says. In fact it could add unnecessary complexity. It will give you some redundancy in terms of testing both methods, but that's it. If you have a correctly set up opencore system, you will be able to create a normal usb installer which is bootable, and thus negates the reason to have a "robust" micropatcher... Having said that, my advice, stick with the Micropatcher. OC is not ready for game day, and will attempt to upgrade firmware. Theres just too many cases of it bricking systems right now.
 
You don't have to use both, and it is not advisable to do so, regardless of what anyone here says. In fact it could add unnecessary complexity. It will give you some redundancy in terms of testing both methods, but that's it. If you have a correctly set up opencore system, you will be able to create a normal usb installer which is bootable, and thus negates the reason to have a "robust" micropatcher... Having said that, my advice, stick with the Micropatcher. OC is not ready for game day, and will attempt to upgrade firmware. Theres just too many cases of it bricking systems right now.
Seems most of people don’t know I have done that days ago. I also have 3 non-Mac systems with OpenCore so I’m not really unfamiliar with it.

 
  • Like
Reactions: naylom11
Seems most of people don’t know I have done that days ago. I also have 3 non-Mac systems with OpenCore so I’m not really unfamiliar with it.

I did see that post a few days ago. Like I said, if you know OC inside and out, then more power to you. Its a good method to use. I just wanted to make it clear to others you don't need both. Contrary to what others have said.
 
Seems most of people don’t know I have done that days ago. I also have 3 non-Mac systems with OpenCore so I’m not really unfamiliar with it.

The problem is basic logic:

To prove that there is a problem with a certain solution a single bad example is sufficient - we had already more than one bricked system.

To prove that there is no problem with a certain solution you have to prove it for all possible cases (in math and operating on natural numbers one might use induction).

So your three positive (non Apple hardware!!) cases are nothing worth, even if I add my more than twenty successful OTA upgrades during the last days (on real Apple hardware) it does no even the odds. We are in a phase where publishing or pushing inexperienced users into such experiments will cause damage with high probability.

As I wrote before: I am able to restore my iMacs firmware. Your non Apple hardware will unlikely face a firmware upgrade.
 
  • Like
Reactions: mwidjaya
If you are running the micropatcher it doesn't matter. Your machine won't receive any OTA updates, firmware or otherwise. Depending on what you do have installed, you'll obviously still receive Safari, Xcode Tools, and other non-system updates... The only people that need to be concerned with OTA updates are those with OpenCore installed. Unless you plan on doing that, I wouldn't worry about it
So you are saying that with the micropatcher, the autoupdate system simply won't find updates?
 
You don't have to use both, and it is not advisable to do so, regardless of what anyone here says. In fact it could add unnecessary complexity. It will give you some redundancy in terms of testing both methods, but that's it. If you have a correctly set up opencore system, you will be able to create a normal usb installer which is bootable, and thus negates the reason to have a "robust" micropatcher... Having said that, my advice, stick with the Micropatcher. OC is not ready for game day, and will attempt to upgrade firmware. Theres just too many cases of it bricking systems right now.
well said, I'm sticking ( Mid 2012 13"MBP) with micropatcher for now.
 
  • Like
Reactions: naylom11
For the moment at least security updates get rolled into OS updates that go into the full installer and whilst it's a pain to have to download the whole OS for each update it is doable.

The Micropatcher only starts to become a security issue once next year's new Mac OS is released and Big Sur only gets OTA security updates, and that's assuming that a way to download those OTA updates and safely install them using a micropatcher hasn't been figured out by then. And that's assuming either Intel isn't supported for the next Mac OS or your Mac won't work well unsupported on it using a micropatcher or you don't want to move past Big Sur just yet.
 
So you are saying that with the micropatcher, the autoupdate system simply won't find updates?
I think the simple way to think of it, is that micropatcher is not spoofing identity of your mac. It is primarily patching the USB installer to bypass the checks for supported macs.

So software update still reads that your mac is not supported for big sur, and as such will not update it.
 
  • Like
Reactions: MacCanick
I think the simple way to think of it, is that micropatcher is not spoofing identity of your mac. It is primarily patching the USB installer to bypass the checks for supported macs.

So software update still reads that your mac is not supported for big sur, and as such will not update it.
Thanks! Makes sense. So no danger of bricking anything which is my main concern.
 
New note from OpenCore Legacy Patcher readme:

Ivy Bridge and Haswell Notes​

Currently in Big Sur 11.0.1 and 11.1, there are partial firmware brickings happening during the install stage. The exact issue depends on the CPU model generation:

  • Ivy Bridge:
    • Simply power cycling the machine will resolve this issue
      • Laptops will need to unplug the battery for a bit
    • To avoid this issue outright, simply shutdown the machine after Big Sur has installed macOS instread of having the installer auto reboot
  • Haswell:
    • Power cycling maywork however some iMac14,x users have reported needing a firmware reflash
      • Patcher currently has removed support for these machines till macOS 11.2's release to avoid any unnessary headaches for users
iMac14,1 # Due to issues with 11.1, currently not supported
iMac14,2 # Due to issues with 11.1, currently not supported
iMac14,3 # Due to issues with 11.1, currently not supported
 
Actually every method for patching unsupported Macs is not for noobs...
Agreed. Most Mac users prefer the more intuitive GUI than text commands.

And I must praise that DosDude1's Catalina Patcher is very nicely done with all patching in GUI.
But even then some still encounter problems.

Thus we can expect more questions from users of these developing new patchers.
They are still experimental and evolving, not for routine general consumption at the moment in my opinion.
 
I've still (!!) been playing around with using @jackluke's sideloader for installing unpatched Big Sur on a nearly-supported Mac (i.e. a late 2012 13" retina MBP with an upgraded Wi-Fi card).

I'm successfully on 11.2 beta now ... but only with a lot of disassembling and disconnecting the battery! I should always be using createinstallmedia from a full download, which is safe, but I'm persisting in trying to get incremental OTA installs to work ... which they always do ... except for having to remove the battery to fix the black-screen problem after first-reboot, every time! 😡

I'm posting again because my understanding is that since Big Sur 11.1 release version (or so?) an incremental OTA update no longer black-screens the supported 2013 and 2014 MBPs - i.e. Apple fixed that problem?

So I thought that editing the config.plist file in @jackluke's customised bootloader to specify MacBookPro11,1 and Mac-189A3D4F975D5FFC would stop the black-screen problem for me, since Big Sur should no longer do the problem step on the Mac I've specified. But it didn't work! 😏😏🙁

Has anyone got any other ideas or .plist settings I might try?
 
  • Like
Reactions: Ausdauersportler
For those who are using OpenCore to spoof the Mac's indent in order to get Big Sur support.

I have a suggestion to avoid unintentional BootROM update (if both run-efi-updater=No and BlacklistAppleUpdate=true failed).

Rather than use actual BootROM version, manually inject 999.0.0.0.0 in the config plist.

This won't do anything damaging to your Mac. Your Mac still use the current (and actual) BootROM.

However, once booted to macOS, macOS will "believe" that the Mac already has BootROM version 999.0.0.0.0.

So, let's say, Big Sur 11.2 official release contain a BootROM update for the Mac ident that you are spoofing (e.g. version number 430.0.0.0.0).

Since 999.0.0.0.0 is already higher than 430.0.0.0.0. Therefore, the installer / updater will automatically skip the BootROM update. Therefore, even both run-efi-updater=No and BlacklistAppleUpdate=true failed, your Mac should be still protected.
 
Last edited:
Alright, so I've created multiple mini-projects, all relating to my patcher in obj-c, and everything is going really well. However, I am still stuck on one thing: unzipping files. Is there any way of doing it directly in obj-c? If not, I think I'll just make a shell script for doing so and ask the obj-c app to run that script (which I have successfully done, thanks to @Ausdauersportler and @ASentientBot )
 
  • Like
Reactions: iMac-iPad
Hello,
I have installed the big sur on an iMAC late 2010. Everithing works except the ethernet LAN Card. The BCM5701 driver, so i guess, is not right installed. So far usualy is this firmware in the AppleBCM5701Ethernet.kext somewhere in the /S/L/E folder... But this folder is write protected now. So my question is, is it possible to inect this driver with the opencore bootloader, too? Or is it necessary to install the System new?
 
  • Like
Reactions: K two
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.