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.
Last edited:
Using OCLP, it builds an EFI 'and' a System folder. Does the latter go inside an EFI partition at root level with the main folder or is the 'boot.efi' file in the System folder supposed to replace the OS one in CoreServices?
 
  • Like
Reactions: macinfo
I believe you're confusing what Ausdauersportler said, they're specifically referring to custom OpenCore builds and trying to use OCLP with it. Most users never configure OpenCore to expose itself so there's actually no way to reliably detect the usage of it.

However that's the only edge case, you can run OCLP on any patched OS starting from 10.9+(10.7+ if python 3.6+ is manually installed). Doesn't matter who's patcher you used, we'll still be able to detect and build a proper config regardless.

So for this example, a MacPro3,1 running Catalina via Dosdude1's patcher will have no issues running OCLP to build a configuration. Same logic applies to the Barrykn's Micropatcher, BenSova's Patched Sur, etc

However, an iMac12,1 user already running a custom OpenCore build not from OCLP will be unsupported. This is due to how by default OpenCore hides the "real hardware" making it impossible to detect the appropriate patches.

Hope this clarifies a bit,

- Mykola

Tks @khronokernel @Ausdauersportler for your detailed explanations.

Just to rephrase with my words to check if I understood fully:

Having swapped GPU on my 2011 iMac and using Catalina Loader for boot screen, I have then upgraded macOS to BS using Ausdauersportler modified version of micro patcher. If one day I would want / need to switch to OCLP, it would require me unpatch my system and reperform a clean install otherwise OCLP will not perfectly work.

Correct ?
 
Last edited:
Tks @khronokernel @Ausdauersportler for your detailed explanations.

Just to rephrase with my words to check if I understood fully:

Having swapped GPU on my 2011 iMac and using Catalina Loader for boot screen, I have then upgraded macOS to BS using Ausdauersportler modified version of micro patcher. If one day I would want / need to switch to OCLP, it would require me unpatch my system and reperform a clean install otherwise OCLP will not perfectly work.

Correct ?
I think so, yes. But you can still create the OCLP on an USB drive on your micropatched BS. You just need to select the specific model and turn on Metal support in the patcher settings.
 
On another topic, since theres no sound on iMac 2011 with OCLP, i used an usb sound card, something like this. Work fine for both out and in, but sadly this does not solve the built-in audio and microphone problem. Camera works though.
 
  • Like
Reactions: macinfo
Tks @khronokernel @Ausdauersportler for your detailed explanations.

Just to rephrase with my words to check if I understood fully:

Having swapped GPU on my 2011 iMac and using Catalina Loader for boot screen, I have then upgraded macOS to BS using Ausdauersportler modified version of micro patcher. If one day I would want / need to switch to OCLP, it would require me unpatch my system and reperform a clean install otherwise OCLP will not perfectly work.

Correct ?
Some weeks ago I implemented (to my knowledge) everything what has been used on the Catalina Loader and it's OC versions I provided for some months in the past until 0.6.6 into an OCLP fork.

@khronokernel picked all this up and integrated it into the latest versions of OCLP.

So if you need more recent OpenCore versions of to run Big Sur please move on to OCLP. If you find a bug or an issue open one on GitHub. It is that easy.

One can install the EFI folder provided by OCLP on the Catalina Loader (as before), or on an EFI partition of an USB memory stick or SD card device or on the EFI partition on your internal disk.

AMD (Polaris/Ellesmere) GPU users should stick with external devices (USB, SD, Catalina Loader) because they have no native boot screen and unlike MacPro systems they cannot just pull an internal disk to force an iMac to boot from an externally attached device! This is a very special iMac (or all in one system) problem. This is just to prevent users being unable to boot the system if and only if they have stored there a non working OpenCore or macOS version.

If you want to configure OCLP (i.e. run the patcher app) do this without another OpenCore version active! To get rid of an preconfigured OpenCore reboot and reset the PRAM.
 
Last edited:
Using OCLP, it builds an EFI 'and' a System folder. Does the latter go inside an EFI partition at root level with the main folder or is the 'boot.efi' file in the System folder supposed to replace the OS one in CoreServices?
The boot.efi you see is simply a bootstrap for EFI/OC/OpenCore.efi, this is done because on Macs there are 2 standard locations boot loaders are scanned at on OS start:

- EFI/BOOT/BOOTx64.efi
- System/Library/CoreServices/boot.efi

The partition type does not matter whether FAT32 or HFS+, however the pathing does. OCLP opts for the former to ensure BootCamp compatibility with GPT-based Windows installs, as Windows will also install its bootloader at EFI/BOOT/BOOTx64.efi.

And to clarify, OpenCore is never installed onto any disk other than the EFI partition. The only things that will ever touch your root volume are Apple kexts that need to be re-added such as AppleHDA and other GPU acceleration binaries

Hope this clarifies a bit,
- Mykola
 
I believe you're confusing what Ausdauersportler said, they're specifically referring to custom OpenCore builds and trying to use OCLP with it. Most users never configure OpenCore to expose itself so there's actually no way to reliably detect the usage of it.

However that's the only edge case, you can run OCLP on any patched OS starting from 10.9+(10.7+ if python 3.6+ is manually installed). Doesn't matter who's patcher you used, we'll still be able to detect and build a proper config regardless.
Ok, Got it

Thanks for the clarification

After I posted I realized OCLP must not be too problematic in case of a native Mac because it offers option to build for an 'other' machine ID, so it's working from a catalog of model traits.

Nonetheless it still feels like a bit of a messy situation to me (as uninitiated) because spoofing is a key feature of all approaches and such opens the door (at least mentally) to problems with config cycles. To be clear, for me and many users these approaches must be black-boxes.
* * *

As a total aside, per another recent convo on this thread, I think this concern shines a narrow but relevant light into the darkness of big-picture questions like how does Apple decide when a line is no longer supported, why don't they offer wider support, and when does a work-around for a key performance factor, such as security, become too burdensome to support. For example, can the supporters of OCLP promise that spoofing will not disturb config detection? Yes, when the config is stipulated to certain Apple models. What about this OC hackintosh which is almost the same as this model? Well, define "almost". ...1,000 messages later...

Substitute Apple lawyers for OCLP supporters and we begin to get a sense of how challenging "support" can be.
 
Nonetheless it still feels like a bit of a messy situation to me (as uninitiated) because spoofing is a key feature of all approaches and such opens the door (at least mentally) to problems with config cycles.
Could you elaborate what config cycles means in this context? I'm a bit lost
For example, can the supporters of OCLP promise that spoofing will not disturb config detection? Yes, when the config is stipulated to certain Apple models.
Same as earlier, what does config detection mean in this context?
 
Translate "cycle" as recurrence. What I mean is that because I am ignorant of the methods used to grok config, the situation of spoofed config includes wonderment at how any knows when its done looking. The simplest answer it looks for some status once, and uses whatever it finds. This means the user of the tool has to be aware of when config may not be valid. We can imagine using special techniques to detect the spoofing: The tool could look again at other status, or just ask the user. However it's done we encounter that to support the unsupported there's a question of where does the authentic config live. In a supported system this is stipulated by its design. RTFM.

This leads to a goofy situation in the pursuit of keeping unsupported systems running: When does the support of the unsupported become unsupportable?

"I'm sorry to report that your unsupported system is no longer supported by the xyz parcher." This ties into the hand-wringing conplaints very often made against Apple, such as one recently posted that said (in a loose quote) Why does Apple shirk support for older systems when so many here are successfully running latest OS.

WRT "config detection" I see clear evidence of dosdude patcher and OCLP provisions to examine the system status and make helpful config decisions, but I don't know how this works.

I don't want to drag this discussion into a hole.

My thoughts are boil down to I want to understand reasonable operation of the tool.

I was startled by this topic because OCLP fails to run on my 3,1 and I submitted an issue at github without stopping to question whether running dosdude Catalina patcher might interfere with OCLP. I just don't want to waste good peoples' time — tho maybe too late haha

Again, to me these are black boxes. I get the point, in context, re OC spoof layers hazard as an edge case. No prob.

My OCLP issue report got a commit and I'm looking forward to trying again with next release of patcher.

Thanks to all for the awesome work.
 
Last edited:
Tks @khronokernel @Ausdauersportler for your detailed explanations.

Just to rephrase with my words to check if I understood fully:

Having swapped GPU on my 2011 iMac and using Catalina Loader for boot screen, I have then upgraded macOS to BS using Ausdauersportler modified version of micro patcher. If one day I would want / need to switch to OCLP, it would require me unpatch my system and reperform a clean install otherwise OCLP will not perfectly work.

Correct ?
I installed 11.2.3 as OTA update on top of a patched 11.1 installation. After that the APFS snapshot was correctly sealed and hence I got an unpatched installation that way.
OCLP set to SIP and SBP enabled boots this without problems so I think it's all OK.
 
What I mean is that because I am ignorant of the methods used to grok config, the situation of spoofed config includes wonderment at how any knows when its done looking.
We do document OCLP quite a bit as well as OpenCore has plenty of documentation as well. We make sure users have all the information available if they're interested in learning more:

- OpenCore Legacy Patcher Guide (Includes terminology, boot process and kext break down)
- OpenCorePkg documentation

Its less of a black box and more that users do not actively research, that is fine but we've made it so that nothing seems like a mystery.
This means the user of the tool has to be aware of when config may not be valid.
Not necessarily, you only need to update OpenCore when you have an issue. Otherwise use the OpenCore build you built with till you feel there's some benefit with the newer updates
Why does Apple shirk support for older systems when so many here are successfully running latest OS.
Mainly security and engineering efforts. If Intel drops microcode updates for a certain generation of CPU, Apple's not interested in having a security flaw due to a 3rd party vendor. For users here, that may not matter but to Apple, who advertises the security of their platform, it's very important.

- Mykola
 
We do document OCLP quite a bit as well as OpenCore has plenty of documentation as well. We make sure users have all the information available if they're interested in learning more:

- OpenCore Legacy Patcher Guide (Includes terminology, boot process and kext break down)
- OpenCorePkg documentation

Its less of a black box and more that users do not actively research, that is fine but we've made it so that nothing seems like a mystery.

Not necessarily, you only need to update OpenCore when you have an issue. Otherwise use the OpenCore build you built with till you feel there's some benefit with the newer updates

Mainly security and engineering efforts. If Intel drops microcode updates for a certain generation of CPU, Apple's not interested in having a security flaw due to a 3rd party vendor. For users here, that may not matter but to Apple, who advertises the security of their platform, it's very important.

- Mykola
You have somehow overlooked all the ironies in my comments.

Nonetheless I appreciate all the good work.

The OCLP project is beautifully organized a la Github, and the writeup worked well for me. The Github portal is great where issues can be submitted at same channel as picking releases reading docs, and getting involved, so love it.

What I'm trying to convey re my comments for documentation is my surprise at something akin to the observation 'what are the limits of running a virtual machine on a virtual machine?' — It so happens my interests include science and philosophy, where problems in meta and recursion are perennial topics. There's a great treatment of this in a book which was once very popular among geeks in the 80s (no it's not the stupid Fountainhead!) It's titled 'Godel, Escher and Bach,' by Doug Hodstadter. He discusses the epistemological limits of meta in the work of these three great creators and offers a thougt experiment limits of an unbreakable record player, like Superman, with one weakness; from wikipedia writeup:

//An [unbreakable] phonograph dubbed "Record Player X" destroys itself by playing a record titled I Cannot Be Played on Record Player X (an analogy to Gödel's incompleteness theorems), an examination of canon form in music, and a discussion of Escher's lithograph of two hands drawing each other.//

I'll leave it at thar, hoping this reference provides food for thought beyond bounds of EFI hacking. Google "record player x" for a good medium.com article on meta and fascism, which is a topic always too close to the machinations of giant media/technology corporations building thought-control devices.

Back to OCLP:

All my points are meta-points about limits of support, aimed at dudez who post complaints about Apple dropping support. There are good reasons to be unhappy about loss of support, and we may wish it were otherwise, but it doesn't imply Apple is screwing up.

If it sounds like I'm working both sides od the street, I am.

The freedom for a community to support itself is key and in keeping with Stallman and GNU's original concerns for free software. It's wonderful to find an intelligent, active support community for gear that a conpany of extraordinary wealth and power, built on backs of these its users, has no overt interest in supporting except by selling us more of the same.

And the writing is on the wall: soon Apple products will be completely locked away from their users, which is a situation I find much more dangerous than the risks of security — following a dictum of Record Player X.

This community is giving everyone more freedom to chose how to keep living with our existing gear. Thank you!

As to how good this is? It feels really good, though I have to admit I'm overlooking effects like maybe the high electrical power consumption of my old Mac Pro has a downstream cost in pollution that would be better mitigated by the upfront cost of a much more efficient M1? IDK honestly.

As you say, maybe it's not so much a sealed black box as just being willing / able to look inside.

Our society, although conpletely computerized, only clumsily applies such to help understand life's tradeoffs.

I still think locally even tho I act globally haha. And by local measures keeping my old gear working is a preservation of wealth that makes sense to me!

People working together freely to do so is the best expression of creativity.

I hope any reader can see my views look up past horizon as well as watching to not stumble over ground at my feet.

Again I pray I'm not wasting time.

Carry on
 
Hello all, I have a 2011 iMac 27". 12,2 with K2000m metal gpu upgrade and I am having trouble with both @Ausdauersportler's dev-0.5.5 micro patcher, as well as the automated-micropatcher both listed on the 2011 iMac GPU thread. I have used two different USB drives, each with 11.2.1 and 11.2.3 and then reversed, each using the different micropatching methods.

Whenever booting to EFI, then clicking on "Install macOS Big Sur," the verbose output rolls for about 20-30 seconds and the screen promptly shuts off but the computer is still on.

Things to note:
Using an external monitor through thunderbolt
Tried multiple PRAM and SMC resets before and after
Tried rebooting after EFIl then straight to the installer - no dice
Made sure OC 0.6.6 and the 11.2.1/11.2.3 were truly the correct version
Only a single SSD with HS is internally installed

Other things which may not make a difference:
The external monitor is outputting 720x1280, however this is a Thunderbolt Cinema Display

I would appreciate any help!
 
Hello all, I have a 2011 iMac 27". 12,2 with K2000m metal gpu upgrade and I am having trouble with both @Ausdauersportler's dev-0.5.5 micro patcher, as well as the automated-micropatcher both listed on the 2011 iMac GPU thread. I have used two different USB drives, each with 11.2.1 and 11.2.3 and then reversed, each using the different micropatching methods.

Whenever booting to EFI, then clicking on "Install macOS Big Sur," the verbose output rolls for about 20-30 seconds and the screen promptly shuts off but the computer is still on.

Things to note:
Using an external monitor through thunderbolt
Tried multiple PRAM and SMC resets before and after
Tried rebooting after EFIl then straight to the installer - no dice
Made sure OC 0.6.6 and the 11.2.1/11.2.3 were truly the correct version
Only a single SSD with HS is internally installed

Other things which may not make a difference:
The external monitor is outputting 720x1280, however this is a Thunderbolt Cinema Display

I would appreciate any help!
Last time I checked the micropatcher dev-v0.5.5 it came with an opencore package included to install and later use Big Sur. I had no time to unify both packages....but is is on the short todo list while I was helping to port all the stuff into OCLP.

It would really help if you describe what you did and not only what you have. The micropatcher has a 15+ points step by step list.

P.S.:
It has never been tested with K1000M and K2000M - at least I got no feedback so far. But there is nothing special with these GPU types (other than lack of brightness control).
 
Last time I checked the micropatcher dev-v0.5.5 it came with an opencore package included to install and later use Big Sur. I had no time to unify both packages....but is is on the short todo list while I was helping to port all the stuff into OCLP.

It would really help if you describe what you did and not only what you have. The micropatcher has a 15+ points step by step list.

P.S.:
It has never been tested with K1000M and K2000M - at least I got no feedback so far. But there is nothing special with these GPU types (other than lack of brightness control).
Thanks for the reply. Here is what I did:

1. Format USB to Mac OS extended (journaled) with GUID.
2. Create install media with downloaded install package (11.2.1/11.2.3)
3. Drag and dropped micropatcher.sh and found USB.
4. Drag and dropped install-open core.sh
5. Partitioned the single internal SSD to create the HS container, and an empty Big Sur container
6. Restarted holding down option, control-selected EFI boot. Then immediately selected Install Big Sur after the screen went black and came back on.
7. Verbose script started and ran for about 20-30 seconds then the screen promptly flashed and went blank/black. No backlight or anything.
8. I waited for something to happen and then the iMac shut off.

Repeated steps 9 and 10 of your micropatcher to no avail. Same end-result. I even tried booting into EFI, then to HS and ran the software update Big Sur installer and the same result after restarting.
 
Whenever booting to EFI, then clicking on "Install macOS Big Sur," the verbose output rolls for about 20-30 seconds and the screen promptly shuts off but the computer is still on.
This is also happening to me when I install or update Big Sur without OC or OCLP. I tried once with OC that's preconfigured on @Ausdauersportler micropatcher but it was stuck while I was on verbose mode. I'll try it again with OCLP when 11.3 is released and report back.

All my successful upgrades were done using the same micropatcher but without OC. The screen is turned off after the first reboot but the update is running. After that it reboots a few times and the screen remains dark. I verify that it has finished updating using a power consumption device attached on my power outlet and I see that the power has dropped to minimum. It means there is no activity on the disk and I manually turning it off and on.
Try to wait 45-60 minutes before turning it off. It could be updating while the display is off especially if it reboots. Sometimes when it reboots while updating you will hear only the ODD and not the chime sound.
 
Try to wait 45-60 minutes before turning it off. It could be updating while the display is off especially if it reboots. Sometimes when it reboots while updating you will hear only the ODD and not the chime sound.
I just tried this: waited after the screen goes black/ computer still on after the verbose roll and the iMac shut off exactly at 24 minutes. Man, I have no idea what is going on. I'm retrying the micropatcher and automated-micropatcher on a 3rd USB to see of anything changes.
 
Thanks for the reply. Here is what I did:

1. Format USB to Mac OS extended (journaled) with GUID.
2. Create install media with downloaded install package (11.2.1/11.2.3)
3. Drag and dropped micropatcher.sh and found USB.
4. Drag and dropped install-open core.sh
5. Partitioned the single internal SSD to create the HS container, and an empty Big Sur container
6. Restarted holding down option, control-selected EFI boot. Then immediately selected Install Big Sur after the screen went black and came back on.
7. Verbose script started and ran for about 20-30 seconds then the screen promptly flashed and went blank/black. No backlight or anything.
8. I waited for something to happen and then the iMac shut off.

Repeated steps 9 and 10 of your micropatcher to no avail. Same end-result. I even tried booting into EFI, then to HS and ran the software update Big Sur installer and the same result after restarting.
Do not share the same APFS with HS and BS containers. Create two separate partitions! But this does not explain the behaviour described.

Another point: dev-v0.5.5 is called dev for a reason. You should check back the main fork (0.5.4). This is stable. I stopped working on dev-v0.5.5 three weeks ago for personal reasons and will spend more time on it the upcoming days.

Last point: Try to deinstall the memory modules and start with a single one to rule out any (hardware) problems there.

EDIT: Have you checked the card and the complete system before with High Sierra (unpatched, but latest version)?
 
Last edited:
Slightly off-topic, but is it possible to clone my SSD to a new one, while keeping OCLP, which is currently installed on my ssd? I bought a new SSD, because the current one is pretty old and slow and i don't want to start from scratch again. What would be the best option to clone my drive?
 
Since you surely have a working recovery strategy (i.e. backup and restore) just use it. This is the perfect situation to use it since you have the old SSD to go back in case your method fails for some reason.
 
  • Like
Reactions: passatgt
Do not share the same APFS with HS and BS containers. Create two separate partitions! But this does not explain the behaviour described.
I mean't to say separate containers in separate partitions.
Another point: dev-v0.5.5 is called dev for a reason. You should check back the main fork (0.5.4). This is stable. I stopped working on dev-v0.5.5 three weeks ago for personal reasons and will spend more time on it the upcoming days.
I just tried v0.5.4 with 11.2.1 (using OC). I did however try the install-setvars.sh command and went through the motions and reached a screen after booting EFI-->"Install macOS Big Sur" with the Apple logo and a loading bar. The screen shut off after 20 seconds very similarly to OC version and the iMac was still running.
Last point: Try to deinstall the memory modules and start with a single one to rule out any (hardware) problems there.
I tried this with one 8 gb module in either top slot and nothing changed using dev-v.0.5.5 or v0.5.4 with OC.
EDIT: Have you checked the card and the complete system before with High Sierra (unpatched, but latest version)?
Basic functionality is fine (openGL score of 814 compared to 797 in the GPU table). Brightness control works on 10.13.6, streaming video works (YouTube, Netflix) in Safari. Only thing is the GPU recognizes the external display as 1280x720 instead of 2560x1440.
 
Last edited:
In addition to the StarPlayrX method (currently MIA for later updates) what is the other next-best or even better method for getting later Big Sur versions on a cMP 3,1? I've tried OCLP but there is confusing information about whether the 3,1 CPU is supported and it didn't work for me.
 
Last edited:
  • Like
Reactions: gw463
Hi guys, i don't know how but, this morning i tried to reset pram because the system was a bit slow at starting...but when i didi this i had no chance to start the system again, i had a warning and the system goes off...never hapened before, i'm on 11.2.3 with micropatcher, never had a problem until today, what can i do to fix this?

The problem is that now i do not have a mac to restart the entire process, can i do something from recovery?
I tried to load recovery, but it seems like Snow Leopard recovery...any chance to fix this by any windows tool? The drive seems deactivated, and can't set active


Ok, sometimes i'm lucky, i found the installer on a old hdd, and did a ssd check, and fix my issue
 
Last edited:
Hi guys, i don't know how but, this morning i tried to reset pram because the system was a bit slow at starting...but when i didi this i had no chance to start the system again, i had a warning and the system goes off...never hapened before, i'm on 11.2.3 with micropatcher, never had a problem until today, what can i do to fix this?

The problem is that now i do not have a mac to restart the entire process, can i do something from recovery?
Reboot into the Boot EFI of the installer USB you prepared. This is also part of the docs.
 
  • Like
Reactions: macinfo
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.