Jump to content
30960 posts in this topic

Recommended Posts

13 minutes ago, vector sigma said:

Yes!

The nvram.plist goes to IODeviceTree:/options, then nvram.plist is not taken into account. If you clean the nvram means you clean the nvram in the memory map not on the filesystem. At next reboot a new nvram.plist will be created with a new time stamp. For this reason ther's no need to delete the file.

 

hope test emuvariableuefi case. nvram.plist place to ESP and Mac partition(APFS and HFS+) and check f11. and check clover boot log. and nvram -p.

 

nvram.plist will be remove when using f11. but there are nvram.plist in mac parition(apfs and hfs). clover will read it.

Edited by Sherlocks
16 minutes ago, Sherlocks said:

nvram.plist will be remove when using f11. but there are nvram.plist in mac parition(apfs and hfs). clover will read it.

this is not the problem. The question is: what goes in nvram (IODeviceTree:/options) then?

 

  1. the contents of the file (Clover bug).
  2. a cleaned nvram and all is perfect because at next reboot a new plist will be created and Clover read the new one.
  3. a cleaned nvram, but Clover next reboot ignore it and read another one. Clover bug.

 

What of these happens?

Edited by vector sigma
  • Like 1
25 minutes ago, vector sigma said:

this is not the problem. The question is: what goes in nvram (IODeviceTree:/options) then?

 

  1. the contents of the file (Clover bug).
  2. a cleaned nvram and all is perfect because at next reboot a new plist will be created and Clover read the new one.
  3. a cleaned nvram, but Clover next reboot ignore it and read another one.

 

What of these happens?

 

1. i don't understand it.

2. yes. thats right. your new cloverdaemon make new date nvram.plist in ESP. and clover read recently date nvram.plist. although other old nvram.plist on other partition.

3. until clean nvram.plist when press f11. example there are 2 nvram.plist both ESP and APFS root.

both files included your Clover.RW nvram value in nvram.plist. we want to remove Clover.RW nvram value on memory. normally we use to type sudo nvram -c in terminal. but in recent macos, we can't remove it. so we reboot and use f11.

it is normal process.

our goal is that Clover.RW remove. like i mentioned before, if two nvram.plist(ESP,APFS) have Clover.RW value. when press f11, nvram will be remove in ESP. but left nvram.plist in APFS root. so clover read left nvram.plist in APFS root when enter GUI. so clover still into Clover.RW value to memory. and boot macos.

and type nvram -p. we still see Clover.RW. until user remove nvram.plist in APFS root, will be keep Clover.RW. yeah. this nvram.plist will be skip after new clover daemon make new date nvram.plist on ESP.

it is not for clean nvram. of course, it is rare case. i just tell you that there is this case.

 

in this case, only legacy and emuvariableuefi user+GPT

 

EDIT1.

your new cloverdaemon consider MBR user? old rc script consider MBR user. if MBR user, nvram.plist will be make in macos partition. bcuz there is no ESP.

MBR case, clover cant remove nvram.plist by using f11. bcuz macos partition type hfs or apfs. in clover gui, i heared both type support only read before.

Edited by Sherlocks
18 minutes ago, Sherlocks said:

1. i don't understand it.

If you clean the nvram with F11 then in memory should go a cleaned nvram and who cares of nvram.plist or if another plist still exist every where, because after the shut down a new one will be created, and again, who cares if exist an old nvram.plist inside a APFS partition.

 

For this reason, if Clover ignore the new created file, is it a Clover bootloader bug.

 

F11을 사용하여 nvram을 정리하면 정리 된 nvram이 메모리로 이동하므로 Clover는 nvram.plist 내부의 내용을 더 이상 신경 쓰지 않아야합니다. 그렇지 않으면 버그를 풉니 다.

 

Clover가 새로운 nvram.plist를 읽지 못하면 또 다른 결함입니다. ESP에서 새 nvram.plist를 다시 시작한 후 Clover는 다른 것을 읽을 필요가 없습니다. APFS 파티션에서와 같이.

 

:D

Edited by vector sigma
  • Like 1

Clover non deve eliminare i file dal file system, so there not will be the problem of reading a too old file somewhere else.

클로버는 파일 시스템에서 파일을 삭제하지 않아야합니다.

 

EDIT

If you need to do that, then Clover have to create a new file instead. Otherwise will read old files.

그렇게해야 할 경우 대신 새 파일을 만들어야합니다.

 

If you delete the latest nvram.plist, it is normal that another one, if exist, will became the newer available.;)

Edited by vector sigma
22 minutes ago, vector sigma said:

If you clean the nvram with F11 then in memory should go a cleaned nvram and who cares of nvram.plist or if another plist still exist every where, because after the shut down a new one will be created, and again, who cares if exist an old nvram.plist inside a APFS partition.

 

For this reason, if Clover ignore the new created file, is it a Clover bootloader bug.

 

F11을 사용하여 nvram을 정리하면 정리 된 nvram이 메모리로 이동하므로 Clover는 nvram.plist 내부의 내용을 더 이상 신경 쓰지 않아야합니다. 그렇지 않으면 버그를 풉니 다.

 

Clover가 새로운 nvram.plist를 읽지 못하면 또 다른 결함입니다. ESP에서 새 nvram.plist를 다시 시작한 후 Clover는 다른 것을 읽을 필요가 없습니다. APFS 파티션에서와 같이.

 

:D

 

15 minutes ago, vector sigma said:

클로버는 파일 시스템에서 파일을 삭제하지 않아야합니다.

at least, i understand english.

thanks vector for korean.

i just mentioned it why for long time.

1. when clover legacy and emuvariableuefi, find nvram.plist and compared file date on all partition when enter GUI.

2. if all nvram.plist doesnt have clean contents?

3. if user use legacy and emuvriableuefi, f11 remove only nvram.plist in ESP. i commited f11 function with enough test for long time ago. please see f11 code. and clover bootlog

 

yeah. all is okay like you said,

i understand enough. 1-3 is my opinion

hope just clover app make nvram.plist in only ESP when users use GPT with legacy and emuvariable.

Edited by Sherlocks

IDEA:

  1. at start up CloverDaemonNew clean all old nvram.plist
  2. save the nvram to the boot partition, so at least one copy exist

Did you like?

3 minutes ago, Sherlocks said:

2. if all nvram.plist is not clean?

There will be no problem because Clover has to read only one.

3 minutes ago, vector sigma said:

IDEA:

  1. at start up CloverDaemonNew clean all old nvram.plist
  2. save the nvram to the boot partition, so at least one copy exist

Did you like?

There will be no problem because Clover has to read only one.

 

it is just my opinion. i just worry that clean nvram goal is not reach from nvram.plist(dummy nvram values)

 

yes clover have to read only one. if one has dummy content? a goal of f11 is clean nvram status without dummy nvram values.

6 minutes ago, Sherlocks said:

yes clover have to read only one. if one has dummy content? a goal of f11 is clean nvram status without dummy nvram values.

What do you mean for dummy content? The daemon at start up has all the time to do every things we want, also delete things, add things, correct things. Can also write the NVRAM directly and not only on the plist (if allowed by SIP). Tell me more please.

Edited by vector sigma
21 minutes ago, vector sigma said:

What do you mean for dummy content? The daemon at start up has all the time to do every things we want, also delete things, add things, correct things. Can also write the NVRAM directly and not ony on the plist (if allowed by SIP). Tell me more please.

 

yes. at least Clover app support Clover.* nvram values. write is okay. but remove?

this is my nvram.plist after 10.15.2 beta1 in ESP.

 

in legacy and emuvariableuefi, it doen't matter. this values in nvram.plist

efi-backup-boot-device

efi-backup-boot-device-data

install-product-url

previous-system-uuid

 

also both keys causes osinstall.pkg installation issue for long time ago. so i added this line

install-product-url

previous-system-uuid

https://github.com/CloverHackyColor/CloverBootloader/blob/master/rEFIt_UEFI/Platform/DataHubCpu.c#L391

 

now uploaded nvram.plist in ESP for me, i can clean nvram.plist as very clean

because there is only nvram.plist in ESP. there is no nvram.plist in other type partition(apfs).

 

if uploaded nvram.plist with dummy contents located in apfs root and hfs root?

clover choose recent file (apfs or hfs), then boot. continuously keep dummy contents when enter gui.

said again. in this case is rare.

clover log

Spoiler

3:971  0:001  === [ PutNvramPlistToRtVars ] =============================
3:971  0:000   Adding Key: Clover.DisableSleepProxyClient: Size = 4, Data: 74 72 75 65 
3:971  0:000   Adding Key: Clover.RootRW: Size = 4, Data: 74 72 75 65 
3:971  0:000   Adding Key: EFILoginHiDPI: Size = 4, Data: 00 00 00 00 
3:971  0:000   Skipping EmuVariableUefiPresent
3:971  0:000   Adding Key: LocationServicesEnabled: Size = 1, Data: 01 
3:971  0:000   Adding Key: SystemAudioVolume: Size = 1, Data: 80 
3:971  0:000   Adding Key: SystemAudioVolumeDB: Size = 1, Data: ED 
3:971  0:000   Adding Key: SystemAudioVolumeSaved: Size = 1, Data: 37 
3:971  0:000   Adding Key: backlight-level: Size = 2, Data: 69 05 
3:971  0:000   Adding Key: bluetoothActiveControllerInfo: Size = 16, Data: 7A E0 89 04 00 00 00 00 40 14 AC D1 B8 E2 A4 D0 
3:971  0:000   Adding Key: csr-active-config: Size = 4, Data: 77 02 00 00 
3:971  0:000   Adding Key: efi-backup-boot-device: String: Size = 443, Val = '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>2DCFE836-4404-4C80-AB32-62ACD78E462D</string></dict></dict><key>BLLastBSDName</key><string>disk1s2</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\D910D268-909A-4CF6-A95C-A01D3A630F97\System\Library\CoreServices\boot.efi</string></dict></array>'
3:971  0:000   Adding Key: efi-backup-boot-device-data: Size = 264, Data: 02 01 0C 00 D0 41 03 0A 00 00 00 00 01 01 06 00 00 17 03 12 0A 00 01 00 00 00 00 00 04 01 2A 00 02 00 00 00 28 40 06 00 00 00 00 00 D8 77 48 17 00 00 00 00 36 92 99 D5 4B EA 15 44 AA 7E ED AA 77 BE E3 B3 02 02 04 03 24 00 F7 FC 74 BE 7C 0B F3 49 91 47 01 F4 04 2E 68 42 36 E8 CF 2D 04 44 80 4C AB 32 62 AC D7 8E 46 2D 04 04 9A 00 5C 00 44 00 39 00 31 00 30 00 44 00 32 00 36 00 38 00 2D 00 39 00 30 00 39 00 41 00 2D 00 34 00 43 00 46 00 36 00 2D 00 41 00 39 00 35 00 43 00 2D 00 41 00 30 00 31 00 44 00 33 00 41 00 36 00 33 00 30 00 46 00 39 00 37 00 5C 00 53 00 79 00 73 00 74 00 65 00 6D 00 5C 00 4C 00 69 00 62 00 72 00 61 00 72 00 79 00 5C 00 43 00 6F 00 72 00 65 00 53 00 65 00 72 00 76 00 69 00 63 00 65 00 73 00 5C 00 62 00 6F 00 6F 00 74 00 2E 00 65 00 66 00 69 00 00 00 7F FF 04 00 
3:971  0:000   Adding Key: flagstate: Size = 32, Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3:971  0:000   Adding Key: fmm-computer-name: Size = 25, Data: 53 68 65 72 6C 6F 63 6B 73 EC 9D 98 20 4D 61 63 42 6F 6F 6B C2 A0 50 72 6F 
3:971  0:000   Adding Key: install-product-url: Size = 73, Data: 78 2D 6F 73 70 72 6F 64 75 63 74 3A 2F 2F 45 38 36 44 45 36 42 35 2D 31 32 36 33 2D 34 45 35 42 2D 41 42 37 30 2D 38 37 42 39 31 31 44 31 43 41 41 37 2F 6D 61 63 4F 53 25 32 30 49 6E 73 74 61 6C 6C 25 32 30 44 61 74 61 
3:971  0:000   Adding Key: prev-lang:kbd: Size = 4, Data: 6B 6F 3A 30 
3:971  0:000   Adding Key: previous-system-uuid: String: Size = 36, Val = 'D910D268-909A-4CF6-A95C-A01D3A630F97'
3:971  0:000   Adding Key: security-mode: String: Size = 4, Val = 'none'
3:971  0:000   Adding Key: specialbootdevice: Size = 110, Data: 02 01 0C 00 D0 41 03 0A 00 00 00 00 01 01 06 00 00 17 03 12 0A 00 01 00 00 00 00 00 04 01 2A 00 02 00 00 00 28 40 06 00 00 00 00 00 D8 77 48 17 00 00 00 00 36 92 99 D5 4B EA 15 44 AA 7E ED AA 77 BE E3 B3 02 02 04 03 24 00 F7 FC 74 BE 7C 0B F3 49 91 47 01 F4 04 2E 68 42 68 D2 10 D9 9A 90 F6 4C A9 5C A0 1D 3A 63 0F 97 7F FF 04 00 

Spoiler

Last login: Fri Nov  8 22:44:18 on console

sherlocks@SherloccBookPro ~ % nvram -p

backlight-level i%05

efi-backup-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>2DCFE836-4404-4C80-AB32-62ACD78E462D</string></dict></dict><key>BLLastBSDName</key><string>disk1s2</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\D910D268-909A-4CF6-A95C-A01D3A630F97\System\Library\CoreServices\boot.efi</string></dict></array>

efi-backup-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%00%17%03%12%0a%00%01%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%d8wH%17%00%00%00%006%92%99%d5K%ea%15D%aa~%ed%aaw%be%e3%b3%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hB6%e8%cf-%04D%80L%ab2b%ac%d7%8eF-%04%04%9a%00\%00D%009%001%000%00D%002%006%008%00-%009%000%009%00A%00-%004%00C%00F%006%00-%00A%009%005%00C%00-%00A%000%001%00D%003%00A%006%003%000%00F%009%007%00\%00S%00y%00s%00t%00e%00m%00\%00L%00i%00b%00r%00a%00r%00y%00\%00C%00o%00r%00e%00S%00e%00r%00v%00i%00c%00e%00s%00\%00b%00o%00o%00t%00.%00e%00f%00i%00%00%00%7f%ff%04%00

fmm-computer-name Sherlocks%ec%9d%98 MacBook%c2%a0Pro

previous-system-uuid D910D268-909A-4CF6-A95C-A01D3A630F97

specialbootdevice %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%00%17%03%12%0a%00%01%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%d8wH%17%00%00%00%006%92%99%d5K%ea%15D%aa~%ed%aaw%be%e3%b3%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hBh%d2%10%d9%9a%90%f6L%a9\%a0%1d:c%0f%97%7f%ff%04%00

EmuVariableUefiPresent Yes

security-mode none

flagstate %00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00

SystemAudioVolumeDB %ea

prev-lang:kbd en:252

Clover.RootRW true

install-product-url x-osproduct://E86DE6B5-1263-4E5B-AB70-87B911D1CAA7/macOS%2520Install%2520Data

bluetoothActiveControllerInfo z%e0%89%04%00%00%00%00@%14%ac%d1%b8%e2%a4%d0

EFILoginHiDPI %00%00%00%00

csr-active-config w%02%00%00

SystemAudioVolume 4

Clover.DisableSleepProxyClient true

LocationServicesEnabled %01

sherlocks@SherloccBookPro ~ % sudo nvram -c

Password:

nvram: Error clearing firmware variables: (iokit/common) not permitted

sherlocks@SherloccBookPro ~ % 

 

if this case happen, how can we resolve?

nvram.plist

 

after press f11

Spoiler

3:962  0:000  PutNvramPlistToRtVars: nvram.plist not found
3:962  0:000  found 2 handles with audio
3:962  0:000  No AudioIoDevice stored
3:962  0:000  no stored audio parameters
3:962  0:000  === [ InitTheme ] =========================================

 

Spoiler

Last login: Sat Nov  9 00:39:59 on console

sherlocks@SherloccBookPro ~ % nvram -p     

LocationServicesEnabled %01

EmuVariableUefiPresent Yes

security-mode none

prev-lang:kbd ko:0

flagstate %00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00

SystemAudioVolumeDB %ed

bluetoothActiveControllerInfo z%e0%89%04%00%00%00%00@%14%ac%d1%b8%e2%a4%d0

EFILoginHiDPI %00%00%00%00

csr-active-config w%02%00%00

backlight-level i%05

SystemAudioVolume 7

specialbootdevice %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%00%17%03%12%0a%00%01%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%d8wH%17%00%00%00%006%92%99%d5K%ea%15D%aa~%ed%aaw%be%e3%b3%02%02%04%03$%00%f7%fct%be|%0b%f3I%91G%01%f4%04.hBh%d2%10%d9%9a%90%f6L%a9\%a0%1d:c%0f%97%7f%ff%04%00

sherlocks@SherloccBookPro ~ % 

 

cleaned nvram now.

 

EDIT1.

How can you remove Clover.* value in nvram on macos?

Edited by Sherlocks
11 minutes ago, Sherlocks said:

 

efi-backup-boot-device

efi-backup-boot-device-data

install-product-url

previous-system-uuid

Ok these variables will be removed. And all old files as well, but at start up a new copy of the nvram will be dumped to the boot partition for safely.

On 11/6/2019 at 6:43 PM, Pene said:

Hi, 

 

A friend is trying to install macOS with Clover, from a USB stick made by createinstallmedia, and 2 minutes before the end of first phase of install, he is getting the error:

"An error occurred validating the installer data. The download is either damaged or incomplete. Redownload the installer and try again."

He tried with both Mojave and Catalina USB installers (created with createinstallmedia from his Macbook), and he also tried with two different USB sticks, and the same error persists in all cases. 

 

Anyone saw this error before and has an idea what it could be?

Not sure, read what Sherlocks said about Installers failure.. may be the problem for you?

  • Like 2
1 minute ago, vector sigma said:

Ok these variables will be removed. And all old files as well, but at start up a new copy of the nvram will be dumped to the boot partition for safely.

 

yes. 1.01 actually there are no big issues for nvram usage. vector do you use hibernationfixup?

cloverdaemon only make nvram.plist after logout?

enter hibernation mode, have cloverdaemon remove that hibernationfixup makes nvram.plist in booted mac partition or not?

18 minutes ago, Sherlocks said:

How can you remove Clover.* value in nvram on macos?

Some variables cannot be removed due to SIP, but using bash:

sudo nvram -d variablename

 

in CloverDaemonNew:

nvram?.removeObject(forKey: "variablename") :)

  • Like 1
7 minutes ago, vector sigma said:

Some variables cannot be removed due to SIP, but using bash:


sudo nvram -d variablename

 

in CloverDaemonNew:

nvram?.removeObject(forKey: "variablename") :)

thanks a lot. i will test when you improve app, and report. also i can test i on old macos if you want to test. thank you for hard work:thumbsup_anim:

Edited by Sherlocks
  • Thanks 1
6 minutes ago, Sherlocks said:

cloverdaemon only make nvram.plist after logout?

Yes.

 

7 minutes ago, Sherlocks said:

vector do you use hibernationfixup

No, I don't even know what is it

 

7 minutes ago, Sherlocks said:

enter hibernation mode, have cloverdaemon remove that hibernationfixup makes nvram.plist in booted mac partition or not?

It should? But now I understand why you have more the one nvram.plist Lol. 

i think ia can intercept sleep and wake and do a clean up, but I have to write the code.

@Sherlocks, if this hibernationfixup can dump to /tmp/nvram.plist instead, there will be no need to do nothing. All will be happy.

  • Like 1
1 minute ago, vector sigma said:

Yes.

 

No, I don't even know what is it

 

It should? But now I understand why you have more the one nvram.plist Lol. 

i think ia can intercept sleep and wake and do a clean up, but I have to write the code.

 

if entire process is same way about logout hook like old rc script, there is no problem.

 

Q. It should? But now I understand why you have more the one nvram.plist Lol. 

A. hibernationfixup makes nvram.plist included hibernation in booted mac partition. so when enter hibernate mode, it will be not remove.

bcuz of reason, i asked question this "cloverdaemon only make nvram.plist after logout?"

thank you for clean.

23 minutes ago, Sherlocks said:

A. hibernationfixup makes nvram.plist included hibernation in booted mac partition. so when enter hibernate mode, it will be not remove.

Why  I told you that if this kext will dump to a temporary directory every one will e happy:

 

- #define FILE_NVRAM_NAME "/nvram.plist"

+ #define FILE_NVRAM_NAME "/private/tmp/nvram.plist"

 

link

 

they can make also a boot argument to override the path.. or detect C,l,o,v,e,r  as firmware.

 

EDIT

This only if is the kext that is doing the fix, and not the bootloader.

Edited by vector sigma
  • Like 1
On 11/7/2019 at 1:57 PM, Slice said:

No, I got the result and cancel experiments.

There are variables like InstallPhase1, I don't remember exactly. The problem appeared on my computer #1 which has good working NVRAM.

I have another thought that GraphicsOutputProtocols are different in UEFI and in legacy mode. And the difference influences on GraphicsConsole which may be a problem for the installer.

Well, he tried to Clean nvram using Clover method (it is a board with native nvram working) - and it didn't help.

 

But to my surprise, he says that when he switched the two DIMMs with other DIMMS (of the same size), it let him pass that stage and installed correctly. So maybe an SMBIOS issue?

The only changes I saw in his boot.log were regarding ScanSPD and PatchSMBIOS, from this (case with error):

67:270  0:000   partNum=CMW16GX4M2C3000C15
67:270  0:000  SMBIOS Type 17 Index = 0 => 0 0:
67:270  0:000  BANK 0 DIMM0 2998MHz 8192MB
67:270  0:000   partNum=CMW16GX4M2C3000C15
67:270  0:000  SMBIOS Type 17 Index = 1 => 1 2:
67:270  0:000  BANK 1 DIMM0 2998MHz 8192MB
67:270  0:000  mTotalSystemMemory = 16384

to this (case working properly):

3:924  0:000   partNum=F4-3200C16-8GTZB
3:924  0:000  SMBIOS Type 17 Index = 0 => 0 0:
3:924  0:000  BANK 0 DIMM0 3200MHz 8192MB
3:924  0:000   partNum=F4-3200C16-8GTZB
3:924  0:000  SMBIOS Type 17 Index = 1 => 1 2:
3:924  0:000  BANK 1 DIMM0 3200MHz 8192MB
3:924  0:000  mTotalSystemMemory = 16384

Honestly it seems voodoo to me :S

Maybe you or someone have a better idea of what it could cause it...

 

(I actually found before some posts related to this issue where people said they removed a DIMM or changed memory and it started working, and I thought it's nonsense, but apparently it's not...)

Edited by Pene
  • Like 3
On 11/7/2019 at 8:32 PM, Sherlocks said:

 

anyone who has system problem that repeatly wakeup and sleep every hours or 2hours after sleep.

i already use rc script mDNSResponder. but actually it doesn't work in catalina.

 

my setting

enable AppleRTC Patch

enable ACPI RTC Patch

 

is there script problem?

# Check that all variable are bound
set -u

#
# Source clover rc library if needed
#
if [[ ! "$(type -t GetNVRamKey)" == "function" ]]; then
    selfDir=$(cd $(dirname "$0") && pwd -P)
    source "${selfDir}"/../rc.clover.lib
fi

# Variables
mDNSResponderPList=/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
pListBuddy=/usr/libexec/PlistBuddy
disableOption='-DisableSleepProxyClient'

# Debug mode ?
[[ "$DEBUG" -ne 0 ]] && set -x

[[ ! -f "$mDNSResponderPList" ]] && exit 0

# Check if sleep proxy is not already disabled
already_disabled=$($pListBuddy -c 'Print ProgramArguments:' \
 "$mDNSResponderPList" | grep -c -- "$disableOption")

if [[ $already_disabled -eq 0 ]]; then
    echo "Disabling mDNS responder sleep proxy"
    $pListBuddy -c "Add ProgramArguments: string $disableOption" \
     "$mDNSResponderPList"
else
    echo "mDNS responder sleep proxy already disabled"
fi
 

my system has sleep sick

2019-11-07 02:03:15.255240+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"
2019-11-07 02:04:43.251968+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:04:43.251970+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:15:53.168855+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:15:53.168857+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:20:34.330425+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:20:34.330427+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:23:52.458953+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:23:52.458955+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:27:06.234257+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:27:06.234259+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:36:02.814919+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:36:02.814920+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:45:46.584514+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:45:46.584515+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:56:39.137461+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 02:56:39.137463+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:06:15.585653+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:06:15.585655+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:15:37.396535+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:15:37.396537+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:23:06.821319+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:23:06.821321+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:29:17.356199+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:29:17.356201+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:32:52.959052+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:32:52.959054+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:35:33.280214+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
2019-11-07 03:35:33.280216+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

 

source

https://apple.stackexchange.com/questions/151568/mac-wakes-up-from-sleep-every-two-hours-on-mac-os-x-yosemite

https://discussions.apple.com/thread/6611068?page=7

 

thanks in advance

 

EDIT1

also force to make power event. i didn't make power event. is it normal?

  appPID: 348

  유형: 깨우기

  일정:: com.apple.alarm.user-visible-Weekly Usage Report

  시간: 2019. 11. 10. 오전 2:11

  UserVisible: 0

 

  appPID: 350

  유형: 깨우기

  일정:: com.apple.alarm.user-visible-Weekly Usage Report

  시간: 2019. 11. 10. 오전 2:12

  UserVisible: 0

 

  appPID: 350

  유형: 깨우기

  일정:: com.apple.alarm.user-visible-Weekly Usage Report

  시간: 2019. 11. 10. 오전 4:31

  UserVisible: 0

 

  appPID: 348

  유형: 깨우기

  일정:: com.apple.alarm.user-visible-Weekly Usage Report

  시간: 2019. 11. 10. 오전 5:02

  UserVisible: 0



I have fixed this issue with "sudo pmset -a proximitywake 0"

No more wake up ini 2 or several hours automatically

  • Like 2
2 hours ago, Andres ZeroCross said:



I have fixed this issue with "sudo pmset -a proximitywake 0"

No more wake up ini 2 or several hours automatically

 

thank you for tip. i will check it in the morning tomorrow after sleep.

  • Like 1

Clover configurator FakeCPUID not update for Cascade Lake.

I thing Cascade Lake supported MacPro7,1

https://ark.intel.com/content/www/us/en/ark/products/codename/124664/cascade-lake.html

  • Like 1
On 11/8/2019 at 4:35 PM, Sherlocks said:

yes. at least Clover app support Clover.* nvram values. write is okay. but remove?

this is my nvram.plist after 10.15.2 beta1 in ESP.

 

in legacy and emuvariableuefi, it doen't matter. this values in nvram.plist

efi-backup-boot-device

efi-backup-boot-device-data

install-product-url

previous-system-uuid

 

also both keys causes osinstall.pkg installation issue for long time ago. so i added this line

install-product-url

previous-system-uuid

https://github.com/CloverHackyColor/CloverBootloader/blob/master/rEFIt_UEFI/Platform/DataHubCpu.c#L391

 

On 11/8/2019 at 4:53 PM, Sherlocks said:

enter hibernation mode, have cloverdaemon remove that hibernationfixup makes nvram.plist in booted mac partition or not?

Now it does:

 

18 hours ago, Andres ZeroCross said:



I have fixed this issue with "sudo pmset -a proximitywake 0"

No more wake up ini 2 or several hours automatically

 

no success. did you surely check com.apple.mDNSResponder.plist?

 

Spoiler

sherlocks@SherloccBookPro ~ % log show --style syslog | fgrep "Wake reason"

2019-11-09 18:19:21.702078+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

2019-11-09 18:19:53.748688+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

2019-11-09 18:19:53.748690+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

2019-11-09 22:35:24.021395+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

2019-11-09 23:56:53.153390+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-09 23:56:53.153392+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 01:15:21.959120+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 01:15:21.959122+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 01:32:07.282035+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 01:32:07.282038+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 03:32:06.053971+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

2019-11-10 03:33:35.470901+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 03:33:35.470903+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 03:47:04.749877+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 03:47:04.749879+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 04:19:09.488969+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 04:19:09.488971+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 05:25:23.583409+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 05:25:23.583412+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 05:28:13.310072+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 05:28:13.310074+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 07:28:13.056016+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

2019-11-10 07:29:35.291074+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 07:29:35.291076+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-11-10 08:11:58.154142+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

2019-11-10 08:11:58.154144+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

 

6 hours ago, vector sigma said:

 

Now it does:

 

 

i will report it. thank you for hard work

×
×
  • Create New...