Contribute
Register

<< Solved >> Changing SMBIOS creates a sleepimage! :-o

Joined
Jul 11, 2012
Messages
450
Motherboard
Gigabyte GA Z68XP-UD3
CPU
i7 3770
Graphics
GT 210
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. Android
Hi!
Pretty weird thing I've just discovered on my old Z68 build — that still runs perfectly :thumbup: : if I change my SMBIOS from iMac12,1 to iMac14,2 a sleepimage is created at boot time, no matter what... :banghead:
- I checked pmset -g | grep hibernatemode and it's still at 0
- I deleted nvram (sudo nvram -c)
- only reverting config.plist to iMac12,1 stops this behaviour

Any idea? Some additional setting needed?
N.B.: you may ask "why change smbios if it works?"
=> One reason is that I replaced my i3 Sandy Bridge with an i7 Ivy, so I thought it would fix some issue (I had a few unusual crashes but maybe they weren't related).
=> The other reason is that it fixes the external drives appearing as internal (I also tried iMac13,2 but it didn't fix it).
 
Joined
Jul 11, 2012
Messages
450
Motherboard
Gigabyte GA Z68XP-UD3
CPU
i7 3770
Graphics
GT 210
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. Android
Well, in absence of any explanation, I found a workaround at macrumors:
- Remove the sleep image: sudo rm /private/var/vm/sleepimage
- sudo ln -s /dev/null /var/vm/sleepimage
N.B.: this creates a symlink to /dev/null a.k.a. "the black hole of Unix" — meaning that anything sent to /var/vm/sleepimage will simply be ignored.
No Console errors, everything works ok — even sleep/wake of course... :mrgreen:

EDIT: while the above works, I'm still digging to find what's the real cause, as I've found another EFI folder on another drive of mine that's not causing sleepimage creation with the same SMBIOS! :eek:
I'm keen on thinking it's a combination of settings, or a side effect of something unrelated as I've already done many tests (switching config.plist, SSDT, etc.) and there's no clear answer... I'll keep the thread updated if I find something. ;)
 
Last edited:
Joined
Jul 11, 2012
Messages
450
Motherboard
Gigabyte GA Z68XP-UD3
CPU
i7 3770
Graphics
GT 210
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. Android
Eureka! I finally found where the issue lies and the result of my inquiries is quite amazing! :eek:
It's not plain to see when using Clover Configurator, but if I don't have the following lines in my config.plist, the sleepimage is created!
XML:
<key>Generate</key>
<dict>
    <key>CStates</key>
    <false/>
    <key>PStates</key>
    <false/>
    <key>PluginType</key>
    <false/>
</dict>

I was assuming that deleting those lines (or not checking those items in Clover Configurator) was enough — and it was for former system definitions... :mrgreen: — but apparently they default to true since iMac14,2! (also tried iMac15,1)
It's also possible that only one of them lines (PluginType?) creates the issue, or that it depends on which version of Clover I use, etc.

N.B.: those lines are also created when checking the corresponding ACPI/Generate Options in Clover Configurator, saving, unchecking then saving again. ;)
 

Feartech

Moderator
Joined
Aug 3, 2013
Messages
23,647
Motherboard
Asus N752VX-OpenCore
CPU
i7-6700HQ / HM170
Graphics
HD 530 1920 x 1080
Mac
  1. iMac
Mobile Phone
  1. iOS
Eureka! I finally found where the issue lies and the result of my inquiries is quite amazing! :eek:
It's not plain to see when using Clover Configurator, but if I don't have the following lines in my config.plist, the sleepimage is created!
XML:
<key>Generate</key>
<dict>
    <key>CStates</key>
    <false/>
    <key>PStates</key>
    <false/>
    <key>PluginType</key>
    <false/>
</dict>

I was assuming that deleting those lines (or not checking those items in Clover Configurator) was enough — and it was for former system definitions... :mrgreen: — but apparently they default to true since iMac14,2! (also tried iMac15,1)
It's also possible that only one of them lines (PluginType?) creates the issue, or that it depends on which version of Clover I use, etc.

N.B.: those lines are also created when checking the corresponding ACPI/Generate Options in Clover Configurator, saving, unchecking then saving again. ;)
seems strange

also you could have just created a directory called sleepimage as per:
 
Joined
Jul 11, 2012
Messages
450
Motherboard
Gigabyte GA Z68XP-UD3
CPU
i7 3770
Graphics
GT 210
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. Android
seems strange

also you could have just created a directory called sleepimage as per:
Thanks, but I find the symlink to /dev/null solution I found in post #2 more elegant. :D
Also, being a geek, I wanted to find out the real blip. :mrgreen:
I agree that it's strange, but believe you me, I carefully tested other possibilities, comparing the differences between the EFI folder that's not causing sleepimage creation and the one that does... There are still other differences but this one clearly makes the switch between creating/not creating the sleepimage.

EDIT: I've just put back the original EFI, only adding the Generate lines, confirming that it was the only meaningful difference. :thumbup:
EDIT2: further trials showed that the PluginType line is the only one that matters.
 
Last edited:
Joined
Jul 11, 2012
Messages
450
Motherboard
Gigabyte GA Z68XP-UD3
CPU
i7 3770
Graphics
GT 210
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. Android
An update after my many trials:
As I mentioned, I recently replaced my i3 Sandy with an i7 Ivy and generated a new SSDT, but in the course of my trials, I've accidentally put back the SSDT I had generated for the i3 years ago... :mrgreen:

So, it turns out that the PluginType=false fix I've found only works with that SSDT! o_O

Whether I use the correct i7 SSDT (with or without PluginType=false) or no SSDT at all (following Rehabman's method with PluginType=true), the sleepimage is always created, so I ended up using no SSDT and using the symlink fix instead... :D

EDIT: I've later discovered that Hackintool includes a "Fix sleepimage" utility in its Power section! (the screwdriver icon at the bottom) It creates a locked dummy file, so it's the easiest way to solve the issue. :thumbup: Downside is that you'll need root permissions if you ever want to remove it.
 
Last edited:
Top