We are in violent agreement. I didn't realize just how violent.
I have no travel plans at the moment but appreciate the good wishes for my next trip. Thank you.
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
I have no travel plans at the moment but appreciate the good wishes for my next trip. Thank you.
@deeveedee Please accept my apologies for that typo in my last post. I have very shaky hands these days and I didn't re-read the post before hitting that button or afterwards. No intention to be "violent" in any way. The Bon Voyage as referring to your continuing on "your way" rather than mine with regard to the sleep commands. As you said, "there are many ways" to achieve the same result, a working system. In regard to the sleep commands I have been using for years, I found them originally in a post on a Japanese computer blog. Now I found it rather interesting that they were in almost complete agreement with the recommendations in the link you posted with the Dortania sleep suggestions.
Those had a "powernap 0" in addition to the original (Japanese blog) commands. Otherwise there was no difference.
That original URL is still viable if you want to check it out;
URL:
http://baqamore.hatenablog.com/entry/2019/02/08/222401
Last edited:
No, I have root patches installed, I've had this issue since updating to Ventura last November.
No change here overnight after SMC and NVRAM reset. The MacBook Pro is off and turns on as soon as the lid is opened. That would have been too easy
...In the console again the same diagnostic report.
Code:
Sleep Wake failure in EFI
Failure code:: 0x0171260e 0x0000001fHere are my current power settings BTW – didn't change anything since the SONOMA installation on the MacBookPro14,2 (macOS 14.1 (23B73), OCLP 1.1.0n):
Last edited:
Did you try using the hibernation mode 0?No change here overnight after SMC and NVRAM reset. The MacBook Pro is off and turns on as soon as the lid is opened. That would have been too easy
In the console again the same diagnostic report.
Code:Sleep Wake failure in EFI Failure code:: 0x0171260e 0x0000001f
Here are my current power settings BTW – didn't change anything since the SONOMA installation on the MacBookPro14,2 (macOS 14.1 (23B73), OCLP 1.1.0n):
View attachment 2298897
I noticed the Dortania suggestions for sleep commands recommended that and also
sudo pmset -a powernap 0
Here are the sleep commands again for easy reference:
sudo pmset -a hibernatemode 0 standby 0 autopoweroff 0
sudo rm /var/vm/sleepimage
--Ignore any message saying there is no such file
Create a blanked zero-byte file so the OS cannot rewrite the file:
sudo touch /var/vm/sleepimage or sudo touch /private/var/vm/sleepimage
Make file immutable: (sudo chflags nouchg ... to revert)
sudo chflags uchg /var/vm/sleepimage
The sleep image file is actually in /private/var/vm/ but /var/vm/ is a symbolic link to that location.
sudo pmset -a proximitywake 0
sudo pmset -b tcpkeepalive 0
Try these and see if you still get that "Sleep Wake failure in EFI"
I've now tried Hibernation 0, it works but it loses about 15% battery overnight. What happens when the battery runs out does it shut down or just crash?
I suggest to familarize yourself with what the pmset parameters do before changing them on real Macs.
Hibernatemode is highlited in red in Hackintool, because Hibernatemode usually is not working on Hackintoshes out of the box and it's therefore recommended to change it to 0 (suspend to RAM) because Hibernatemode 3 or 25 can cause issues. Dortania's instructions are primarily aimed at PC users to address these issues (most of these fixes are not applicable to real Macs anyway…)
So before changing any of these settings on a real Mac you should first figure out what causes the system to not enter sleep. You can use Terminal to do so:
pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"
Next, check the results and see what causes the issue and how to address them. Sometimes it's a PCI device prohibiting entering sleep. In this case this can be adddressed by simple injecting a different ASPM state for the device in question via DeviceProperties in the config.plist.
Hibernatemode is highlited in red in Hackintool, because Hibernatemode usually is not working on Hackintoshes out of the box and it's therefore recommended to change it to 0 (suspend to RAM) because Hibernatemode 3 or 25 can cause issues. Dortania's instructions are primarily aimed at PC users to address these issues (most of these fixes are not applicable to real Macs anyway…)
So before changing any of these settings on a real Mac you should first figure out what causes the system to not enter sleep. You can use Terminal to do so:
pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"
Next, check the results and see what causes the issue and how to address them. Sometimes it's a PCI device prohibiting entering sleep. In this case this can be adddressed by simple injecting a different ASPM state for the device in question via DeviceProperties in the config.plist.
That is what I was thinking! Those PC desktop settings are not very useful when you actually want sleep and hibernate in a Mac laptop.
So I am not the only one with the first entry in power log when attempting to wake saying:
"Failure during sleep: 0x171260E0000001F : EFI/Bootrom Failure after last point of entry to sleep"
followed by a reboot.
And this whatever setting for hibernatemode - 0, 3 or 25.
Suggests, to me, that we have an EFI problem which is not going to be fixed by further tweaking of pmset.
Hi to All!
Successfully updated my CMP 3.1 to last macOS 14.1 RC by OTA update from 14.0 RC2 (OCLP 1.1.0 NB)
Thanks to OCLP dev's, greate job!
Successfully updated my CMP 3.1 to last macOS 14.1 RC by OTA update from 14.0 RC2 (OCLP 1.1.0 NB)
Thanks to OCLP dev's, greate job!
Agree with everything said about pmsettings. Devs are working hard to enable power management on Macs that are no longer supported in Sonoma. As Devs restore and/or enable power management for unsupported Macs (e.g., by using Open Core to inject kexts like AppleIntelCPUPowerManagement or CPUFriend which are NOT required when macOS natively supports the Mac), the real Mac may develop some characteristics of a hackintosh.
As I said before, we're driving the car while the Devs are building the engine. And we're now using Open Core to boot real Macs. Some of the Developer techniques used to boot macOS on unsupported Macs are the same techniques used to boot macOS on hackintoshes.
Not wanting to offend, not wanting to have my way, not wanting to prove anyone wrong... It's just a fact that we now have real Macs with a split personality: part real Mac and part hackintosh. The line between the real Mac and hackintosh is at the very least blurred a little.
EDIT: For example, in hackintoshes, it is not uncommon to disable "Wake for Network Access" and "Enable Power Nap." Disabling these in macOS Energy Saver settings fixed the EFI wake issue for this real Mac user. Fixing sleep/wake issues is probably going to require solutions that differ for each Mac Model. Finding the solution that works is going to require some trial and error and may include testing some solutions that are recommended for hackintoshes. Note that this Dortania reference recommends disabling Wake for Network Access and Power Nap.
As I said before, we're driving the car while the Devs are building the engine. And we're now using Open Core to boot real Macs. Some of the Developer techniques used to boot macOS on unsupported Macs are the same techniques used to boot macOS on hackintoshes.
Not wanting to offend, not wanting to have my way, not wanting to prove anyone wrong... It's just a fact that we now have real Macs with a split personality: part real Mac and part hackintosh. The line between the real Mac and hackintosh is at the very least blurred a little.
EDIT: For example, in hackintoshes, it is not uncommon to disable "Wake for Network Access" and "Enable Power Nap." Disabling these in macOS Energy Saver settings fixed the EFI wake issue for this real Mac user. Fixing sleep/wake issues is probably going to require solutions that differ for each Mac Model. Finding the solution that works is going to require some trial and error and may include testing some solutions that are recommended for hackintoshes. Note that this Dortania reference recommends disabling Wake for Network Access and Power Nap.
Last edited:
I thought the Devs fixed this with AMFIPass.kext and maybe other fixes (to allow unsupported Macs to boot with AMFI enabled). Are there still some Mac Models that require AMFI to be disabled?
I think you don't fully understand. To activate AMFIPass - you need checkbox "disable AMFI". For work with CGN legacy drivers or Modern WIFI drivers - you need to check "disable AMFI".
Agree that there is definitely a misunderstanding.
EDIT: For some Mac Models, AMFIPass
EDIT2: If you would like to see what happens when you uncheck "Disable AMFI," look in the Open Core config.plist generated by OCLP. You will see that when you uncheck "Disable AMFI" in the OCLP GUI and then "Build and Install Open Core," the OC config.plist generated by OCLP
EDIT3: It is very important to note that when you check or uncheck "Disable AMFI" checkbox in the OCLP GUI, this setting will not take effect until you "Build and Install Open Core" and then reboot.
Last edited:
Maybe you first try it on REAL old mac??
I check the box "Disable AMFI" and i get AMFIpass.kext in my EFI folder on my real CMP 3.1.
I don't know, what tell about this your friends - alien reptiloids, but it's real case.
I stand corrected - you are correct. At some point during the Beta testing of AMFIPass.kext (I hadn't noticed this), OCLP is now keeping AMFIPass.kext regardless of whether "Disable AMFI" is checked in the OCLP GUI. I'm not sure when this changed and will need to look back in commit history. I never reexamined this after the AMFIPass.kext beta testing completed, so that is clearly my mistake. It now looks like AMFIPass.kext is always injected and that checking "Disable AMFI" adds "amfi=0x80" boot-arg. Thank you.
My question remains... I thought that Devs fixed OCLP so that AMFI no longer needed to be disabled. I wasn't aware that there were still Mac Models that needed "Disable AMFI" to be checked.
EDIT: I will modify my previous post to indicate that AMFIPass.kext is always injected and that checking "Disable AMFI" adds "amfi=0x80" boot arg.
Last edited:
Did you upgrade your mac's SMC firmware to the latest version? Also, try the Terminal command I metioned to get more info abou the event that caused the issue:
pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"
@deeveedee Just giving you a heads up that VMware Fusion 13.5 was released today and has official Sonoma support, so if you want to do some testing with it in a VM, you should be able to now.
After you test, could you please post an update to confirm that disabling AMFI works for you (checking "Disable AMFI" in OCLP GUI and then "Build and Install Open Core")? I was unaware that there were still Macs that required AMFI to be disabled in order to install and boot macOS with OCLP post-install patches. Also, please confirm the Mac Model on which disabling AMFI is required.
Thank you.
EDIT: Just to be clear since it appears that my question has been perceived as an argument: I am asking about the need for disabling AMFI because I don't know, not because I'm challenging the position. Thank you.
The OCLP 1.1n version has been updated, dated 0ct. 19, 1:09AM.
@deeveedee Are you still mad at me? (where is that heartbroken emoji?)