Clover does not install on EFI Partition of HS

[Going Bald]

well I have almost figured it out.
The Problem is the kernel patch for the trim support.
As soon I apply it boot tie is up to 3 min.
Deleting it brings back fast booting of about 40 sec.
The rest of the system is all up and running.
working:
-network
-sound
- sleep
-all usb and bluetooth
- i Message

so far very happy just need to get this trim thing worked out.

Thanks for your help

Most drives have trim support in the firmware - no need to have Mac OS trim support.

 

[RehabMan]

I was able to do a clean install of HS using an USB disk.
When i try to install clover on my efi partition of my fresh HS install it does not do it.
It always installs clover on the main partition.

The efi partition has been mounted of course before I try to install clover. Any hints?

At my build my Broadcom bluetooth card is no longer detected (was working fine in Sierra)
Hersteller: Broadcom
Transport: USB
Chipsatz: 20702B0

might an USB problem.. have to check

FYI:

I have fixed this in my fork of Clover: https://github.com/RehabMan/Clover

 

[svencux]

Most drives have trim support in the firmware - no need to have Mac OS trim support.

but under "my mac" trim support for my disk Samsung EVO850 says "Trimm supported = no"

 

[RehabMan]

but under "my mac" trim support for my disk Samsung EVO850 says "Trimm supported = no"

The firmware support is transparent to host software.

 

[Henties]

The mounting script inside Clover needs revising.

I solved this in a different way without having to worry about whether there are hidden files or not in the EFI partition. I have 2 test systems of HS one on a hdd with hfs+ and the other on a SSD with APFS. Here is what I do from within a terminal session. dd if=/dev/disk0s1 of=/disks1s1, when complete I copy the proper apfs.efi driver into the drivers64UEFI folder of the EFI partition of the APFS formatted hdd.
For me this works every time without having to think too much and also without having to spend hours troubleshooting. Caveat when using this method: both EFI partitions need to be unmounted, and also make sure that the medium described by the "if=----" statement is a working EFI boot partition of your hfs+ based HS system. Doing it the wrong way will leave you in limbo not being able to even boot from your hfs+ formatted drive anymore. Of cause the medium described by the "of=----" statement needs to be your EFI partition of your APFS formatted HS macOS.
Greets

 

[RehabMan]

I solved this in a different way without having to worry about whether there are hidden files or not in the EFI partition. I have 2 test systems of HS one on a hdd with hfs+ and the other on a SSD with APFS. Here is what I do from within a terminal session. dd if=/dev/disk0s1 of=/disks1s1, when complete I copy the proper apfs.efi driver into the drivers64UEFI folder of the EFI partition of the APFS formatted hdd.
For me this works every time without having to think too much and also without having to spend hours troubleshooting. Caveat when using this method: both EFI partitions need to be unmounted, and also make sure that the medium described by the "if=----" statement is a working EFI boot partition of your hfs+ based HS system. Doing it the wrong way will leave you in limbo not being able to even boot from your hfs+ formatted drive anymore. Of cause the medium described by the "of=----" statement needs to be your EFI partition of your APFS formatted HS macOS.
Greets

The Clover installer does not hide any files when installing to the ESP.
Did you read post #22?

 

[Henties]

The Clover installer does not hide any files when installing to the ESP.
Did you read post #22?

At long last I read your post and confirm your Clover now writes to the EFI partition of an APFS formatted drive. Hope it is OK to mention here that I also removed SSDT.aml from ACPI/patched and set config.plist/ACPI/SSDT/PluginType=1 - I don't have this path though - "config.plist/ACPI/SSDT/Generate/PluginType=true" to get to ../../PluginType and that can only be set to logical 0 or 1, which of cause is identical to logical false and true. "Generate" is superfluous.
PM works well for both my builds with this new setting and without the SSDT.aml in ACPI/patched
Greets

 

[RehabMan]

Hope it is OK to mention here that I also removed SSDT.aml from ACPI/patched and set config.plist/ACPI/SSDT/PluginType=1

Wrong.
That will not enable the feature I added.
config.plist/ACPI/SSDT/PluginType=1 is different from config.plist/ACPI/SSDT/Generate/PluginType=true.

I don't have this path though - "config.plist/ACPI/SSDT/Generate/PluginType=true"

Obviously... Must be added.

to get to ../../PluginType and that can only be set to logical 0 or 1, which of cause is identical to logical false and true. "Generate" is superfluous.

Wrong.

 

[Henties]

Wrong.
That will not enable the feature I added.
config.plist/ACPI/SSDT/PluginType=1 is different from config.plist/ACPI/SSDT/Generate/PluginType=true.



Obviously... Must be added.

Thanks I get the drift - need to add - Generate/PluginType=true in the config.plist file with a suitable editor, and replace the SSDT.aml file which I removed.

 

[RehabMan]

Thanks I get the drift - need to add - Generate/PluginType=true in the config.plist file with a suitable editor, and replace the SSDT.aml file which I removed.

Correct.
You can verify the difference if you look at the ACPI files injected (use 'patchmatic -extract' in each scenario and compare).