Sidebar Sidebar
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

Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
deeveedee said:
The laptops and desktops are now using Open Core - I'm simply suggesting that it might be time to start accepting sleep fix advice from Dortania (the makers of OCLP). Definitely not a hill I want to die on, so if you don't want to accept the suggestion, it's ok. I suspect that there are multiple ways to achieve a fully working OCLP-patched Mac.

EDIT: I checked my macOS volumes for Big Sur, Monterey, Ventura and Sonoma and don't have /var/vm/sleepimage and /private/var/vm/sleepimage in any of them. I, too, like to save disk space, so if there is another place to look for the sleep file, I'd like to know. Thank you.
Click to expand...
I noticed that there is only one difference between the pmset commands suggested by the devs at Dortania and the commands I found years ago, namely the addition of
"sudo pmset -a powernap 0"
They do suggest using "sudo pmset -a hibernatemode 0", which will save on disk space, but may drain the battery more during sleep as all of the data in the RAM is saved to only in the RAM and not written to disk (not being written to the disk may help in cases where the computer struggles to wake up correctly).
So it seems I don't need to "accept any sleep fix advice from Dortania" at all, as I have been in accordance with their advice for years before seeing that link you provided (thanks anyway, confirmation is good).
I don't know why you are not seeing that sleepimage file. Maybe it is prevented during the OCLP installation.
I do remember seeing it often in the past using the various systems installed over the years before OCLP became necessary. In all cases that file has the name "sleepimage" so a search using EasyFind etc. that allows for showing files buried deep in the system (/private/var/vm/) should pop it up if it exists.
Ass you said, "there (must be) multiple ways to achieve a fully working OCLP-patched Mac.
Bon Voyage
 
Last edited:
deeveedee said:
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.
Click to expand...
@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:
davidlv said:
That sounds like you are running OCLP without the post-install root patches, or the root patches didn't work correctly. Try running them again?
Click to expand...
No, I have root patches installed, I've had this issue since updating to Ventura last November.
 
  • Like
Reactions: mat316
Mark Meretz said:
I did an NVRAM reset and will see if it helps

EDIT: However, I don't have a Sleep Wake failure in EFI in the console
Crash reports
Click to expand...
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):

pmset_mbp14,2.png
 
Last edited:
coasterOneEightThree said:
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
Click to expand...
Did you try using the hibernation mode 0?
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"
 
  • Like
Reactions: coasterOneEightThree
@davidlv
Thank you very much! But I'll wait a little before I change anything. Maybe this problem will be solved when the official release versions of Sonoma 14.1 or OCLP 1.1.0 are published.
 
Last edited:
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.
 
  • Like
Reactions: hvds, deeveedee, roronl and 1 other person
5T33Z0 said:
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…)
Click to expand...
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.

coasterOneEightThree said:
In the console again the same diagnostic report.
Click to expand...
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.
 
  • Like
Reactions: coasterOneEightThree
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.
 
Last edited:
  • Like
Reactions: K two, shmasser and Calibre5
deeveedee said:
I thought the Devs fixed this with AMFIPass.kext (which allows unsupported Macs to boot with AMFI enabled). Are there still some Mac Models that require AMFI to be disabled?
Click to expand...
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".
 
Pri-est said:
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".
Click to expand...
Agree that there is definitely a misunderstanding. In order to activate AMFIPass, you need to uncheck "Disable AMFI." AMFIPass.kext is always included in the OC config.plist. Checking or unchecking "Disable AMFI" in the OCLP GUI does not enable or disable AMFIPass.

EDIT: For some Mac Models, AMFIPass (activated by UNCHECKING "Disable AMFI" in the OCLP GUI) has worked since OCLP 0.6.7 or 0.6.8 (don't remember which version). I was simply asking if some Mac Models still require the checkbox "Disable AMFI" to be checked.

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 will include AMFIPass.kext does not include boot-arg "amfi=0x80" and does include AMFIPass.kext. When you check "Disable AMFI" in the OCLP GUI and then "Build and Install Open Core," the OC config.plist generated by OCLP will not include AMFIPass.kext and instead will includes "amfi=0x80" boot-arg and kernel patches (to disable AMFI) and still includes AMFIPass.kext.

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:
  • Like
Reactions: K two and perez987
deeveedee said:
Agree that there is definitely a misunderstanding. In order to activate AMFIPass, you need to uncheck "Disable AMFI."

View attachment 2299047

EDIT: For some Mac Models, AMFIPass (activated by UNCHECKING "Disable AMFI" in the OCLP GUI) has worked since OCLP 0.6.7 or 0.6.8 (don't remember which version). I was simply asking if some Mac Models still require the checkbox "Disable AMFI" to be checked.

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 will include AMFIPass.kext. When you check "Disable AMFI" in the OCLP GUI and then "Build and Install Open Core," the OC config.plist generated by OCLP will not include AMFIPass.kext and instead will include "amfi=0x80" boot-arg and kernel patches (to disable AMFI).

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.
Click to expand...
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.
 
  • Like
Reactions: deeveedee
Pri-est said:
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.
Click to expand...
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:
  • Like
Reactions: perez987
gilby101 said:
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.
Click to expand...

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"
 
  • Like
Reactions: perez987 and deeveedee
MacRumors3590 said:
Thanks!!
Click to expand...
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.
 
deeveedee said:
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.
Click to expand...
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?)
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back