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.
Installed Sonoma 14.0 a few days ago on my MacBook Air mid 2012 model (MacBookAir 5,2) using OpenCore Legacy Patcher 1.0.1. It has a dual-core i7 Ivy Bridge and 8GB of RAM.

I got an SSD drive is from OWC (1TB) because I wanted to get it dual booting with Linux Mint.
The OpenLinuxBoot loader (and of course OCLP as a whole) is great, really impressed!
 
Bluetooth doesn't seem to be working on my iMac 9,1. Don't know why, I've reapplied patches maybe 10 times now.
Also it seems like the Photos app crashes on non Metal. No mention of it anywhere in the known issues but it has been the case with two non metal macs I've tried.
Look at post 2035 on page 82 and posts 2052 & 2057 on page 83. Don’t know if it will work, but give it a try and please tell us all the results. Jim
 
It seems that the current OCLP 1.1.0 nightly build does not update the patcher app in /Library/Application Support/Dortania/ during installation. It remains with version 1.0.1 in that directory. If I delete version 1.0.1 there before installation, the new version is not installed either.
 
It seems that the current OCLP 1.1.0 nightly build does not update the patcher app in /Library/Application Support/Dortania/ during installation. It remains with version 1.0.1 in that directory. If I delete version 1.0.1 there before installation, the new version is not installed either.
I noticed that too. Just download it and copy it manually to the Dortania folder at that location (/Library/Application Support/Dortania/). Works for me. I created an alias to that app and put it in the Applications folder, just in case.
That function of the OCLP app will probably be restored in good time.
 
  • Like
Reactions: K two
It seems that the current OCLP 1.1.0 nightly build does not update the patcher app in /Library/Application Support/Dortania/ during installation. It remains with version 1.0.1 in that directory. If I delete version 1.0.1 there before installation, the new version is not installed either.
I noticed that too. Just download it and copy it manually to the Dortania folder at that location (/Library/Application Support/Dortania/). Works for me. I created an alias to that app and put it in the Applications folder, just in case.
That function of the OCLP app will probably be restored in good time.

How are you updating the OCLP app? Just downloading it and dragging the icon to /Applications will not install it to the Application Support folder. The auto updater will though.
 
IIRC, the OCLP-Patcher app is moved to /Library/Application Support/Dortania (and an alias created for it in /Applications) only after doing a root patch (or with autoupdate).
 
Last edited:
How are you updating the OCLP app? Just downloading it and dragging the icon to /Applications will not install it to the Application Support folder. The auto updater will though.
There is a difference between updating the app itself, and updating the installed OCLP.
Of course, "Just downloading it and dragging the icon to (the) /Applications (folder) is not enough.
As I posted above, you just have to download the app, and copy it or move it to the location coasterOneEightThree posted "/Library/Application Support/Dortania". That updates the app itself, and then in order to update the "install" you have to run the app and choose the Build and Install option.
As you mentioned, the auto updater will update the app in that location and offer the user the chance to run the Build and Install option within the app. However, the auto updater will not always show up. I do not know why but on my iMac, it catches updates about 30% of the time, maybe a little more. Doing the manual download and copy plus running the Build and install is somewhat troublesome and takes time, but it is sure.
 
  • Like
Reactions: K two and olad
Look at post 2035 on page 82 and posts 2052 & 2057 on page 83. Don’t know if it will work, but give it a try and please tell us all the results. Jim
Thank you very much for pointing that out, it did the trick for me :)
I don't know why this doesn't get mentioned anywhere in the OCLP documentation when this is such a common issue
 
I just wanted to add a comment stating that I haven't had any issues with the patcher updating.
Typically I follow these steps, and things usually work as expected:

1. Download nightly, or public build (if not auto-updating from within the app)
2. extract application
3. move application to desktop
4. update the bootloader / reboot
5. apply root patches from within the new app. The app is copied to the Applications support location during root patching.

Then I just remove the app on the desktop, and call it a day and go on.

The only issue I've encountered with any nightly was, it not creating the alias, but the application itself was copied as it should be. Example was with the 0.6.9 nightly builds, it didn't create the alias in Applications, however when 1.0.0 came out, it took care of that problem.
 
  • Like
Reactions: olad
I understand, but it seems all known issues (sometimes specific to a limited number of hardware) are not listed.
How to raise issues and be sure OCLP team has logged them ?
First, it's painful to have an ongoing problem list, but at the end, it's less support to end user (at least for the user who are able to read :D )
Support on Discord is really a strange idea, and when you post something, it's immediately hidden by the big amount of users who are not able to read the base documentation.
Support here seems to be a strange idea, too:

- most active users tend to install beta versions of macOS and OCLP (both not supported by the OCLP team for obvious reasons)
- no new user or casual user is used to search or retrieve for information, instead they usually drop another question and the end of this thread and ignore the answer just given minutes before (happens every day here, too)
- support on Discord or here is a community effort, not a developer duty
- here and there most people obviously do not know how GitHub works

The bluetooth solution is an administrative task, not a software issue.

Opening the issues would only end in a new flood of help requests and of duplicates of already known issues and new ETA questions, very popular!

You can spend some of your time and scroll through the first 1000 issues to confirm this suspicion. All this is not ideal, but with only a few people working actively on the project and the common inability of the public to use public resources there is no other way.
 
Support here seems to be a strange idea, too:

- most active users tend to install beta versions of macOS and OCLP (both not supported by the OCLP team for obvious reasons)
- no new user or casual user is used to search or retrieve for information, instead they usually drop another question and the end of this thread and ignore the answer just given minutes before (happens every day here, too)
- support on Discord or here is a community effort, not a developer duty
- here and there most people obviously do not know how GitHub works

The bluetooth solution is an administrative task, not a software issue.

Opening the issues would only end in a new flood of help requests and of duplicates of already known issues and new ETA questions, very popular!

You can spend some of your time and scroll through the first 1000 issues to confirm this suspicion. All this is not ideal, but with only a few people working actively on the project and the common inability of the public to use public resources there is no other way.
I understand your concerns, but how to raise issues and/or have a updated issue list ?
Don't mix all the problems, we all know that some people don't read, are not skilled enough for OCLP, use beta without any reason, ask question without making a 30s research ...
The world could be better, obviously ...
But ... having a limitation list available somewhere is not "spamming" the developers.
How many people are asking 10 times the same question for very well known limitations (but not documented on OCLP site/documentation) ?
 
tldr:
This is familiar basic stuff and I am sure we can all do better.

Just a brief and possibly misguided attempt at peacekeeping.
I am an old guy who has been doing computers and forums for a long time and OCLP for as long as it has been public knowledge. The gradual recent influx of people asking the same questions is familiar and understandable due to the excellent functional quality of OCLP. The lack of reciprocity in some of this influx is of course also typical and indicative of internet forums such as this one, as well as society as a whole. No surprises there.

It should of course be possible in this space to respect the devs who has made this possible, the process they have chosen to set up including the docs as "The World is run by the people who show up", as someone famously said.
At the same time also show respect to other fellow users on the forum and act in a sensible fashion with common internet forum courtesy. The reactions from some of the devs might be lacking in diplomacy at times but that is also understandable , given the Open Source nature of the project and the obvious lack of resources to answer the same questions again and again to hundreds or thousands of users that don't take the time to use the search function or learn basic netiquette. This is familiar basic stuff and I am sure we can all do better. Enough meta from me. Promise.
Peace.
 
At the risk of rehashing an issue mentioned much earlier by Ausdauersportler, those who are having problems with booting recovery or performing clean installs of macOS may need boot-arg -no_compat_check. During the latest revisions of RestrictEvents.kext, I was doing experiments where I had removed this boot-arg. OCLP 1.0.1 generates an OC EFI for my MBP6,2 that does not include this boot-arg, so depending on your SMBIOS, you may need to add this yourself.

Release notes for RestrictEvents.kext 1.1.3
Screenshot 2023-10-18 at 9.12.48 AM.png


EDIT: I have stopped testing with OCLP 1.0.1 and I have stopped testing nightly OCLP builds. This is my personal preference and just sharing my opinion, but the rate at which Devs are making changes in preparation for the next release makes OCLP beta-build testing (for me) unproductive. I'm waiting for the next OCLP release before continuing further OCLP testing. This is not a criticism - it's the nature of software development. We're driving a car while the Devs are still building the engine. The fact that this process works as well as it does is amazing. The OCLP Devs' mastery of configuration management is a pleasure to behold.
 
Last edited:
Welcome. Look at posts 2024, 2052 and 2057. I have a 2009 21.5" iMac 10.1 and also lost my bluetooth. Right now that iMac is in VA, while I'm in FL, so I haven't had the opportunity to try the hack explained in the above posts. Please pass on if it works. Cheers, Jim
Thanks for your help my friend.
Just now i tried the tool that you mentioned and now my bluetooth works just fine.
 
Hey all, I was hoping to get the attention of the moderator, who removed one or more of my posts for bickering, I was curious as to why my posts were removed for this reason? If that was based on this morning's posts, I was trying to calm down two other people who were going at it. I wasn't fighting about anything. I'm posting here because I don't know who to message to ask about this. A name wasn't given on the post removals.
 
gtg 14.1RC running on imac17,1 and macbookpro12,1 both using oclp 1.1.0 built from source
 

Attachments

  • Screenshot_2023-10-17_at_4.26.00_PM.png
    Screenshot_2023-10-17_at_4.26.00_PM.png
    171 KB · Views: 76
  • Screenshot_2023-10-17_at_4.25.19_PM.png
    Screenshot_2023-10-17_at_4.25.19_PM.png
    195.3 KB · Views: 65
  • Like
Reactions: Lgga74
As I mentioned before, I'm waiting for the official release of OCLP 1.1.0 before further testing. However, when building OCLP 1.1.0 from source (I'm using python3.11.5 from phython.org), I found that before building the OCLP-Patcher binary, I needed to upgrade pip (pip3 install --upgrade pip) and reboot before OCLP would build successfully for me. Not sure if this is unique to my build environment (in Ventura 13.6) - just sharing in case it helps others.
 
  • Like
Reactions: perez987
Thank you very much for pointing that out, it did the trick for me :)
I don't know why this doesn't get mentioned anywhere in the OCLP documentation when this is such a common issue
You’re very welcome. We all need a little help occasionally getting through this ever changing environment. If it wasn’t for the extremely dedicated developers, I would be lost!
 
  • Like
Reactions: Heindijs
In regard to "installing Beta3 via OTA method (there is no full installer available)", If you start up OCLP 1-16-23 and choose the "Create USB Installer" function, then the "Download macOS installer" and put a tick on the "Older versions and Betas" you will see the "macOS Sonoma Beta 3 23B5067a" there. Just follow the prompts!
Thank you for the tip.
I did use the OCLP to download the (then) latest Sonoma Beta3, following your suggestion. The OCLP automatically extracted installer to Application folder but, on reboot back to thumb drive created by OCLP, the recovery window "asked" 'which volume did I want to recover'? Unfortunately, the volume I created on internal SSD for Sonoma installation did not appear as one of the choices. I booted back into Ventura installation (where Sonoma installer was extracted) and double clicked the Installer icon. The process started without isssues, and the volume I created for Sonoma was available as an installation target. Thereafter installation proceeded as it would on Sonoma compatible machine. I reapplied OCLP to main drive and followed with patching process. Booted MAcBook Pro 5,2 to the desktop without issues.
 
Hello RogueB,

thank you for the report. Useful for me as our machines are very similar (maybe not completely, since I have installed an APFS-related firmware change once provided by dosdude1).
I have four remarks:

I need the hub-connected external keyboard and mouse since longer (since Ventura actually) when booting a USB installer. When doing an OTA update of MacOS, I need it only later when the login screen first appears, probably because no input is required before that.

I remember your report from Monterey OTA upgrade. I think I had something similar with Sonoma. It seems installation from USB can do less harm than OTA.

However recovery was easier in my case. If it is mainly the EFI which is bad, could you generate a new one (maybe on a separate USB medium) on a different machine selecting the proper target machine in OCLP settings? Worth a try, though in my case more things were corrupted. But it happened only once, the other OTA updates went well.

Indeed as davidlv says, 14.1b3 is available in OCLP, and also via gibMacOS. I'll make a USB installer from it as an up-to-date fallback point.
Hello hvds,

Thank you for feedback, I appreciate the background information for the MacBook Pro 5,2.
You are correct that I do not have the dosdude1's APFS firmware patch applied to my current logic board.
I did apply the firmware patch when Catalina came out, having looked at appropriate chip for the data necessary to choose correct firmware variant. It worked perfectly, but some time thereafter the Nvidia GPU failed due to solder
weakness (a common problem with that GPU chip). I replaced logic board (relatively cheaply via eBay purchase), and "resurrected" the MBP 5,2. However, given the amount of labor I had to go through to replace logic board twice, due to refurbishing problems, I did not want to risk bricking the machine should wrong firmware patch be applied.
It may have been much easier if the patch was applied and APFS formatted drives were accessible via Catalina's finder.

I do apply most of the updates OTA, and that may have been the reason I only needed the external USB hub for login procedure(?) When I did try to boot through the USB thumb drive, the external hub solution was required to reach recovery partition.

Suggestion to create an EFI on another machine while targeting MBP 5,2 is a really good one, and I actually did that using Samsung Shield T7 USB drive, but I couldn't boot via said drive. There was also no bootable drive visible within the internal SSD listings. The last option was to reinstall Catalina via existing USB Thumb Drive, and then use that OS to replace OCLP EFI, and follow with patching. That procedure worked rather well for second time (similar experience in Monterey) and I recovered all drives and data.

For Sonoma beta3 update I used OCLP to download the beta3 and then create USB installer (thanks for the tip). When I booted into the USB installer drive, and then recovery partition, I could not find the newly created Sonoma volume on the internal SSD listing; Ventura, Monterey and Catalina volumes were made available as targets. To rectify the problem I booted into Ventura volume, where OCLP extracted the Sonoma Beta3 installer, and "double clicked" on the icon. Installer launched and everything proceeded as if the OS was on Sonoma compatible machine. Post install I applied patches, and had full functionality available (within known hardware constrictions). Photos app. does crash.

Finally, I installed Sonoma RC1 OTA on the MBP 5,2; there were no apparent problems, and patching process went well. Photos app. still crashes. I did note that VTDecoderXPCService was active, significantly loading the CPU, and triggering fans. Based on Activity Monitor record and logs it appeared to be related to the Sonoma's wallpaper motion. I changed wallpaper to Big Sur (dynamic) and both, VTDecoderXPCService and high CPU loads stopped.
The machine is mainly a Test Bed, but it is regularly, if occasionally, used for productive endeavors.

An OTA update to Sonoma RC1 on the iMac 13,2 went without incidents.

Hope this may be of help.
 
Last edited:
  • Like
Reactions: hvds
Yes, very well, the T1 is now running for me again with 1.1.0n.

Now the only problem I have is that if the Macbook has been in standby for a longer period of time and I open it, it's as if it was switched off.

It just doesn't work for me anymore. Does anyone here know what this could be?

Macbook Pro 13,2
I also have this on a MacBookPro14,2 – every morning when I open the lid.

I had a look in the console. There I found diagnostic reports of the past three days.

The first two lines read in each case:

Code:
Sleep Wake failure in EFI

Failure code:: 0x0171260e 0x0000001f

macOS 14.1 (23B73), OCLP 1.1.0n
 
Yes, I haven't been able to fix it in any way yet. I'm currently trying sudo pmset -a hibernatemode 0 and tomorrow I'll try 25 because of the battery. But neither is as great as 3, but I have no idea why that is.
 
Found a similar
Yes, I haven't been able to fix it in any way yet. I'm currently trying sudo pmset -a hibernatemode 0 and tomorrow I'll try 25 because of the battery. But neither is as great as 3, but I have no idea why that is.
In a thread (not OCLP related) at the Apple Support Community a similar case was mentioned. Supposedly, this could be fixed with an SMC and NVRAM reset. I will continue to monitor this ...
 
I did an NVRAM reset and will see if it helps

EDIT: However, I don't have a Sleep Wake failure in EFI in the console
Crash reports
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.