I can only speak 2 languages fluently. One of which is my native language. :)) I also speak a bit of Spanish, French, Italian, Russian, and currently learning a bit of Japanese, as well. I definitely know the bad words in some of these. :))) But, for these last ones, I can't say I speak well enough to get a translation done.
Clover wiki has been migrated back to sourceforge to try to keep it as up to date as possible, and is now live. Please use this wiki as official from now on.
EDIT: You may comment fixes and suggestions to a page, but they are subject to moderation by admin (basically slice and I) unless you are a team member (but ultimately still manually moderated if necessary).
EDIT2: Forgot to give a huge shout out to @arsradu for migrating and updating the wiki. Thanks!
Then proceed with install.
The X120 will be installed with Leopard and working Ethernet. Do a software update, which will update it to 10.5.8, then reboot. Screen will just be blank. Do a safe boot by typing -x on Chamaleon screen. Then run Netbook installer, install all. Leopard will then boot normally. But ethernet will no longer work.
LG X120's WiFi is using Realtek's rtl8187se. This is the same card as MSI Wind, and there is already a driver for MacOS. Install the driver to enable WiFi. More at Gamestop complaints number
Yeah, no problem because this will be the last time I respond. No one said you were a computer engineer but I'm going to go ahead and say you have completely no idea what you are talking about. You've been building hackintoshes for ten years?? But yet you don't even know how clover works, also that clover doesn't even have an Extra folder, that you don't even know how to see what is causing the panic and fix it, that installing to /L/E is stupid for any kext you need to boot, because you won't be able to run the installer to upgrade, and also some kexts do not work properly if they are not injected, so no idea what you mean. No one said inject all your kexts, in fact I am now explicitly stating it to you for the FOURTH time, INJECT KEXTS THAT ARE NEEDED TO BOOT OR REQUIRE INJECTION AND PROPERLY INSTALL THE REST. For the sake of everyone in the world's sanity, stop reading tonymac! That website is full of trash and misinformation, and why every other hackintosh site literally will remove anything to do with that site, and even ban you for repeatedly doing it. Not to mention that you are far more likely to be banned from that site for just saying something inane than anywhere I have ever seen. I just googled install unsigned kexts and found several guides that literally are almost word for word copies, it's like no one there can actually do anything but look at the same site and make the same posts with the same wrong information. They don't even have consistent information, I will go over that below because I see this exact same block of text in multiple places on that site and it is wrong. Also, I really hope you don't use any of those tools from that site because you have absolutely no idea what they do and they sign stuff with an actual developer certificate so they can pretty much install any sort of malware and you'd have absolutely no idea unless you knew what to look for, which it's obvious you would not. And hilariously those tools are all available from the actual developers, tonymac just steals everything to make advertising money off unsuspecting people like yourself. There's very little useful information on that site and I only trust two people because I know that they research and go else where too, Rehabman and Toleda.
The previous three times, I stated to inject kexts needed for booting and that don't work unless injected:
Destroying this idiotic statement I see all over tonymac:
Injected Kexts live outside of "protected MacOS memory" *
* Note: I use the term "protected MacOS memory" in this guide as a generic descriptive term. In reality kext's installed in /L/E are loaded into MacOS's kernel memory which is 'protected' (IE: segregated) form application memory and execution memory. Everything running in kernel memory (including kexts) is actively managed and monitored by MacOS.
Doesn't realize that every kext must be in kernel memory or it couldn't work, also how would it be extending the kernel if it wasn't? You know, the main purpose of a kernel extension....? Every kext no matter what is placed into kernel memory.
Injecting a large amount of kexts can result in an unstable system.
This is somewhat true, but unless you have very little memory (less than the requirement for macOS) it's most likely not going to be any issue since at most this may be a few hundred MBs (which even that is extremely high and you are probably more likely injecting somewhere around a few to maybe tens of MBs). You actually have a higher chance of having too many devices cause more memory problems than this, also newer aptio fix helps alleviate this issue by placing the kernel in any random position that is still available for KASLR.
Many 3rd party kexts will not work correctly when injected by Clover.
Then it doesn't need injected. The only reason to inject kexts is to boot and because they need to be loaded and initialized before other kexts that are in the kernelcache, especially ones that are prioritized by the kernel.
EDIT: I forgot that the kext doesn't work because you injected the kext before its prerequisite kexts were initialized. If you force load those prereq kexts it will work, however you now run the risk of one of the injection only kexts that patch any of those kexts to possibly fail to do so.
Injected Kexts are not included in the kernel cache and thus are excluded form MacOS error checking.
I don't even know how to respond to this. This is just so utterly stupid. First, every kext is loaded by the kernel, checked, and initialized, no matter what. This scenario here would be equivalent to using kextload to only load a kext temporarily, it's not in the cache but it's certainly in kernel memory and checked....
Installing kexts in /Library/Extensions is the Apple endorsed and recommended location for all 3rd Party kexts.
Ok, that's wonderful, and has absolutely nothing to do with how to boot macOS because you can't really do that without injecting kexts or making special installers every time and constantly installing kexts every time you use the installer...
If you purchase a piece of hardware that requires the installation of a manufactures MacOS driver, the kexts will be installed in /Library/Extensions so why treat hackingtosh kexts any different ?
Because a hackintosh IS different, if it wasn't, clover would not be needed in the first place. You can install stuff into /L/E all day but if you need that kext to boot, because of my last point it's not really that helpful is it...?
EDIT2: I totally forgot about RampageDev, where he removed his posts from tonymac because they were being jerks, so they sent a DMCA request against his site because it had the same information. Or Mieze (who wrote like every network driver) got banned for pointing out that one of the drivers from tonymac was from an open source linux GPL driver, which requires the source code to be released and they refused. Why would they do that? Probably because it does something that they don't want people to know about. Not to mention literally everything on the site is stolen, modified(?), and closed sourced, which is pretty much against the license of almost every project. In fact, they are currently violating the clover license as well as they actually are not allowed to use the name of the project or authors without the written consent of the project.
So what about the suggestion I made a while ago regarding AppleVPA patching alongside AppleGVA patching? It would be neat if certain Shiki features Boot would also apply to the AppleVPA framework.
Use case example:
Enabling The RX580 Hardware Encoder / Decoder while running iMac18,3 with IGPU disabled (necessary for optimum performance). For this you use a dummy kext that overrides the driver configuration with the Vega 56/64 parameters for video acceleration. Then you need to spoof iMacPro1,1 board ID for stable working GVA with shikigva=32 and shiki-id=<Board-ID>. This is due to AppleGVA containing hardcoded parameters which in case of iMac18,3 are for the IGPU and not for the AMD card. Switching to iMacPro1,1 board ID for AppleGVA fixes this.
However, the same is true for the AppleVPA framework!
Issue: AppleVPA expects IGPU so preview will stop working on Mojave when IGPU is disabled. NoVPA.kext needs to be used, which isn't really a fix because it just disables the VPA feature of preview. It's kind of a dirty workaround.
Real solution: Editing AppleVPA so the iMacPro1,1 board ID configuration applies to the currently used SMBIOS. If Whatevergreen would patch the board ID for AppleVPA as well, preview would start working without NoVPA.kext and without the need of manually editing the AppleVPA framework.
Since AppleGVA patching is already fully implemented in Whatevergreen, it shouldn't be that hard to extend this to AppleVPA I think?
From 10.14.4, installing older graphics kexts (in your case Tesla kexts) from High Sierra no longer suffices. You now need to install / recall GPUSupport.framework and OpenGL.framework from 10.14.3 too. See here.
No, not all all. OS X/macOS offers native support for Fermi from Lion 10.7.5/ML 10.8.2 up to High Sierra. It's just that some Fermi cards are poorly or not supported in certain OS X/macOS versions. Eg: GeForce GT610 (GF119) not properly supported beyond El Capitan.
Anyway, let's avoid the off-topic here please @ellaosx. The only nVidia cards compatible with Mojave to date are Kepler. Fermi are not. And I think the OP has long ceased to consult this thread...
IOReg shows that the Broadcom BT chip is BCM2045A0 with PCI id 0a5c:6414. That's not listed in Rehabman's list of tested/validated devices so it may be fair to assume it ain't supported.
Regardless of support for that Bluetooth chip, installing the Broadcom patching kexts should not prevent your Hack from booting; as such, I expect you're doing something wrong on that matter. It's recommended to cache the kexts from /S/L/E or, ideally, /L/E rather than inject from Clover.
@rooney08, I would try to install 10.13.6 and check it with the same hardware.
Sometimes ACPI methods can turn off hardware using dedicated pins.
Yes, there is a way - using boot-args or clover device properties, please have a look a github page.