Clover General discussion

[Matgen84]

21 minutes ago, arsradu said:

 

Hi Matt,

 

Uhm...no such issues on my side.

 

However, I'm still getting this weird warning. Maybe because Clover was built on Mojave...? No idea. Clicking Install Anyway does seem to install it properly though.

 

 

How are you building Clover? Maybe you're selecting something else in Drivers....? I only chose the mandatory (automatically checked) drivers + OSXAptioFix3Drv. That's all.

 

Also, we were previously talking about the post install script, which should prevent user from getting both AptioMemoryFix and OSxAptioFix drivers both at the same time.

There seems to be a case where this does not happen.

 

Because this is what I'm getting after installing Clover, while previously I had AptioMemoryFix in drivers64UEFI.

 

 

My guess is that since the previous Clover installer did have AptioMemoryFix (and it was checked for installation) and this one doesn't (since I've switched to the default OsXAptioFix3Drv instead, and did not include AptioMemoryFix in the build anymore), the installer doesn't know AptioMemoryFix is already present, and it doesn't do anything based on that. Doesn't skip the installation of OsXAptioFix3Drv, and it doesn't remove AptioMemoryFix either to avoid conflicts.

 

I'm looking forward to your opinions though. In my opinion this could be a real life scenario. If one day we ship Clover with AptioMemoryFix, and the other day we don't or we use something else instead, I see this as a potential problem on the long run, if people will end up with two (or more) Aptio fixes. And I've actually seen people with all 3 OsXAptioFixes in their drivers folders. Probably added manually, not through the installer. In which case there's not much we can do. But if that was through the installer...maybe we should think of a better solution to this other than relying on the post-install script to fix everything in the background.

 

I think a bit more transparency wouldn't hurt anyone. Meaning let the user know in the UI that what they're trying to do is not ok. I don't know, it's just my opinion. If we just allow the user to choose whatever he wants and then "fix it" in the background, it will create confusion, they'll think it's a bug the fact that they didn't get their drivers installed as they selected, and they will never learn anything from that. They'll think it's Clover's fault for not installing everything they wanted, not their fault, for selecting (stupid) incompatible things in the installer UI.

 

This revision was build on Mojave. I use sharing between two hacks for copy/paste Clover on Desktop.

"Clicking Install Anyway does seem to install it properly though." I hope the code was modified in the future in Clover source.

 

I try again 

[arsradu]

6 minutes ago, Matgen84 said:

 

This revision was build on Mojave. I use sharing between two hacks for copy/paste Clover on Desktop.

 "Clicking Install Anyway does seem to install it properly though." I hope the code was modified in the future in Clover source.

 

I try again 

 

Yeah, but I mean...which method of building Clover did you use? Did you use the official steps provided by Slice a while ago for UDK2018, did you use another script? This is what I meant. And also, which drivers are you choosing for installation? I have a feeling that's where it gets stuck. Of course, and as always, I could be wrong.

 

EDIT: also, attached you can find my own build, if you wanna give this one a try, for comparison. Keep in mind, though, that it's built without AptioMemoryFix.

Clover_v2.4k_r4977.zip

Edited June 28, 2019 by arsradu

[Matgen84]

18 minutes ago, arsradu said:

 

Yeah, but I mean...which method of building Clover did you use? Did you use the official steps provided by Slice a while ago for UDK2018, did you use another script? This is what I meant. And also, which drivers are you choosing for installation? I have a feeling that's where it gets stuck. Of course, and as always, I could be wrong.

 

I use Dids UDK 2018 script to build Clover (all works fine under Mojave). For my config i7 9700K, I use: mandatory (except smchelper), aptiofixmemory. All works fine before on Catalina, before r4977.

 

EDIT: same issue with your Clover r4977

Edited June 28, 2019 by Matgen84

[arsradu]

24 minutes ago, Matgen84 said:

 

I use Dids UDK 2018 script to build Clover (all works fine under Mojave). For my config i7 9700K, I use: mandatory (except smchelper), aptiofixmemory. All works fine before on Catalina, before r4977.

 

I see. I take it you use VirtualSMC instead of FakeSMC? Also, can you try the build I uploaded above? I'm curious if that one installs properly on your rig.

 

Update: since you're getting the same issue with my build, I'm thinking maybe the issue is somewhere else...? Can you try once with SMCHelper, as well? You can remove it afterwards. Just to have the same drivers checked, in case that makes any difference.

 

Uhm...can you make a backup of your EFI folder to your Desktop, then remove it from the EFI partition, then try to install Clover again? Also, maybe remove the Backups from your system partition as well....? Just to have everything clean?

I don't know. This could also be a specific issue with your hardware? Though I see no reason why this would happen.

Edited June 28, 2019 by arsradu

[Matgen84]

45 minutes ago, arsradu said:

 

I see. I take it you use VirtualSMC instead of FakeSMC? Also, can you try the build I uploaded above? I'm curious if that one installs properly on your rig.

 

I already try your build uploaded above: same issue. 

 

In terminal:

spctl --master-disable
mount -uw/
Failed to stat file //AppleInternal, error no such file or directory
killall finder

 

EDIT: I don't understand why but it's works again when I disconnect ethernet cable. For my local network, I've two hack who sharing files via ethernet (no wifi card into i7 9700K config).

Sorry about my bad english

Edited June 28, 2019 by Matgen84

[chris1111]

4 hours ago, arsradu said:

 

However, I'm still getting this weird warning. Maybe because Clover was built on Mojave...? No idea. Clicking Install Anyway does seem to install it properly though.

 

HI @arsradu

As for the issue of the warning I think that the Clover program is designed to install files in the system in usr/standalone/i386 and also in /etc

I have other program .pkg who do not receive this warning and yet it installs in /Library
So in my opinion Catalina recognizes clairely some repertory he does not want change

[arsradu]

Thanks Chris!

 

I'm guessing this is normal then....? A new security "feature" implemented by Apple? But people might see it as a problem.

[vector sigma]

Hi guys, *I honestly think that you all pretend to much from a package Installer that is just a xar archive and should, imho, not be used in that hard way.  Memory fix drivers are just one big example and if depend by me I'll probably install all of them and disable the ones not used directly in the config.plist. More then one easy solution:

 

1. Clover package always silently install all of the memory fix drivers available in Clover, a config sample should contains all of them disabled by default in DisableDrivers. Users are responsible to activate them in config.
2. Clover package always silently install all of the drivers available in Clover, a config sample should contains all of them disabled by default in DisableDrivers, less then ones considered the essential ones. Users are responsible to activate them in config.

Result?

1. Drivers always updated
2. Drivers used always decided by the user.
3. Drivers always hidden, so no headache.
4. No way third party drivers you decided to install are deleted or activated w/o your will.
5. Easy

 

*of course I'm not talking about bugs or the fact that the pkg should be updated or changed to support Catalina. Not even one try on it by me right now.. tomorrow I will and I do what I can. 

 

Maybe DisableDrivers should be better as "DriversEnabled".

 

[pkdesign]

On 6/26/2019 at 9:57 PM, Jehoshua said:

You can format a USB stick as fat32 and it will boot EFI no problem

I know I can, the question is do you still have to? Will it work without formatting to FAT32?

 

Also I am not talking about formatting a USB flash drive, I am talking about formatting the EFI volume on the SSD.

Edited June 28, 2019 by pkdesign

[Badruzeus]

On 6/28/2019 at 1:34 PM, Matgen84 said:

Hi Clover Team

I don't know if I'm Off-Topic

Under catalina Developer Beta 2, Clover stuck at prepare stage so I can't update

 

Open Window menu, Show logs.. On my case Installer was used by another process: Software Updates. An annoying bug on Beta System though I set Updates to not automated #LoL. Force close SU using Activity Monitor. So, it seems issue came from the OS, not Clover #CMIIW

Edited June 29, 2019 by Badruzeus

[Badruzeus]

Ah.. Nevermind, I proud having different System Profiler that' s not forced to mimic the real macs #LMAO

Bcoz. uhmmb.., why not if we can? Just my opinion though. Looks funny  and cool..!!!

 

 

smbios.diff

Edited June 29, 2019 by Badruzeus

[cecekpawon]

"To Be Filled By OEM" is trve legend man!

I think some ppl here need "custom Apple ROM info" from a new config prop. And prevent injecting type 11 when its null? ;))

[Sherlocks]

On 6/27/2019 at 8:11 PM, Slice said:

I just added SMBIOS table 11. It does present in real Macs.

There is a question why System Profiler not always shows the information. May be because of FeatureMask? Or because of MacModel? Or because of SMBIOS version?

 

not sure. but seems realmac still not show only Apple ROM in system profiler.

9 hours ago, cecekpawon said:

"To Be Filled By OEM" is trve legend man!

I think some ppl here need "custom Apple ROM info" from a new config prop. And prevent injecting type 11 when its null? ;))

 

i hope this. turn on/off. i prefer realmac system profiler

[Slice]

If you turn off table 11 then it will NOT be SMBIOS like real Mac.

 

[kylon]

not sure this is the right place, anyway

 

proposal: use MacInfoPkg database to generate platform data

if these changes are good i think we can even remove the switches for PlatformFeature, FirmwareFeatures/Mask and Mobile and get the data from MacInfoPkg.

 

It will be easier to mantain a single database for everything

platformdata.zip

generate_platformdata.py

[vector sigma]

Hi @Slice and all, I need testers for the attached package that has a new abilities:

 

1. MemoryFix group where OsxAptioFix3Drv.efi, OsxAptioFixDrv.efi and OsxLowMemFixDrv.efi now reside. Only one driver is selectable. A preinstall script, if any of them is selected, will remove any drivers named *memoryfix*, *aptiofix* or *memfix*, i.e. each old memory fix drivers will be deleted. Nothing will happen if you use AptioMemoryFix.efi and you selected none of them but mind that the package will record if you previously selected one of them..
2. The package during the installation now rename drivers by removing the -64 suffix, i.e., DataHubDxe-64.efi will be DataHubDxe.efi.
3. I have a commit ready where ebuild.sh now no longer uses the -64 suffix, no downloadable drivers (bye bye --ext-pre, --ext-co etc.), only one used by Clover and where I've completely eradicated each sign of 32 bit.

Please guys test and report back, thanks! Later I'll post the changes...

 

Edited July 8, 2019 by vector sigma
package removed. Changes committed to r4983

[arsradu]

17 hours ago, vector sigma said:

Hi @Slice and all, I need testers for the attached package that has a new abilities:

 

1. MemoryFix group where OsxAptioFix3Drv.efi, OsxAptioFixDrv.efi and OsxLowMemFixDrv.efi now reside. Only one driver is selectable. A preinstall script, if any of them is selected, will remove any drivers named *memoryfix*, *aptiofix* or *memfix*, i.e. each old memory fix drivers will be deleted. Nothing will happen if you use AptioMemoryFix.efi and you selected none of them but mind that the package will record if you previously selected one of them..
2. The package during the installation now rename drivers by removing the -64 suffix, i.e., DataHubDxe-64.efi will be DataHubDxe.efi.
3. I have a commit ready where ebuild.sh now no longer uses the -64 suffix, no downloadable drivers (bye bye --ext-pre, --ext-co etc.), only one used by Clover and where I've completely eradicated each sign of 32 bit.

Please guys test and report back, thanks! Later I'll post the changes...

Clover_v2.4k_r4979.pkg.zip

 

Excellent job!

 

Still testing this. But...so far so good.  Just want to test that preinstall script a little more. But as I said, so far it looks really promising.

 

First point is exactly as I imagined it. Perfect! Well done!

Second point is something I actually wanted to suggest for a loooong time, since it's been one of the reasons for me (and I'm sure other users, as well) to get duplicated drivers without even noticing (due to different naming suffixes). There's no need to put a -64 at the end, if they're all 64-bit. So I perfectly agree with that.

 

 

Update:

 

Few issues I've found so far:

1. Removing AptioMemoryFix.efi (assuming it was present before, and not from a previous installation, but let's say the user added it manually to drivers64UEFI) doesn't seem to work. Renaming AptioMemoryFix-64.efi to AptioMemoryFix.efi does work though. But in terms of removing AptioMemoryFix (if present) when selected one of the OSxAptioFixes...not so much.

2. Regardless which of the AptioFixes you choose, they're not gonna show as already selected (already existing) when re-running the installer (like for an update or something).

However, when clicking one of them, it will show the Upgrade action. Which means that it does detect it. It's just not detecting when first opening the Customise view (like it does for the other drivers).

 

Before checking any memory fix driver (but having OsxAptioFix3Drv already installed), it looks like this. 

 

The MemoryFixes group also doesn't show any sign of having any of the drivers inside already installed (such as the - sign for the UEFI drivers folder above).

 

 

After checking OSxAptioFix3Drv.

 

 

3. Suggestion: can we include the Memory Fixes group under the UEFI drivers group? Since they are all UEFI drivers, right? No...? Same for FileVault drivers, I guess..?

 

Meaning the folder tree to be something like:

 

UEFI drivers

    Memory Fix drivers (with their corresponding sub-selections).

    FV2 drivers (with their corresponding sub-selections).

 

I guess that should also include something like:

    Mandatory drivers (with the first 6 drivers already selected)

    Optional drivers...? (lack of inspiration for the naming right now LOL). So if you have a better name, I'm all for it.

 

Anyway, this is just a suggestion. We could talk about this later. Let's fix the issues first (if they're really issues).

 

4. Any point to keep the naming of the folder "drivers64UEFI" if we only have 64-bit drivers?

Edited July 5, 2019 by arsradu

[Sherlocks]

3 hours ago, vector sigma said:

Hi @Slice and all, I need testers for the attached package that has a new abilities:

 

1. MemoryFix group where OsxAptioFix3Drv.efi, OsxAptioFixDrv.efi and OsxLowMemFixDrv.efi now reside. Only one driver is selectable. A preinstall script, if any of them is selected, will remove any drivers named *memoryfix*, *aptiofix* or *memfix*, i.e. each old memory fix drivers will be deleted. Nothing will happen if you use AptioMemoryFix.efi and you selected none of them but mind that the package will record if you previously selected one of them..
2. The package during the installation now rename drivers by removing the -64 suffix, i.e., DataHubDxe-64.efi will be DataHubDxe.efi.
3. I have a commit ready where ebuild.sh now no longer uses the -64 suffix, no downloadable drivers (bye bye --ext-pre, --ext-co etc.), only one used by Clover and where I've completely eradicated each sign of 32 bit.

Please guys test and report back, thanks! Later I'll post the changes...

Clover_v2.4k_r4979.pkg.zip

 

 

i always use osxaptiofixv2-20000.efi

if my case, what is result for me?

[arsradu]

@Sherlocks Since the script looks for "aptiofix", my guess is that it should be deleted and only kept if you didn't select any of the built-in drivers (OSxAptioFixDrv).

 

But just like it doesn't yet do that for AptioMemoryFix, I think the problem is not the actual driver you're using, but probably the function responsible for removing it.

 

It's only my guess though.  

[Slice]

17 hours ago, vector sigma said:

Hi @Slice and all, I need testers for the attached package that has a new abilities:

 

1. MemoryFix group where OsxAptioFix3Drv.efi, OsxAptioFixDrv.efi and OsxLowMemFixDrv.efi now reside. Only one driver is selectable. A preinstall script, if any of them is selected, will remove any drivers named *memoryfix*, *aptiofix* or *memfix*, i.e. each old memory fix drivers will be deleted. Nothing will happen if you use AptioMemoryFix.efi and you selected none of them but mind that the package will record if you previously selected one of them..
2. The package during the installation now rename drivers by removing the -64 suffix, i.e., DataHubDxe-64.efi will be DataHubDxe.efi.
3. I have a commit ready where ebuild.sh now no longer uses the -64 suffix, no downloadable drivers (bye bye --ext-pre, --ext-co etc.), only one used by Clover and where I've completely eradicated each sign of 32 bit.

Please guys test and report back, thanks! Later I'll post the changes...

Clover_v2.4k_r4979.pkg.zip

Go forward!

I agree about excluding all about 32 bit and excluding -64 suffix. It is no more needed.

 

Out of this look please ticket 538 if we can implement the commands.

 

[Slice]

3 hours ago, daltanious78 said:

 

 

This hackintosh is based in lenovo thinkcentre m73 tiny this specs:

CPU i3-4130T
12 gb ram
Scheda video hd4400
SSD Samsung evo 860 500gb
Wi-Fi/Bluetooth azurwave BCM94352HMB

 

 

 

 

Your question will be moved to dedicated place

https://www.insanelymac.com/forum/152-lan-and-wireless/

As well you can search a topic with the same laptop if present.

[vector sigma]

7 hours ago, Slice said:

Go forward!

I agree about excluding all about 32 bit and excluding -64 suffix. It is no more needed.

Ok, I'll do that tomorrow!

7 hours ago, Slice said:

Out of this look please ticket 538 if we can implement the commands.

About this I have a better idea of using a command line tool that intercepts power off signal instead of scripts.... less code and better result I guess, or at least I'll give it a try.

[vector sigma]

22 hours ago, arsradu said:

1. Removing AptioMemoryFix.efi (assuming it was present before, and not from a previous installation, but let's say the user added it manually to drivers64UEFI) doesn't seem to work.

I'll fix it somehow. Actually I'm adding a preinstall script to do that, but only now I realaze that get overwritten by the "MarkChoice" script that is a preinstall script as well..

22 hours ago, arsradu said:

2. Regardless which of the AptioFixes you choose, they're not gonna show as already selected (already existing) when re-running the installer (like for an update or something).

However, when clicking one of them, it will show the Upgrade action. Which means that it does detect it. It's just not detecting when first opening the Customise view (like it does for the other drivers).

Probably caused by what I've already told you just above. Let see..

22 hours ago, arsradu said:

3. Suggestion: can we include the Memory Fixes group under the UEFI drivers group? Since they are all UEFI drivers, right? No...? Same for FileVault drivers, I guess..?

I need a try... I'll try very soon 

[vector sigma]

22 hours ago, arsradu said:

4. Any point to keep the naming of the folder "drivers64UEFI" if we only have 64-bit drivers?

Don't forget we have 'drivers64' too for duet. Just 'drivers' will not be a solution.

[vector sigma]

20 hours ago, Sherlocks said:

i always use osxaptiofixv2-20000.efi

if my case, what is result for me?

When I'll fix a stupid problem, for you will be easy:

don't install any of OsxAptioFix3Drv.efi or OsxAptioFixDrv.efi or OsxLowMemFixDrv.efi and your driver will never be touched. 

 

Is clear that if you install them instead, your driver will be deleted (or to saying better is moved to the backup directory) because is conflictual.