- Sep 5, 2011
- Lenovo T440s
Enable legacy boot/CSM in BIOS as per guide:@Sniki I tried to boot the installer with your files and I'm getting a "garbled" screen that makes it impossible to proceed with the installation. I had this issue when I installed Sierra a while ago, and I solved it by connecting my Mini-DP to HDMI cable. This time, that solution isn't working for me.
Any tips? Are there any "garbled" screen fixes out there for Mojave that I can try?
Duh, forgot I had CSM off in the BIOS. However, that did work fine with Sierra. I'll see later today if that gets me to the installer, and then afterward I'm hoping I can disable CSM again once it's installed.Enable legacy boot/CSM in BIOS as per guide:
This answer is already covered on Rehabman post:Hey @Sniki @RehabMan
Can you give me an explanation of why do you install kexts in S/L/E (or L/E) as opposed to the Clover directory? I've found mixed opinions on which option is better, like the Clover one being more "vanilla" and easier to update MacOS (minor version upgrades) with, etc. What are the pros/cons of both options and which one is objectively better?
You should install all kexts you need (including FakeSMC, VoodooPS2Controller, etc) to /Library/Extensions (/L/E) or /System/Library/Extensions (/S/L/E) for 10.10.x and prior using a kext installer or Terminal. Think carefully about "kexts you need". For example, if you needed HPRAIDInjector.kext for a SATA chip locked in RAID mode, you'll need to install it in order to boot (without it, the system would be unable to mount root and would get stuck early in the boot process).
Of course, essential kexts should be installed to EFI/Clover/kexts/Other as they are needed to boot the installer (during updates) or the recovery partition.
It is a mistake to install everything to Clover/kexts. Contrary to popular hackintosh myth, it does not result in a cleaner install (the opposite is true). Many kexts will not work from Clover/kexts, so installing them to /S/L/E where they can be included in kernel cache is the best approach.
People often ask me why I install kexts to /S/L/E (or /L/E on 10.11).
I have many reasons:
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)
IMO, placing kexts in Clover/kexts for injection when not needed is like "flying blind." I don't know about you, but I would not board a plane with a blind pilot (no offense to the blind).
You might be wondering if this will result in duplicate kexts being loaded due to the kexts in EFI/Clover/kexts being injected when they are also installed to the system volume. The answer is no, not generally. With config.plist/SystemParameters/InjectKexts="Detect", kexts in EFI/Clover/kexts are not injected when FakeSMC.kext is in kernel cache. Because FakeSMC.kext is always a "kext you need", you will always install it to the system volume, which will put it in kernel cache. Kernel cache, of course, will not have FakeSMC.kext when booting the installer or recovery, so in these cases the kexts in EFI/Clover/kexts *will* be injected as you would expect.
@Sniki do you happen to know if the "InjectKexts=Detect" mode will check for VirtualSMC on newer Clover revisions? That check would fail with your new setup since we aren't using FakeSMC anymore.This answer is already covered on Rehabman post:
(Guide) Booting OS X Installer on laptops with Clover
I quoted the answer to your question down below.:
I will fix that for you tonight or tomorrow, i will send you a testing SSDT-T440.aml so you can send me an ioreg so i can see where it is attached to, if i recall correctly it was assigned to a EH01 port, or if you can find the post where you used to send me problem reporting files for that i can fix it right away for you.@Sniki - really fantastic work here. I got everything installed and setup, and as far as I can tell, everything is working perfectly.
For my machine, there is one thing I noticed. My touchscreen is not working. I believe this is due to your USB injection SSDT. It looks like all USB devices are routed through the USB 3.0 bus (XHC instead of EHC if I remember correctly?). When I made my own SSDT a few years ago, I needed a particular port opened to make the touchscreen work.
Otherwise, I can't seem to find anything that isn't working. Sleep is working perfectly too! Thank you again for putting together the GitHub project.