Clover General discussion

[iCanaro]

2 hours ago, Matgen84 said:

 

Hi @iCanaro

I notice that in your config.plist:

• algrey - Disable _i386_lbr_init have a Replace, but no Find (Line 2282)
• algrey - Disable _i386_switch_lbrs: Idem (Line 2255)
• algrey - Disable _i386_lbr_native_state_to_mach_thread_state: Idem (Line 2337)

 

Maybe, it's an explanation for the warnings.   I hope 

kernel patches are exact translation for Clover of those of OC and the find has empty field there

6 hours ago, jsl2000 said:

I guess because 3 "Find" were found "#Find" in your config.plist.

Try to fix it for re-testing.

I made some changes from what the config was like and it gave the same alerts even with Find without # in front

[kushwavez]

But then how do you patch a thing if Find isn't defined? Just a Replace won't do anything, because the patcher doesn't know what to patch.

That is why the warning there

Edited June 16, 2021 by kushwavez

[iCanaro]

I understand the arguments, but I did not make patches; I just converted them for Clover from OC

https://github.com/AMD-OSX/AMD_Vanilla

 

In addition, these alerts are related to the latest versions of Clover and the validater, until recently nothing was reported.
I also fixed the warnings by opening the config with clover configurator --> text mode --> synchronize; but it has a serious side effect, the validater does not report anything, but the AMD hack no longer starts as it does not load the kernelpatch

[naiclub]

That's why the developers disappeared because everyone was scolding him for making him disappear.

[kushwavez]

Oh I see.
Unfortunately I don't use KernelPatcher so this is out of my understanding. 

Bet @Slice can help you  

[Slice]

5 hours ago, iCanaro said:

kernel patches are exact translation for Clover of those of OC and the find has empty field there

I made some changes from what the config was like and it gave the same alerts even with Find without # in front

"Find" should not be empty.

It must contains array of bytes the same length as "Replace".

If the contents of the array is not meaningful then set Find=00000 and MaskFind as 00000 with the same length.

[iCanaro]

On 6/16/2021 at 2:18 PM, Slice said:

"Find" should not be empty.

It must contains array of bytes the same length as "Replace".

If the contents of the array is not meaningful then set Find=00000 and MaskFind as 00000 with the same length.

 

I did not reply immediately, because in these days I have done several tests, I have run the translation of the OC patchkernels for Clover from scratch, but I cannot find a solution.
In patches 0, 1 and 3 (which relate only to big sur) if I leave the find and maskfind fields blank, I get the validator signal; if I fill them as recommended with 00000, then I have no signal at boot and from the validator, but the effect is that big sur does not start; catalina and mojave start regularly, but big sur not.
At the moment I have not found a solution for not having warnings and being able to start big sur.

[jsl2000]

17 minutes ago, iCanaro said:

 

I did not reply immediately, because in these days I have done several tests, I have run the translation of the OC patchkernels for Clover from scratch, but I cannot find a solution.
In patches 0, 1 and 3 (which relate only to big sur) if I leave the find and maskfind fields blank, I get the validator signal; if I fill them as recommended with 00000, then I have no signal at boot and from the validator, but the effect is that big sur does not start; catalina and mojave start regularly, but big sur not.
At the moment I have not found a solution for not having warnings and being able to start big sur.

In my Hackintoshs there was a bug of Clover 513x if legacy boot of Big Sur which should be 11.x instead of 10.13.6.

So I need patch Big Sur as 10.13.6 to boot properly including FX-6300, P6TSE, P5Q PRO, and GA-965P-DS4.

No such an issue if legacy booted by OpenCore.

So can you change your patch MatchOS from 11.x to 10.13.6 and reboot ?

[iCanaro]

i could boot regularly from high sierra to big sur; just yesterday due to the failure to support ad display port 1.2 and USB problems, I updated high sierra to big sur 11.4 stable, while big sur 11.5 beta I will update it in monterey when there will be patches to try

[iCanaro]

this is my latest OC kernelpatch translation job for Clover CLOVER_KernelToPatch_17H_19H.plist_iCan.zip

[jsl2000]

1 hour ago, iCanaro said:

this is my latest OC kernelpatch translation job for Clover CLOVER_KernelToPatch_17H_19H.plist_iCan.zip

Please try my modification of your config.plist either one of which should boot Big Sur successfully.

CLOVER_KernelToPatch_17H_19H-modified.plist

CLOVER_KernelToPatch_17H_19H-Ryzen.plist

Edited June 19, 2021 by jsl2000

[iCanaro]

21 minutes ago, jsl2000 said:

Please try my modification of your config.plist which should boot Big Sur successfully.

CLOVER_KernelToPatch_17H_19H-modified.plist 34.88 kB · 2 downloads

 

the kernelpatch that I put, I start all macOS, including big sur, the point is that at boot Clover reports 3 warnings, which are related to patches 0, 1, and 3; specifically, the empty fields of find and matchfind. If they are filled as recommended by Slice, with 00000, there are no more warnings, but big sur does not start

 

i saw the addition you made in matchOS: 10.13.6

 

your config starts regularly, but there is always the question of the 3 warnings that you have at boot and with the validator, which are also present in your

[iCanaro]

I wait to hear the opinion of the developers, but my point of view, is that the validator does not report empty fields in find, because for the moment, any other option that does not trigger the warning then leads big sur

[jsl2000]

15 minutes ago, iCanaro said:

 

the kernelpatch that I put, I start all macOS, including big sur, the point is that at boot Clover reports 3 warnings, which are related to patches 0, 1, and 3; specifically, the empty fields of find and matchfind. If they are filled as recommended by Slice, with 00000, there are no more warnings, but big sur does not start

 

i saw the addition you made in matchOS: 10.13.6

 

your config starts regularly, but there is always the question of the 3 warnings that you have at boot and with the validator, which are also present in your

After booted by Clover can you verify your MatchOS of Big Sur is 10.13.6 or 11.x ?

[iCanaro]

4 minutes ago, jsl2000 said:

After booted by Clover can you verify your MatchOS of Big Sur is 10.13.6 or 11.x ?

 

to my knowledge, Jief had specified matchOS to use for big sur was the only 11.x valid one
10.13.6 for Clover corresponds to high sierra

and the kexts folder to use is 11 for big sur and now for monterey it is 12

[D-an-W]

Evening folks,

 

Having a spare partition with Big Sur installed and running Clover 5137 I thought I might as well try updating the partition with Monterey.

 

I managed to with various boot options get the installer to run and the very briefly booted into Monterey but then something panicked and caused a reboot.

 

I realise my hardware is probably an issue but did read some people reporting success, would anyone know what I might need to do to boot back into Monterey with no panic please?

[iCanaro]

2 hours ago, D-an-W said:

Evening folks,

 

Having a spare partition with Big Sur installed and running Clover 5137 I thought I might as well try updating the partition with Monterey.

 

I managed to with various boot options get the installer to run and the very briefly booted into Monterey but then something panicked and caused a reboot.

 

I realise my hardware is probably an issue but did read some people reporting success, would anyone know what I might need to do to boot back into Monterey with no panic please?

 

in EFI Clover kexts create folder 12 and insert LILU, WEG and VirtualSMC which are recently compiled for monterey support
in folder 11, leave the same kexts as in folder 12 temporarily for updating. If you keep the kexts only in the Others folder, same speech as before, the 3 compiled kexts for monterey support

[D-an-W]

3 minutes ago, iCanaro said:

 

in EFI Clover kexts create folder 12 and insert LILU, WEG and VirtualSMC which are recently compiled for monterey support
in folder 11, leave the same kexts as in folder 12 temporarily for updating. If you keep the kexts only in the Others folder, same speech as before, the 3 compiled kexts for monterey support

 

Thanks,

 

Does it need VirtualSMC as I have FakeSMC in there currently. I actually remembered to create a 12.0 folder with updated kexts prior to the upgrade (Does it need to be 12 and not 12.0 though?)?

Edited June 19, 2021 by D-an-W

[iCanaro]

FakeSMC is fine too
I created folder 12 and there I put the kexts for monterey to which I updated high sierra HSF on the Z170 and Z370, so a good jump, successfully performed with double pike twist

if you don't have the updated kexts, you need to add the following boot-args

 

-lilubetaall -wegbeta

[D-an-W]

Thanks, I have tried both but still can't get it booted.

 

I did manage to capture this but not sure if it's the actual cause...

[Avery B]

9 hours ago, iCanaro said:

 

the kernelpatch that I put, I start all macOS, including big sur, the point is that at boot Clover reports 3 warnings, which are related to patches 0, 1, and 3; specifically, the empty fields of find and matchfind. If they are filled as recommended by Slice, with 00000, there are no more warnings, but big sur does not start

 

According to OC docs, an empty find does an immediate replace at the address of base (https://raw.githubusercontent.com/acidanthera/OpenCorePkg/master/Docs/Configuration.pdf under Kernel->Patch)
If Clover uses OC for kext patching, it may be similar.

[Slice]

9 hours ago, 1Revenger1 said:

 

According to OC docs, an empty find does an immediate replace at the address of base (https://raw.githubusercontent.com/acidanthera/OpenCorePkg/master/Docs/Configuration.pdf under Kernel->Patch)
If Clover uses OC for kext patching, it may be similar.

No, Clover uses own kext patching with a similar abilities or more.

I can find a bug if any when I can reproduce it. What should I do to reproduce the issue?

[Matgen84]

12 minutes ago, Slice said:

No, Clover uses own kext patching with a similar abilities or more.

I can find a bug if any when I can reproduce it. What should I do to reproduce the issue?

Hello @Slice I may have misunderstood. @1Revenger1 and others users are talking about KernelToPatch, not KextToPatch. Maybe we need some explanation on this point and Clover's ability to convert OC patches. If it's necessary.

 

Thanks.

[iCanaro]

21 minutes ago, Slice said:

No, Clover uses own kext patching with a similar abilities or more.

I can find a bug if any when I can reproduce it. What should I do to reproduce the issue?

 

you asked a question, that answering you as a normal user is not easy ... since it manifests itself with the KernelToPatch on AMD, the most obvious thing would be to have an AMD hack; otherwise try to reproduce the bug on Intel, even if I don't have a precise idea how to do it.
The problem arises with patches 0, 1 and 3 here CLOVER_KernelToPatch_17H_19H.plist_iCan.zip

so we need a patch for intel that is similar ... I think

[Slice]

2 hours ago, Matgen84 said:

Hello @Slice I may have misunderstood. @1Revenger1 and others users are talking about KernelToPatch, not KextToPatch. Maybe we need some explanation on this point and Clover's ability to convert OC patches. If it's necessary.

 

Thanks.

Clover has separate patches for kexts and for kernel while OC joined them as to be similar.