Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

vector sigma
vector sigma
Posted
Posted (edited)
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
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited)

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
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted (edited)
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
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted

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.

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
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.

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited)
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
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted (edited)
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
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
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
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
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?

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted (edited)
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
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
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
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
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.

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited)
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
Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)
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
Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
Posted
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
Link to comment
Share on other sites
nmano
nmano
Posted
Posted

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
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
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:

 

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
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

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
On 11/8/2019 at 7:30 PM, vector sigma said:

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.

There is no sense to save nvram.plist somewhere not in root. Clover will check only root folders of all volumes.

Let me explain about HibernationFixup.

For the hibernation success in 25 mode OS must save some variables in NVRAM (boot0082, boot-image, boot-signature). They will not be saved by rc.script or by the command sudo nvram -p because they have other GUID. AppleNvramGuid instead of AppleBootGuid.

The kext HibernationFixup magically do the works creating nvram.plist with those variable. The question is "does it save other variables?". Will it overwrite nvram.plist at the same place? Or may be Clover should merge two nvram.plist? 

  • Like 3
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
6 hours ago, Slice said:

There is no sense to save nvram.plist somewhere not in root. Clover will check only root folders of all volumes.

Let me explain about HibernationFixup.

For the hibernation success in 25 mode OS must save some variables in NVRAM (boot0082, boot-image, boot-signature). They will not be saved by rc.script or by the command sudo nvram -p because they have other GUID. AppleNvramGuid instead of AppleBootGuid.

The kext HibernationFixup magically do the works creating nvram.plist with those variable. The question is "does it save other variables?". Will it overwrite nvram.plist at the same place? Or may be Clover should merge two nvram.plist? 

Thanks for the explanation!  Can I recreate those vars boot0082, boot-image, boot-signature? .. we can write to the plist..

Link to comment
Share on other sites
Andres ZeroCross
Andres ZeroCross
Posted
Posted
15 hours ago, Sherlocks said:

 

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

 

  Reveal hidden contents

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)

 

 

i will report it. thank you for hard work


I don't know what should i check in mDNSResponder.plist.,, I just can say i have that issue several weeks ago, and proximitywake set to 0 is the solution. No more random wake,,
image.png.8463eb20cafd69ef1b5192854f8a0488.png
Sleep and wake cycle normally with USB device (keyboard / mouse), i don't patch device RTC in ACPI. it's still "0x08"

image.thumb.png.e9cfee5006cd14f1a13ed16b09c48c33.png

Link to comment
Share on other sites
Pene
Pene
Posted
Posted (edited)

 

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

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. 

 

On 11/7/2019 at 11:38 AM, Slice said:

I had similar error resolved by boot with legacy Clover. Wow! It works! I didn't understand what is happen. May be some variable in NVRAM is a culprit.

Another time I installed Mojave and got a message "The installer is broken and can't be used". The solution is set data to half year ago. That's fine! 

 

Following this problem, I have narrowed it down to the rank of DIMMs used.

This error appears during install when he is trying to install with Single-Rank DIMMs (2x8GB).

The error does not appear, and he can install successfully, when trying to install with Dual-Rank DIMMs (also 2x8GB).

 

The memory rank information appears in SMBIOS, at Type17->Attributes (0Bh), maybe it needs to be taken into consideration for something? (currently we are not doing anything with it within Clover)

It still baffles me though how it can affect the installer to give this error. Also, if the Single-Rank DIMMs are put back after macOS is already installed, everything seems to be functioning properly.

Edited by Pene
  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...