Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

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.

 

1922686680_Schermata2021-07-07alle23_19_09.thumb.png.d0c9acf8eb2a3f486c7c91edd15fa71f.png422021508_Schermata2021-07-07alle23_30_46.thumb.png.569cff09578385c81b847e2b88bfbb58.png16295980_Schermata2021-07-07alle23_31_41.thumb.png.f78a682e11c9f412c5edcc66a97d1942.png

 

2021-07-07_21-10_CLOVERX64.efi.log2021-07-07_21-27_CLOVERX64.efi.log

 

Link to comment
Share on other sites

I'm reading these latest CLOVER Discussion posts with a big smile as I remember September 7, 2020 when folks were advising Slice to abandon CLOVER to allow developers to focus on a single boot loader.  Well done, CLOVER Team!

Edited by tonyx86
Link to comment
Share on other sites

I for one have never given up on clover, I’ve switched to OC a few times and then back just purely because of the way clover handles other operating systems…..it doesn’t and that’s the way I like it.


Sent from my iPhone using Tapatalk

  • Like 2
Link to comment
Share on other sites

On 7/8/2021 at 7:13 AM, Slice said:

MaskFind should be FFFFFFFFFFFFF

 

it is funny to observe that an obvious error then in the log does not generate any kerneltopatch borked

but how many F's should there be? Here I count 13, but then once entered and saved, PlistEDPlus reduces them to 12

  • Sad 1
Link to comment
Share on other sites

Hi @Slice @Jief_Machak @MifJpn and @all

I want to change this setting in config.plist: replace LastBootedVolume to MY_VOLUME_NAME, for Monterey. What is the correct way to do that ! Because, Clover boot Monterey or Big Sur via Preboot Volume.

Should I use Preboot or Monterey (the name of the main volume and my hard drive). Let me know, please.

Link to comment
Share on other sites

29 minutes ago, MifJpn said:

The developers of PlistEDPlus have changed </true> to </ true> and </false> to </ false>.
When I asked why, he replied, "It's a cosmetic problem."
So I said, "Everyone will use it if you don't put spaces in true and false."

This editor is very easy to use, but you might want to talk to the developers.

I think the developers will be flexible.

 

For FindMask all zeros, I think it's appropriate to have a "warning" in the log message, since all bits are arbitrary.

 

Thank you.

 

the developer seems to me very careful 

https://www.insanelymac.com/forum/topic/345512-open-source-cross-platform-plist-file-editor-plistedplus/?do=findComment&comment=2762425

 

 

  • Like 2
Link to comment
Share on other sites

38 minutes ago, MifJpn said:

It is OK if you specify this "Disk / Partition UUID" in Boot → Default Volume of Clover as shown below.

 

DefaultBoot.png

 

 

Thanks a lot 🙂 If In understand well, you're using physical group volume container !

 

30 minutes ago, Slice said:

I prefer LastBootedVolume. It works for Monterey as well.

 

You are right. But for some reason, I've got problems with LastBootedVolume when I switch between HDD and USB test stick. Or Boot Windows (separate hard drive).

 

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

6 hours ago, Matgen84 said:

Hi @Slice @Jief_Machak @MifJpn and @all

I want to change this setting in config.plist: replace LastBootedVolume to MY_VOLUME_NAME, for Monterey. What is the correct way to do that ! Because, Clover boot Monterey or Big Sur via Preboot Volume.

Should I use Preboot or Monterey (the name of the main volume and my hard drive). Let me know, please.

This is a very complex question. You want non-standard solution if possible.

First priority is users choice during boot. It will be remembered if "LastBootedVolume" is set.

Second priority is NVRAM variable. Not config. Why?

1. Because Startup Preference setting should work no matter what is written in config.

2. Because OS update may and want to change this setting. First reboot into "Install..." and second reboot into "Preboot".

See, I updated Monterey beta 1 to beta 2 by one click in Sofware Update. Clover performs correct reboot first, second and third times during update installation. While OC failed.

If NVRAM is empty and user choose nothing then there will be config setting to be taken into account: UUID of the partition containing boot.efi. For Mojave it will be system partition Fot BigSur and Monterey it must be corresponding Preboot partition. See Clover.log.

Quote

4:999  0:000  - [18]: 'Preboot'
4:999  0:000      ApfsContainerUUID=1EF63EAA-F2D7-4601-ADFC-9979491D69D5
4:999  0:000      ApfsFileSystemUUID=A844613B-12ED-49BF-B559-D72145442E84
4:999  0:000      APFSTargetUUID=0C483552-CAC3-4E72-B7DD-94F16C44C394
5:054  0:054        contentDetails name:Monterey
5:068  0:013        AddLoaderEntry for Volume Name=Preboot, idx=5
5:079  0:010        OSVersion=12.0 
 

5:624  0:000      - found entry 3. 'Boot Mac OS from Monterey via Preboot', Volume 'Preboot', '\0C483552-CAC3-4E72-B7DD-94F16C44C394\System\Library\CoreServices\boot.efi'

diskutil info disk2s2 

   Volume Name:               Preboot
   Mounted:                   Yes
   Mount Point:               /System/Volumes/Preboot

   Disk / Partition UUID:     A844613B-12ED-49BF-B559-D72145442E84

 

  • Like 1
Link to comment
Share on other sites

7 hours ago, MifJpn said:

It is uncertain whether the following are relevant:

From some previous versions, or in H370 + i7 8700, when updating the OS, I feel that the next candidate to be started indicated by NVRAM is not applied.

In the middle of the update, I think that a boot candidate with "Install" in the name should be selected, but since it is not selected, I manually select it at the time of update.

I apologize for not knowing why and failing to report because it cannot be reproduced without an update.

I can't reproduce because it works for me. May be it depends on my setting "LastBootedVolume"?

  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

11 hours ago, Slice said:

This is a very complex question. You want non-standard solution if possible.

First priority is users choice during boot. It will be remembered if "LastBootedVolume" is set.

Second priority is NVRAM variable. Not config. Why?

1. Because Startup Preference setting should work no matter what is written in config.

2. Because OS update may and want to change this setting. First reboot into "Install..." and second reboot into "Preboot".

See, I updated Monterey beta 1 to beta 2 by one click in Sofware Update. Clover performs correct reboot first, second and third times during update installation. While OC failed.

If NVRAM is empty and user choose nothing then there will be config setting to be taken into account: UUID of the partition containing boot.efi. For Mojave it will be system partition Fot BigSur and Monterey it must be corresponding Preboot partition. See Clover.log.





diskutil info disk2s2 

   Volume Name:               Preboot
   Mounted:                   Yes
   Mount Point:               /System/Volumes/Preboot

   Disk / Partition UUID:     A844613B-12ED-49BF-B559-D72145442E84

 

 

@Slice Thanks for these detailed explanations. Since few years, I only use "LatestBootedVolume" for my HDD.

Now, I've another issue: my USB Install Monterey (set to "LatestBootedVolume) with the same EFI folder (5137 (master, commit e12aefe81)) as my HDD, don't boot macOS Monterey HD named Monterey. Or Install macOS 12 Beta.
Stuck at 

 

[EB LOG:EXITBS:START]
*************************
		-

Debug.log attached. Two tries.
Let me know if you have an idea. I try to found a solution since few days, without success.

 

2021-07-09_16-03_BOOTX64.EFI.log

2021-07-09_16-03_BOOTX64.EFI.log

 

EDIT: Opencore USB stick boot  fine macOS or Installer :cry:

Edited by Matgen84
  • Sad 1
Link to comment
Share on other sites

17 hours ago, MifJpn said:

Excuse me.

Which version are you using?
With V1.0.59, the number of F in Item10 seems to be maintained.

CLOVER_patches_17H19H.item10.plist 52.24 kB · 1 download

Thank you

I'm sorry if I misunderstand the meaning.

 

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

  • Sad 1
Link to comment
Share on other sites

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

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

  • Like 2
Link to comment
Share on other sites

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 by kushwavez
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

430CDC70-E1CC-40E3-A953-43469335B982_1_105_c.thumb.jpeg.eea9344c44135ebc1a7954774298b58e.jpeg

  • Sad 1
Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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

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

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

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.

 

1922686680_Schermata2021-07-07alle23_19_09.thumb.png.d0c9acf8eb2a3f486c7c91edd15fa71f.png16295980_Schermata2021-07-07alle23_31_41.thumb.png.f78a682e11c9f412c5edcc66a97d1942.png

 

 

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...

 

56568675_AMDpatchconvertedforClover.thumb.png.550ef76edc44f59d50a8d14f101cc29d.png

 

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 by fusion71au
Clarification for @MifJpn
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

:thanks_speechbubble:

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...