Shaka, when the walls fellFigured out my errors and got my config.plist working. Had an extra array end and start in there when applying patches from two different sections on the OP setup.
Shaka, when the walls fellFigured out my errors and got my config.plist working. Had an extra array end and start in there when applying patches from two different sections on the OP setup.
more appropriately:Shaka, when the walls fell
which is the complete opposite.Arnock, on the night of his joining
Temba, his arms wideEdit. Asked a question but I figured it out myself!
You better check if the BootROM still healthyOkay, so I screwed something up and had to start from scratch again. I followed the initial setup guide, dropped in the default config.plist, put in the OG GPU and selected the EFI partition to boot, and it worked. However, the change isn’t keeping when I reboot again, so it isn’t booting off OpenCore. What might be going on? This didn’t happen the first time I did the initial setup.
I was missing a very simple step, when selecting the EFI partition, I forgot to hold down control when I hit enter. Mundane detail, as Michael Bolton would say.You better check if the BootROM still healthy
Other than the three changes to the UEFI key, is there anything really new in OC 0.8.6? For instance, something remotely nudging a cMP toward Ventura compatibility?The guide has been updated to OpenCore version 0.8.6.
What would make a cMP Ventura-compatible would be AVX2 emulation or AVX2-free GPU drivers (and working drivers for some other hardware like wifi or bluetooth, too). Neither is an element of the "core" Open Core.Other than the three changes to the UEFI key, is there anything really new in OC 0.8.6? For instance, something remotely nudging a cMP toward Ventura compatibility?
Pertinent changes include improvements to emulated NVRAM (in particular, a fix for the wake from sleep issue). Regarding Ventura, as mentioned by @hwojtek, fixes for getting it to run on the classic Mac Pro are not really on the OpenCore issue radar...Other than the three changes to the UEFI key, is there anything really new in OC 0.8.6? For instance, something remotely nudging a cMP toward Ventura compatibility?
There are people claiming successful upgrades to 13.0 using OCLP 0.5.x on cMPs, and there are those who even claim that their computer is more responsive than in Monterey! I might try that on a backup volume and see how it goes, but I suspect that, sooner or later, in the current situation, Ventura will cause frequent kernel panics on our aging hardware.Yeah, I'm pretty sure Monterey is the end of the road for the cMP
This is valid only for NVIDIA Kepler GPUs, where there is no requirement of AVX2.0, since it's Big Sur drivers hacked to work with Ventura. No DRM working and a long list of small issues:There are people claiming successful upgrades to 13.0 using OCLP 0.5.x on cMPs
You might be surprised. Yesterday I saw this (not my computer):This is valid only for NVIDIA Kepler GPUs, where there is no requirement of AVX2.0, since it's Big Sur drivers hacked to work with Ventura. No DRM working and a long list of small issues:
Legacy Metal Graphics Support and macOS Ventura - Sequoia · Issue #1008 · dortania/OpenCore-Legacy-Patcher
With the forth coming release of OpenCore Legacy Patcher v0.5.0, systems with legacy Metal GPUs will finally be able to achieve graphics acceleration in macOS Ventura! Reminder: These patches are s...github.com
AMD HD 7950 is a legacy GCN1-3 card with Monterey drivers hacked to work with Ventura, that also doesn't require AVX2.0. Like NVIDIA Kepler, no DRM support and no H.264 acceleration, see the list of issues.
Just one question, does the problem with trimming samsung ssds persist in 12.6.1; do I still need to use 4294967295 as the value in SetApfsTrimTimeout in config.plist?
I looked into it a bit further. As per Dortania, with OS 12 and above one cannot change the trim timeout; thus there is no change in booting times whether one uses -1 or 4294967295 as values in the said parameter.Wow, thanks for this comment, I was plagged with slow boot for months, and it gaves me a clue about the issue.
After disabling TRIM on OpenCore config (SetApfsTrimTimeout=0) I have fast boot again !
My question is, is it OK to keep TRIM disabled and to just run it with big timeout from time to time as a "maintenance" task ?
<Error>: Failed to bootstrap path: Path = /Library/Apple/System/Library/LaunchDaemons, error = 2: No such file or directory
0 disables trim altogether but I do not thing it will be good for your ssd in the long run.Wow, thanks for this comment, I was plagged with slow boot for months, and it gaves me a clue about the issue.
After disabling TRIM on OpenCore config (SetApfsTrimTimeout=0) I have fast boot again (I'm running OpenCore 0.8.4 with OCLP 0.4.10 and 12.6) !
My question now is, is it OK to keep TRIM disabled and to just run it with big timeout from time to time as a "maintenance" task ?
That's a bit confusing. The OC manual state thisMy question now is, is it OK to keep TRIM disabled and to just run it with big timeout from time to time as a "maintenance" task ?
Trim operations are only affected at booting phase when the startup volume is mounted. Either specifying timeout, or completely disabling trim with 0, will not affect normal macOS running.
That is the prohibited boot screen - means your OS is unsupported. You would see that for example if you spoofed a MacPro7,1 and tried to boot Mojave since Mojave is not supported by the MacPro7,1.So what does it mean when you manage to get to the boot screen, and after selecting your MacOS partition you get a black screen with Ø ? I’m a bit baffled since I’m reusing a config file that worked before but I had to reformat and reinstall. I think I did all the same setup as before. The default config works fine, so I’m doing something wrong.