Jump to content

Clover General discussion


ErmaC
29,866 posts in this topic

Recommended Posts

1 hour ago, Slice said:

Expected. 

This will be more correct


CHAR8 TempRev[128];
AsciiSPrint(TempRev, 128, "\n⌘  Powered by Clover v2.5k %s\n", gFirmwareRevision);
AsciiStrCatS(OEMString, MAX_OEM_STRING, TempRev);

 

Oh nice, it works yeiy..! Also, built succeeded with nasm 2.15 (RC) & GCC9.2. Many thanks.

 

Screen Shot 2019-11-06 at 17.13.57.jpg

Edited by Badruzeus
  • Like 1
Link to comment
Share on other sites

On 11/4/2019 at 7:02 PM, loganMac said:

 

Please share your result.  I also have RX580 and I noticed that OC no longer support Clover.  Currently, I use WEG and Liliu for RX580 to work with iMac13.2.  Not sure if latest OS will be compatible for RX580 and if WEG no longer working.  I felt OC is more advance for me, whereas, Clover is more friendly user. just my opinion. 

 

All these "misleading " write up for RX580 compatibility (OOB) but it turn out, u still need 3rd party kext to work.

Third-party kechtas are not required for rx580. You need the correct combinations of the model and the board ID. For example, Mac Pro 6.1 still starts rx5xx out of the box, without using WEG.
For RX580 to work with iMac13.2, AppleGraphicsDevicePolicy patch, which is implemented in WhateverGreen.kext 1.3.4, either this patch:
 

<key>KextsToPatch</key>

<array>

<dict>

<key>Comment</key>

<string>Black Screen Patch (c) Pike R. Alpha</string>

<key>Disabled</key>

<false/>

<key>Find</key>

<data>

Ym9hcmQtaWQ=

</data>

<key>Name</key>

<string>AppleGraphicsDevicePolicy</string>

<key>Replace</key>

<data>

Ym9hcmQtaXg=

</data>

</dict>

</array>

Edited by MakAsus
  • Like 1
  • Thanks 2
Link to comment
Share on other sites

1 hour ago, LAbyOne said:

 

Not my business and totally oft, but if I may, I would advise you to stay away from nasm 2.15 (RC)  as at the moment is still very Unstable and not really suggested for stable releases

Good advice, then I've rolled nasm back to 2.14.02 (Stable). Thanks anyway.

Link to comment
Share on other sites

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?

Edited by Pene
Link to comment
Share on other sites

32 minutes ago, 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:

Can't he try to let the app create the installer targeting the USB pen drive?

 

32 minutes ago, Pene said:

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

internet is full

Link to comment
Share on other sites

37 minutes ago, vector sigma said:

internet is full

Yes, full with a lot of bla bla about it but nothing coclusive ;) That's why I asked if someone here has personal experience with that error, and knows what it really caused by...

Edited by Pene
Link to comment
Share on other sites

1 hour ago, vector sigma said:

What I did when comes to me was to let the app target the drive directly, but I can't tell where the problem reside.

But wouldn't that just install it on the USB stick, and not create an installer?

Link to comment
Share on other sites

3 minutes ago, Pene said:

But wouldn't that just install it on the USB stick, and not create an installer?

Yes, forget me, you're right... as also i said:

1 hour ago, vector sigma said:

What I did when comes to me was to let the app target the drive directly, but I can't tell where the problem reside.

..wanted to say the same app gives an error creating a USB installer while was ok directly. 

  • Like 1
Link to comment
Share on other sites

3 hours ago, 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. 

 

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

 

Expired certificate...?

How about Terminal: date 0701172919 // before createinstallmedia?

Edited by Badruzeus
  • Like 2
Link to comment
Share on other sites

hi,anyone knows how to fix this error,pxsx cannot assert wake from d3cold,i received this error installing catalina on my acer v3 471g,i dont received this error before with macos  mojave and lower version of macos

Edited by cyrhex
Link to comment
Share on other sites

3 hours ago, Badruzeus said:

 

Expired certificate...?

How about Terminal: date 0701172919 // before createinstallmedia?

Mmmm, it's an interesting idea, but the error displayed is different than the one in that article, and he downloaded them yesterday, so it can't be the case of an expired cert.

Edited by Pene
  • Like 1
Link to comment
Share on other sites

15 hours ago, 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?

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! 

  • Thanks 1
Link to comment
Share on other sites

12 hours ago, Pene said:

Mmmm, it's an interesting idea, but the error displayed is different than the one in that article, and he downloaded them yesterday, so it can't be the case of an expired cert.

I'm not really sure if adding `--downloadassets` with createinstallmedia (10.14++) will make any difference related to those "error validation", but give it a try.

Edited by Badruzeus
  • Like 1
Link to comment
Share on other sites

58 minutes ago, 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! 

Thank you for your reply, Slice.

After excluding about every other possibility I could think off, I also started to think about NVRAM. I specifically suspect maybe something in the Boot* variables, which the installer probably tries to get/set at that stage, and maybe something fails there from some reason. If no other solution works we will probably try Legacy as you say.

 

By the way, did you try a reset Nvram from Clover when you had that problem? 

 

11 minutes ago, Badruzeus said:

I'm not really sure if adding `--downloadassets` with createinstallmedia (10.14++) will make any difference related to those "error validation", but give it a try.

Doubt it. As the same USB stick works when installed in a virtual machine. So it's not a problem with it.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Pene said:

 

 

By the way, did you try a reset Nvram from Clover when you had that problem? 

 

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.

  • Thanks 1
Link to comment
Share on other sites

 

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

Edited by Sherlocks
Link to comment
Share on other sites

On 11/6/2019 at 7:59 AM, MakAsus 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

Link to comment
Share on other sites

16 minutes ago, vector sigma said:

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

dspc.png.6a465ed1e98f8fb55cc776096883c54a.png

daemon.png.c8bb2c4d4e38cdf4559cb62d0140c4b3.png

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.

1436933089_ScreenShot2019-11-07at11_47_06PM.png.b4406aaf080969da724645ea9fa0b35e.png

 

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

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 by vector sigma
  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...