Contribute
Register

[Guide] Booting the OS X installer on LAPTOPS with Clover

jwballan said:
I have an old HP Probook 4540s that was running High Sierra release #4 until it refused to boot from the hard disk or a USB installer. While it runs Windows 10 and Linux ok, which I understand don't require the same "resource" level, it still give me problems with CLOVER from a USB Install drive. I was able get to the "Utility" page ( Partition/term, etc) and reformat the hard disk, it now seems to hang in the install_osx program.

I've attached a photo of where it hangs, a screenshot of the USB CLOVER drive and a zip file of the EFI without theme and tools dirs.

The question is something wrong with the EFI drivers64UEFI/kexts/Other, or does there appear to be something wrong with the laptop and I should just make it a windows/Unix box?

Thanks for any advice

Jim Ballantine
Click to expand...

Your profile has no hardware details for any 4540s... therefore no way for me to know what screen resolution, or CPU you have on your 4540s. You also failed to press F2 so no misc/preboot.log to examine. Please read the FAQ carefully.
 
MCMLXXV said:
Hi RehabMan,
I just found there are two EFI folders on my computer: EFI folder on the EFI partition, and another EFI folder in the root of my macOS drive. They are similar, but not exactly the same. And both contains config.plist files, they're also different.
Why there is a folder on my macOS drive? How it's used?
Sorry for my noob's questions, I'm new to hackintosh...View attachment 348251
Click to expand...

It means you installed Clover incorrectly at some point.
Must always go into "Customize..." and install for UEFI to ESP.
 
Hi RehabMan,
Strange, I followed the guide...
Thanks for the information! I'll check Clover.
 
Hi,

I have a question related to kernelcache and how the system boots related to kexts:

I understand that the kernelcache is an optimised and pre-linked version of the kernel with its extensions (kexts), which is then stored in /System/Library/PrelinkedKernels/prelinkedkernel, which is pointed to from its more traditional location of /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache (definition from here).

So based on the second post of @RehabMan I always place my kexts on /L/E (10.13).

On the clover installation on the hard disk I have all the configuration plus the bare minimum in kexts/Other directory in order to boot the installer or recovery plus SystemParameters/InjectKexts="Detect" in order to avoid clover injecting the kexts if already in the kernel cache.

Now I created a backup USB stick with just clover and the exact same configuration as clover in the hard disk.

Question: When I boot from the USB stick clover and select the macOS partition to boot I assume that given that I have installed the FakeSMC in /L/E and exists in the kernelcache, it will load all the kexts from the kextcache right (assuming that I have rebuild the cache upon installing the kexts)? Is this the expected behavior?

What I am experiencing on my system is that when I boot from USB as I described and log in in my machine and use the command kextstat I am not seeing all the kexts from /L/E. Is there something that I am missing? I know that I have to submit the troubleshoot files and I did not have time to look at it in detail, but I just need a verification that my thinking is correct.

I really have really learned so many things in the last month because of these guides of @RehabMan . Big thanks!
 
sakoula said:
Hi,

I have a question related to kernelcache and how the system boots related to kexts:

I understand that the kernelcache is an optimised and pre-linked version of the kernel with its extensions (kexts), which is then stored in /System/Library/PrelinkedKernels/prelinkedkernel, which is pointed to from its more traditional location of /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache (definition from here).

So based on the second post of @RehabMan I always place my kexts on /L/E (10.13).

On the clover installation on the hard disk I have all the configuration plus the bare minimum in kexts/Other directory in order to boot the installer or recovery plus SystemParameters/InjectKexts="Detect" in order to avoid clover injecting the kexts if already in the kernel cache.
Click to expand...

Perfect.

Now I created a backup USB stick with just clover and the exact same configuration as clover in the hard disk.

Question: When I boot from the USB stick clover and select the macOS partition to boot I assume that given that I have installed the FakeSMC in /L/E and exists in the kernelcache, it will load all the kexts from the kextcache right (assuming that I have rebuild the cache upon installing the kexts)? Is this the expected behavior?
Click to expand...

Correct. No different from when you boot from the same Clover setup on HDD.

What I am experiencing on my system is that when I boot from USB as I described and log in in my machine and use the command kextstat I am not seeing all the kexts from /L/E.
Click to expand...

Certain kexts (codeless kexts) are not shown by kextstat.
 
Hello @RehabMan,
Does using your SSDT-SATA eliminate the need to use SATA-100-series-unsupported.kext? My device-id is 'pci8086,a103'.

For me, I never encountered any problems without this kext, maybe because I'm booting from my NVMe SSD?
 
the-braveknight said:
Hello @RehabMan,
Does using your SSDT-SATA eliminate the need to use SATA-100-series-unsupported.kext? My device-id is 'pci8086,a103'.
Click to expand...

Yes.
I tend to recommend the kext instead though... easier to install a kext than to properly configure the SSDT (for example, ACPI may need renaming for SSDT-SATA to work, as it assumes _SB.PCI0.SATA, while most ACPI sets use something else).

For me, I never encountered any problems without this kext, maybe because I'm booting from my NVMe SSD?
Click to expand...

Hardware dependent.
Depends on whether the OEM decided to disable the chipset SATA controller or not.
And even some computers with it enabled will work with the generic SATA kexts, where some will not.
Best result usually with SATA-100-series-unsupported.kext for the case of enabled SATA controller.
 
Last edited:
RehabMan said:
Yes.
I tend to recommend the kext instead though... easier to install a kext that properly configure an SSDT (for example, ACPI may need renaming for SSDT-SATA to work, as it assumes _SB.PCI0.SATA, while most ACPI sets use something else).
Click to expand...
Makes sense. Although I’ll stick with your SSDT-SATA + SAT0 -> SATA patch for my repo since everything is handled by automated scripts anyway.
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top