Sherlocks Posted November 7, 2019 Share Posted November 7, 2019 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. Link to comment Share on other sites More sharing options...
Slice Posted November 7, 2019 Share Posted November 7, 2019 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. Link to comment Share on other sites More sharing options...
vector sigma Posted November 7, 2019 Share Posted November 7, 2019 (edited) 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 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 7, 2019 Share Posted November 7, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
vector sigma Posted November 7, 2019 Share Posted November 7, 2019 (edited) 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: nvram dump in boot partinion. 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 2 Link to comment Share on other sites More sharing options...
Slice Posted November 8, 2019 Share Posted November 8, 2019 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. 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 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? Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 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: nvram dump in boot partinion. 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)? Link to comment Share on other sites More sharing options...
Slice Posted November 8, 2019 Share Posted November 8, 2019 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. Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
Slice Posted November 8, 2019 Share Posted November 8, 2019 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. 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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: nvram dump in boot partinion. 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 Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 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? 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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: set Clover.NVRAMpath=VolumeUUID CloverDaemonNew will always write the nvram.plist to a mounted volume (the same) What do you think? Edited November 8, 2019 by vector sigma Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 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: set Clover.NVRAMpath=VolumeUUID 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 Link to comment Share on other sites More sharing options...
Slice Posted November 8, 2019 Share Posted November 8, 2019 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. 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 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. Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 (edited) Of course, after F11 then you have to boot otherwise the old file will be read again. Edited November 8, 2019 by vector sigma Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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 November 8, 2019 by Sherlocks Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 @Sherlocks based on what @Slice said (that I agree), I'm going to delete the code that search for the nvram.plist in all volumes and delete all the instance. There's no need. Link to comment Share on other sites More sharing options...
vector sigma Posted November 8, 2019 Share Posted November 8, 2019 (edited) 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? the contents of the file (Clover bug). a cleaned nvram and all is perfect because at next reboot a new plist will be created and Clover read the new one. a cleaned nvram, but Clover next reboot ignore it and read another one. Clover bug. What of these happens? Edited November 8, 2019 by vector sigma 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted November 8, 2019 Share Posted November 8, 2019 (edited) 25 minutes ago, vector sigma said: this is not the problem. The question is: what goes in nvram (IODeviceTree:/options) then? the contents of the file (Clover bug). a cleaned nvram and all is perfect because at next reboot a new plist will be created and Clover read the new one. 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 November 8, 2019 by Sherlocks Link to comment Share on other sites More sharing options...
Recommended Posts