Clover General discussion

[AndyYa]

Does  not  start  OS 10.13.6.     Clover r5115 (SHA: d10cadac4)

 

[Slice]

1 hour ago, Pene said:

@Slice

 

In my case OSX can load only if I change at kext_patcher.cpp:

#define OLD_METHOD 0 

to 

#define OLD_METHOD 1

otherwise it hangs before macOS loads. So there is some problem there, not sure what to do with it.

After I change that, it works OK, and applications start normally.

 

It is AppleRTC patch. Looks to be more complex.

[AndyYa]

My  OS 10.13.6  starts  after  turn  off   "AppleRTC patch".   Clover r5115 (SHA: d10cadac4).

Thanks   :-)

 

[chris1111]

6 hours ago, Slice said:

Test, please, commit d7d3c96

gives me binary of d7d3c96 because I compile the source and its hang for 10.14 and 10.15 after the apfs driver

then on 10.6 its prety much the same its hang here verry quickly

Just a question why not include the change of @Pene here 

its work for all os's ?

 

 

 

 

[Slice]

OK, I committed the change 0->1 as it rises a problem for those who compiles clover for himself.

[Matgen84]

@chris1111 @Slice

 

The change of Pene don't work alone on my Z390 mobo (Catalina 10.15.5 Beta 3) + if I uncheck Clover Fix AppleRTC patch: I can boot with latest commit.

 

Re-Build from source the change 0->1 + Clover Fix AppleRTC works together on my Z390.

 

I don't test on Mojave (IvyBridge).

 

 

Edited May 3, 2020 by Matgen84

[chris1111]

@Slice Half a good news latest change work for 10.14 /10.15

Failled to load kext in 10.6

not test other OS's

 

Sorry @Slice I forgot to change the FakeSMC after my latest install 

You latest change 2502b0d82 are good 

Thank you for your effort

Thanks to all Dev 

working10.6 Saved Output.txt.zip

Edited May 3, 2020 by chris1111

[vector sigma]

Hi @Slice, but this:

UINTN procLocation = searchProc(Driver, "updateChecksum", &procLen);

should not be:

UINTN procLocation = searchProc(Driver, "__ZN8AppleRTC14updateChecksumEv", &procLen);

?

 

P.S. for 64 bit... I think for 32 bit was different

Edited May 3, 2020 by vector sigma

[Pene]

2 hours ago, chris1111 said:

Just a question why not include the change of @Pene here 

Not sure I understood you, but I committed the changes to master already. They are included now in current version.

[chris1111]

16 minutes ago, Pene said:

Not sure I understood you, but I committed the changes to master already. They are included now in current version.

Ha ok thanks 

[chris1111]

@Slice I suggest you modify the EFIFolder preinstall script because this will avoid problems if a third party application or a script.sh has already mounted the EFI partition of the volumes with the name EFI
Clover mounts the EFI partition with the name ESP so you may have some problem
Also all drivers in drivers / Bios and UEFI should be deleted as CLOVERX64.efi and BOOTX64.efi are

Here is the original and here are my proposed changes ➣ Modifying preinstall script

 

Thanks in advance

 

[Jief_Machak]

@Pene

I saw you replaced "Entry->LoadOptions = loaderEntry->LoadOptions;" by "Entry->LoadOptions = Split<XStringArray>(loaderEntry->LoadOptions.ConcatAll(" "_XS8).wc_str(), " ");"

For me, they are strictly equivalent because you concat all to split it. I'm wondering if you were trying to do something else ?

 

@everyone :

- the parameter "OSVersion" in LOADER_ENTRY::KernelPatcher_32 is hiding the member with the same name OSVersion. Is this parameter redundant ?

- patchLocation2 = FindMemMask(...) kext_inject.cpp:1178

- patchLocation2 = FindRelative32(...) kext_inject.cpp:1189

- patchLocation3 = FindMemMask(...) kext_inject.cpp:1239

these Find method returning an UINTN (64 bits) and patchLocation2 and patchLocation3 are UINT32, giving a warning. Could I change patchLocation2 and patchLocation3 to UINTN ? (Please, do not solve this with downcast because one day, we'll have FindMemMask or FindRelative32 returning an UINTN bigger than a UINT32 and we will have a nasty bug.)

[vector sigma]

27 minutes ago, chris1111 said:

I suggest you modify the EFIFolder preinstall script because this will avoid problems if a third party application or a script.sh has already mounted the EFI partition of the volumes with the name EFI

if the ESP is already mounted its mount point will be used, what ever is:

    # Get the ESP mount point if the partition is currently mounted
    ESPMountPoint=$("$partutil" --show-mountpoint "$ESPDevice")

And this way:

rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/BIOS/*.efi
rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/UEFI/*.efi

you will delete also any third party drivers not included in the package.

 

And:

rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/off

there is an option to install these drivers:

so why delete them?  Tthis should be done,  at least, by a preinstall of /CloverBootloader/CloverPackage/package/Scripts.templates/off

 

Edited May 3, 2020 by vector sigma

[Jief_Machak]

I must add that I took the occasion to extend ConcatAll and Split. They now accept literal, and even just a char.

So "LoadOptions.ConcatAll(" ")" and "LoadOptions.ConcatAll(' ')" must work, for example.

[chris1111]

1 minute ago, vector sigma said:

if the ESP is already mounted its mount point will be used, what ever is:

    # Get the ESP mount point if the partition is currently mounted
    ESPMountPoint=$("$partutil" --show-mountpoint "$ESPDevice")

And this way:

rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/BIOS/*.efi
rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/UEFI/*.efi

you will delete also any third party drivers not included in the package.

 

And:

rm -rf "${EFI_ROOT_DIR}"/EFI/CLOVER/drivers/off

there is an option to install these drivers:

so why delete them? 

 

 

Delete drivers all drivers because Newbie really not know if he add  unnesserary drivers 

 

you should see the EFI (Drivers) folder that I sometimes see; you ask how these drivers find it and they put the faults on the program

[vector sigma]

15 minutes ago, chris1111 said:

Delete drivers all drivers because Newbie really not know if he add  unnesserary drivers 

e.g. but peoples using OcQuirks.efi will have a boot failure at next reboot. 

15 minutes ago, chris1111 said:

you should see the EFI (Drivers) folder that I sometimes see; you ask how these drivers find it and they put the faults on the program

Sorry but not sure I've understood you. If you mean that the ESP is already mounted, by another program for example, this is not going to be a problem as the MountESP will find the mount point, what ever is. But the preinstall should not mount anything as this is decided by the user only if  "install Clover in the ESP” is selected which activate the MountESP script. 

And $3 is always the target volume, but can't be the ESP. 

Edited May 3, 2020 by vector sigma

[chris1111]

10 minutes ago, vector sigma said:

e.g. but peoples using OcQuirks.efi will have a boot failure at next reboot. 

Sorry but not sure I've understood you. If you mean that the ESP is already mounted, by another program for example, this is not going to be a problem as the MountESP will find the mount point, what ever is. But the preinstall should not mount anything as this is decided by the user only if  "install Clover in the ESP” is selected which activate the MountESP script. 

And $3 is always the target volume, but can't be the ESP. 

Ok for the ESP mount point but the drivers I disagreed because OcQuirks.efi  not comes from the package Clover

You say it will not reboot if the drivers are no longer there and I say that it will not reboot if any drivers are there so it comes down to the same

Anyway do what you want me I only propose changes that I already adapt and that works

Edited May 3, 2020 by chris1111

[vector sigma]

49 minutes ago, Jief_Machak said:

the parameter "OSVersion" in LOADER_ENTRY::KernelPatcher_32 is hiding the member with the same name OSVersion. Is this parameter redundant ?

looks like needs a rename. 

[Pene]

1 hour ago, Jief_Machak said:

@Pene

I saw you replaced "Entry->LoadOptions = loaderEntry->LoadOptions;" by "Entry->LoadOptions = Split<XStringArray>(loaderEntry->LoadOptions.ConcatAll(" "_XS8).wc_str(), " ");"

For me, they are strictly equivalent because you concat all to split it.

Equivalent, yes, but not strictly equivalent.

The idea was an equivalent which works, because that one did not work  More details in the C++ thread, as it's too long for here.

Edited May 3, 2020 by Pene

[vector sigma]

2 minutes ago, chris1111 said:

Ok for the ESP mount point but the drivers I disagreed because OcQuirks.efi  not comes from the package Clover

If a driver is installed by hand and at will of the user, we can't delete it. I resolved this in Clover.app as it show all the drivers so that you can decide which one to delete, third parties included, but with the package cannot be done. 

[Slice]

3 hours ago, vector sigma said:

Hi @Slice, but this:

UINTN procLocation = searchProc(Driver, "updateChecksum", &procLen);

should not be:

UINTN procLocation = searchProc(Driver, "__ZN8AppleRTC14updateChecksumEv", &procLen);

?

 

P.S. for 64 bit... I think for 32 bit was different

No, there is strstr() comparison. But the problem is more complex. I will commit new procedure soon.

[tluck]

FYI, the lastest changes/fix for 5115 is working again on Sierra, High Sierra, Mojave, and Catalina.

 

thanks!

[Slice]

14 hours ago, Jief_Machak said:

@everyone :

- the parameter "OSVersion" in LOADER_ENTRY::KernelPatcher_32 is hiding the member with the same name OSVersion. Is this parameter redundant ?

- patchLocation2 = FindMemMask(...) kext_inject.cpp:1178

- patchLocation2 = FindRelative32(...) kext_inject.cpp:1189

- patchLocation3 = FindMemMask(...) kext_inject.cpp:1239

these Find method returning an UINTN (64 bits) and patchLocation2 and patchLocation3 are UINT32, giving a warning. Could I change patchLocation2 and patchLocation3 to UINTN ? (Please, do not solve this with downcast because one day, we'll have FindMemMask or FindRelative32 returning an UINTN bigger than a UINT32 and we will have a nasty bug.)

Yes, OSVersion as parameter is redundant. Will be excluded.

 

Find*** methods operates within kernel size so they range is 20Mb. UINT32 will be enough.

[Jief_Machak]

4 hours ago, Slice said:

Find*** methods operates within kernel size so they range is 20Mb. UINT32 will be enough.

I know it's coincidentally alright because of kernel size. But it's still an assumption.

Is there a problem to change patchLocation2 and patchLocation3 to UINTN ?

 

 

 

[Slice]

7 hours ago, Jief_Machak said:

I know it's coincidentally alright because of kernel size. But it's still an assumption.

Is there a problem to change patchLocation2 and patchLocation3 to UINTN ?

 

 

 

I think no problem.