Clover General discussion

[vector sigma]

1 hour ago, Sherlocks said:

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

Of course that he can't with rc scripts. It will work if you use this:

using the new app.

 

Edited November 7, 2019 by vector sigma

[Sherlocks]

16 minutes ago, vector sigma said:

Of course that he can't with rc scripts. It will work if you use this:

using the new app.

 

 

thanks alot.

there is something issue like legacy system for reset nvram.

except case about hibernation(hibernationfixup), nvram file is save in ESP partition.

but your app makes nvram file in root of macos partition.

 

if we clean nvram in Clover GUI, we can't erase nvram.plist in root of macos partition.

is there solution for clean nvram.plist?

 

EDIT.

also i erased rc script all for test. my system use OsxAptioFix2Drv + EmuVariableUefi.efi.

i checked daemon log. here is

- System start at 2019-11-07 11:37:44
--------------------------------------------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
unloading old CloverDaemon

- System power off at 2019-11-07 11:40:29
nvram saved correctly at '/nvram.plist'.
DisableSleepProxyClient: trying to disable the service.. SIP permitting.

---------------------------------------------------
CloverDaemon start at 2019-11-07 23:41:04
---------------------------------------------------
/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable
 

Edited November 7, 2019 by Sherlocks

[vector sigma]

11 minutes ago, Sherlocks said:

if we clean nvram in Clover GUI, we can't erase nvram.plist in root of macos partition.

is there solution for clean nvram?

That looks like a bug in Clover. If you clear the nvram in Clover GUI then it should not read the nvram.plist, or start a new empty nvram, so that the next shut down the new plist will be empty or with new values. Otherwise guys who still install on MBR insteag of GPT can't never clear it?

11 minutes ago, Sherlocks said:

/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable

This is the old daemon, should no longer log at second shut down, let me know.

Edited November 7, 2019 by vector sigma

[Sherlocks]

6 minutes ago, vector sigma said:

That looks like a bug in Clover. If you clear the nvram in Clover GUI then it should not read the nvram.plist so that the next shut down the new plist will be empty or with new values. Otherwise guys who still install on MBR insteag of GPT can't never clear it?

 

legacy+GPT is best to deal with clean nvram.plist.
legacy+MBR, clover now can't clean nvram.plist.
just only can remove nvram.plist on ESP partition in Clover GUI.
i considered it before for clean nvram.plist. example hibernation situation. at that time, some system can't wake hibernation mode. because nvram.plist save hibernation info like example Boot000 values. it was resolved long time ago.

[vector sigma]

2 minutes ago, Sherlocks said:

just only can remove nvram.plist on ESP partition in Clover GUI.

Just a question. What if Clover remove the plist in the ESP but another one is present else where?

 

The new Daemon if found "/" already writable didn't search for the boot partition. Let me study something. Let you now within the time to write some code.

[Sherlocks]

1 minute ago, vector sigma said:

Just a question. What if Clover remove the plist in the ESP but another one is present else where?

 

The new Daemon if found "/" already writable didn't search for the boot partition. Let me study something. Let you now within the time to write some code.

 

Q. What if Clover remove the plist in the ESP but another one is present else where?

A. avoid this case, we considered rc script(made it long time ago), when mac restart, rc script checked nvram.plist in root(mac partition), end erase, and make nvram.plist on ESP.

maybe it is correct. this work is old.

 

80.save_nvram_plist.local

 

#!/bin/bash
#
# 2017 (c) syscl/lighting/Yating Zhou, tluck, Sherlocks, lvs1974
# dump NVRAM for UEFI Clover with EmuVariable or Legacy Clover
#
# Script version info
gScriptVersion=1.16.6
#================================= GLOBAL VARS ==================================
#
# The script expects '0.5' but non-US localizations use '0,5' so we export
# LC_NUMERIC here (for the duration of the 80.save_nvram_plist.local) to prevent errors
#

 

Q. Hibernationfixup case.

A. when enter Hibernation mode, Hibernationfixup makes nvram.plist in root(mac partition). in this case, actually, there are two nvram. root(mac partition) and root(ESP)

and after enter hibernation, and wakeup, we meet clover gui, and enter mac partition. when enter clover GUI, clover read recent nvram.plist. it means to check date of nvram.plist.

and after enter macos, we can see two nvram.plist. then when restart, rc script remove nvram.plist in root(mac partition). and make nvram.plist or skip if nvram.plist info is same.

[Slice]

4 hours ago, loganMac said:

 

Just to recap your statement on RX580 w/out the need of WEG but by adding KextsToPatch script it should work.   Is Liliu still needed? 

 

I forgot to do a screenshot, what odd was when I view in DPCIManager under PCI List, the device name listed as Radeon 470 instead of rx580 but in the Mac About, it show rx580

The mistake of DPCIManager.

3 hours ago, vector sigma said:

Just a question. What if Clover remove the plist in the ESP but another one is present else where?

 

The new Daemon if found "/" already writable didn't search for the boot partition. Let me study something. Let you now within the time to write some code.

What is possible reason to remove any nvram.plist? This reason must explain what is happen if other nvram.plist will be found.

[vector sigma]

22 minutes ago, Slice said:

What is possible reason to remove any nvram.plist? This reason must explain what is happen if other nvram.plist will be found.

Hi, not sure I've undertood you correctly. Is good to clean old nvram.plist files or not?

 

the first thought is that if you delete it at boot time, at the next reboot there will be another one with a newer timestamp, so why cares?
If you delete it, instead and a kp happens, there will be no nvram. Perhaps the old plist is better than nothing?

Edited November 7, 2019 by vector sigma
typos

[Sherlocks]

1 hour ago, vector sigma said:

Hi, not sure I've undertood you correctly. Is good to clean old nvram.plist files or not?

 

the first thought is that if you delete it at boot time, at the next reboot there will be another one with a newer timestamp, so why cares?
If you delete it, instead and a kp happens, there will be no nvram. Perhaps the old plist is better than nothing?

 

seems fixed sleep issue about 2hours wakeup/sleep repeatly. it is great. thank you.

what is difference from old script?

can you fix this issue for old script?

 

EDIT

OC Bootloader also support nvram.plist if board is not support native nvram.

https://github.com/acidanthera/OcSupportPkg/tree/master/Utilities/LogoutHook

it also makes nvram.plist in ESP.

Edited November 7, 2019 by Sherlocks

[vector sigma]

2 hours ago, Sherlocks said:

what is difference from old script?

There are no scripts in the new daemom. Before was (CloverDaemon + rc scripts) now only CloverDaemonNew.

Anyway I fixed it:

1. nvram dump in boot partinion.
2. delete nvram.plist if found in all mounted volumes

Try Clover.app_v1.01.zip and let me know

 

EDIT

two reboots are needed to make it loaded.

 

EDIT 2

in the cases you have the old app opened close it before run the new one. Otherwise wont run because only one app is allowed.

 

2 hours ago, Sherlocks said:

OC Bootloader also support nvram.plist if board is not support native nvram.

Can work with it if they are using EmuVariableUefi.efi automatically. If not just type this in Terminal:

sudo nvram TestEmuVariableUefiPresent=true

and it will start dumping also if the emuvariable is not present.

Edited November 7, 2019 by vector sigma

[Slice]

8 hours ago, vector sigma said:

Hi, not sure I've undertood you correctly. Is good to clean old nvram.plist files or not?

 

the first thought is that if you delete it at boot time, at the next reboot there will be another one with a newer timestamp, so why cares?
If you delete it, instead and a kp happens, there will be no nvram. Perhaps the old plist is better than nothing?

I think we should never delete any nvram.plist.

Clover checks modification date and use the most recent file.

[Sherlocks]

7 hours ago, Slice said:

I think we should never delete any nvram.plist.

Clover checks modification date and use the most recent file.

 

i have a question.

if we want to clean nvram in legacy or EmuVariableUefiPresent, how can i reset nvram in CLOVER GUI?

 

[Sherlocks]

12 hours ago, vector sigma said:

There are no scripts in the new daemom. Before was (CloverDaemon + rc scripts) now only CloverDaemonNew.

Anyway I fixed it:

1. nvram dump in boot partinion.
2. delete nvram.plist if found in all mounted volumes

Try Clover.app_v1.01.zip and let me know

 

EDIT

two reboots are needed to make it loaded.

 

EDIT 2

in the cases you have the old app opened close it before run the new one. Otherwise wont run because only one app is allowed.

 

Can work with it if they are using EmuVariableUefi.efi automatically. If not just type this in Terminal:

sudo nvram TestEmuVariableUefiPresent=true

and it will start dumping also if the emuvariable is not present. 

 

perfect working. thank you so much. can we use this new cloverdaemon in old macos(10.9 and under)?

[Slice]

4 minutes ago, Sherlocks said:

 

i have a question.

if we want to clean nvram in legacy or EmuVariableUefiPresent, how can i reset nvram in CLOVER GUI?

 

When you reach the CloverGUI then NVRAM was created in memory. nvram.plist was already read and interpretated it was read at start of Clover. You may clean nvram variables in memory just by typing F11 but it will not be written to file.

When you started macOS these variables will be accessible by the system and will be saved into new nvram.plist by the rc.script.

3 minutes ago, Sherlocks said:

 

perfect working. thank you so much. can we use this new cloverdaemon in old macos(10.9 and under)?

I think old system should use old rc.script.

[Sherlocks]

2 minutes ago, Slice said:

When you reach the CloverGUI then NVRAM was created in memory. nvram.plist was already read and interpretated it was read at start of Clover. You may clean nvram variables in memory just by typing F11 but it will not be written to file.

When you started macOS these variables will be accessible by the system and will be saved into new nvram.plist by the rc.script.

When you reach the CloverGUI then NVRAM was created in memory. nvram.plist was already read and interpretated it was read at start of Clover. You may clean nvram variables in memory just by typing F11 but it will not be written to file.

- yes. it is correct when there is no two nvram.plist both root(mac) and root(esp).

 

When you started macOS these variables will be accessible by the system and will be saved into new nvram.plist by the rc.script.

if there are two nvram.plist both root(mac) and root(esp), to reset nvram, we use f11, clover clear nvram.plist in root(esp), but there is nvram.plist in root(mac). after f11, clover restart and read nvram.plist(mac partition).

 

At that time, the remaining nvram.plist is read regardless of the latest date of nvram.plist. So my guess is that nvram.plist in the mac partition as much as possible should be deleted. Of course, hibernation doesn't matter because the nvram.plist is created in the Mac partition's root folder before the hibernationfixup file enters hibernation mode.

[Slice]

No. Clover at start will search all nvram.plist in all volumes then compare their modification date and chose one most recent. It may be in ESP or it may be in macOS root folder. One of them most recent.

The content of the winner Clover will keep in memory and it will not delete or rewrite any nvram.plist. It just keep variables in own memory.

Typing F11 we don't erase nvram.plist. It is the same as before. We just clean variables in memory.

Starting macOS we get variables from memory and will not look for any nvram.plist.

Finishing OS we will write new nvram.plist overwriting old one. The new nvram.plist will be most recent then any nvram.plist found on this computer and will be used next Clover start.

[Sherlocks]

No. Clover at start will search all nvram.plist in all volumes then compare their modification date and chose one most recent. It may be in ESP or it may be in macOS root folder. One of them most recent.

- yes. that's right. i already considered before.

The content of the winner Clover will keep in memory and it will not delete or rewrite any nvram.plist. It just keep variables in own memory.

- strange. in legacy and EmuVariable case, not keep nvram value on macos if there is no rc script with nvram.plist compared native nvram. i tested it several times

Typing F11 we don't erase nvram.plist. It is the same as before. We just clean variables in memory.

 

https://github.com/CloverHackyColor/CloverBootloader/blob/master/rEFIt_UEFI/refit/main.c#L1741

 

- yes. if system support native nvram, we just clean variables.
https://github.com/CloverHackyColor/CloverBootloader/blob/master/rEFIt_UEFI/Platform/Nvram.c#L370

if we boot macos with legacy or EmuVariable, can we write nvram in memory?. it means that no need rc script?

legacy and EmuVariable system. clover just find nvram.plist and erase nvram.plist on ESP partition.
https://github.com/CloverHackyColor/CloverBootloader/blob/master/rEFIt_UEFI/Platform/Nvram.c#L271

 

i clean nvram.plist in F11. and clover not found nvram.plist and after boot mac, all values of clover app is clean.

here is proven pic.

 

Last login: Fri Nov  8 20:32:40 on console

sherlocks@SherloccBookPro ~ % nvram -p

LocationServicesEnabled %01

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

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 %ea

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 4

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 ~ % 

 

Starting macOS we get variables from memory and will not look for any nvram.plist.

clover find nvram.plist if system not support native nvram
- legacy and EmuVariable system, clover read nvram.plist
3:968  0:000  PutNvramPlistToRtVars: nvram.plist not found

 

Finishing OS we will write new nvram.plist overwriting old one. The new nvram.plist will be most recent then any nvram.plist found on this computer and will be used next Clover start.

- yes. it is correct.

but if we clean nvram.plist in GUI, there is old nvram.plist and clover will read old nvram.plist.

 

i'm using fix-free2000+EmuVariable mode.
i tested several test for nvram.plist and save nvram value when using legacy and EmuVariable. i never save native nvram on macos. my system needs nvram.plist. and depends on nvram.plist to read lcd backlight and etc.

 

sorry for my bad english. thanks in advance

Edited November 8, 2019 by Sherlocks

[Sherlocks]

14 hours ago, vector sigma said:

There are no scripts in the new daemom. Before was (CloverDaemon + rc scripts) now only CloverDaemonNew.

Anyway I fixed it:

1. nvram dump in boot partinion.
2. delete nvram.plist if found in all mounted volumes

Try Clover.app_v1.01.zip and let me know

 

EDIT

two reboots are needed to make it loaded.

 

EDIT 2

in the cases you have the old app opened close it before run the new one. Otherwise wont run because only one app is allowed.

 

Can work with it if they are using EmuVariableUefi.efi automatically. If not just type this in Terminal:

sudo nvram TestEmuVariableUefiPresent=true

and it will start dumping also if the emuvariable is not present.

 

i got some problem, ESP partition mount issue. seems like rare issue.

Spoiler

Kext with invalid signature (-2147416000) allowed: <OSKext 0x7fe65472baa0 [0x7fff8aca6d10]> { URL = "file:///System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext/", ID = "com.apple.kpi.bsd" }
Disabling KextAudit: SIP is off
(kernel) Kext loading is disabled.
Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled.
/System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled.
mount_msdos: msdos filesystem is not available
mount: /Volumes/PKFWljNpIB failed with 71
nvram saved to u disk with UUID 0E239BC6-F960-3107-89CF-1C97F78BB46B
---------------------------------------------------
CloverDaemon start at 2019-11-08 21:29:19
---------------------------------------------------
/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable
--------------------------------------------
- System start at 2019-11-08 09:29:19
--------------------------------------------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
unloading old CloverDaemon

- System power off at 2019-11-08 09:30:53
try to making '/' writable as Clover.DisableSleepProxyClient=true.
DisableSleepProxyClient: service already disabled

nvram saved to u disk with UUID 0E239BC6-F960-3107-89CF-1C97F78BB46B
---------------------------------------------------
CloverDaemon start at 2019-11-08 21:31:30
---------------------------------------------------
/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable
--------------------------------------------
- System start at 2019-11-08 09:31:30
--------------------------------------------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
unloading old CloverDaemon
making '/' writable as Clover.RootRW=true
try to making '/' writable as Clover.DisableSleepProxyClient=true.
DisableSleepProxyClient: service already disabled

- System power off at 2019-11-08 09:32:47
DisableSleepProxyClient: service already disabled

nvram saved to am disk with UUID 0E239BC6-F960-3107-89CF-1C97F78BB46B
---------------------------------------------------
CloverDaemon start at 2019-11-08 21:33:21
---------------------------------------------------
/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable
--------------------------------------------
- System start at 2019-11-08 09:33:21
--------------------------------------------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
unloading old CloverDaemon
making '/' writable as Clover.RootRW=true
try to making '/' writable as Clover.DisableSleepProxyClient=true.
DisableSleepProxyClient: service already disabled

- System power off at 2019-11-08 09:43:27
DisableSleepProxyClient: service already disabled

---------------------------------------------------
CloverDaemon start at 2019-11-08 21:44:19
---------------------------------------------------
/Library/LaunchDaemons/com.projectosx.clover.daemon.plist: Operation now in progress
--------------------------------------------
- System start at 2019-11-08 09:44:19
--------------------------------------------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
unloading old CloverDaemon

- System power off at 2019-11-08 09:45:40
try to making '/' writable as Clover.DisableSleepProxyClient=true.
DisableSleepProxyClient: service already disabled

nvram saved to u disk with UUID 0E239BC6-F960-3107-89CF-1C97F78BB46B
---------------------------------------------------
CloverDaemon start at 2019-11-08 21:46:14
---------------------------------------------------
/Library/LaunchDaemons/com.projectosx.clover.daemon.plist: Operation now in progress

 

Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled.
/System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled.
mount_msdos: msdos filesystem is not available
mount: /Volumes/PKFWljNpIB failed with 71

 

i tried to clean system for nvram.

first, in clover app v1.01. and make rw and disabled sleep options.

and check nvram -p, clover app write nvram value without problem. and reboot

typed f11, nvram.plist, then boot macos, and type nvram -p.

there is no value that clover app wrote values. it's normal.

once again, i try to check each rw and disabled sleep options.

then i try to see check box again, rw check box is checked. but disable sleep check is unchecked. but there are two nvram values on "nvram -p"

 

thanks in advance for hard work.

 

EDIT.

tested repeatly 2hours wake/sleep again.

perfect!.

Spoiler

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) . .   <--------- i'm used old sleep proxy client fix. but not working every times wake. it causes my laptop life and fan on/off life.

2019-11-07 23:25:19.226519+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

2019-11-07 23:25:39.777203+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

2019-11-07 23:25:39.777205+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User)

2019-11-08 00:16:05.504165+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

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

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

2019-11-08 07:55:16.773409+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

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

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

2019-11-08 19:24:29.580431+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

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

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

2019-11-08 20:50:36.554764+0900  localhost powerd[71]: [powerd:sleepWake] Wake reason: "<private>"  identity: "<private>"

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

2019-11-08 20:51:56.808281+0900  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: PWRB (User) .    <-------- vector new sleep proxy client fix. never wakeup until i press power button. it can help save battery more.

sherlocks@SherloccBookPro ~ % 

 

Edited November 8, 2019 by Sherlocks

[vector sigma]

29 minutes ago, Sherlocks said:

/Library/Application Support/Clover/CloverDaemon: line 131: /etc/rc.clover.lib: No such file or directory
/Library/Application Support/Clover/CloverDaemon: line 22: CLOVER_LOG_LOCATION: unbound variable

Hi Sherlocks, unfortunately this is the old daemon. I don't want to delete it, but looks like everytime going to conflict... what to do?

[Sherlocks]

3 minutes ago, vector sigma said:

Hi Sherlocks, unfortunately this is the old daemon. I don't want to delete it, but looks like everytime going to conflict... what to do?

 

yes. looks like just old cloverdaemon log makes confilict.

[vector sigma]

2 hours ago, Slice said:

2 hours ago, Sherlocks said:

perfect working. thank you so much. can we use this new cloverdaemon in old macos(10.9 and under)?

I think old system should use old rc.script.

Swift can work in 10.9 if I set the deployment target to it, but not in 10.8 and older, no way. The Clover.app in 10.11+. 

 

Guys, to be honest the old rcscript often fail for me, not a problem because I'm running in UEFI. If you want I can add the possibility to override the path where to save the nvram:

1. set Clover.NVRAMpath=VolumeUUID
2. CloverDaemonNew will always write the nvram.plist to a mounted volume (the same)

What do you think?

Edited November 8, 2019 by vector sigma

[Sherlocks]

1 minute ago, vector sigma said:

Swift can work in 10.9 if I set the deployment target to it, but not in 10.8 and older, no way. The Clover.app in 10.11+. 

 

Guys, to be honest the old rcscript often fail for me, not a problem but because I'm running in UEFI, but if you want I can add the possibility to override the path where to savethe nvram:

1. set Clover.NVRAMpath=VolumeUUID
2. CloverDaemonNew will always write the nvram.plist to a mounted volume

What do you think?

 

sleep proxy client problem also happen in native nvram system? 2hour wake/sleep repeatly.

if there is, seems better makes only script with daemon without rc script.

 

old sleep proxy client script not working properly on old macos.

 

if new cloverdaemon work in 10.6~10.9, we just type nvram to work old sleep proxy client when cant run clover app on old macos?

 

sorry for my bad english

[Slice]

Option 2 is enough. Clover will find nvram.plist in those volume.

 

@Sherlocks

Quote

- strange. in legacy and EmuVariable case, not keep nvram value on macos if there is no rc script with nvram.plist compared native nvram. i tested it several times

Clover keeps nvram values in memory. OS will use it.

rc.script will write these value and new values set by OS to nvram.plist at reboot.

Quote

if we boot macos with legacy or EmuVariable, can we write nvram in memory?. it means that no need rc script?

legacy and EmuVariable system. clover just find nvram.plist and erase nvram.plist on ESP partition.

Clover will write nvram in memory.

rc.script will save nvram values into nvram.plist at restart. It is needed in legacy system to save variables into nvram.plist.

Quote

i clean nvram.plist in F11. and clover not found nvram.plist and after boot mac, all values of clover app is clean.

Because F11 will clean variables in memory, not in nvram.plist. Clover.app sees values in memory not from plist.

[Sherlocks]

11 minutes ago, Slice said:

Option 2 is enough. Clover will find nvram.plist in those volume.

 

@Sherlocks

Clover keeps nvram values in memory. OS will use it.

rc.script will write these value and new values set by OS to nvram.plist at reboot.

Clover will write nvram in memory.

rc.script will save nvram values into nvram.plist at restart. It is needed in legacy system to save variables into nvram.plist.

Because F11 will clean variables in memory, not in nvram.plist. Clover.app sees values in memory not from plist.

It is needed in legacy system to save variables into nvram.plist.

- does it mean that actually legacy system cant save in memory right? altough to type nvram values. so save values into nvram.plist and there is no nvram value in memory about legacy system. clover read and check and load and write nvram values in memory from nvram.plist when enter GUI. is it right?

 

Did you test emuvariable or legacy system?

i tested it. strange.... there is prove.

Clover app read other GUID memory part? hidden nvram values not related in nvram -p?

 

and in macos clover app write other GUID memory part? like Clover.RW or Sleep proxy clien patch. like clover boot chime nvram value?

Edited November 8, 2019 by Sherlocks

[vector sigma]

9 minutes ago, Slice said:

Clover.app sees values in memory not from plist.

Yes!

2 minutes ago, Sherlocks said:

It is needed in legacy system to save variables into nvram.plist.

- does it mean that actually legacy system cant save in memory right? altough to type nvram values. so save values into nvram.plist and there is no nvram value in memory about legacy system. clover read and check and load and write nvram values in memory from nvram.plist when enter GUI. is it right?

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.