El Capitan support for unsupported hardware is here!

A little over a month ago I blogged about El Capitan support for macosxbootloader and today, after 80 hours of research and development, I released two versions of boot.efi for El Capitan. One with a black background and a white Apple logo, and another one with a grey background and Apple logo.

You can read more about this project for El Capitan here.

Note: I should have added that using -f (flush caches) is no longer supported, and using it will throw a KP. In short. Please wait for me to add support for it (see development phase 3).

Edit: Great. Mike started a new developer thread over at macrumors.com

Have fun now!

137 thoughts on “El Capitan support for unsupported hardware is here!

  1. This is the message I’ve just posted at Macrumors:

    To everyone interested in this project:

    It is foreseeable that, in the next few hours or days, Pike will begin including phase-3 improvements to his boot.efi. If it is OK with everybody, I’ll go on compiling them for Mike’s tests. Naturally, other people can also test them at their own risk.

    In any case, people must be aware that such interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want the “black” boot.efi (El Capitan edition) should download https://raw.githubusercontent.com/Piker-Alpha/macosxbootloader/El-Capitan/Prebuilt/boot.efi, whereas those who prefer the “grey” version of the same should download https://raw.githubusercontent.com/Piker-Alpha/macosxbootloader/El-Capitan/Prebuilt/boot_grey.efi. Pike alone will decide when such repository versions will be updated with a newer version.

    Please, notice that the upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, such versions ARE NOT FOR YOU!

  2. That’s great. I’ve noticed your page “How to replace boot.efi with mine”. I can’t find the shell script (?) that produces the output shown. Are you going to publish it?

    • Yes and no. The one that we are testing is specifically made for El Capitan – though the source code also support Yosemite and Mavericks. The only change you would need to make is this line. There you change the EL_CAPITAN into OS_LEGACY and you are ready to compile it, but please note that I have yet to hear from anyone that this works. Yosemite should be fine though.

  3. Commit 2cc44fb7a356705ccd5c394afd427eea9ba7f055 compiler errors:
    Error 1 error C2065: ‘symbolTableCommand’ : undeclared identifier C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\MachO.cpp 1252 1 boot
    Error 2 error C2227: left of ‘->StringTableOffset’ must point to class/struct/union/generic type C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\MachO.cpp 1252 1 boot
    Error 3 error C2664: ‘const CHAR8 *strstr(const CHAR8 *,const CHAR8 *)’ : cannot convert argument 1 from ‘const char [15]’ to ‘const CHAR8 *’ C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\MachO.cpp 1264 1 boot
    Error 4 error C2664: ‘int strcmp(const CHAR8 *,const CHAR8 *)’ : cannot convert argument 1 from ‘const char [10]’ to ‘const CHAR8 *’ C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\MachO.cpp 1270 1 boot

    • It would appear something has happened to the hardware where Mike used to test the experimental boot.efi files. It might be some time before he can run any tests. If any other knowledgeable person, such as splifingate, can give us a hand, the compilation can be found at the Macrumors site.

  4. no big deal, the old Mac Pro is okay. it’s just that I disassembled it already. I need to put the components back together, that’s all 😉 will be up and running again tomorrow.

  5. splifingate here (in the process of migrating to Windows 10 on my Dell xeon Server, and things are, well, kinda strange, at times (and un-timely, it seems).

    I have not updated my credentials, etc, &c., et al. . . . .

    I have compiled commit 61c5f5b, and replaced all the boot.efi’s in all their respective places.

    Boot into El Cap install fails…

    I can successfully boot into the 10.11 Recovery HD, but I don’t know what I should do, now (do not know how to flush cache(s), or where to add ‘-f’).

    Reading/parsing your source, I can provide this:

    # nvram -p ->

    IdlePML4 = %d0%daN%08%80%ff%ff%ff

    # nvram -xp ->

    IdlePML4 = “0NpOCID///8=”

    /Volumes/backs2tb/csrstat fails(hangs, until ‘control+c’) . . . not mounted?

    How can I help you best/better?

    • Er…

      mount of /Volumes/partition/csrstat now works:

      # /Volumes/backs2tb/csrstat ->

      System Integrity Status: enabled (0x00000000)

      Apple Internal: enabled
      Kext/FilesystemProt/DebugRest/DTracePest/NVRAMProt: disabled

  6. Although I don’t suppose it’s very different from the previous build, commit 61c5f5b7ff1540d4ec582c4f7a78be66caedb29d has been compiled and posted.

    • Please don’t use -f. Not yet. The patch is waiting for a confirmation that the other commit works, which apparently it does not and thus I enabled verbose boot and added new debug info so that we can see what the problem is.

  7. I was under the impression that the boot.efi is finished and that there’s no need to test anymore… so I dismantled the system (I do own a bunch of other, more recent Macs to run modern OS X releases).

    4fe6137845f7b734db6a2f52d79b7ad1f8cdf3f5: this commit does not boot successful. I can see the grey Apple logo and the progress bar but then the system immediately reboots.

    • I must have made an error somewhere. Verbose boot enabled and new debug output added.

      Edit: I think I have found the problem. You could add slide=0 as boot argument. That should solve this. Source code updated.

  8. Commit 029c466eb045ecb16b4af9db232e477c08ff8eab compilation error:
    Error 1 error C1012: unmatched parenthesis : missing ‘)’ C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\MachO.cpp 1264 1 boot

    • Great. Thanks. Yeah the debug output. You should see something like:

      “PIKE: loadExecutable found!”
      “PIKE: _IdlePML4 found!”
      “PIKE: ArchpKernelIdlePML4(0x%llx)!”
      “PIKE: ArchpKernelIdlePML4(0x%llx)!”

      Is the value of the last 10 lines the same?

    • I will. Only need some data. Added before going back to bed. Will have a look later.

      Note that the previous versions I released are fine, and can be used for the official release. What I am working on is not required for the installation. Just something extra. To support -f (flush caches) that also fails in Yosemite now.

  9. Pike, I feel you might be reading this far too soon. Really, wouldn’t it be better if you call it a day and we can talk tomorrow? Have some tea, or some broth and go back to bed.

    Commit 3f996378a0ff0f21a2da152fefddeb436af7598b has been compiled and posted. Someone will comment on it, but there’s no need for you to work when you are sick. Their report will still be there tomorrow. There’s no hurry. Take it easy.

  10. Hey piker! I’ve stumbled across this site after googling how to install el captain on a 1.1 mac pro. I’ve noticed that the boot.efi you’ve created is complete through all 3 stages. Do you plan on releasing a program like sfott? I liked how simple it was to make a bootable install drive that was pre patched. It really helps the people like me that are not the greatest at this.

    PS. Thank you for all your dedicated time and hard work. I’m very sorry for your recent personal loss. You’ve made a lot of people very happy, and I’m sure your work to come will always provide benefits to real world problems. You’ve kept my mac pro alive for years to come and will take my music studio to the next level again I give thanks.

  11. If you aren’t well, don’t work. Take tea, herbs, something light to eat, and have plenty of rest. Commit 31851607e8ce47ab4f4ec9e5f8080e383c8803c6 compiled and posted!

    • Hangs too at the same point on a MBP2,2 – but with the normal boot of a patched Installer (Release-version 30-Sept-2015). Plus a lot of “kxld[…]:_kernel_couldn’t find symbol” messages before ….

      • The installer copies bootbase.efi from the inner DMG to /.IABootfiles/boot.efi (this one has SIP disabled) so you probably need a similar file from the macosxbootloader project, which was made possible minutes ago. Wait for Peter Holbrook to compile this version (the one before the last commit) and see what that does.

  12. Outstanding! You guys seriously rock!

    I have replaced the boot.efi on my (previously not working) Fusion drive that I’d built in my MacPro 1,1 and it’s now returned to a working state! Beautiful.

    I’ve also put through a donation. All I could do at this point.

    You’re an amazing and intelligent team! Thank you.

  13. Hi.
    Thanks for all your hard work! My 2006 Mac Pro is running El Capitan like a boss.
    But I have one question. Would utilities like “PikeYoseFix” still work, now that SIP blocks root access to /System ? Or will I now require a seconds partition to replace boot.efi with every update release? Thanks

  14. Commit 81fa8702089b74dd292349865c6f1c4721eefd44 compiled and posted!

    This is boot.efi, not bootbase.efi. Is there a source code repository of the latter that I can compile? Or is there a patch that should be applied?

    • Thanks. The only thing that you need to change is the BOOT_BASE_EFI setting in src/boot/StdAfx.h Setting it to 1 is all is required to get a SIP disable copy of boot.efi.

      • Bootbase.efi of commit 81fa8702089b74dd292349865c6f1c4721eefd44 compiled and posted. The environment of the two latest compilations has been as follows:

        Microsoft Visual Studio 2013 Professional
        Windows 8.1 (32 bits)
        VMware Fusion 8.0.1
        OS X 10.11 El Capitan

        In case these versions are considered stable, you might want to ask spriflingate to recompile them using MVS 2015 and Windows 10.

      • Thank you Peter. Let’s hope that SIP is really disabled, so that people can use it to replace bootbase.efi in the DMG. And that is an excellent idea about MVS2015/Windows 10. Thanks!

    • This version boots the patched Installer (Release-version 30-Sept-2015) on a MBP2,2 – but when the Installer copies the files to the destination the MBP2,2 restarts suddenly after 2 minutes. I’ve used the same file for Boot.efi and Bootbase.efi.

      When the black progress bar (grey Boot.efi) has reached 100 percent (identical to the end of verbose mode) then a grey progress bar appears with firm 10 percent until later on the OSX Welcome screen appears.

  15. with regards to latest commit 81fa870:

    I get a warning (which precipitates an error that halts the build):

    MachO.cpp Line:1250 ->

    “declaration of ‘ix’ hides previous local declaration”

    About an hour ago, I decided that I had set things up improperly, so I decided to re-install Win10 and VSE15 from scratch.

    Fresh install of Visual Studio Express 2015 (Microsoft Visual Studio Express 2015 for Windows Desktop, Version 14.0.23107.0 D14REL), and I get the same warning/error.

    I’ve fiddled both sides of the install, but fixoring is beyond my ken ;(

  16. I haven’t heard from mikeboss lately, so I don’t know whether the latest compilations were any good for him. Be that as it may, I have a question about something that happened to my Mac Pro yesterday. Before the compilation of bootbase.efi, I created an El Capitan Installation medium on an internal 8Gb disk partition in which I replaced the two stock boot.efi files with the black one in your repository. For it to boot successfully, I had to alter its /Library/Preferences/SystemConfiguration/com.apple.Boot.plist so that the section will contain these two lines

    <key>Kernel Cache</key>

    When the installation (update of my previous Yosemite partition) ended without a glitch, I didn’t let the system reboot. I simply opened Terminal, replaced boot.efi in both folders of the target disk, closed Terminal, selected my Macintosh HD (now with El Capitan) as the startup disk and it booted without any problems.

    From within El Capitan, I used diskutil to mount its Recovery HD partition and replaced its boot.efi. There weren’t any problems. My plan was to test the Recovery HD partition later, but never had the chance.

    Several hours later, I had to briefly boot a 64-bit version of Windows 7, which went well. When I went back to El Capitan, I received a kernel panic (unable to find driver for ACPI in /Library/Caches and blah, blah, blah). I tried everything I could think of (like booting to Snow Leopard and, from Terminal, entering sudo nvram boot-args=”-f”, “-x”, “-v” “noacpi” and combinations thereof, to no avail. I also cleared the nvram completely. Nothing worked. In the end, I chose to reinstall El Capitan using the same procedure as in the morning. It worked fine.

    Do you have any idea as to what may have gone wrong? Is there a more sensible way to extricate oneself from such a predicament than reinstalling the system? Should I change /Library/Preferences/SystemConfiguration/com.apple.Boot.plist on my Macintosh HD? Is there a foolproof method of erasing the El Capitan kernel cache from the Terminal once one has booted from another disk (say, Mountain Lion)?

    Any pointers that you can provide will be greatly appreciated.

    • First. I don’t understand why the Kernel Cache setting was even required, but it appears not have found one otherwise. This is something we should look into. Also. When you reboot, then please don’t use -f and/or -noacpi.

      My first though is that the boot process stalled with a KP, because the prelinkedkernel was not there anymore, or not properly rebuilt. Note that only Yosemite and El Capitan can do this right. sudo touch /Volumes/ElCapitan/System/Library/Extensions from Yosemite should work. Used that myself a couple of times already. Other than that. We are still trying to iron out the kinks, and me not being 100% (after the flu) isn’t helping, and did set us back some time. Let’s try to regroup, get some energy and fix the last bugs that we may end up getting to see.

      • I was also surprised by the need to alter com.apple.Boot.plist with the kernel cache parameter and the path to the prelinked kerne, but the installer only worked after entering that. Naturally, I hadn’t altered the bootbase.efi at the time. Perhaps things are different now.

        Can you elaborate on the instruction “sudo /Volumes/ElCapitan/System/Library/Extensions”? Isn’t something missing there?

      • Many thanks for the clarification. If something like that happens again, I’ll try that.

        On another front, from what you’ve said to atvusr, I interpret that IF BOTH boot.efi occurrences AND bootbase.efi are replaced on the installer, the installation process will be intelligently modified so that a special copy of bootbase.efi is saved to /Volumes/MacintoshHD/.IABootFiles, which is automatically blessed. Whether this interpretation of mine is correct or not, can you clarify the procedure. For those of us who already installed El Capitan without recourse to bootbase.efi, is there something we should do (via Terminal instructions, for instance) to set things straight?

        If, supposedly, the future official update to 10.11.1 were to overwrite boot.efi, how would an old Mac Pro that used to have your boot.efi behave? Would it boot nevertheless thanks to that blessed bootbase.efi parading as a normal boot.efi? Would the user, then be able to manually reinstall your regular boot.efi to both sites?

      • bootbase.efi is indeed saved to /.IABootfiles/boot.efi or /OS X Install Data/boot.efi (depends on the type of installation) and used by bless for the reboot. Meaning that you still need a modified copy of InstallESD.dmg (and the inner BaseSystem.dmg) with the new boot files, but I don’t know what the best approach is for the next update. Not yet. Still working on a solution. That bring me to another question; What exactly did you change in the DMG?

  17. commit 81fa8702089b74dd292349865c6f1c4721eefd44: starts flawles with boot-args “-f” in NVRAM.

    bootbase.efi indeed disabled SIP completely (even though csrutil status stated otherwise).

    • I’ve tested the boot-64be04e895785b48117ea0b3cdc2b555ac836422 on a MBP2,2 with a patched Installer. Boot.efi and Bootbase.efi each replaced with their specific version.

      It boots, but after 2 minutes while the Installer copies the files to the destination I get suddenly a Kernel Panic and the MBP2,2 reboots.

      The original Installer-App downloaded from Apple’s App-Store is ok because I was able to install OSX 10.11 flawless on a supported Mac.

      • Please check:

        /OS X Install Data/boot.efi

        or (this depends on the installation method):


        Is that the file we expect it to be (our file is almost 50% smaller)?

        This copy of boot.efi should actually be our bootbase.efi (renamed by the installed) and is used in a bless command to let your Mac reboot with SIP disabled. Having the wrong version of boot.efi in the above directory will, most likely, break the installation process.

      • Where can I find /.IABootfile/boot.efi ?
        The patched Installer doesn’t have hidden files/directories. With “sudo find /Volumes/Installer/ -type f -iname boot*.efi” I can only find the 3 well known Boot.efi files.

      • It’s only there right after the installation process is started. Then it reboots the blessed boot.efi in that directory. The next target is OS X Install Data on the same drive. Directory is removed when the installation process is done.

  18. this is strange. I have no idea since when this is the case because I never actually tested it: SIP seems to be disabled with the latest boot.efi in place. csrutil status gives enabled (Apple Internal). but I’m able to rename a KEXT file even when not logged in as root. this is not possible on El Capitan release version running on an officially supportd machine.

    • That is strange. Can you reproduce this with the official releases? Also. Please report the value of csr-active-config or the output of csrstat (mine) because csrutil status doesn’t report anything useful with its one liner output.

      Edit: Please do a grep 'bootbase.efi' boot.efi (should not return anything for boot.efi) to determine if your copy of boot.efi is in fact boot.efi or bootbase.efi (compiler detective may fail).

  19. I tested this with boot.efi from sept. 27th (the official one). grep didn’t return anything suspicious. csr-active-config value in NVRAM reads “EAAAAA”. SIP is clearly deactivated as I am able to rename KEXTs in /System/Library/Extensions. something went wrong 😉

  20. 51b05ad5c3250ecbee1d0194e8aace5f281f79e1: aahhh, much better 😉 both files behave the way they should. boot.efi -> SIP is really ON and prevents me from renaming the files. bootbase.efi (installed in El Capitan as boot.efi) allows me to mess with system files.

      • what do you mean exactly with “would not have been able to install El Capitan”? I did not yet create an installer volume for old Mac Pro…

      • Apple was smart enough to start the SIP implementation in Yosemite, and since most people will upgrade from Yosemite… that will fail without bootbase.efi from the El Capitan installer – or mine for unsupported hardware.

  21. ah, I see. ATM I’m still using the MacPro5,1 to do a fresh install. afterwards I replace the boot.efi and move the SSD to the MacPro2,1. AFAIR peter did initiate the installation of El Capitan from within Yosemite. when testing the bootbase.efi I simply rename it to boot.efi and place them where they belong so I can check their behavior.

    • Thanks Peter. Please note that this is a special version to find the bug that breaks the installer without the Kernel Cache property specified in com.apple.Boot.plist. We want to solve this bug as soon as possible as it could potentially lead to other issues during the installation process.

      • Currently downloading teh ‘Official’ El Cap release…

        Tid-bit from Distribution in OSInstall.mpkg (lines 287-289):


        I have thought it possible to re-place the BaseSystem.dmg with a modified .dmg, and adjust these values in the installer, but have not actually tried this.

        It will take me a bit of time (personal, familial and business requirements are such that I have far less screen-time than I currently desire) to get the results, but I will report back.

        Waiting on the phenomenally-slow copy of the Release to a thumb before I can actually dissect it.

      • Yes, I understand that. I considered uploading a copy of the installer I made, but uploading 6GB and then for Mike to download it would take much longer than creating an installer from scratch. So, I wrote a guide (based on Hennesie2000’s) to the installation of El Capitan on an old Mac Pro. It’s imperfect and, certainly, not foolproof, but it’s easy to follow for medium-level users. It can be found at http://forums.macrumors.com/threads/boot-efi-developers-thread.1924434/#post-22018159

      • One note. The copy of boot.efi for the Recovery HD can be the ‘normal’ boot.efi – either grey or black – because I already included code to detect that it is running from the Recovery HD i.e. you don’t need to copy bootbase.efi to it (and rename it).

        We might want to add code to detect that it is running from the installer directories so that one copy of boot.efi can be used everywhere.

        Edit: Under “Things you will need” points 3 and 5 you mention Pacifist.

        Ehm. Why don’t you use createinstallmedia and mod the result instead?

  22. …forking web-bulletin-board-thingy nicked the important bits:

    “Tid-bit from Distribution in OSInstall.mpkg (lines 287-289):”

    pkg-ref id=”com.apple.mpkg.OSInstall” auth=”root” version=”10.11.0″ OSInstall.mpkg
    system-image id=”com.apple.dmg.MacOSX” BaseSystem.dmg
    system-image id=”com.apple.dmg.MacOSX” version=”″ sha1=”eddf71b54c632cd3b9ac9bdb7cc60db798363020″

    • o.k….

      So, I made a new installer with the official release of El Cap, and modded the BaseSystem.dmg with a fresh compile of the latest commit (MS Visual Studio Express 15 (which clears fine; thx Pike)) *.efi’s.

      I created a new sha1, and incorporated that into the Distribution contained within OSInstall.mpkg…

      (I added/replaced everything else, as I’ve always done)

      Boot into installer gives me:

      “OS X could not be installed on your computer”
      “No bless setting for primary boot program was found.”

      I will try again…

  23. It just occurred to me, Pike, that perhaps I should stop compiling special versions for bootbase.efi? I mean, if bootbase.efi on the Installer can be left alone as the stock version Apple provides, shouldn’t it be simply ignored from now on?

    • You cannot use the Apple stock provided one on unsupported hardware. That is the 64-bit only. Compiling bootbase.efi is no longer required. Not until I add new code for it.

      Edit: Can you test the latest commit, with new debug output, so that we can try to locate the issue you had with the installer (Kernel Cache required)?

      • I was referring to bootbase.efi, not the regular boot.efi.

        I only have my production Mac Pro 1,1, but I can’t turn it off at will. After advising my clients, I might be able to run this test on Monday about 3 o’clock in the afternoon (your time). It’s quite possible that Mike will be able to test it this afternoon if he manages to build the install media.

  24. Pike:

    in your commit 9edc64d, line 453:

    for (; ii < 5; ii++)

    lack of variable before semi-c seemed odd to me; I changed it to:

    for (ii; ii < 5; ii++)

    and re-compiled with no noticeable change in performance (still received the null string four times on boot)

    Just a thought before I move to the latest commit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s