Clover General discussion

[Slice]

20 hours ago, MifJpnAlphaPlus said:

Thank you for your wonderful development.
When I tried using the latest CLOVER, I found that BigSur, Monterey, and Ventura were reset at startup and could not be booted.
Have you added any settings?

Nothing new.

But I tested every commit with Monterey 12.5.1

[MifJpnAlphaPlus]

Please help us. Please help us.
In 6890d48, BigSur,Monterey,Ventura all boot.

EFI.6890d48.zip

But with f639353, everything does not bootEFI

EFI.f639353.zip
I just want to enjoy Hackintosh till the end like everyone else, and everyone likes Clover.

Please help us.

(Every EFI include log)

 

Edited September 1, 2022 by MifJpnAlphaPlus

[Matgen84]

Hi @Slice

I can't build Clover r5149 commit f639353 with XCODE 12.4 (macOS Catalina)

[GENFW] BdsDxe
/Users/mathieu/src/Cloverbootloader/rEFIt_UEFI/Platform/DataHubCpu.cpp:54:12: error: unused variable 'CDM' [-Werror,-Wunused-const-variable]
const char CDM[16] = "sha2-384";
           ^
1 error generated.
make: *** [/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/OUTPUT/Platform/DataHubCpu.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/mathieu/src/Cloverbootloader/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -

EDIT: no issues with GCC 🙂

Edited September 2, 2022 by Matgen84
EDIT: no issues with GCC

[Slice]

12 hours ago, Matgen84 said:

Hi @Slice

I can't build Clover r5149 commit f639353 with XCODE 12.4 (macOS Catalina)

[GENFW] BdsDxe
/Users/mathieu/src/Cloverbootloader/rEFIt_UEFI/Platform/DataHubCpu.cpp:54:12: error: unused variable 'CDM' [-Werror,-Wunused-const-variable]
const char CDM[16] = "sha2-384";
           ^
1 error generated.
make: *** [/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit/OUTPUT/Platform/DataHubCpu.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8/X64/rEFIt_UEFI/refit]


build.py...
 : error F002: Failed to build module
	/Users/mathieu/src/Cloverbootloader/rEFIt_UEFI/refit.inf [X64, XCODE8, RELEASE]

- Failed -

EDIT: no issues with GCC 🙂

OK, confirmed and fixed.

Thanks for the signal.

[ameenjuz]

@Slice

Sometime i have black screen issue during playing video on Quicktime player

do you have any idea? how to fix this

Is It framebuffer issue or related ig platformid?

[Slice]

5 hours ago, ameenjuz said:

@Slice

Sometime i have black screen issue during playing video on Quicktime player

do you have any idea? how to fix this

Is It framebuffer issue or related ig platformid?

I afraid you got black screen on DRM video. Consult WhateverGreen documentation if it can help you.

For my case DRM plays fine with AMD RX570 and SMBIOS iMacPro1,1. But if I switch on IGPU HD530 in BIOS and set SMBIOS iMac then I also get black screen in DRM video.

For system Mojave and older there was Shiki project for this. Not for Monterey.

AFAIK QuickTime player will work fine in Ventura.

[MifJpnAlphaPlus]

@Slice

Hello

I can only suggest to you.
Think logically.
The iMacPro1.1 should not have a T2 chip. If there are no other T2 chips, HW.Target and BridgeOSHardwareModel are X86LEGACYAP.
Additionally, since the T2 chip is not included, some of these variable values will not be scrutinized.
So, as you say, setting HardwareModel to x86legacyap is the right thing to do for Macs that don't have a T2 chip.

I tested it, but the HardwareModel of iMac20.2 when started with OpenCore was j185fap.
Therefore, I set the HardwareModel of the modified part of Clover to j185fap.
However, the start log flowed as well and It was reseted.
After that, when I started it with OpenCore, I was pointed out that "There was a problem at startup".
This suggests that setting the HardwareModel to j185fap is correct, but something else is missing.

To sum up the logic, hardcoding X86LEGACYAP prevents booting for all models with T2 chips.

From the behavior of OpenCore, it seems correct to set HardwareModel to HW.Target in Lowercase. But for Clover, other settings are still uncertain.

In this case, hardcoding a boot-blocking x86legacyap for a model that doesn't have a T2 chip doesn't make sense for Clover's future T2 explorations.

I think we'll get some bad news from Hackintosh, the model with the T2 chip, at the next release.
At the very least I think there should be some choice in the config.plist when hardcoding x86legacyap.

thank you for reading.

Edited September 3, 2022 by MifJpnAlphaPlus

[Matgen84]

Hi @Slice

[my Z390 config, SMBIOS Imac19,1] I can't boot Ventura Beta 6 (Clover r5149 commit 847b46b). No problem with commit 806c09e

 

MacOS stucks at:

 

First test : com.apple.AppleFSCompressionZlib mod start

Second test: Couldn't alloc class "AppleKeySorteTest"

Third test: ASP: NVRAM pointer initialized 😪

Edited September 3, 2022 by Matgen84

[STLVNUB]

FEATURE REQUEST:

SMBIOS AS IT'S OWN CONFIG

 

Reason:

Would Love To Go Back In Time And Try Snow Leopard ETC

So With Separate SMBIOS.plist This Would Be Achievable 

Could Also Check Which OS X is Getting Booted And Auto Select The Right SMBIOS

 

SMBIOS.plist Would Be Named 10.6.SMBIOS.plist ETC

Make My Dream (NIGHTMARE) Come True PLEASE

 

Actually Could Have Multiple configs and Call Which One Is Needed

i.e. 10.6 would be 10.6.config.plist

 

[Common_Sense]

Hello,

 

I would really appreciate some help as I am stuck with a non working system after installing a newer Clover version.

 

I installed Clover 5149 (commit: 847b46b) that was compiled under Actions -> Runs in Github. After that macOS didn't start. Downgrading to the release version of 5149 that was installed before didn't work, going down to 5148 or 5147 didn't work either. All kexts are the same, all UEFI drivers are the same, config is the same. Nothing has changed. Clover preboot.log looks good until the end where it now says:

"151:645  0:000  OC: Supported boot capabilities 4
151:646  0:001  OCABC: AllocPages 1 0xC9964000 (1) - Success
151:652  0:005  RestoreConfig called Param1=2
161:669  10:017  OCB: InternalEfiExit D85D3A18 - Aborted / Unsupported
161:669  0:000  StartImage failed : Aborted"

 

What can have happened? 

 

 

[iCanaro]

@Common_Sense run nvram reset with F11 from the Clover GUI on boot, then boot with version 5148. For what little I have tested, no Commit of Clover 5149 succeeds in starting ventura

[Common_Sense]

13 hours ago, iCanaro said:

@Common_Sense run nvram reset with F11 from the Clover GUI on boot, then boot with version 5148. For what little I have tested, no Commit of Clover 5149 succeeds in starting ventura

That did the trick  

 

Edit: upgraded again to Clover 5149 original release via Clover app, and working fine. 

Edited September 6, 2022 by Common_Sense

[mariosun]

Clover 5149 works in Ventura from original release

https://www.macos86.it/topic/86-aggiornamento-clover/?do=findComment&comment=133394

 

 

 

problem is this attached if you try to boot again with Opencore, It was solved previously but now it is back again!

 

 

Clear Cmos or others methods you like help to boot again with Opencore safe if you haveNVRAM problems

https://github.com/acidanthera/bugtracker/issues/1868#issuecomment-970377807

 

Edited September 6, 2022 by mariosun

[MifJpnAlphaPlus]

Thanks for all your development.

I will report about 9cdae6f.
iMac20.2
(i9-10900f,RX-570)

 

Monterey resets during boot and will not boot.😨

Ventura also resets during boot and will not boot.😨

 

As a side effect, when I boot OpenCore afterwards, the resolution is out of whack.😨

 

Thank you.

Spoiler

Reference

The value of each variable after booting with OpenCore.

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:ApBoardID
94B73556-2197-4702-82A8-3E1337DAFBFB:ApBoardID    #%00%00%00

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:ApSecurityDomain
94B73556-2197-4702-82A8-3E1337DAFBFB:ApSecurityDomain    %01%00%00%00

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:ApProductionStatus
94B73556-2197-4702-82A8-3E1337DAFBFB:ApProductionStatus    %01

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:ApSecurityMode
94B73556-2197-4702-82A8-3E1337DAFBFB:ApSecurityMode    %01

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:EffectiveProductionStatus
94B73556-2197-4702-82A8-3E1337DAFBFB:EffectiveProductionStatus    %01

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:EffectiveSecurityMode
94B73556-2197-4702-82A8-3E1337DAFBFB:EffectiveSecurityMode    %01

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:CertificateEpoch
94B73556-2197-4702-82A8-3E1337DAFBFB:CertificateEpoch    %02

 

% nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:MixNMatchPreventionStatus
94B73556-2197-4702-82A8-3E1337DAFBFB:MixNMatchPreventionStatus    %00

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:CryptoDigestMethod
94B73556-2197-4702-82A8-3E1337DAFBFB:CryptoDigestMethod    sha2-384%00%00%00%00%00%00%00%00

 

nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:InternalUseOnlyUnit
94B73556-2197-4702-82A8-3E1337DAFBFB:InternalUseOnlyUnit    %00

 

[deeveedee]

18 hours ago, Common_Sense said:

Hello,

I would really appreciate some help as I am stuck with a non working system after installing a newer Clover version.

This probably doesn't help much now, but I've found that it's best to test new boot loaders on a removable USB stick before overwriting the EFI on my production volume.

[Common_Sense]

4 hours ago, deeveedee said:

This probably doesn't help much now, but I've found that it's best to test new boot loaders on a removable USB stick before overwriting the EFI on my production volume.

 

Very good advice, I should be more careful when upgrading to a newer Clover version. Luckily I can mount the EFI partition from Windows and make changes to Clover.

[oldman20]

17 hours ago, mariosun said:

Clover 5149 works in Ventura from original release

https://www.macos86.it/topic/86-aggiornamento-clover/?do=findComment&comment=133394

 

 

 

problem is this attached if you try to boot again with Opencore, It was solved previously but now it is back again!

 

 

Clear Cmos or others methods you like help to boot again with Opencore safe if you haveNVRAM problems

https://github.com/acidanthera/bugtracker/issues/1868#issuecomment-970377807

 

i have same issue NVRam, and F11 at Clover GUI not reset NVRam

[mariosun]

10 hours ago, oldman20 said:

i have same issue NVRam, and F11 at Clover GUI not reset NVRam

to reset successfully NVRAM if this problem happens, I use Clover R5149 release found on clover Hacky site

If it doesn't work for you you can try with some older release

I use also 084 Opencore release

Edited September 7, 2022 by mariosun

[oldman20]

2 hours ago, mariosun said:

to reset successfully NVRAM if this problem happens, I use Clover R5149 release found on clover Hacky site

If it doesn't work for you you can try with some older release

I use also 084 Opencore release

I already v5149, and current use opencore 084 too. 

[Slice]

After testing Opencore I can't boot by Clover until make F11.

I need more observations related to switch between bootloaders.

[joevt]

4 hours ago, Slice said:

After testing Opencore I can't boot by Clover until make F11.

I need more observations related to switch between bootloaders.

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

[Slice]

8 hours ago, joevt said:

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

Do you know why some variables in NVRAM should be Volatile or Non-volatile?

Volatile as said Acidanthera.

Non-volatile as said Clover developers 10 years ago.

[Slice]

16 hours ago, joevt said:

Do you have UEFI Shell for Open Core and Clover? Maybe get a dmpstore in each case and compare.

No, variables will be set at system start not at Shell start.

We can get some list of variables by DarwinDumper but the list is restricted.

[joevt]

5 hours ago, Slice said:

No, variables will be set at system start not at Shell start.

 

I suppose the solution is to somehow put a dmpstore between when Clover and OpenCore is launching macOS and when macOS starts. Can they be fooled into thinking that a UEFI Shell renamed to boot.efi is macOS? Do this in the preboot partition.

[iCanaro]

with this commit https://github.com/CloverHackyColor/CloverBootloader/commit/9d6f4fa5a3ae5a493b3c7986294d9f9fa138635a

now ventura starts without problems