Clover General discussion

[chris1111]

there is a small problem with the revision Clover r4399 it does not mount the EFI partition of a disk image of this format

hdiutil create -size 5g -type SPARSE -fs HFS+J -volname Mac_OS_Installer -uid 0 -gid 80 -mode 1775 ~/Desktop/Mac-Image

before 4399 it was not a problem

[vector sigma]

@chris1111 cool, tested:

but here works good. Anyway we can make it also APFS?

[chris1111]

@chris1111 cool, tested:

tested.png

but here works good. Anyway we can make it also APFS?

Not working here 10.13.3

not test 10.13.4 Beta 1

Yes APFS

hdiutil create -size 5g -type SPARSE -fs apfs -volname Mac_OS_Installer -uid 0 -gid 80 -mode 1775 ~/Desktop/Mac-Image

[vector sigma]

10.13.4 b1 here. Just updated Clover on the real esp disk. rebooted all normal

[chris1111]

10.13.4 b1 here. Just updated Clover on the real esp disk. rebooted all normal

Ok that's what I thought because here on 10.13.3 it does not work 4399 

[vector sigma]

I have it on another hack, wait 2 minutes..

EDIT

works here on 10.13.3, clover updated with the same package, I'm on it.

[chris1111]

I have it on another hack, wait 2 minutes..

EDIT

works here on 10.13.3, clover updated with the same package, I'm on it.

Test in 10.13.4 yes working 

Strange here not work in 10.13.3 don't know why ?

 

Edit ***

this kind of disk image converted with

hdiutil create -size 5g -type SPARSE -fs HFS+J -volname Mac_OS_Installer -uid 0 -gid 80 -mode 1775 ~/Desktop/Mac-Image

hdiutil convert ~/Desktop/Mac-Image.sparseimage -format UDTO -o ~/Desktop/Mac-Image.cdr

mv ~/Desktop/mac-image.cdr ~/Desktop/macOS-High-Sierra.dmg

this is a useful image for Restore with dd command

making already bootable USB or Disk 

[tluck]

MountESP seems broken for 10.13.4 beta1 - doesn't know how to mount the ESP (on an APFS)?

[Kynyo]

diskutil list

diskutil mound diskXsX

diskutil unmound diskXsX.

(X) is your EFI partition 

[llamafilm]

I have noticed that in recent versions of Clover, the Kext patches can be specified with full name, like com.apple.iokit.IOAHCIBlockStorage instead of just IOAHCIBlockStorage.  What is the benefit to this?  I suppose it's possible to have two different kexts with the same short name, but that seems unlikely to me.

[PMheart]

I have noticed that in recent versions of Clover, the Kext patches can be specified with full name, like com.apple.iokit.IOAHCIBlockStorage instead of just IOAHCIBlockStorage.  What is the benefit to this?  I suppose it's possible to have two different kexts with the same short name, but that seems unlikely to me.

When specifying a *rough* name, for instance, IOAHCIBlockStorage, Clover will also search for its dependencies and try to patch. (This should not be what you want, you are just willing to patch the kext itself, additionally in most cases there is no such occurrence in those dependent kexts, and you don't want to patch it/them either, furthermore, it's a waste of time, though, you can hardly ever feel it)

[llamafilm]

Thanks for that explanation, PMheart.  So would you recommend updating all my older patches to include the full name, for a minuscule boot speed improvement?

[RehabMan]

When specifying a *rough* name, for instance, IOAHCIBlockStorage, Clover will also search for its dependencies and try to patch.

No.

 

Current Clover behavior:

- look for a match within *only* the bundle-id if there are no '.' characters in the specified Name (eg. it is a strstr search). The old behavior (forget the specific version of Clover for this change) was that the entire Info.plist was searched.

- look for an exact bundle-id match if there are '.' characters in the specified Name (eg. it is a strcmp comparison)

[PMheart]

No.

 

Current Clover behavior:

- look for a match within *only* the bundle-id if there are no '.' characters in the specified Name (eg. it is a strstr search). The old behavior (forget the specific version of Clover for this change) was that the entire Info.plist was searched.

- look for an exact bundle-id match if there are '.' characters in the specified Name (eg. it is a strcmp comparison)

Thanks for the clarification. Oh yes, remembered that there was a discussion on this probably in late 2016, perhaps since then the behavior has been changed.

Thanks for that explanation, PMheart.  So would you recommend updating all my older patches to include the full name, for a minuscule boot speed improvement?

Sorry, I was wrong! (You can see @RehabMan's clarification above.)

According to his sayings, you don't have to do it. Just keep your "dirty-but-effective" patch.

By the way, you may remove some duplicated patches. (e.g. The ones applied to AppleUSBXHCIPCI)

[RehabMan]

there was a discussion on this probably in late 2016, perhaps since then the behavior has been changed.

Yes, definitely new behavior since then.

[chris1111]

bad news the package does not work in Snow Leopard and Lion for UEFI and ESP

4399 and 4400

It installs the EFI folder on the root Disk instead of mounting the EFI partition

[bronxteck]

yeah thats the same issue I was having before I had to select and install clover to my first osx partition for it to install clover to EFI volume

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2580721

[Smallersen]

Also on 10.13.3: Clover 4400 ends with installation error.

 

Install Clover in the ESP does no longer work in 4400. Never had this issue before. Just possible to install EFI folder on the system partition. Updating EFI on EFI partition by hand is kind of risky.

 

4398 still worked.

[Zenith432]

So would you recommend updating all my older patches to include the full name, for a minuscule boot speed improvement?

It's not about speed improvement. It's because some bundle ids are substrings of other bundle ids. This was discovered on

AppleIntelKBLGraphics

AppleIntelKBLGraphicsFramebuffer

 

So if you want to patch AppleIntelKBLGraphics and use partial name, your patch is also applied to AppleIntelKBLGraphicsFramebuffer and puts you at risk of a spurious incorrect patch (this actually happened).

 

If bundle-id is not a substring of another bundle-id - you can continue to use partial name.

If it's a substring of another bundle-id use full bundle name for exact match.

[RehabMan]

It's not about speed improvement. It's because some bundle ids are substrings of other bundle ids. This was discovered on

AppleIntelKBLGraphics

AppleIntelKBLGraphicsFramebuffer

 

So if you want to patch AppleIntelKBLGraphics and use partial name, your patch is also applied to AppleIntelKBLGraphicsFramebuffer and puts you at risk of a spurious incorrect patch (this actually happened).

 

If bundle-id is not a substring of another bundle-id - you can continue to use partial name.

If it's a substring of another bundle-id use full bundle name for exact match.

Bottom line: it is safer (therefore, recommended) to use the complete bundle-id for Name specifications in KextsToPatch.

[mhaeuser]

Bottom line: it is safer (therefore, recommended) to use the complete bundle-id for Name specifications in KextsToPatch.

Why is StrStr used rather than StrCmp?

[apianti]

Why is StrStr used rather than StrCmp?

 

For partial matches....? Why is it not StriStr or StriCmp?

[mhaeuser]

For partial matches....? Why is it not StriStr or StriCmp?

I know what the functions do, I asked for the choice... Why support partial matches?

[apianti]

I know what the functions do, I asked for the choice... Why support partial matches?

 

That was my point, I don't know. Why would it partially match exact case? No clue, I didn't write it.... I guess to make it easier, but I think it should be StriCmp, to match the full string case insensitive.

[RehabMan]

Why is StrStr used rather than StrCmp?

StrStr is used if the Name specified does not have any '.' characters.

I would bet that was done to enhance backward compatibility.

 

For partial matches....? Why is it not StriStr or StriCmp?

Typically, we accept case sensitivity.