Clover General discussion

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

[arsradu]

13 minutes ago, vector sigma said:

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

 

Well, yeah, I didn't forget that.  Buuut...my point is: is there a need to specify "64" when we don't have any 32-bit drivers anyway? 

 

In other words, I'm thinking, since both sets of drivers (drivers64 and drivers64UEFI) are both 64-bit, to remove the "64" part from the name, which would leave us with these two names:

    "drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

 

The only point I was trying to make, si not to specify "64" anymore in the folder name, if all the drivers inside that folder are 64-bit anyway. There are no 32-bit drivers. So...no need to differentiate between them anymore.

Edited July 5, 2019 by arsradu

[arsradu]

27 minutes ago, vector sigma said:

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

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

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

 

yep, it would make sense for those two issues to be related. So...fixing one might fix the other, as well.

Also, no rush.  Take your time.

[vector sigma]

6 minutes ago, arsradu said:

 

Well, yeah, I didn't forget that.  Buuut...my point is: is there a need to specify "64" when we don't have any 32-bit drivers anyway? 

 

In other words, I'm thinking, since both sets of drivers (drivers64 and drivers64UEFI) are both 64-bit, to remove the "64" part from the name, which would leave us with these two names:

    "drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

 

The only point I was trying to make, si not to specify "64" anymore in the folder name, if all the drivers inside that folder are 64-bit anyway. There are no 32-bit drivers. So...no need to differentiate between them anymore.

If Slice wants.. for me is ok but only one problem. While renaming drivers makes no difference running them, a problem of retro compatibility exist with old directory. This is not a problem if you in the case will use the installer where surely we will perform a rename action, but in case a user will copy drivers manually a risk of boot failure will happen if you are unaware of the change.

2 minutes ago, arsradu said:

Also, no rush.  Take your time.

tomorrow, no time today since my son want to eat pizza and patatine for dinner at a specific place chosen by him... I've to obey Lol!

[vector sigma]

1 hour ago, arsradu said:

"drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

By watching the code I've just realized that we can easily implement this with retro compatibility:

 

static VOID ScanDriverDir(IN CHAR16 *Path, OUT EFI_HANDLE **DriversToConnect, OUT UINTN *DriversToConnectNum)

to a function that return true if at least one driver is loaded

static BOOLEAN ScanDriverDir(IN CHAR16 *Path, OUT EFI_HANDLE **DriversToConnect, OUT UINTN *DriversToConnectNum)

where if no drivers is found at 'driversUEFI'... just fall back to 'drivers64UEFI':

 

if (!ScanDriverDir(L"\\EFI\\CLOVER\\driversUEFI", &DriversToConnect, &DriversToConnectNum)) {
  ScanDriverDir(L"\\EFI\\CLOVER\\drivers64UEFI", &DriversToConnect, &DriversToConnectNum);
}

 ... see you

Edited July 5, 2019 by vector sigma
typo

[arsradu]

11 hours ago, vector sigma said:

If Slice wants.. for me is ok but only one problem. While renaming drivers makes no difference running them, a problem of retro compatibility exist with old directory. This is not a problem if you in the case will use the installer where surely we will perform a rename action, but in case a user will copy drivers manually a risk of boot failure will happen if you are unaware of the change.

tomorrow, no time today since my son want to eat pizza and patatine for dinner at a specific place chosen by him... I've to obey Lol!

 

Yep!  I agree. And you do have a point with those old directories.

 

However, in my opinion, sometimes, moving forward means getting rid of old stuff from your past, so you can make room for new, exciting things waiting for you in the future.

 

In this example, if the user adds those folders back AFTER the fact, that would be kinda problematic indeed. But I think we need to address that issue...rather than keeping old things that are no longer necessary, just for such cases. I'm not sure it's worth it. I don't see many users actually doing this.

 

Also, while there are a few ways we could fix this edge case (such as checking folder structure upon boot and dynamically choosing the right folder) I think it might be easier to simply notify the user about the change (pop-up, message...something). Important thing is to communicate it easily, right within the installer. Since some of them (probably most of them) don't access our sourceforge page to check the changelog, I think the best way would be to include these important announcements right within the installer itself.

 

Something like this:

"please, note that, starting with release xxxx the folder structure for drivers folder has been updated to drivers and driversUEFI respectively. If you're using external folders, please, make sure you update the names accordingly before booting".

 

Also...here's an idea. And it could be a stupid idea. :)) But...instead of looking for a fixed folder structure and causing issues when that folder structure changes, why not try to do it dynamically, and focus on what really matters, which are the actual drivers inside those folders, rather than the folders themselves?

 

I'm thinking...probably, maybe...why not...something similar to what MacOS is doing with Spotlight search. You don't need to know a certain file's location to find it. You just search for it. And while searching in the entire Clover folder might not be really efficient, though I guess we could shorten the search time by indexing the files in a file, so we know where is each file located for each specific user, probably an easier approach would be to look for folders starting with "drivers*".

This way, no matter if you're still using the "old name" or the new names, and even if you ignored the message above that said to update your folder names, you'll still be able to boot, since the focus won't be on the folder structure, but on the actual drivers.

 

So, basically, instead of looking for a folder and a fixed folder structure, (which is kind of a "hardcoded" way of doing things in my opinion, and not really the best approach on the long term, as we can see), look directly for the drivers. Cause those are the ones which will be executed on boot. Those are the important part.

 

Anyway, I wrote so much! :)) I'm sorry about it...  

 

I'll let you guys decide what would be the best course of action in this case. I only wanted to share my point of view, and a few ideas. If you guys find any of that useful, then it would be my pleasure to see it in action. If not, let's discuss it further until we find the best possible solution.

Edited July 6, 2019 by arsradu

[Slice]

We should keep retro compatibility.

 

One more wish. Can we include the command

sudo mount -uw /

into install script for Catalina compatibility?