Jump to content

Clover General discussion


ErmaC
27,991 posts in this topic

Recommended Posts

25 minutes ago, fusion71au said:

 

Hi @iCanaro,

 

Just noticed in the screenshot that you had the patch disabled (Disabled field is set to True) so I suggest changing it to below...

 

56568675_AMDpatchconvertedforClover.thumb.png.550ef76edc44f59d50a8d14f101cc29d.png

 

Looking at the original patch for OpenCore, it seems it is doing a simple (and exact) search and replace so maybe MaskFind, MaskReplace and RangeFind are unnecessary and can be omitted.  Just my 2c.

 

Good Luck!

 

AMD patches.plist.zip 3.26 kB · 0 downloads AMD patch converted for Clover.plist.zip 1.22 kB · 0 downloads

I'm getting a little confused too.
If MaskFind is set to 0, everything will be arbitrary. (However, if omitted, I think that there is no problem if all are 1.)
The same is true for Mask Reprace.

AMD patch converted for Clover.plist
Therefore, if

If it doesn't work, it will be as follows.

AMD patch converted for Clover_With_Masks.plist.zip

I will try to re-organize the information of many people.
For now, especially what I'm wondering about is the lack of values in Find.
This is because the value to be searched is missing, so the behavior is uncertain, so I think that it is harmful as a patch.
Therefore, I think it should be excluded.

  • Thanks 2
Link to comment
Share on other sites

10 hours ago, MifJpn said:

Thank you,@iCanaro

Thank you for reading what I was worried about.

As you probably understand, the bit-inverted version of OpenCore's Mask (FindMask) is exactly Clover's FindMask. As I heard from

@Slice the other day (this was very good information).
The length should be exactly the hexadecimal length you enter in Find.

Your AMD Clover settings have influenced your country's OSX86-Project, and I'd love to share it with everyone in Japan.
Please proceed with the elucidation and verification of Clover's Kenel-patch.
Good luck.

sorry.
I seem confused now.
I am reconfiguring the Clover patch from the @fusion71au and @iCanaro patches. (I respect the data of the first patch as much as possible)

There, I noticed that
The idea of mask bit strings is the same for both OC and Clover. Same as that of IP-Mask. (I withdraw the previous statement)

I apologize for being rude to @Slice and @iCanaro.

  • Thanks 1
Link to comment
Share on other sites

5 hours ago, MifJpn said:

I'm getting a little confused too.
If MaskFind is set to 0, everything will be arbitrary. (However, if omitted, I think that there is no problem if all are 1.)
The same is true for Mask Reprace.

AMD patch converted for Clover.plist
Therefore, if

If it doesn't work, it will be as follows.

AMD patch converted for Clover_With_Masks.plist.zip 1.27 kB · 3 downloads

I will try to re-organize the information of many people.
For now, especially what I'm wondering about is the lack of values in Find.
This is because the value to be searched is missing, so the behavior is uncertain, so I think that it is harmful as a patch.
Therefore, I think it should be excluded.

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

 

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.

 

  • 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

35 minutes ago, D-an-W said:

 

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?

 

 

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.

Hello. @D-an-W
I use VirtualSMC for both OpenCore and Clover. It works fine.
I have a chronic illness, so I have a fellow Alpha. (I'm testing it jointly, so you can think of him as the same person.) On his page, I'm giving out a sample EFI. It's actually working. please refer.

https://translate.google.com/translate?sl=ja&tl=en&u=https://mifmif.mydns.jp/alpha/?p%3D1894

 

We don't know how much we can fix (Monterey is still in beta).
The Alpha page has an upload function, so if you'd like, please attach the EFI along with the description of the PC configuration for reference.
We will also learn about this issue.

 

Thank you

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

 
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:

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


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

1 hour ago, iCanaro said:

 

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:

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.

  • Like 3
  • Thanks 1
  • Sad 1
Link to comment
Share on other sites

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 :thumbsup_anim:

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

1408923212_Schermata2021-07-11alle14_20_13.thumb.png.3c8e3e610545cbe677fc28ca6d8e455e.png

  • Like 3
  • Sad 1
Link to comment
Share on other sites

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

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

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

  • Like 2
Link to comment
Share on other sites

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:malato:

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

Link to comment
Share on other sites

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

1 hour ago, iCanaro said:

 

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

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

1408923212_Schermata2021-07-11alle14_20_13.thumb.png.3c8e3e610545cbe677fc28ca6d8e455e.png

 

1 hour ago, iCanaro said:

 

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

That many versions of the OS worked! To be honest, I'm surprised! !!

 

Therefore,
I think there was only one patch for @fusion71au.

 

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 I'm sorry, I fixed some mistakes. (On the contrary, if that matters, everything doesn't work, so let's put it back and think again.)

 

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 like to fix the second patch and prepare three patterns of patches first.

 

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

Then, if we put a blank in MatchOS, we see that there is no matching OS and ignore the patch.

AMD patches to Clover With Mask NULL MachOS Ignored.plist.zip

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

 

For the time being, two of the three proposed patches have been created, so please test them. If you find a problem in those contents, you can fix it there and have it returned.

 

Thank you.

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

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.

 

image052.jpg

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.

 

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

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

  • Thanks 1
Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

57 minutes ago, MifJpn said:

 

That many versions of the OS worked! To be honest, I'm surprised! !!

 

Therefore,
I think there was only one patch for @fusion71au.

 

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 I'm sorry, I fixed some mistakes. (On the contrary, if that matters, everything doesn't work, so let's put it back and think again.)

 

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 like to fix the second patch and prepare three patterns of patches first.

 

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 · 1 download

Then, if we put a blank in MatchOS, we see that there is no matching OS and ignore the patch.

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.

 

For the time being, two of the three proposed patches have been created, so please test them. If you find a problem in those contents, you can fix it there and have it returned.

 

Thank you.

Thank you for waiting.
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

Apparently, from the result, when MatchOS is blank, it matches all OSs.


Then, despite some mistakes, it's a blessing of God that more than 40 patches worked! (And I don't have an AMD computer!) That's very exciting! ... and the person who found this patch is just amazing!

 

There was one exception to the change to return MatchOS to the original blank, so I'll report it.
In the sixth patch, MatchOS was x86_64. In the case of the full patch version, there was 12.0 in the comment, so I fixed it as 12.x.
Even in the MatchOS blank (not collect) version, it is not left as x86_64, but is set to 12.x as an exception. I don't think there will be any problems, but I will report it.

 

It depends on the result, but I think that the test based on the assumption is up to this point for the time being.
After that, I have to try applying each patch and see how it looks, so it is difficult because there is no AMD computer here.

 

Thank you.

Link to comment
Share on other sites

@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 by iCanaro
  • Like 3
Link to comment
Share on other sites

Thank you for your test.

 

Hmmm, I really wish I had an AMD computer here. (It's very exciting, but it's a little regrettable.)

 

Throughout the hypothesis, if we didn't write anything in MatchOS, then all OSs are patched. That's because the full-patch-version when you reconfigure MatchOS from comments is the same as if you didn't write anything in MatchOS.

 

The original OpenCore AMD-Patch is from @fusion71au, and the MatchOS information is from @iCanaro.

 

In my opinion, MatchOS is working fine, as per the @iCanaro settings and the patch comments in each patch. That's why the patch is valid on as many as three mac OSs.

 

Therefore, I would say that the most appropriate patch is the Full-Patch version.

 

I think it's a good idea to search for problems based on that patch.

 

I think trial and error is also good.
Also, since this patch comes from OpenCore, I think one way is to go back and try this patch back to OpenCore to test Mojave's boot.
In particular, it's strange from Clover's point of view that there are comments about patches that don't have a Find value. (Because I don't know what I want to replace)
So it might make sense to try booting Mojave with OpenCore, removing patches that don't have a Find value.

 

You can also consult with @fusion71au with the full-patch version and the current error log.

 

(Oh, I wish I had an AMD CPU ...)

Anyway, thank you for giving me an exciting experience.

 

Thank you!!

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

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 

  • Like 2
Link to comment
Share on other sites

9 minutes ago, iCanaro said:

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 

I'm looking at the 0.7.1 manual right now.
Officially
1. Arch
2. Base
3. Comment
4. Count
5. Enabled
6. Find
7. Identifier
8. Limit
9. Mask
10. MaxKernel
11. MinKernel
12. Replace
13. Replace Mask
14. Skip
These are defined.
From this point of view, it is strange that there are comments on patches that do not have a Find value. Also, I can't even search for Procedures.(It's a mystery)
From a logical point of view, it may be rational to manage with the Kernel version. However, the Kernel version does not change without upgrading, so I'm not sure how effective it is.

Link to comment
Share on other sites

×
×
  • Create New...