Clover General discussion

[SavageAUS]

 
with version 1.060 the number of F is brought back to 12, which should be the maximum value that can be inserted, since propertree also warns of the excess number of characters and returns it to 12 in case you enter 13

How’s progress coming along?


Sent from my iPhone using Tapatalk

[iCanaro]

1 hour ago, SavageAUS said:

How’s progress coming along?


Sent from my iPhone using Tapatalk

 

no positive news
see this post how Fusion filled in the fields

https://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?do=findComment&comment=2761372

 

[iCanaro]

as I have said several times, I am not a developer, all this information for me is not easy to understand. 
I would just need a basic example that works, to be able to replicate for all kerneltopatch

[kushwavez]

Maybe this will clarify all the things.

Spoiler

 

Patching with Mask

Starting with revision 5095, the ability to implement binary patches with a mask has been introduced. This applies to KextPatches, KernelPatches and BootPatches

I'll tell you in a separate place, keeping in mind all three points.

It looks like this (specific data is unreal, just like a method).

So, in addition to the hexadecimal string Find, we can also set the MaskFind mask, bitwise. If some bit = 1, then we are looking for an exact match, if = 0, then we ignore the difference.

And for the Replace line, the MaskReplace mask means that bit = 1 - we make a replacement, bit = 0 - we leave it as it was.

Example:

1.  Find all lines in the specified cxt, {also works in the kernel, or in boot.efi} clever or Clever. The difference is in the first letter, it differs by bit 0x20. That is, we set the search mask DF FF FF FF FF FF. This means that we achieve a match for all bytes (letters), except for the first, in which we ignore the uppercase or lowercase. The search mask can be shortened, because by default all missing bytes are assumed to be FF. This means that the unspecified bytes must be the same.

2.  Replace the third letter in the found words with "o", that is, we get clover or Clover, respectively.

MaskReplace = 00 00 FF 00 00 00

The string can be shortened to the right, since it is assumed to be filled with zero. At the same time, those bytes that we are not replacing could have been omitted in Replace, but there is a requirement for an exact match of the length.

To maintain backward compatibility of the new Clover with the old config, it is assumed that the unspecified mask (missing) all consists of FFFFFF, that is, an exact match to the search string, and a complete replacement of all bytes with the specified ones.

Symbolic patching.

Starting with revision 5119 we have more search and patch capabilities. General syntax

<dict>
<key> Comment </key>
<string> Symbolic patch example got lapic panic </string>
<key> MatchOS </key>
<string> All </string>
<key> Disabled </key>
<true/>
<key> Procedure </key>
<string> _lapic_interrupt </string>
<key> RangeFind </key>
<integer> 200 </integer>
<key> StartPattern </key>
<data> ACnHeAAx241H + oM = </data>
<key> MaskStart </key>
<data> ///// wA = </data>
<key> Find </key>
<data> 6AAA // + DAAAAAAAA </data>
<key> MaskFind </key>
<data> / wAA //// AAAAAP // </data>
<key> Replace </key>
<data> 6AAA // 8xwJCQkJCQ </data>
<key> MaskReplace </key>
<data> / wAA //////////// </data>
</dict>

 

MatchOS set to All, since we consider this patching method independent of the system version.

Disabled true for now, as this is not a realistic example.

Procedure here we write the name of the procedure we are looking for. The real name may be longer, but the comparison is based on the presence of a substring. Be sure that such a substring occurs only in this procedure.

RangeFind length of codes to search. In general, just the size of this procedure, or less. This way we speed up the search without going through all the millions of rows.

StartPattern was invented before the symbolic patch. This is the starting point from where to look for our pattern. If we know the name of the procedure, then StartPattern is hardly needed. Nevertheless, let it be. RangeFind also applies to it.

MaskStart this is the mask for the starting point, that is, for the StartPattern. And then the Find / MaskFind and Replace / MaskReplace pairs.

 

Source: https://drovosek01.github.io/CloverHackyColor-WebVersion/english/from Word/Clover_Of_Khaki_Color_eng_5129.htm#_bookmark201

 

Edited July 10, 2021 by kushwavez

[D-an-W]

Might anyone know where to start in getting Clover 5138 to boot Monterey please?

 

I can boot into Catalina fine with Clover and I could also boot into Big Sur prior to updating it to Monterey, I can also boot into Monterey using OpenCore.

 

When I try and boot I get the following error, I have my Kexts in a folder named 12.0 for Monterey.

[iCanaro]

4 hours ago, D-an-W said:

Might anyone know where to start in getting Clover 5138 to boot Monterey please?

 

I can boot into Catalina fine with Clover and I could also boot into Big Sur prior to updating it to Monterey, I can also boot into Monterey using OpenCore.

what kerneltopatch are you using with Clover? can you share them?!|

 

4 hours ago, D-an-W said:

When I try and boot I get the following error, I have my Kexts in a folder named 12.0 for Monterey.

as far as I know, clover's kexts folder for monterey should be named 12 and not 12.0

[D-an-W]

2 hours ago, iCanaro said:

what kerneltopatch are you using with Clover? can you share them?!|

 

as far as I know, clover's kexts folder for monterey should be named 12 and not 12.0

 

Regarding KerneltoPatch, I didn't add anything to my Clover config specific for Monterey which might be why the panic?

 

I can try renaming 12.0 to 12 to test, will do it now.

 

EDIT: Tried with the folder renamed but still the same.

Edited July 10, 2021 by D-an-W

[iCanaro]

39 minutes ago, D-an-W said:

Regarding KerneltoPatch, I didn't add anything to my Clover config specific for Monterey which might be why the panic?

eh sure yes, there are several specific kerneltopatch for monterey, plus some that were used for previous macOS and that are also good for monterey

[fusion71au]

On 7/8/2021 at 7:39 AM, iCanaro said:

after various tests, I had only item 10 left that I could not solve, filling the fields with 00 and FF from the debuglog all a success, too bad you keep not starting anything.
It happens the same with kerneltopatchs that start RIG AMD, if you fill in the fields as indicated by the developers, everything is fine on paper, basically the hack no longer starts. 
It will be a problem with translators that you find it difficult to understand.

 

 

 

Hi @iCanaro,

 

Just noticed in the screenshot from your previous post above that you had the patch disabled (Disabled field is set to True instead of False) so I suggest changing it to below...

 

 

Notes

• Original patch written for OpenCore shown on LHS, suggested changes for Clover shown on RHS
• The original patch for OpenCore seems to only perform a simple (and exact) search and replace so maybe MaskFind, MaskReplace and RangeFind are unnecessary and can be omitted (if above doesn't work).  Only need to specify Mask if non exact finding/replacing required eg where the OC patch has nothing in the "Find" field but has a "Base" and "Replace" specified.
• For MatchOS Clover setting to apply to BigSur or Monterey, maybe 11.x.x,12.x.x better than just 11.x,12.x
• @Shaneee mentions only Monterey Beta1 working for AMD CPU, not anything newer

 

Just my 2c.

 

Good Luck!

 

AMD patches.plist.zip

AMD patch converted for Clover.plist.zip

Edited July 11, 2021 by fusion71au
Clarification for @MifJpn

[D-an-W]

6 hours ago, MifJpn said:

Hello

@D-an-W
Basically, if Big Sur is running on Clover, you should just copy Kext to another folder and Monterey will boot. (I was able to boot too)

Basically, the following will be helpful.

 

[GUIDE] How to Update Clover for BigSur Compatibility using OpenRuntime and Quirks (r5123+)

 

However, some of the many reports include a few unsuccessful cases.
There seems to be an example of a problem with the location of Kext. According to him, putting it in "Other" at the same time as "12" solved the problem. I think it's worth trying.

Also, basically, as you can see in the above reference.

1. The basic part is
Hackintosh Vanilla Desktop Guide
2. For Qurik,
Dortania's OpenCore Install Guide
3. Regarding Kenel-Panic
OpenCore Troubleshooting Guide
I think that will be the basis of the guide.

 

Good luck

 

Thanks, I will have a read now.

 

Does FakeSMC.kext still work ok with Monterey (I use VirtualSMC with OC) and I wonder if some of the other kexts I use might be causing the problem?

 

6 hours ago, iCanaro said:

eh sure yes, there are several specific kerneltopatch for monterey, plus some that were used for previous macOS and that are also good for monterey

 

I will try and find some examples thanks, ironically in the past Clover has always been the one that "Just works" which is probably why I never messed with KerneltoPatch.

[iCanaro]

1 hour ago, MifJpn said:

Thank you for waiting.

Based on @fusion71au's OpenCore-patch, referring to @iCanaro's Clover-Patch, as @Slice says, I put in each Mask and reconfigured as follows.

 

AMD patches to Clover With Mask.plist.zip 4.16 kB · 1 download

 

Here, I can't try it because I don't have an AMD computer, so I'll give an overview of the changes.

 

If properly reconstructed, the Find value and MaskFind value length should match.
Similarly, the Replace value and MaskReplace value length should match.

 

Count = 0 in OpenCore means everything, so it should be removed in Clover.
Also, Count = 1 is replaced once, so it is also left in Clover.

 

Enable = True should be Disable = False. However, one item that @iCanaro set Disable = True in Clover-Patch is left. (Added a comment)

 

In OpenCore, the part showing Kernel-Version has been removed and replaced with the MatchOS item of @iCanaro's Patch.

If there is no description in MatchOS, I set a value that is considered appropriate based on the comment (a comment has been added to that effect).

 

It has been confirmed by CCPV that there is no Typo.

 

However, I can't confirm with AMD, so please confirm the correctness of each adaptation. Please test it.

 

Thank you.

 

 

something new happened, with these you start but then all the macOS, mojave, catalina, bigsur and monterey, go into kernel panic.

I wonder why the kerneltopatch from 46 have become 41

anyway thanks for your work

[SavageAUS]

 
something new happened, with these you start but then all the macOS, mojave, catalina, bigsur and monterey, go into kernel panic.
I wonder why the kerneltopatch from 46 have become 41
anyway thanks for your work

I’ll give them a try and see what happens if you like.


Sent from my iPhone using Tapatalk

[iCanaro]

1 hour ago, MifJpn said:

Hello
Five patches have no Find value and have been removed.

Some patches may not be needed because the MatchOS was not specified and the OS version value was not written (added to the comment).

(Patches that weren't working may work, causing extra mischief and kernel panic.)

Basically, everything is set to work. (Because I added the one that was not written in MatchOS from the comment)

On the contrary, you may want to consider deleting it.

 

if I were rich, I would give you a pond full of koi n carp so you spend hours relaxing 

the translation and integration work you have done, it works, just enable the second patch 

now there are things that are clear to me, and others that I have yet to understand well; but the fact remains that you were mythical, without having any AMD hack you succeeded in translating the kerneltopatch

big sur and monterey start very well, I have yet to test it on catalina and mojave but I'm pretty sure it works there too

[iCanaro]

1 hour ago, SavageAUS said:

I’ll give them a try and see what happens if you like.


Sent from my iPhone using Tapatalk

enable the second patch and try, you will see that it works

credits @MifJpn

[iCanaro]

5 hours ago, MifJpn said:

Thank you for waiting.

Based on @fusion71au's OpenCore-patch, referring to @iCanaro's Clover-Patch, as @Slice says, I put in each Mask and reconfigured as follows.

 

AMD patches to Clover With Mask.plist.zip 4.16 kB · 1 download

 

Here, I can't try it because I don't have an AMD computer, so I'll give an overview of the changes.

 

If properly reconstructed, the Find value and MaskFind value length should match.
Similarly, the Replace value and MaskReplace value length should match.

 

Count = 0 in OpenCore means everything, so it should be removed in Clover.
Also, Count = 1 is replaced once, so it is also left in Clover.

 

Enable = True should be Disable = False. However, one item that @iCanaro set Disable = True in Clover-Patch is left. (Added a comment)

 

In OpenCore, the part showing Kernel-Version has been removed and replaced with the MatchOS item of @iCanaro's Patch.

If there is no description in MatchOS, I set a value that is considered appropriate based on the comment (a comment has been added to that effect).

 

It has been confirmed by CCPV that there is no Typo.

 

However, I can't confirm with AMD, so please confirm the correctness of each adaptation. Please test it.

 

Thank you.

 

 

enabling the second patch, tested on all macOS installed in my AMD RIG:

monterey beta 1 --> OK

big sure 11.5 beta5 --> OK

catalina --> OK

mojave -- > does not work, restarts

[D-an-W]

@iCanaro I tried to get files from the .it site to try and see where I might start with Quirks etc but it said they were missing?

[carlo_67]

2 ore fa, D-an-W ha detto:

@icanaro Ho provato a ottenere file dal sito .it per provare a vedere da dove potrei iniziare con Quirks ecc., ma ha detto che mancavano?

venite signori venite, allora grazie Mario

https://www.macos86.it/topic/4922-amd-kernel-patches-riduzione-patches-utilizzate-big-sur-e-monterey-beta-1/?tab=comments#comment-116067

 

as I see you are not very careful, systems 10.13 / 10.14 / Catalina, bigsur, Monterey 1 start with much less patches

[SavageAUS]

enable the second patch and try, you will see that it works
credits [mention=2589323]MifJpn[/mention]

Can you pm me the patches.plist I don’t have access to my computer until tomorrow night.


Sent from my iPhone using Tapatalk

[iCanaro]

9 minutes ago, MifJpn said:

The fact that it worked if you set Disable for the second patch to False is very nice! Great! Let us take good care of here.

I would not horrendize that we had not understood each other with all these translations from one language to another; the second patch (which is for all versions of macOS) was disabled and I enabled it.

now I try these new works of yours

43 minutes ago, D-an-W said:

@iCanaro I tried to get files from the .it site to try and see where I might start with Quirks etc but it said they were missing?

here --> https://www.macos86.it/topic/3647-clover-quirks-plist-setting/

 

QUIRKS CLOVER

Spoiler

Quirks

The history of this section is as follows. Start of development of Clover for UEFI download

Dmazar was the development of a driver for adjusting the memory that UEFI BIOS Aptio (American Megatrend) reserves. The fact is that the Allocate function in this BIOS allocates memory at the bottom, and to boot macOS, you need to have the bottom memory free. The conflict affects not only memory, boot.efi also does address virtualization, and this affects pointers, functions, and so on. I will not go into more detail, this is not my job, it was Dmazar who found all the conflicts step by step and figured out how to resolve them. This became the OsxAptioFixDrv.efi driver. 32 and 64 bit options with all addressing differences.

I will notice that there was no problem with Legacy Clover, because in this case Allocate from EDK2 is used, and it allocates memory from top to bottom. Legacy Clover works without this driver.

For a long time after Dmazar left, no one touched this driver, except, perhaps, some one-line additions like Free2000. And now vit9696 undertook to overhaul the driver. First of all, he made a change that allows the use of native NVRAM on many chipsets (BIOS), with which it did not work before. And then he broke the driver into semantic parts (quirks), which could now be turned on and off at the user's request if the OpenCore loader was used. But there was also a ReddestDream programmer who decided to separate all these developments from OpenCore into a separate OcQuirks.efi driver, which works in conjunction with the OpenRuntime.efi driver, and all settings are written in the OcQuirks.plist file to use all this with the Clover loader.

And then it's my turn. I need to have all sources in one repo so that bisection can be done. And since the license for the whole thing allows you to use the source code according to your own understanding, and historically everything has returned to its historical homeland, I copied them and modernized them so that instead of a separate .plist file, the same Clover's config.plist was used, and these settings you can also change it simply from the GUI Clover.

 

That is, if you cannot boot right away, you can try to enter this menu and change some setting, yes or no.

Now details about each item. The default values are specified.

<key> AvoidRuntimeDefrag </key>

<true />

Prevents memory defragmentation for runtime services such as NVRAM support. Recommended for everyone except Apple and VMware.

<key> DevirtualiseMmio </key>

<false />

Removes the runtime attribute from some known MMIO areas. Not recommended for systems older than Sandy Bridge. The list of known regions can still be expanded in the MmioWhitelist pickaxe section. However, according to my observations, it is always disabled. The need for the Z390 chipset is claimed.

 

<key> MmioWhitelist </key>

<array />

The list of regions is specified as an array of dictionaries

<dict>

<key> Comment </key>

<string> This is such and such a region </string>

<key> Address </key>

<string> 0xffe00000 </string>

<key> Enabled </key>

<true />

</dict>

 

<key> DisableSingleUser </key>

<false />

Prevents the use of command line mode because it is unsafe.

 

<key> DisableVariableWrite </key>

<false />

Denies access from MacOS to NVRAM by recording, for security.

<key> DiscardHibernateMap </key>

<false />

When waking up from hibernation, use an old memory card. Use only if you are sure that this is your case. Almost always not.

<key> EnableSafeModeSlide </key>

<true />

By default, loading in safe mode gives slide = 0. This patch allows you to use a different value set in the ProvideCustomSlide pickaxe.

<key> ProvideCustomSlide </key>

<false />

Whether or not to automatically calculate the slide = *** value. The need is visible from the log if there is a messageOCABC: Only N / 256 slide valuesare usable!

<key> ProvideMaxSlide </key>

<integer> 0 </integer>

A value from 1 to 254, for the case indicated above. 255 is the default and this can lead to memory allocation errors.

<key> EnableWriteUnprotector </key>

<true />

Clears the write protect bit on the services Runtime page. Due to the insecurity of this pick, there is another RebuildAppleMemoryMap. That is, for systems older than 2018, we setEnableWriteUnprotector - True

RebuildAppleMemoryMap - False SyncRuntimePermissions - False

And for newer ones that support MATS, if such an ACPI table is in the BIOS

EnableWriteUnprotector - False RebuildAppleMemoryMap - True SyncRuntimePermissions - True

<key> ForceExitBootServices </key>

<false />

Retry ExitBootServices with a new memory card. This is where kernel and kext patches occur. Use only if you are sure what you are doing.

<key> ProtectMemoryRegions </key>

<false />

Changes the attributes of some regions when there is a conflict between the concepts of MacOS and BIOS. This pick includes several fixes, including one that I personally developed to protect the CSM region. In particular, if your graphics card does not have UEFI VBIOS, this pick should be enabled. On the other hand, it is certainly included in the OsxAptioFix3Drv driver, and has never caused any complaints. Nevertheless, it is still disabled by default.

 

<key> ProtectSecureBoot </key>

<false />

Protects encryption keys from being overwritten by the operating system. Secure Boot technology, which we somehow don't really need. The need for this pick is observed on some Insyde BIOSes. The rest are not needed.

<key> ProtectUefiServices </key>

<false />

Some BIOSes, such as VMware, try to rewrite pointers to Runtime services. We don't need this, so we protect them. Someone Rediskin claims that this is needed on the Z390 chipset.

 

<key> RebuildAppleMemoryMap </key>

<false />

Generate a memory card compatible with macOS. The fact is that Apple has a slightly different idea of how and what to do than in our UEFI BIOS. The problem, however, is that our memory card matches our hardware. Therefore, we turn off the pick. Other picks do the necessary part of this job. This pick seems to replace EnableWriteUnprotector for systems that support MAT.

Also this Kirk requires SyncRuntimePermissions to be enabled. However, we have it enabled by default. See Kirk EnableWriteUnprotector

<key> SetupVirtualMap </key>

<true />

Kirk deals with the order in which virtual addresses are assigned and used. Some BIOS like OVMF do not support this Kirk. Hmm, why is this OcQuirks.efi driver on a system with OVMF ?! She works without him, like Legacy Clover.

So turn it on.

<key> SignalAppleOS </key>

<false />

Tells BIOS that we are loading the macOS system, although we are loading Windows. Needed on some MacBooks, but not for us. OpenCore may be needed, but not Clover.

<key> SyncRuntimePermissions </key>

<true />

Updates the permission flags in the runtime scope. Of course you need to.

 

The general situation is that for my not very new computers, these default settings were sufficient. That Rediskin has a different list, and he claims that his list matches the behavior of AptioMemoryFix. However, this is not true. With its set, my computer does not boot, while everything is fine with the old AptioMemoryFix. So in Clover the standard pickaxe set is different from the original OcQuirks (RIP).

In Clover 5125, in connection with the inclusion of patches from OpenCore, new values have appeared in this section.

 

<key> FuzzyMatch </key>

<false />

 

The key ensures compatibility with the 10.6 system (Snow Leopard), where they say the cache checksum is calculated differently. I don't know how OpenCore has it, but Clover has been loading Snowball for a long time, and along with that same cache.

 

<key> KernelCache </key>

<string> Auto </string>

Possible values (Auto, Cacheless, Mkext, Prelinked). These types of cache were before the system

10.7 and were usually selected using the boot argument Kernel =, Mkext = and others that existed in the old Clover.

<key> AppleXcpmExtraMsrs </key>

<false />

XCPM support on extra CPUs, which is what the KernelXCPM patch did before.

<key> AppleXcpmForceBoost </key>

<false />

This patch writes 0xFF00 to register MSR_IA32_PERF_CONTROL = 0x199, then������� is instead of normal p-states, Opencore suggests driving the maximum step.

<key> DisableIoMapper </key>

<true />

Disables VT-d technology in its own way. There is an alternative to dropping the DMAR table. And then there is the option dart = 0.

<key> DisableLinkeditJettison </key>

<true />

Makes Lilu.kext run faster. Due to what is unknown. Well, the keepsyms = 1 type is no longer needed.

 

<key> DisableRtcChecksum </key>

<false />

The essence of the patch is that the RTC in the Mac is used differently than in the PC, and the checksum will be bad. In a simple way, we block its calculation. Clover has an analogue AppleRTC = YES, and we use it.

 

<key> DummyPowerManagement </key>

<false />

Blocks AppleIntelCpuPowerManagement as an alternative to NullCPUPM kext. I remind you that kext is blocked mainly if OxE2 is locked, and there are other patches against this.

<key> ExternalDiskIcons </key>

<false />

The long-known patch against yellow icons is designed like a pickaxe.

<key> IncreasePciBarSize </key>

<false />

Increases the memory value for the bar from 1 to 4 GB in the IOPCIFamily kext. I don't know who came up with this patch and for what cases. OpenCore does not recommend using it at all.

 

<key> PowerTimeoutKernelPanic </key>

<false />

This patch, only for Catalina, prevents kernel panic if some device does not fire for a long time. Why cancel it ?! Let him panic instead of a dull hang. If you ever encounter such a situation, try this patch.

<key> ThirdPartyDrives </key>

<false />

A well-known patch is in Clover's config, Enable Trim on Non-Apple. The point is to replace the word Apple with an empty string. There is also a comment that Catalina has internal capabilities to do the same.

<key> XhciPortLimit </key>

<true />

A known issue is that Apple is limiting the number of XHCI, USB2 + USB3 controller ports to 15, and despite the fact that new chipsets provide more ports, Apple is in no hurry to increase this limit. Binary patches have been around for a long time, but they depend on the system version. To what extent OpenCore managed to overcome the dependence on the version, I do not know. Practice shows that all non-flying patches fly off. I made myself Legacy_USB.kext, removed unnecessary USB2 ports, and made room for USB3. This kekst worked in 10.13, so it works in 11.1.

 

[carlo_67]

2 hours ago, MifJpn said:

Maybe we don't need so many patches, or Mojave didn't work because the patch that @iCanaro specified as blank in matchOS works on all operating systems

 

 

and influential, if you don't put MatchOS the patch is applied, even if you don't need it

[iCanaro]

53 minutes ago, MifJpn said:

One is to correct my mistakes and make a full patch as much as possible.

AMD patches to Clover With Mask Full Pach.plist.zip 4.23 kB · 2 downloads

catalina, big sur monterey beta 1 --> OK works

mojave --> NOT works, reboot

 

 

54 minutes ago, MifJpn said:

AMD patches to Clover With Mask NULL MachOS Ignored.plist.zip 4.27 kB · 1 download

Finally, if we put a blank in MatchOS, we see that it matches all OSs, so we dare to put a blank in MatchOS.

 

does not start any macOS

[iCanaro]

34 minutes ago, MifJpn said:

Finally, if we put a blank in MatchOS, we think it will match all OSs and dare to put a blank in MatchOS.

AMD patches to Clover With Mask Full Pach And MachOS not Collect.plist.zip 4.33 kB · 1 download

 

catalina, big sur, monterey beta 1 --> OK works

mojave --> not works, reboot

[iCanaro]

@MifJpnthanks to your input, I made changes to my plist and even with this starts catalina, big sur, monterey beta 1 while movaje restarts (then very calmly I see if I find what causes the restart)

 

PS: in this you have to disable one of the 2 latest patches

CLOVER_Full_patches_17H19H_Monterey_beta1_iCan.plist

Edited July 12, 2021 by iCanaro

[iCanaro]

soon should be released patches for monterey beta 2, the guys of AMD OSX Vanilla are working hard

[iCanaro]

10 minutes ago, MifJpn said:

In my opinion, MatchOS is working fine

MatchOS works fine, if you see in my fullpatch I just commented on Count 0, Procedures and Skip, so they are disabled, IMHO they are these that make Clover go haywire