For those that don't know what's going on, OS X Extractor 1.3 and Pike's Bootloader are two separate things. It appears he was confused by the web Installer's file size. The "Official download page" he is referring to is not the patches, Kexts, and Scripts that you use for Installing OS X on Unsupported Macs.
If you use OS X Extractor and have 32bit EFI, you will have to get the boot.efi from Pike's Github.
Isiah, He would probably be happier if you did not try to obfuscate the truth with all those extra words.
Quick History:
1. With advent of 10.8 first DP, the VERY FIRST BETA had 32 bit and a 64 bit kernel support. So it could run on any and all Intel Macs.
2. The 2nd iteration dropped support for EFI32 machines, no more 32 bit kernel. No 64bit drivers for 32bit machines GPUs.
3. For the run of 10.8 Wayne Wong (and others) put together packages that allowed 32 bit machines to run 10.8 using either the original DP1 Dual kernel, or using 32 bit drivers from 10.7.4 or 64 bit drivers from 10.6.2. This allowed a sorta/kinda use of 10.8 up through 10.8.4 for these older machines. Look in the 10.8 section to read the whole history. (180+ pages)
4. With the advent of 10.9 this buggery/pokery stopped working. A mysterious benefactor named "Tiamo" came along, he had taken the 64bit boot.efi and made it work on 32 bit machines for 10.9. This allowed most 32bit EFI machines to run 10.9. For Mac Pros, use of a newer GPU could make this perfect, for other machines with no GPU drivers, it was still possible to grab the 10.6.2 64bit kexts for partial GPU function. Lots of "coming soon" type teases and screenshots were dropped to hint that fixed GPU drivers were coming, but Godot never showed up with them. So, ONLY MAC PRO 1,1 RAN THIS PERFECTLY, and only then by replacing GPU. All others had weird issues like FULL ON screen brightness, inability to go to sleep, etc. They were, and are, buggy at best running 10.9.
5. With advent of 10.10 Tiamo never came back. A team of folks got together to help Pike R. Alpha put this new Yosemite boot.efi file together. It was eventually finished. Same issues as above for 10.9. The Mac Pro could function normally (i.e., 100% functional) with a new GPU and new WiFi and BT card. The other Macs again had to do with partial GPU support and various tricks and hacks to bandaid over the other issues. So, ONLY MAC PRO 1,1 RAN THIS PERFECTLY.
6. With Advent of 10.11 it was discovered that the Pike boot.efi would enable El Cap Betas to run on EFI32 Macs. As GM went to Final, Pike and his team worked on perfecting the boot.efi. The issue was the ability to run the Recovery Partition. Apple made this far more important then usual, the only way to turn the "rootless" SIP on and off is by using the recovery partition. Pike and his team got it up and running. Once again, ONLY MAC PRO 1,1 RAN THIS PERFECTLY. All others not only have the usual GPU issues, but as an added twist, so far no other Macs have worked in El Cap due to USB not working. I was able to get a 2007 Mini to run with USB, but not in a way anyone will live with on a daily basis. It is possible that fixes will be found for USB, but more then likely you will need to use the Recovery partition to disable SIP first, putting you in a Chicken vs Egg Catch 22 position. It is possible that Mac Pro 1,1 will be the only early Mac to use El Cap as a result. I personally will not put more then 30 minutes of effort into USB fix, and I doubt that Pike and/or his team will, but I can't speak for them.
The boot.efi is the CRUCUAL piece that makes any of these older Macs run newer OSs. Without it, all of the other packages, scripts, patches, kexts, custom apps, hocus pocus, and fairy dust in the world will not get you a working OS.
The central kingpin to getting later OS's on these EFI32 bit macs is the boot.efi file. There were work-arounds for 10.8, but for 10.9 and on, you absolutely
must use a patched boot.efi. So, I imagine that Pike would be curious why this package exists at all in this forum. Nothing other then the Pike boot.efi will allow an EFI32 Mac to run Yosemite or El Cap. The Macs that could be band-aided into 10.10 are currently incapable of running 10.11. So, ONLY MAC PRO 1,1 RAN THIS PERFECTLY and the Mac Pro 1,1 has no use for these other packages, scripts, patches, kexts, custom apps, hocus pocus, and fairy dust unless they are trying to keep using an X1900, X1300 or 7300GT, and even then I don't know that anything here can help.
In short, until he proves otherwise, Isiah's package is of no use whatsoever to anyone. If he can come up with a USB fix package it will still require the boot.efi to work at all, but until then, there isn't a Mac on the planet that needs the package in the first post. If he and his "developers" can come up with a USB fix package, he will have a reason to have this thread here. (Curious how they will install the package with SIP on, will be a challenge) I will sum up:
EFI32 Macs that can run El Capitan:
1. Mac Pro 1,1 and 2,1 - require boot.efi from Pike R. Alpha, a newer GPU (and WiFi BT card for full function), then runs perfect. Don't need anything else in the package linked at open of this thread.
2. All other 32bit EFI Macs - require boot.efi from Pike R. Alpha and a yet unknown USB fix. Until then, they are completely unusable. It is possible that some of the EFI32 Macs are immune/exempt from USB issue, but so far has applied to EVERY MACHINE TESTED. Do they need the rest of the Johnson package? Hard to say since you can't use the machine due to no USB or BT.
So, if the OP wants some credibility for his efforts, and wishes to actually advance the EL Cap on unsupported Macs cause, (other then Mac Pro) he needs to update the first post with the truth. He should list that all is dependent on Pike R. Alpha's boot.efi file and that the package in first post is window dressing that requires Pike's boot.efi file to be of any use at all. He should also update (and keep updating) the list of EFI32 Macs and what the results of the USB tests are. No Macs other then MP 1,1 will ever run El Cap if this USB issue isn't fixed. The inability of readers to figure out what is going on will discourage further testing. This is a place where more transparency is needed, not further opaqueness.
