The problem, apparently, was not the iMac, nor the upgrade. It happened when I restored some files, I have a corrupt file either in my User area, or in Applications.
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 13 Ventura on Unsupported Macs Thread
- Thread starter 0xCUBE
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
This is fantastic news. Which USB 3 PCIe card adapter do you recommend or which one did you pick up?
Edited: Never-mind from just a couple posts below you mention which card your using. Thanks.
Last edited:
I guess you are seeing these options right after the reboot?
They appear to be OpenCore's menu options but something is wrong with your OpenCore configuration. Normally there will be 'macOS' and 'Recovery' entries.
My suggestion is:
They appear to be OpenCore's menu options but something is wrong with your OpenCore configuration. Normally there will be 'macOS' and 'Recovery' entries.
My suggestion is:
- Clear NVRAM, which will revert some modifications OpenCore did.
- The firmware will boot the default Macintosh HD partition, if you still have the old macOS on that. If not:
- Boot through a USB thumb drive or macOS Recovery over the Internet.
- Try to recover/backup your data.
- Reinstall one of the officially supported macOS system.
I'm trying to install Ventura on a 2016 Macbook. It's currently running Monterey. Every time I get to the installation window after restarting the mac, the trackpad stops functioning (the clickable sides become stuck) and the cursor stops moving. When i abandon the installation and boot back into Monterey, everything is perfect. It's happened several times. I get to the installation window, and the trackpad seizes. Tried connecting a mouse; same thing; it just freezes at installation. I installed Ventura on a 2012 Macbook Pro, and it's running flawlessly, but somehow the 2016 Macbook simply won't allow installation. Any ideas?
There is a thread here on MacRumors. You can boost Intel HD4000 vram to 2,3,4GB instead of 1538MB. The performance stays the same and that memory is stolen from RAM but in some cases it is useful, for example for games that needs a lot of memory for textures. I have a MBP 13” 2012 with 16GB so I would love to boots vram to 2 or more GB, but the steps needs you to edit AppleIntelFrameBufferCapri.kext but it is not in Extension but injected by OpenCore. Any idea about that?
The hack was not implemented in OpenCore at least as far I know even if I know some users achieve it. Can you point me to a guide hint how to edit config.plist.The question was "what is the hack?," not "what is a hack?" -
@ikir If your HD3000/HD4000 Memory hack was implemented in OpenCore, then you should still be able to implement the hack with OCLP. When you "build opencore" with OCLP, you are simply generating an Open Core EFI. After building the Open Core EFI, you can modify the auto-generated config.plist to your heart's content. You can even upgrade Open Core to a newer version that has not yet been included in OCLP. For example, OCLP 0.6.1 implements its EFI build with Open Core 0.8.8. I wanted Open Core 0.9.0, so I performed the Open Core upgrade myself.
That hack edit AppleIntelFrameBufferCapri kext
@ikir This is going to require a bit of learning, but I sense that you're up for it. I am not familiar with your specific HD4000 hack, but in general, Intel graphics hacks require an understanding of this. Basically, you're going to use OpenCore to inject WhateverGreen.kext and in the OpenCore config.plist, you'll specify DeviceProperties that tell WhateverGreen.kext to modify macOS kernel. Learn how to edit OpenCore config.plist here. Search for HD4000 graphics patches that have been implemented for hackintoshes.
EDIT: Note that you can also implement kernel patches in OpenCore's config.plist (open config.plist with your favorite plist editor (I use XCode) and look for Kernel > Patch). If you know the hex sequences of the "find" and "replace" sequences required for your hack, you can implement your own kernel patches without WhateverGreen.kext.
EDIT: Note that you can also implement kernel patches in OpenCore's config.plist (open config.plist with your favorite plist editor (I use XCode) and look for Kernel > Patch). If you know the hex sequences of the "find" and "replace" sequences required for your hack, you can implement your own kernel patches without WhateverGreen.kext.
Last edited:
Currently, the KDK for build 22E5236f (13.3b3) seems to be corrupted (both on Apple developer DL and what OCLP tries to fetch). This leads to legacy metal unpatchability atm.
My workaround (fine for i.e. cMP with GCN 1 AMD R9 280X) is to rename the beta2 KDK sub-folder to ...236f.
OCLP then does its job without re-downloading the faulty KDK and 13.3b3 runs "as before."
edit: Mykola wrote he found the .dmg to be actually a .pkg and renaming seems to work. You might also try this instead of using the older renamed KDK.
My workaround (fine for i.e. cMP with GCN 1 AMD R9 280X) is to rename the beta2 KDK sub-folder to ...236f.
OCLP then does its job without re-downloading the faulty KDK and 13.3b3 runs "as before."
edit: Mykola wrote he found the .dmg to be actually a .pkg and renaming seems to work. You might also try this instead of using the older renamed KDK.
Attachments
Last edited:
It is in /System/Library/Extensions, or in /Library Extensions. I don't know the process to hack the kext but it should not be different with OC.
@sinbad21 It's not in /S/L/E anymore with newer versions of macOS that dropped HD4000 support.
*** deleted to avoid duplication of OCLP discussion already happening in this thread ***
EDIT: I see that @ikir is already having the OCLP discussion in this thread. Looks like the conversation is being duplicated in two threads.
*** deleted to avoid duplication of OCLP discussion already happening in this thread ***
EDIT: I see that @ikir is already having the OCLP discussion in this thread. Looks like the conversation is being duplicated in two threads.
Last edited:
After patch it is again in /S/L/E. So it could be updated after patch.
Thank you. I have confirmed that on my MBP6,2, OCLP has installed legacy kexts in /S/L/E.
Last edited:
It depends on the macOS version. In Ventura 13.2.1 it is in /Library/Extensions on my machine. I have also a HD4000.
I stand corrected. I wonder why OCLP would place the Capri kext in /L/E for HD4000 patching, but not for NVidia patching. Makes no sense to me.
Last edited:
@sinbad21 Just when I thought I was beginning to understand OCLP, you've shown me that I have a lot to learn. Thank you!
At the risk of asking a remedial question, does anyone understand why sinbad21 would have OCLP-injected legacy kexts in /Library/Extensions when running Ventura 13.2.1 and on my MBP6,2, I have no OCLP-injected kexts in /Library/Extensionsnor in /System/Library/Extensions in Monterey 12.6.3 and Ventura 13.2.1? I used OCLP 0.6.1 to apply post-install patches in Monterey and Ventura. I didn't think that OCLP used /L/E or /S/L/E, but clearly I'm wrong. Thanks for any explanation.
My /L/E is as follows:
On my MBP6,2, kextstat -a shows that the legacy NVidia kexts are loaded in memory:
At the risk of asking a remedial question, does anyone understand why sinbad21 would have OCLP-injected legacy kexts in /Library/Extensions when running Ventura 13.2.1 and on my MBP6,2, I have no OCLP-injected kexts in /Library/Extensions
My /L/E is as follows:
On my MBP6,2, kextstat -a shows that the legacy NVidia kexts are loaded in memory:
Last edited:
Is anybody else having problems installing the KDK for 13.3 - 22E5236f?
OCLP downloads it, starts installing, but can't open the disk image, then fails.
OCLP downloads it, starts installing, but can't open the disk image, then fails.
Several issues with, security patch (a) and (b) béta 2, not installing.
With 13.3 béta 3, OCLP post root patch issues with KDK download and installation with OCLP 0.6.2-nightly-version-before-latest.
Ventura 13.3 béta 3 installed and running on macbookpro8,1 with latest OCLP 0.6.2-n
Some issues on python3.11 building OCLP 0.6.2-n
With 13.3 béta 3, OCLP post root patch issues with KDK download and installation with OCLP 0.6.2-nightly-version-before-latest.
Ventura 13.3 béta 3 installed and running on macbookpro8,1 with latest OCLP 0.6.2-n
Some issues on python3.11 building OCLP 0.6.2-n
Attachments
Ok, so it appears that the file Kernel_Debug_Kit_13.3_build_22E5236f.dmg that OCLP is downloading is corrupted. I was able to find and download the earlier version Kernel_Debug_Kit_13.3_build_22E5230e.dmg. That is good and mounts, but it is 1.04GB compared to the later file's size of 654.9MB.
Intel iGPU and Nvidia Kepler kernel extensions are mainly in /L/E (why not all, BTW…? those with a .bundle extension are still in /S/L/E, for example) only for Metal-capable KDK-less root patched Macs; se also:
github.com
This could explain the differences between the aforementioned setups (Kepler vs. Tesla)…
sys_patch: Allow KDK-less root patching on Intel iGPUs and Nvidia Kepler by khronokernel · Pull Request #1007 · dortania/OpenCore-Legacy-Patcher
As mentioned in the issue #998, macOS Ventura no longer ships on-disk kernel extensions. Instead requiring Kernel Debug Kits to be installed manually. This creates numerous issues including: Break...
github.com
This could explain the differences between the aforementioned setups (Kepler vs. Tesla)…
I don't think it is an SSD problem. I wonder it is some issue with SATA connector itself. That SSD works at full speed on another Mac. In fact I tried a Hard drive before that, and had the same problem. It worked at half the speed. 60 MBps instead of 120 MBps.