That was a Safari bug. Developer seed 3 deleted the passwords app again, so a delayed launch delay or a mistake. Nothing to do with 14.6 in that way.
Last edited:
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
BTW, the current Safari version for Sonoma 14.6 is 17.6: if you installed the Safari 18 beta and want to return to the stable version, just reinstall Sonoma 14.6 and Safari will be restored to 17.6…
That's great you achieved a firmware update. What is your config for the iMac? SSD or Fusion?
I was never able to update the firmware on my Late 2015 iMac 17,1. Even after Monterey was updated. The firmware is stuck at 170.0.0.0.0. Boards are full of others with this issue. It is the OEM 1tb SSD. I don't want to crack open the display and install another SSD on the I/O to update the firmware.
Has been a great Mac but now reaching end of life. Display flaws dust/ghosting issues. OCLP has kept it up and running nicely though. Thanks to the developers and super helpful MR members!
my iMac has the 2 TB Fusion drive. 2 TB HDD with 128 GB SSD. One thing to remember about the firmware updates is, you have to also reset PRAM when using a native install, so it doesn't boot with the Open core settings. In my case, I'm just waiting for Apple to be done with this Mac so I can move to Linux. Open Core works well for me, and while I've been able to change programs I use so I don't have any of the open core limitations when it comes to graphics drivers, I still have a couple programs that just don't like Sonoma as the OS, and why they run, they are glitchy. So I want to go with a platform, where if I have problems, I'm free to learn to fix them for myself, and macOS though UNIX isn't friendly to that. Since I don't need the latest version of macOS for the features I use, I'll probably dual boot Monterey and Linux for a while.
EDIT: here is a screenshot of SilentKnight and the current EFI version for the iMac 17,1.
Last edited:
Upgraded my MBP6,2 to Sonoma 14.6 via OTA without issues. Still applying Sonoma post-install patches with OCLP 1.4.3 while booting with an Open Core EFI generated with OCLP 1.5.0 (actually a hybrid 1.5.0 / 1.6.0 version that allows me to boot Sequoia). I realize that my patching strategy is different from most others, but it still works for me. 
Why do you need it ?
1.6 has nothing more for end users
Yes it works
You always have people who have problems…
Thanks. Anyway, I´ll keep waiting. There is no hurry at all.
Updated my MBP9,1 (Mid 2012 15") to 14.6 OTA, and all seems fine. No changes to note so far.
Mac Pro 6,1 updated to 14.6 with OCLP 1.5, went smoothly...
Kernel Panic - iMac 15,1 with Core Legacy Patcher
Hello,I could use some help trying to resolve this issue.
I have an iMac 15,1 2015
Hardware Overview:
Model Name: iMac
Model Identifier: iMac15,1
Retina 5K, 27-inch, Late 2014
Processor Name: Quad-Core Intel Core i7
Processor Speed: 4 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Hyper-Threading Technology: Enabled
Memory: 32 GB, 32 GB 1600 MHz DDR3
System Firmware Version: 474.0.0.0.0
OS Loader Version: 580~2215
SMC Version (system): 2.23f11
Graphics: AMD Radeon R9 M295X 4 GB
MacOS Sonoma 14.5
Open Core Legacy Patcher: v1.5.0
I have installed macOS Sonoma using Open Core Legacy Patcher.
Periodically (about once per day), the system will lock up and freeze and the fan will spin up. There is no sign of a crash other than the freezing of the screens and no response to any keyboard, mouse or other inputs. The only option is to hard reboot by holding the power button down.
Kernel Panic Report
View attachment 2401431
Chat GPT Analysis
The kernel panic you've encountered appears to be related to a general protection fault caused by the WindowServer process. Here's a breakdown of the key details:
- Error Type: General protection fault (type 13), which usually indicates an illegal access to memory or a violation of CPU protection mechanisms.
- Registers: The CPU registers at the time of the panic show the state of the processor. Key registers include:
- RIP (Instruction Pointer): 0xffffff800af010b4, which is the address where the fault occurred.
- RAX: 0x0000000000000010, which is a general-purpose register that might hold a pointer or value.
- Faulting Module: The backtrace indicates that the fault occurred in the com.apple.iokit.IOAcceleratorFamily2 and com.apple.kext.AMDRadeonX4000 kernel extensions. These are related to the GPU and graphics acceleration.
- Process Name: The process that caused the panic is WindowServer, which is responsible for managing the graphical user interface on macOS.
- Kernel Extensions:
- IOAcceleratorFamily2: Manages general GPU acceleration functions.
- AMDRadeonX4000: Specific to AMD Radeon graphics cards, handling GPU resource management and acceleration.
- Potential Cause:
- The panic occurred during a call to IOAccelTask::deallocate(), indicating a possible issue with memory deallocation related to GPU resources.
- The presence of the AMDRadeonX4000_AMDAccelCommandQueue and related functions in the backtrace suggests the issue might be linked to how command buffers are processed or memory is managed for GPU tasks.
Possible Solutions:
- Update Graphics Drivers: Ensure you have the latest updates for macOS, which might include fixes for GPU-related kernel extensions.
- Check for Software Updates: Ensure all applications, especially those using GPU acceleration, are updated.
- Hardware Check: If the issue persists, there might be a hardware issue with the GPU. Running Apple Diagnostics can help determine if there's a hardware fault.
- Safe Mode: Boot into Safe Mode to see if the issue persists. Safe Mode loads only essential system components and can help determine if a third-party extension is causing the issue.
Kernel Panic Report (Text)
panic(cpu 0 caller 0xffffff800b37b573): Kernel trap at 0xffffff800af010b4, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0xffffffdcc39ce000, CR3: 0x0000000842f80019, CR4: 0x00000000001626e0
RAX: 0x0000000000000010, RBX: 0xffffff94ff2944f0, RCX: 0x0000000000000188, RDX: 0x0000000000004f80
RSP: 0xffffffd8c05673b8, RBP: 0xffffffd8c05673f0, RSI: 0xffffffdcc398ca08, RDI: 0xffffffdcc398ca18
R8: 0x00000000f94fe250, R9: 0x0000000000001000, R10: 0x000000000103f966, R11: 0x0103f96600000025
R12: 0x000000041797ffff, R13: 0x0000000417980000, R14: 0x00000000000003dd, R15: 0x0000000000000e00
RFL: 0x0000000000010682, RIP: 0xffffff800af010b4, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0
Panicked task 0xffffff869b5b39d8: 14 threads: pid 166: WindowServer
Backtrace (CPU 0), panicked thread: 0xffffff94ff31fb30, Frame : Return Address
0xffffff800af0c140 : 0xffffff800b226481 mach_kernel : _handle_debugger_trap + 0x4b1
0xffffff800af0c190 : 0xffffff800b38bb10 mach_kernel : _kdp_i386_trap + 0x110
0xffffff800af0c1d0 : 0xffffff800b37b0cc mach_kernel : _kernel_trap + 0x55c
0xffffff800af0c250 : 0xffffff800b1bf971 mach_kernel : _return_from_trap + 0xc1
0xffffff800af0c270 : 0xffffff800b22676d mach_kernel : _DebuggerTrapWithState + 0x5d
0xffffff800af0c360 : 0xffffff800b225e13 mach_kernel : _panic_trap_to_debugger + 0x1e3
0xffffff800af0c3c0 : 0xffffff800b9db27b mach_kernel : _panic + 0x84
0xffffff800af0c4b0 : 0xffffff800b37b573 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffff800af0c630 : 0xffffff800b37b257 mach_kernel : _kernel_trap + 0x6e7
0xffffff800af0c6b0 : 0xffffff800b1bf971 mach_kernel : _return_from_trap + 0xc1
0xffffff800af0c6d0 : 0xffffff800af010b4
0xffffffd8c05673f0 : 0xffffff800b92bc01 mach_kernel : __ZN16IORangeAllocator10deallocateEyy + 0xd1
0xffffffd8c0567430 : 0xffffff7fa2728784 com.apple.iokit.IOAcceleratorFamily2 : __ZN11IOAccelTask10deallocateEPK16IOAccelMemoryMapy + 0x56
0xffffffd8c0567470 : 0xffffff7fa2741e7d com.apple.iokit.IOAcceleratorFamily2 : __ZN16IOAccelMemoryMap21freeGPUVirtualAddressEv + 0x4b
0xffffffd8c0567490 : 0xffffff7fa2741bb4 com.apple.iokit.IOAcceleratorFamily2 : __ZNK16IOAccelMemoryMap7releaseEv + 0x8e
0xffffffd8c05674b0 : 0xffffff7f8befcc54 com.apple.kext.AMDRadeonX4000 : __ZN37AMDRadeonX4000_AMDGraphicsAccelerator30completeBatchMemoryMapPreparesEv + 0x3a
0xffffffd8c05674d0 : 0xffffff7f8bf0f7dc com.apple.kext.AMDRadeonX4000 : __ZN31AMDRadeonX4000_AMDAccelResource12BatchPrepareEP37AMDRadeonX4000_AMDGraphicsAcceleratorPKPS_j + 0x142
0xffffffd8c0567570 : 0xffffff7fa27353c7 com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue15coalesceSegmentEP26IOAccelCommandQueueSegmentPjP26IOAccelSegmentResourceListPK20IOAccelKernelCommandS7_ + 0x5b
0xffffffd8c05675b0 : 0xffffff7fa273577b com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue20processCommandBufferEjj + 0x2e5
0xffffffd8c0567850 : 0xffffff7f8bf001e2 com.apple.kext.AMDRadeonX4000 : __ZN35AMDRadeonX4000_AMDAccelCommandQueue20processCommandBufferEjj + 0x62
0xffffffd8c0567880 : 0xffffff7fa27369a8 com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue22process_command_bufferEjj + 0x416
0xffffffd8c0567910 : 0xffffff7fa27349a2 com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue21submit_command_bufferEjjyy + 0x102
0xffffffd8c0567960 : 0xffffff7fa273479a com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue22submit_command_buffersEPK29IOAccelCommandQueueSubmitArgs + 0x308
0xffffffd8c05679b0 : 0xffffff7fa273387d com.apple.iokit.IOAcceleratorFamily2 : __ZN19IOAccelCommandQueue24s_submit_command_buffersEPS_PvP25IOExternalMethodArguments + 0x103
0xffffffd8c05679f0 : 0xffffff800b9507a6 mach_kernel : __ZN12IOUserClient18callExternalMethodEjP25IOExternalMethodArguments + 0x86
0xffffffd8c0567a20 : 0xffffff800b950b1d mach_kernel : _is_io_connect_method + 0x31d
0xffffffd8c0567b90 : 0xffffff800b33393f mach_kernel : _iokit_server_routine + 0x3aef
0xffffffd8c0567cb0 : 0xffffff800b1fe82c mach_kernel : _ipc_kmsg_send + 0x55c
0xffffffd8c0567d70 : 0xffffff800b216e24 mach_kernel : _mach_msg_overwrite_trap + 0x5a4
0xffffffd8c0567de0 : 0xffffff800b2173ef mach_kernel : _mach_msg2_trap + 0x30f
0xffffffd8c0567ee0 : 0xffffff800b35ff1b mach_kernel : _mach_call_munger64 + 0x22b
0xffffffd8c0567fa0 : 0xffffff800b1bfdd6 mach_kernel : _hndl_mach_scall64 + 0x16
Kernel Extensions in backtrace:
com.apple.iokit.IOAcceleratorFamily2(481.40.2)[D4E64BC5-BB33-38C7-A445-932573231969]@0xffffff7fa26ee000->0xffffff7fa2758fff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[F171001F-2B97-3A16-A1AB-7016244B627E]@0xffffff800c896000->0xffffff800c8cdfff
dependency: com.apple.iokit.IOGraphicsFamily(598)[79F2F7E4-E451-35E1-BF22-1EFFA4192888]@0xffffff7fa287e000->0xffffff7fa28acfff
dependency: com.apple.iokit.IOPCIFamily(2.9)[43511668-C040-3FBA-8CD6-25AD6E00FD90]@0xffffff800d551000->0xffffff800d582fff
dependency: com.apple.iokit.IOReportFamily(47)[8476E632-A5DB-34EC-A637-30C25D8C1767]@0xffffff800
Last edited:
I think it's at the beginning of this thread that the advice is that PRAM needs to be reset and the update for the supported OS - which may update the firmware - needs to be done using the Option key at start up to avoid the OCLP Booter. Have not seen any confirmation of this anywhere.
Sounds like a hibernation issue?
You could try setting this in OCLP and rebuild the EFI: advanced/hibernation work-around
Note: This may break booting from external drives.
Or experiment in your terminal with man pmset:
Code:
man pmset
Code:
sudo pmset restoredefaults
sudo pmset -a displaysleep 3
sudo pmset -a autopoweroff 0
sudo pmset -a powernap 0
sudo pmset -a standby 0
sudo pmset -a proximitywake 0
sudo pmset -a tcpkeepalive 0
sudo pmset -a hibernatemode 0
sudo pmset -a disksleep 3
sudo pmset -a sleep 5
Last edited:
I think it's at the beginning of this thread that the advice is that PRAM needs to be reset and the update for the supported OS - which may update the firmware - needs to be done using the Option key at start up to avoid the OCLP Booter. Have not seen any confirmation of this anywhere.
See original post/ firmware spoiler.
I'm trying to update a supported Monterey OS on the same disk as OCLP Sonoma; the advice on the original post is to re-set the PRAM then hold down the option key at startup. Tried this and it booted into Monterey as per my setup. Doing a menu restart with the option key down produced option including EFI. Does selecting this bypass OCLP? Trying restart again did not produce this option so it looks about 99% obvious that the incorrect info. in the original post should have indicated a menu restart (with or without using the option key after PRAM reset; probably not req'd) then selecting the EFI followed by the supported OS. It seems bizarre having to guess through this - but it's appreciated that there isn't a staff of technical writers working on OCLP documentation.
This thread will be dedicated to the discussion of running macOS 14.0 on unsupported Macs.
At the time of writing, we are waiting for Apple to send out macOS 14 Developer Beta 1. It is currently unknown whether or not Apple will release a publicly-downloadable InstallAssistant.
We will be expanding this thread with much more information as the day goes by including known issues as well as patcher support.
macOS Sonoma Compatibility
- iMac 2019 and later
- iMac19,x
- iMac20,x
- Mac Pro 2019 and later
- MacPro7,1
- iMac Pro 2017
- iMacPro1,1
- Mac Studio 2022 and later
- MacBook Air 2018 and later
- MacBookAir8,x
- MacBookAir9,1
- Mac mini 2018 and later
- Macmini8,1
- MacBook Pro 2018 and later
- MacBookPro15,X
- MacBookPro16,X
An early preview of Sonoma support is now out. Notably, it is currently Metal-only. Supported models (inclusive) for this preview are:
Please read this fully before downloading anything, or we'll be very disappointed... As usual, this is a beta operating system and a bleeding-edge patcher version. Don't try this if you're not already familiar with OCLP, don't try this if you're not willing to have to deal with any data loss, and especially don't try this if you don't know how to troubleshoot.
- MacBook8,1 - MacBook10,1 (2015 - 2017 MacBook)
- MacBookAir5,x - MacBookAir7,1 (2012 - 2017 MacBook Air)
- MacBookPro9,x - MacBookPro14,x (2012 - 2017 MacBook Pro)
- Macmini6,x - Macmini7,x (2012 - 2017 Mac mini)
- iMac11,x - iMac18,3 (2009 - 2018 iMac)
- iMac11,x and 12,x require Metal GPUs
- MacPro3,1 - MacPro6,1 (2008 - 2017 Mac Pro)
- MacPro3,1 - MacPro5,1 require Metal GPUs
- Xserve2,1 - 3,1 (2008 - 2009 Xserve)
- Requires Metal GPUs
- 2006-2007 Mac Pros, iMacs, MacBook Pros, and Mac Minis:
- MacPro1,1
- MacPro2,1
- iMac4,1
- iMac5,x
- iMac6,1
- MacBookPro1,1
- MacBookPro2,1
- MacBookPro3,1
- Macmini1,1
- Macmini2,1
- — The 2007 iMac 7,1 is compatible with Monterey if the CPU is upgraded to a Penryn-based Core 2 Duo, such as a T9300.
- 2006-2008 MacBooks:
- MacBook1,1
- MacBook2,1
- MacBook3,1
- MacBook4,1
- 2008 MacBook Air (MacBookAir 1,1)
- All PowerPC-based Macs
- All 68k-based Macs
An compilation of known new issues has been published on the OCLP Github. It might be enhanced when new beta versions hit the road and more road blocks appear ahead.
To avoid any frustration or even worse data loss please create and maintain backups on a regular basis. Before performing a major and even before doing a minor macOS update create a new backup.
Update the firmware of your Mac and keep it up to date! We do not provide support for not proper managed Macs.
Do not swim ahead of the swarm of macOS users, you have an unsupported Mac, neither Apple nor the OCLP developer team will recover your system. If you nevertheless believe installing beta software with development patchers on unsupported Macs is a great idea you will discover quickly nobody can or will help you. Follow the swarm. Observe posts and read about new problems and do not ask if is is safe - it is not!
Look up Apple support pages how to manage and create multiple parallel macOS installations using APFS volumes. Keep the latest working macOS and create test environments with new test users before messing with your single working Mac. A lot of problems are related to incompatible settings inherited in a decade of macOS updates and from incompatible third party software.
Finally:
Keep the USB installer with OC created with the OCLP app. This is an external recovery option. The internal recovery can be accessed after pressing the space bar on the OC boot picker. Do not disable this picker unless you know how to make it visible, again - by pressing ESC on boot.
Please read the official announcement on the OCLP Github page. New versions will only be announced on Github.
Please do not ask for fixes, just report issues. This is no on demand service organization.
The main task at hand is reverse engineering macOS Sonoma, not OCLP. So please stop asking questions how OLCP works. The source is open....
There is no third party software support! If your app is broken running on an unsupported macOS version you are alone. OCLP Developers will not fill the gap left by Apple and the various ISVs.
Please also keep in mind the first versions of Sonoma may have a lot of new (Apple development) bugs to be fixed in upcoming releases. There is rule of thumb: the fourth of fifth minor release will hopefully free of these bugs. So consider yourself to be an early adopter on the hunt for those nasty bugs. Sometimes it helps to compare with a fully supported system, in case you own one.
All hardware still supported with Ventura but dropped from Sonoma support will get Apple software and firmware updates until late summer 2025. To apply those (valuable and often necessary firmware) updates you need to install and update Ventura on your system. All firmware upgrades are bundled into the supported macOS Ventura updates, only. Sonoma will not provide those firmware updates, since your Mac is not supported by Apple with Sonoma!
The most easy way to achieve this is having an APFS container (aka volume) in parallel with your new Sonoma installation. No user data needs to be copied in there. Just boot Monterey when you get an Monterey update notification and apply this update.
Note that when booting a supported OS to get firmware updates it must not be booted via OpenCore. Do a PRAM reset on power on and press alt/option to boot directly without OpenCore back into Ventura.
Note 2. A PRAM re-set may result in the Option key having no effect when starting. A menu restart with the option key held may produce some options and my guess is that the EFI one should be selected to bypass the OCLP.
You may drop (delete) this basic Ventura installation after Apple stopped delivering new updates in autumn 2025. You will not get new firmware releases.
(If you read this section after 2025 just prepare your unsupported system by installing once the latest Ventura version released by Apple including all updates to get the latest firmware update installed. You may drop this Ventura installation after this procedure.)
Another method to update the firmware has been described on this site. It requires some system admin technical skills.
You need to maintain a Ventura installation if there will be any T1 updates until end of 2025. If you wipe the complete disc including the EFI before updating to Sonoma you also delete the T1 firmware image. This will likely disable the T1 functionality on Sonoma. So please check the EFI partition and the Apple subfolder and preserve the contents. This T1 image will only be re-installed when installing Ventura or another Apple supported macOS!
Bad news:
TM (time machine) restoring and MA (migration assistant) is broken on root patched systems. Do not try, system will only arrive in an unbootable and uncorrectable state after hours of restoring or transferring data.
There are two ways around this:
1. Use the OCLP USB installer and install Sonoma on top of your current (supported or unsupported) macOS. This will retain your current user data. But create a final TM backup before leaving your supported macOS installation, it will be the only return ticket.
2. Simply use MA or TM before system has been root patched by the OCLP app. This is sometimes difficult to achieve when auto-patching ran before you even reached the login page. You can prevent auto-patching by creating an USB installer manually (createinstallmedia and install OpenCore manually). You can revert patches, too.
After many requests, we've finally opened up a way for people to make monetary contributions to OCLP's development, using Open Collective: https://opencollective.com/opencore-legacy-patcher If you appreciate what we do, please considering donating! Your support will help us purchase needed hardware to improve the project.
Thanks!
Over the years Apple introduced a lot of new software features relying on new hardware. Sometimes because of execution speed and latency induced by older hardware, sometimes because it is really needing new features like WiFi ac, Bluetooth 4.0, 4k HEVC and 4K H.264 support. Another serious threat is the use of modern AVX2 Intel CPU instructions available only on Late 2013 and newer Mac hardware. The Metal rendering framework is in the middle between this, but without any documentation one would have to write device drivers for other GPUs to achieve support. This is beyond this project.
So a lot of features like AirDrop, Universal Control need BT4.0 and WiFi ac, modern Apple and third party apps using the metal framework, recent Adobe software using AVX2 with Ventura+ will simple break your Mac in a way OCLP cannot ever fix it. Even if installing and booting of a recent macOS works fine some or a lot of apps will not work properly.
We had this clearly defined Metal boarder which puts all no upgradable hardware released until late 2011 into the big non-metal camp. Now we have a 2nd group of 2012-2013 Macs including the MacPro6,1, Metal GPU upgraded MacPro3,1-4,1-5,1 and iMac10,1-12.2 all lacking of AVX2 support and a third group of legacy metal system from late 2013-2015 either with AMD GCN 1-3 and Nvidia Kepler dGPU, Intel HD4000 and Haswell iGPU with different and difficult to address issues.
The most compatible unsupported Macs have a AMD GCN4 dGPU and were released in 2016/2017.
To revert back to the last supported (by Apple) macOS version you must erase your disk as there is no uninstall option provided by Apple and there is not way around this. You should follow Apple supported methods to get back, but create a user data backup before starting to erase the internal disk!
Thanks for this information. I did try doing something similar with my Late 2015 27" iMac 17,1. Never had any luck. Rebooting into recovery, installed El Capitan then upgrading to Monterey. Resetting PRAM after each install. *Note: Recovery on this mac always boots up El Capitan because of the firmware.
After the Monterey install-update and all system updates the firmware never got updated. I even called Apple. They would not admit that it's this Mac's OEM 1 TB SSD causing the firmware update block but they did say it can't be updated.
Decided to proceed with OCLP to use this iMac until a replacement is purchased. It has been a good Mac over all but now really showing it's age.
I updated from Sonoma 14.5 to 14.6 yesterday through the regular MacOS software update on my late 2013 15" MacBook Pro. I had to redo the root patches after rebooting.
Everything seems fine BUT "kernelmanager_helper" is running up the CPU load a bit and CPU frequency to max. It's using up 30W+ of power even though the load isn't that high (30-105% in Activity Monitor). It will calm down for a minute or so then start back up for another few minutes. It's been like this since yesterday.
What could this be? I've tried rebooting multiple times but it continues.
Everything seems fine BUT "kernelmanager_helper" is running up the CPU load a bit and CPU frequency to max. It's using up 30W+ of power even though the load isn't that high (30-105% in Activity Monitor). It will calm down for a minute or so then start back up for another few minutes. It's been like this since yesterday.
What could this be? I've tried rebooting multiple times but it continues.
Attachments
It has been reported by many, including yours truly that your Mac might need some time to do the Spotlight indexing and some other housekeeping after an update. Leave it on over night or something and see if it calms down.
Switching off the Aerial screensavers is a must for older Macs if you don't want fans spinning. Deactivating Game Center if you are not using that might also help and appears to have helped here as far as I can tell. Good luck.
Last edited:
I'm not sure if it's a coincidence but I noticed voltageshift wasn't working and that it wanted the kext approved through Security & Privacy. There was a long list of other ones in there that OCLP had added during its root patch that I assumed would be automatically approved. Once I hit "allow" and rebooted, all seems to be fine! Do you guys also have to reapprove extensions after an update?
P.S. The live screensavers are working great on my machine!