macOS 14 Sonoma on Unsupported Macs Thread

[Sven G]

It looks like the devs have acknowledged that paravirtualized graphics didn’t work with the previous fix (at least on some machines):

Remove ParavirtualizedGraphics.framework downgrade · dortania/OpenCore-Legacy-Patcher@331d5c7

Determined to be ineffective for 3802-based GPUs

github.com

Let’s hope that a solution can be found, in order to be able to run macOS VMs with full acceleration, at least in Parallels (and possibly also Fusion, which however sadly seems to be deprecating macOS guest support)…

 

[Sven G]

Has anyone experienced the apparently random glitch that, after some time, right-clicking on a file/folder in the Finder doesn’t work anymore and seems to relaunch the Finder…? Maybe Bluetooth-related (Magic Mouse)…? Who knows…

 

[marcinsf]

I've had that happen on Ventura a few times.
Usually, I have to click on something else or toggle to another window and then back to finder.
On one occassion, I had to relaunch finder.

 

[davidlv]

Hello.
I installed Sonoma with OpenCore Legacy Patcher. Trying to update to 14.1 beta it got stuck during installation and after forced restart it kept doing that. So I loaded recovery and restored from Time Machine. Now after Apple logo I have Bootkicker.efi, OpenShell.efi and Reset NVRAM options. Unable to boot.
How to get rid of OCLP?

You do have a bootable USB Sonoma Installer disk don't you? Use that to boot and try reinstalling the OS..
BTW, did you install Open Core apart from OCLP? The "Bootkicker.efi, OpenShell.efi" are associated with Open Core, not OCLP.
So your question may be "How to get rid of Open Core?"
The normal way to get rid of OCLP is to initialize the whole disk. But of course that will wipe your data too.
You can try downloading MountEFI, a utility found on Github, use it to mount the EFI partition and erase the contents. Of course to do that you have to get the machine booted up. Do you have an external bootable SSD disk?
I have never tried using MountEFI while booted from an external disk, but it may still work. That is a ? mark there.

 

[marcinsf]

easiest way to get rid of anything on the disk is to format it. You'll need to boot off of something to do that though.
As for getting rid of something from OpenCore, simply format the EFI partition. The rest of the partitions are data (what the user sees). To format the EFI partition I would suggest having something you can boot from although having experienced it myself that can be a chicken and egg proposition (can't make a bootable disk/usb because my machine won't boot to begin with).

I had this happen on another machine that the OpenCore got screwed up and a corrupted EFI. I couldn't format the disk because the only operating system I could boot from was too old. I had to restore the maching back a few OS's, format the disk and then upgrade again with OpenCore. This time the EFI partition wasn't corrupted so it went smoothly.

 

[coasterOneEightThree]

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:

Sleep Wake failure in EFI

Failure code:: 0x0171260e 0x0000001f

macOS 14.1 (23B73), OCLP 1.1.0n

Good news?

Anyway, something has changed here in the behavior regarding hibernation of the MacBookPro14,2 (macOS 14.1 (23B73), OCLP 1.1.0n) when I open the lid in the morning - no crash, no powering on. The keyboard light turns on and shortly after that my Apple Watch unlocks the screen. Great!

What I did last:

I installed the latest OCLP nightly build last night. Of course, I can't judge if anything has been changed in it in this context.

I then deleted the sleep image in the /private/var/vm/ directory in the Finder and not in Terminal. To see these directories and this file in the Finder, press command-shift-. (point). To undo this later, press this shortcut again.

The sleep image (about one GB in size) I could easily put into the trash after entering the administrator password and delete it. After a reboot there was a new image of the same size.

When I closed the computer last night, I had closed the running applications before.

Next time I will leave some applications open again and then test the computer the next morning to see how it behaves. I stay tuned ...

 

[AeroZ]

You do have a bootable USB Sonoma Installer disk don't you? Use that to boot and try reinstalling the OS..
BTW, did you install Open Core apart from OCLP? The "Bootkicker.efi, OpenShell.efi" are associated with Open Core, not OCLP.
So your question may be "How to get rid of Open Core?"
The normal way to get rid of OCLP is to initialize the whole disk. But of course that will wipe your data too.
You can try downloading MountEFI, a utility found on Github, use it to mount the EFI partition and erase the contents. Of course to do that you have to get the machine booted up. Do you have an external bootable SSD disk?
I have never tried using MountEFI while booted from an external disk, but it may still work. That is a ? mark there.

Fortunately I still had the USB installer and I re-installed from there and then migrated my data from time machine backup. Wonder what went wrong with updating to 14.1 that it got stuck.

 

[davidlv]

Fortunately I still had the USB installer and I re-installed from there and then migrated my data from time machine backup. Wonder what went wrong with updating to 14.1 that it got stuck.

I had two installs using a prior 1.1n version of OCLP go bad, then using the Oct. 16th version, Sonoma 14.1 installed easily. Your case may have been related to the OCLP version, difficult to say for sure. The latest OCLP 1.1 nightly works well. However, it is probably better to wait for the release of the official version of Sonoma 14.1 and OCLP 1.1.

 

[MacinMan]

It looks like the devs have acknowledged that paravirtualized graphics didn’t work with the previous fix (at least on some machines):

Remove ParavirtualizedGraphics.framework downgrade · dortania/OpenCore-Legacy-Patcher@331d5c7

Determined to be ineffective for 3802-based GPUs

github.com

Let’s hope that a solution can be found, in order to be able to run macOS VMs with full acceleration, at least in Parallels (and possibly also Fusion, which however sadly seems to be deprecating macOS guest support)…

From someone who has been testing 3D acceleration on (Supported) hardware / software, you're better off running macOS on bare metal anyway. It runs well enough but you're still limited with what will run. For example, Apple Compressor won't run in a VM. It gives a message on startup clearing stating it's not supported. In fact, before they fixed it, in the root patches, compressor wouldn't run with open core either because it thought it was in a VM.

I haven't tested a macOS guest in Fusion 13.5 yet, so don't know how it performs, so going on experience with 13.0.2 here. The other thing is, 3D acceleration is only supported as of Big Sur and later host / guest on both platforms, VMWare, and Parallels, which makes it pointless for me, I would want the support in an older version such as Mojave, so old 32-bit games would run. i still have that option with a Windows VM, or even Linux, and that I can report both work well in fusion 13.5.

I was going to consider buying Parallels after trying it, but after looking at their site for pricing, they only offer standard with a one time payment option, Pro is subscription only, and I'm not into the subscription thing for a program like that.

Plus, I went with VMware over PD way back because I had issues with the PD demo, where Fusion was fine, and VMware products are cross platform, where Parallels is Mac only, and I don't like using platform specific things anymore, unless there isn't a good cross platform solution for what I need.

 

[ChrisOSX]

Good news?

Anyway, something has changed here in the behavior regarding hibernation of the MacBookPro14,2 (macOS 14.1 (23B73), OCLP 1.1.0n) when I open the lid in the morning - no crash, no powering on. The keyboard light turns on and shortly after that my Apple Watch unlocks the screen. Great!

What I did last:

I installed the latest OCLP nightly build last night. Of course, I can't judge if anything has been changed in it in this context.

I then deleted the sleep image in the /private/var/vm/ directory in the Finder and not in Terminal. To see these directories and this file in the Finder, press command-shift-. (point). To undo this later, press this shortcut again.

The sleep image (about one GB in size) I could easily put into the trash after entering the administrator password and delete it. After a reboot there was a new image of the same size.

When I closed the computer last night, I had closed the running applications before.

Next time I will leave some applications open again and then test the computer the next morning to see how it behaves. I stay tuned ...

It appears that OCLP has permission protections in place as I am unable to delete the sleepimage file.

Mine is currently at 4.29GB.

Every time I mess with permissions, stuff gets goofed lol, so I'm a little cautious.

 

[deeveedee]

It appears that OCLP has permission protections in place as I am unable to delete the sleepimage file.

After you 'sudo pmset -a hibernatemode 0' and reboot, are you using 'sudo rm sleepimage' ?

Google to learn more and find discussions like this: https://discussions.apple.com/thread/1638823#:~:text=If you're pretty confident,file and empty the trash.

EDIT: The sleepimage permissions are not controlled by OCLP.

 

[rp7777]

These two URLs are your starting points:

Releases · dortania/OpenCore-Legacy-Patcher

Experience macOS just like before. Contribute to dortania/OpenCore-Legacy-Patcher development by creating an account on GitHub.

github.com

OpenCore Legacy Patcher

Experience macOS just like before

dortania.github.io

On your other Mac, get the latest OCLP, have a 16GB USB memory stick initialized to HFs+ Guid format and named Untitled.
On the iMac, Insert the formatted USB, run the OCLP app and choose 1.

Thanks for replying and the info.

To close this out:

I started the iMac in Target Disk mode (Thunderbolt) and was able to access from my MBP - cloned (CCC) the drive that appeared so I had a copy in case I trashed everything in trying to recover.

Built an OCLP installer USB with Sonoma on it for the iMac14,1 model.

Inserted USB into iMac. Started iMac holding Option Key and picked USB EFI. Then picked Install MacOS Sonoma and pointed it to the internal iMac HD.

Install proceeded - I left it after about 15 minutes (showing 20+ minutes remaining) to have dinner.

When I returned - MacOS desktop showing with OCLP msg asking if I wanted to install to internal HD (for boot). At this point I got various error msgs (Finder - Windows Service etc.) having issues etc. Things seemed to work OK though.

Selected the OCLP to install to internal and then rebooted. It started up OK but got the OCLP thing again so did it again (had the USB still connected so possibly that is why) - removed the USB and restarted and it started OK.

Everything appears OK - all settings and the user account and Mail, AppleID (iCloud) etc. all appears as before so looks like over-the-top install preserved everything.

Only weirdness is - every boot immediately after the Apple Logo and progress bar completes and the 1st desktop show - the menu bar is red with "Installer Progress" as the Active item - this (quickly - faster than I can get the mouse to the menu bar to select it (generally) is replaced by the "normal" menu bar with Finder as selected and then the menu bar begins populating with its normal startup stuff. Also - when this "Installer Progress" thing is there - the previously opened app have windows on the desktop so its not impacted those starting.

I googled this and its unclear if it is an issue or not. There are other reports with no clear reason or resolution - some seem to think things like google auto updater (my playing with that saw no changed) or possibly other launch daemon related things.

I was concerned as, when I left the machine and came back it seemed (possible) that the multiple reboots that normally happen installing may not have and the errors I saw made me wonder if somehow the install had not "completed" fully and somehow every time it is restarted it is expecting a "I'm continuing the install now" bit but its done. Could be (because I did an over-the-top install of a completed install maybe it got its brain in a twist). No idea really but I tested everything I could think of and the system appears OK so I am assuming (and hope) that this is just an anomaly.

 

[deeveedee]

@rp7777 Thanks for posting your observations - helpful to all following the OCLP development progress. It would also be helpful to include the OCLP version (or build date if you download source and built yourself).

Just curious - when you "Built an OCLP installer USB with Sonoma on it for the iMac14,1 model", did you "Build and Install Open Core" to the USB installer on the Mac that you are installing Sonoma or on another Mac? In other words, did you build on another Mac that required you to manually set "iMac14,1" or did you build on the Mac being patched (allowing OCLP to detect the Mac model)?

EDIT: Also, while you were installing macOS, were you careful to make sure that you booted with the Open Core EFI (created by OCLP when you "Build and Install Open Core") during each step of the installation and then when you booted the installed macOS? Did you then use the same version of OCLP that you used to "Build and Install Open Core" to apply post-install patches before you re-booted your new macOS?

 

[Portiere]

Successfully installed Sonoma on an empty partition of the original Apple HDD.

 

[Cuadrados]

Hello everyone.
I have installed Opencore Legacy Patcher to upgrade my Mac Pro 2013 (6.1) to Mac OS Sonoma. The installation went well, without problems. Once everything was working, I wanted to enable Universal Control so I could use a single keyboard with my iPad. I followed the setup guide: https://dortania.github.io/OpenCore-Legacy-Patcher/UNIVERSALCONTROL.html#blacklisted-models

I used the SMBIOS SPOOF option, and I chose the option in SMBIOS Spoof Level to MODERATE and in SMBIO SPOOF MODEL I chose Mac Pro 7.1. Finally I built and installed OpenCore again.

When I restart, it doesn't start Mac Os Sonoma, nor does it let me reinstall from scratch, so I would like to set the SMBIOS back to the original version for the Mac Pro 2013 (6.1), but I don't know how to do it.
How can I reset the SMBIOS to version 6.1 and make Mac OS work again?

Thank you so much!
Kind regards

 

[deeveedee]

Hello everyone.
I have installed Opencore Legacy Patcher ...

What version of OCLP?

EDIT: If I had to guess (I don't, but I will anyway), it appears that you are trying to boot your new macOS installation without the Open Core EFI that is generated by Open Core Legacy Patcher (OCLP) when you "Build and Install Open Core."

EDIT2: The SMBIOS Spoofing is controlled by the Open Core config.plist that is generated by OCLP when you "Build and Install Open Core." To eliminate the spoofing, use OCLP (on another bootable Mac) to "Build and Install Open Core" to a bootable USB thumb drive. Make sure to "Build and Install Open Core" without spoofing. Then boot your macOS with the USB thumb drive's EFI. Note that you will need to manually set your SMBIOS model if you "Build and Install Open Core" on another Mac (unless it is an identical Mac), because OCLP detects the Mac Model and will detect the model of the Mac on which you are "Building and Installing Open Core."

In the future, always have a recovery plan. Best to do your testing in a "sandbox" APFS volume while you leave your working "production" APFS volume untouched.

EDIT3: If you are testing a new Open Core EFI/config.plist, it is best to leave the working EFI on your SSD UNTOUCHED. Do your Open Core EFI testing by building to a USB thumb drive and booting from the thumb drive. Only after you have confirmed that the thumb drive's EFI works for you should you "Build and Install Open Core" to your SSD.

Many of the problems I see here are because people are building their Open Core EFI and installing an unsupported macOS without a solid recovery plan. There is no need to risk production APFS volumes and production EFIs while testing OCLP and an unsupported macOS.

 

[Cuadrados]

What version of OCLP?

EDIT: If I had to guess (I don't, but I will anyway), it appears that you are trying to boot your new macOS installation without the Open Core EFI that is generated by Open Core Legacy Patcher (OCLP) when you "Build and Install Open Core."

EDIT2: The SMBIOS Spoofing is controlled by the Open Core config.plist that is generated by OCLP when you "Build and Install Open Core." To eliminate the spoofing, use OCLP (on another bootable Mac) to "Build and Install Open Core" to a bootable USB thumb drive. Make sure to "Build and Install Open Core" without spoofing. Then boot your macOS with the USB thumb drive's EFI. Note that you will need to manually set your SMBIOS model if you "Build and Install Open Core" on another Mac (unless it is an identical Mac), because OCLP detects the Mac Model and will detect the model of the Mac on which you are "Building and Installing Open Core."

In the future, always have a recovery plan. Best to do your testing in a "sandbox" APFS volume while you leave your working "production" APFS volume untouched.

EDIT3: If you are testing a new Open Core EFI/config.plist, it is best to leave the working EFI on your SSD UNTOUCHED. Do your Open Core EFI testing by building to a USB thumb drive and booting from the thumb drive. Only after you have confirmed that the thumb drive's EFI works for you should you "Build and Install Open Core" to your SSD.

Many of the problems I see here are because people are building their Open Core EFI and installing an unsupported macOS without a solid recovery plan. There is no need to risk production APFS volumes and production EFIs while testing OCLP and an unsupported macOS.

Well, it seems I have been able to solve it. I recreated a Macpro 6.1 USB from a Macbook Air with the OpenCore installer and booted from the USB again. Then reinstall OpenCore on the internal SSD. I followed these instructions, in case this solution can help someone:

General troubleshooting | OpenCore Legacy Patcher

Stuck on This version of Mac OS X is not supported on this platform or (🚫) Prohibited Symbol​

This means macOS has detected an SMBIOS it does not support. To resolve this, ensure you're booting OpenCore before the macOS installer in the boot picker. Reminder that the option will be called EFI Boot.


Once you've booted OpenCore at least once, your hardware should now auto-boot it until either an NVRAM reset occurs, or you remove the drive with OpenCore installed.


However, if the 🚫 Symbol only appears after the boot process has already started (the bootscreen appears/verbose boot starts), it could mean that your USB drive has failed to pass macOS' integrity checks. To resolve this, create a new installer using a different USB drive (preferably of a different model.)

The version I have been using of Opencore Legacy Patcher is 1.0.1.

Thank you so much Deeveedee!

All the best

 

[MacinMan]

Well, today I had to replace the UPS on the iMac. It was a little over 3 years old, and initially I had no way to know if it was just a bad battery, or a combination. It decided to just shut the computer off cold turkey randomly and doing a self test did the same thing. So replaced it with a whole new unit to make sure. Talk about saving an older Mac.

Thankfully the other one may just be a dead battery, but I have a new unit so I can take my time with that one now.

Point of the story is, I caught this in time, OCLP can't help a fried Mac.

 

[TheShortTimer]

I've used OCLP to install Somona on my 13" mid-2012 MacBook Pro (8GB RAM, 500GB SSD) and I'm having major problems with sleep issues. The computer will freeze after resuming from several hours of sleep with either a black screen or the log-in screen and it won't respond to keypresses and there's no activity from the lights on USB sticks which suggests that the OS has completely locked up.

A cold boot is the only remedy - till it reoccurs at some point during another prolonged sleep. Resetting the SMC and NVRAM doesn't appear to have made a difference. I'm not sure what to try next beyond reverting to an earlier macOS version. Does anyone have suggestions?

 

[marcinsf]

Yep, I had OCLP Ventura on my MB Pro late 2016 and saw the update in software manager, I naively clicked on it to get Sonoma thinking it would download and give me the opportunity to install or not.
Well, it did no such thing. It immediately shutdown my MB Pro and started installing. I couldn't stop it.
I tried a little to run with it but the OCLP site says it's way buggy with lots of glitchy stuff so far. It was, my wifi and bluetooth and touch bar stopped working.
Luckily, I had a time machine backup so rebooted from OCLP and restored from my time machine backup which took about 20 hours (network backup and over 1 TB of disk use).
I'm not going to Sonoma anytime soon. The guys at the OCLP project still don't feel confident about their patches for most of us - especially those of us with touchbar Macs!

So, if I were you, I'd go back to Ventura. It's pretty stable and haven't had any major issues.

 

[TheShortTimer]

Yep, I had OCLP Ventura on my MB Pro late 2016 and saw the update in software manager, I naively clicked on it to get Sonoma thinking it would download and give me the opportunity to install or not.
Well, it did no such thing. It immediately shutdown my MB Pro and started installing. I couldn't stop it.

Thanks for replying.

I tried a little to run with it but the OCLP site says it's way buggy with lots of glitchy stuff so far. It was, my wifi and bluetooth and touch bar stopped working.

Unfortunately I didn't check this beforehand.

Luckily, I had a time machine backup so rebooted from OCLP and restored from my time machine backup which took about 20 hours (network backup and over 1 TB of disk use).
I'm not going to Sonoma anytime soon. The guys at the OCLP project still don't feel confident about their patches for most of us - especially those of us with touchbar Macs!

So, if I were you, I'd go back to Ventura. It's pretty stable and haven't had any major issues.

Previously I was using Catalina - which also has sleep issues and was hoping to escape them by leapfrogging to Sonoma. Would I have to reinstall Catalina and then use OCLP to install Ventura or can I do this from Sonoma? Thanks again.

 

[marcinsf]

You'll have to restore to Catalina and then use OCLP to install Ventura over it.
If you want to be super clean, you can use OCLP to load Ventura and then use disk utility to format your hard disk, run the Ventura install and then near the end it will ask about importing from a backup. There you'll import from your last Catalina backup. It will NOT import from Sonoma because that is newer than Ventura.

 

[TheShortTimer]

You'll have to restore to Catalina and then use OCLP to install Ventura over it.
If you want to be super clean, you can use OCLP to load Ventura and then use disk utility to format your hard disk, run the Ventura install and then near the end it will ask about importing from a backup. There you'll import from your last Catalina backup. It will NOT import from Sonoma because that is newer than Ventura.

Got it! Thanks so much for the clarification.

 

[rp7777]

@rp7777 Thanks for posting your observations - helpful to all following the OCLP development progress. It would also be helpful to include the OCLP version (or build date if you download source and built yourself).

Just curious - when you "Built an OCLP installer USB with Sonoma on it for the iMac14,1 model", did you "Build and Install Open Core" to the USB installer on the Mac that you are installing Sonoma or on another Mac? In other words, did you build on another Mac that required you to manually set "iMac14,1" or did you build on the Mac being patched (allowing OCLP to detect the Mac model)?

EDIT: Also, while you were installing macOS, were you careful to make sure that you booted with the Open Core EFI (created by OCLP when you "Build and Install Open Core") during each step of the installation and then when you booted the installed macOS? Did you then use the same version of OCLP that you used to "Build and Install Open Core" to apply post-install patches before you re-booted your new macOS?

To answer your questions:

I download OCLP to my 2012 MBP (running OCLP/Ventura). Version I downloaded was 1.0.1. Version my MBP was built with/running was 0.4.x (do not remember exactly).

I fired up OCLP Patcher (1.0.1) on the MBP and manually selected "iMac14,1" for the model I was building for. Downloaded the Sonoma installer and built the USB installer (for iMac14,1 as mentioned).

Could not build on the iMac itself - could not get it to boot - stopped halfway progress bar.

Did attempt Option key on iMac - then select the USB EFI (with 1.0.1 iMac14,1) and then selecting the internal HD to boot Sonoma but that also stopped halfway progress bar (with mouse pointer disappearing then reappearing regularly but no progress).

So to install (over the top) I:

1) Inserted USB built on MBP - OCLP 1.0.1 EFI and Sonoma installer) into iMac
2) Started iMac holding Option key
3) Presented with 3 option on boot screen:
1) iMac Disk OCLP EFI (0.4.x) - OCLP I had originally installed when installing Ventura
2) MacHD (Sonoma icon)
3) USB EFI - with OCLP 1.0.1 I had just built on MBP
4) Selected 3) - USB EFI
5) Boot screen changed to 2 options (I think from memory)
1) Internal MacHD (Sonoma icon)
2) USB - Sonoma Installer
6) Selected 2 - USB - Sonoma Installer
7) Install began
8) Presented with "usual" install desktop (where you get options to run Disk Utility etc. and selected Instal Sonoma - selecting the internal iMac HD to install to (apologies - don't remember the exact presentation/sequence here).
9) Install began
10) At some point it went to black screen with progress bar and "28 minutes" or similar message.
11) At around 20 minutes left (i.e. same progress screen - time left gone from 28 minutes previous to 20 minutes) I left office to have dinner
12) When I returned (I think about 30 minutes or so later) - it was sitting at the desktop and appeared to be finished (and OCLP popup saying something like "we see you have booted from USB - do you want to install OCLP to internal disk"
13) I chose yes and OCLP then went through it's normal thing to install EFI to internal drive (don't remember the exact process/sequence).
14) When OCLP done I got the "please reboot" thing which I did.

As I mentioned I did get some errors about Windows Service, Finder and one or two other things appear but cannot recall exactly where/when in the sequence.
15) After reboot I think OCLP popped up again and same msg so I did again and rebooted.
16) After that - Sonoma boots and appears to be working. Has been running for a day+ now and Mail, Safari, everything I can think to try appears to be working and nothing obvious in Console Log (although I believe Sonoma logging is light on) so I am assuming it is OK.

Only anomaly I can see (as mentioned) is this "Installer Progress" in Menu bar when booting that quickly disappears.

I was expecting the multiple reboots and having to select the Open Core USB but that does not seems to have happened? (or I missed while at dinner and it defaulted to ????).

Also - went to run Root patches but OCLP said already applied.

 

[deeveedee]

I was expecting the multiple reboots and having to select the Open Core USB but that does not seems to have happened? (or I missed while at dinner and it defaulted to ????).

Also - went to run Root patches but OCLP said already applied.

Excellent summary - thank you! It is important to make sure that the Open Core EFI is used to boot each step of the installation (when installer reboots) and when booting the installed, unsupported macOS.

If you are able, you might want to try a clean macOS install to a new APFS volume (add the APFS volume to your existing APFS container). Sometimes, problems resulting from macOS upgrades or re-installs over an existing macOS can be resolved with clean installations. You can use MA to migrate date/apps/settings from your other macOS volume before you apply post-install patches to the new volume.

Nice work.

EDIT: If you try the new macOS installation in a new APFS volume, "Build and Install Open Core" on the target Mac so that OCLP can auto-detect SMBIOS and configure itself.