I see the process on my MBP6,2, but it stays at 0%.
EDIT: Google may be your friend. Search and you'll find advice (possibly old, but maybe still relevant) like this.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 14 Sonoma on Unsupported Macs Thread
- Thread starter dhinakg
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
EDIT: Google may be your friend. Search and you'll find advice (possibly old, but maybe still relevant) like this.
MBP5,2: OTA installed 14.0 RC (23A339) over beta7 on external SSD, using latest sonoma-branch of OCLP (last commit "fix non-metal PhotoBooth"). New in this version is the use of patcher support package 1.2.9 and some preferences settings.
I'm not a PhotoBooth user and didn't test it.
One thing I don't get to work at present is "show desktop", which used to be the "right option key" shortcut. Enabling an active edge for it has no effect either. Don't remember if it worked with b7 or earlier OCLP. - Not important anyway.
Enjoying good graphics performance, working WLAN, working sleep/wake etc etc ... Thanks developers!
EDIT: reverting root patches brings back the "show desktop" functionality. Other tries (using previous PSP 1.2.8, and changing latest preference settings made by the patcher) had no effect.
Attachments
Last edited:
Thanks for the suggestion. It's the RC though.Try the RC
However I found the culprit. I ran: sudo fs_usage and found that it was constantly accessing some callhistory data base within ~/Library/Application\ Support/
Deleting that one and rebooting did solve the issue. Seemingly the db did not survive the update.
Does the Radeon Pro resume after sleep? have you tried to use an external display?
Where can I see current issues with the RC? Specifically for MacBookPro9,x. Mine is running Big Sur and I'd like to know if Sonoma would be a suitable version yet or if I should put it on Monterey or Ventura for now.
Had a similar issue with no data populating the weather widget on a supported Mac mini 2018. I added my zip code to the weather app which I had not been using up until then, being a loyal weather underground fan; in fact I had deleted the Apple weather app a while ago.
I selected the new location, and dragged it to the top of the list in the weather app's left list. Data started appearing in the weather widget. Hope this helps.
Last edited:
I haven't tried putting the MacBook to sleep and waking it up and I haven't tried another display
ok I'll try... I think it's the correct solution.... in other situations, in the past, I had actually updated the weather app with my postal code and other places
Same impression on the iMac 15,1 with 24GB RAM and running the RC on an older Apple 128GB blade (former Fusion drive). Getting to the root patching menu was rocky, poor mouse and keyboard response, but a wired keyboard and mouse sorta worked. After the root patches (Sonoma branch 9-12-2023) the iMac feels good, not blazingly fast but no obvious lagging either. Very similar to Ventura. The OCLP devs certainly know their stuff!Very difficult to discern between supported and unsupported performance w/ OCLP069n hack in Sonoma RC.
View attachment 2260812
I tried to put the MacBook with Radeon Pro 560 to sleep, then wake it up... the screen remains practically black, you can see something underneath, very very little, but it remains almost totally black, even by raising the brightness... restart required
OCLP 0.6.9 sonoma-development commit cf7a553 fixed PhotoBooth on the MBP6,2 (non-metal NVidia Tesla). Well done, Devs!
EDIT: @amaze1499 Looks like Maps has issues on MBP6,2 (non-metal NVidia Tesla)
EDIT2: @amaze1499 Maps does not work for non-metal Macs. According to this, Maps requires metal and the solution is to revert to Big Sur on non-metal. I have confirmed that on MBP6,2, Maps does not work on Monterey, Ventura and Sonoma, but it does work in Big Sur.
EDIT: @amaze1499 Looks like Maps has issues on MBP6,2 (non-metal NVidia Tesla)
EDIT2: @amaze1499 Maps does not work for non-metal Macs. According to this, Maps requires metal and the solution is to revert to Big Sur on non-metal. I have confirmed that on MBP6,2, Maps does not work on Monterey, Ventura and Sonoma, but it does work in Big Sur.
Last edited:
Yes. Maps work for me on all the Metal-Macs in my SIG. No big demands but as far as I can tell 100%
The non-metal Macs do not work with Maps at all here. Grey screen where the maps should be. All metal.
Last edited:
Since we are at 14rc maybe time for a short recap of what does _not_ work, since most things already seem to work
The only thing I can not get to work at all on my main rMBP 10,1 that would be useful is screen mirroring to an Apple TV 4K. It connects but then I just see a black screen. Airplay works fine to same Apple TV and the other MBA:s screen mirrors just fine. Can also screen mirror from 10,1 to other Macs. Was the same on Ventura.
Also some issues with wake up screen after sleep, and the fans run a little more than I would like for normal things.
Still troubleshooting that. I suppose the greater demand on the CPU and GPU is to be expected.
Other than that great stable functionality on all my Macs. Devs rock!
The only thing I can not get to work at all on my main rMBP 10,1 that would be useful is screen mirroring to an Apple TV 4K. It connects but then I just see a black screen. Airplay works fine to same Apple TV and the other MBA:s screen mirrors just fine. Can also screen mirror from 10,1 to other Macs. Was the same on Ventura.
Also some issues with wake up screen after sleep, and the fans run a little more than I would like for normal things.
Still troubleshooting that. I suppose the greater demand on the CPU and GPU is to be expected.
Other than that great stable functionality on all my Macs. Devs rock!
Last edited:
install on mid 2014 pro with broken screen just using hdmi no issues for me .
When clicking edit widgets on my mid 2014 with working screen it will stall but only when clicking edit and choosing widgets the one with the broken screen has no issues at all with edit widgets may be random or something else .
Updated: obviously now I’ve figured out if edit widgets is crashing for you the easiest thing is to use a app like Gswitch to switch to nvidia only choosing widgets will no longer crash only crashing on intel .
When clicking edit widgets on my mid 2014 with working screen it will stall but only when clicking edit and choosing widgets the one with the broken screen has no issues at all with edit widgets may be random or something else .
Updated: obviously now I’ve figured out if edit widgets is crashing for you the easiest thing is to use a app like Gswitch to switch to nvidia only choosing widgets will no longer crash only crashing on intel .
Last edited:
Well, another quick heads-up about this. My MBP 9,2 still has this issue, even with the RC. As I said before, I have workarounds so it doesn’t affect me much, but I just did something (on hindsight) very stupid.Hi all, just a quick heads-up (in case someone else experiences this issue)
UPDATE: Lazy me, hadn't checked the release notes. This looks like a possible cause:
File System
New Features
It surely has something to do with this
- The implementations of the exfat and msdos file systems on macOS have changed; these file systems are now provided by services running in user-space instead of by kernel extensions. If the application has explicit checks or support for either the exfat or msdosfile systems, validate the applications with those file systems and report any issues. (110421802)
-----------------------------------------------------------------------------------------------------------------
After OTA upgrading to 23A5312d, whenever I try to copy/move a file (either via the Finder or the terminal) to a USB-attached volume formatted with FAT32 or exFAT, the Finder hopelessly hangs. It does not crash and it does not respond to a relaunch. It just does not work anymore. The only way out is to shut down via the terminal or by holding down the power button.
If the copy/move is started via the terminal, this process hangs also and it cannot be killed (it does not even respond to a sudo kill -9), so it's a weird situation. The Finder also hangs in this situation.
This does not happen if the disk is formatted with APFS or HFS, so it seems to me to be an issue with the OS native FAT drivers. It also works fine if I copy/move the files to an NTFS formatted volume via Tuxera's driver, which seems to give more credibility to my supposition, but cannot be 100% sure.
I don't think this is an issue with OCLP... It might be a beta OS issue or just something on my end, so YMMV
I have devised a workaround for my needs so right now this is a non-issue for me, but I wanted to keep you aware in case some of you notice something similar.
I'll let you know if I find something else or if it gets sorted out on the next beta update.
The issue in a nutshell is that as soon as I mount a non-apple file system volume (FAT, FAT32, exFAT…) the Finder hangs and the OS is left in a zombie state, requiring a reboot and of course any operation you wanted to do with the mounted volume starts, but hangs and never finishes.
As I haven’t seen or heard anyone else with the same issue, I decided (very stupidly) to rebuild and reinstall OCLP using a freshly downloaded Sonoma-branch version, to see if by any chance it would improve things.
Well, OCLP built normally but as soon as I told it to install onto the disk, it mounted the EFI volume and… yes. As it’s not an apple format, the finder hung, the app deleted my “previous” efi folder and proceeded to hung right after so it never copied (it couldn’t) the new open core efi. Result: no more Sonoma boot.
The funny part is that just last week I erased all the other partitions and bootable USB sticks as “I’ve never had to use them” 😂😂. Just my luck.
Long story short, I used internet recovery to download and install Catalina on an external drive, downloaded OCLP Sonoma branch, ran it from Catalina, installed it onto my internal drive and recovered my Sonoma boot capabilities. That took a while 😂.
What worries me is that, as it stands, I won’t be able to update OCLP directly from Sonoma until I find out wtf is going on. Now I think it must be some piece of software I have installed, as I haven’t seen any of you guys having the issue, so I have a long road of sleuthing to travel.
Will report back if I find the cause. In the meantime, be aware of that so it doesn’t happen to you (and of course, I’m not deleting that Catalina install) 🤣
Now to get some sleep…
Yes, This is a problem that was caused by you. I recommend doing an installation from scratch on a new volume, if possible even erasing the internal SSD completely and starting again.
Everything works here, exFAT, FAT, FAT32, NTFS, APFS, and others.
MacBook Air 2012, macOS Sonoma 14.0 RC, OCLP 0.6.9n (upgrate to OpenCore 0.9.5).
I had to empty ~/Library/Caches/GeoServices first, in order to have Maps working as expected.
The RC is working great on my M1 Macbook Pro. There is one bug that has persisted across the betas related to Safari, open a private window, lock the device and in its locked state open a new private window, attempt to enter password or use fingerprint, freezes the laptop for sometime with a loading spinner on the cursor. After some duration, it will remain locked but this time the unlock of the private windows will work. Can anybody else test this on their device?