Recover HD booting with macosxbootloader

The macosxbootloader is almost fully functional. Adds support for OS X 10.10 Yosemite for the 2006/2007 Mac Pro models. Supports both grey and black theme mode – with the white process bar – but booting from the Recovery HD is still not working. Or maybe I should say no longer working? I mean. Did this ever work with the unmodified version of boot.efi (Tiamo’s), with Mavericks, or not?

If that is a yes, then something is obviously broken. I had a few ideas, and we’ve been testing some of them already, but I am getting confused. What I need now is a full list of all files, and directories, from a Recovery HD partition on a 2006/2007 Mac Pro. Mine appears to be quite different, or maybe it is borked, so that is where you guys come in handy.

p.s. I only need one list so if we have one, please only add omissions. This way we can keep it as clean as possible. Thanks!


Good news. I remembered something from like five months ago. Yes. I already figured this out but I forgot about this change. Luckily some part of my brain recalled it and that was when I asked Mikeboss – a great help by the way – to backup: / and to copy: /System/Library/Caches/ over it. BOOM. A successful boot from his Yosemite Recovery HD!

In other words. The missing 28 bytes (before the mach_header) at the start of the kernelcache, which was removed by Apple in BaseSystem.dmg and the one on the Recovery HD, is causing this boot problem. I have no idea why Apple did remove it, but it is likely to break most boot loaders. With a few exceptions. And that ladies and gents was why the load routine in macosxbootloader is failing.

A fix to remedy this problem is being worked on and should soon be available.

Update 2

The last commit (bf5115b) probably doesn’t work, but the one before that (f519966) should work. Please give it a try.

146 thoughts on “Recover HD booting with macosxbootloader

  1. Hi, Pike and everybody. I’ve been away for a few days and I’m still not sure I can duly appraise current situation. Is the latest commit the “good” one, or should we compile a previous one? Are we expecting further improvements in the immediate future? Has the “surprise” already been implemented in the current code?

    • Hi Peter,

      Well. Mikeboss said that everything is ok. All I did next was an initial cleanup (to hide debug output when you set the compiler directives to 0) but what we really need right now is more testers, because for splinfingate it still doesn’t seem to work.

      The surprise isn’t ready for primetime, but I can assure you that it will be a sweet surprise for everyone.

      • OK. I’ll compile your latest code in a few hours and reboot my old Mac Pro using the Yosemite Recovery HD. I’ll report whether it boots (I suppose it will) or hangs. By the way, Hennesie mentioned that he’d be posting a compiled version of your code at the Macrumors forums so other people can test it, so you’ll have more input. Looking forward to seeing that surprise.

      • Unfortunately, I can’t claim success. Perhaps further tests might be in order, but I can’t do that now. Not until tomorrow anyway. I might have done something wrong. This was my (presumably faulty) procedure:

        1. I compiled the latest build in Visual Studio (Release/Win32).
        2. I copied the resulting boot.efi to my Documents folder in my regular Yosemite partition.
        3. I opened Terminal. From /Volumes, I mounted “Recovery HD” (sudo diskutil mount “Recovery HD”).
        4. I opened folder and saved a copy of Apple’s boot.efi.
        5. Within that folder, I entered sudo chflag nouchg boot.efi
        6. Next cp “/Volumes/Macintosh HD/Users/PJH/Documents/boot.efi” .
        7. I made sure boot.efi was owned by root (system). I also caused it to be executable by group wheel and everyone else (without write privileges).
        8. Next, I entered sudo chflag uchg boot.efi
        9. From /Volumes, I unmounted “Recovery HD” (sudo diskutil unmount “Recovery HD”).
        10. I restarted my computer.
        11. When I heard the chime, I pressed Option and selected “Recover 10.10”.
        12. It restarted perfectly fine (“black” boot.efi), not to the Yosemite Recovery partition though, but rather to my regular Yosemite partition.

        The only thing I can think of is my build was somehow defective (350,720 bytes) and, being unable to use the Yosemite Recovery HD boot.efi, the computer went to the regular boot.efi and booted the regular Yosemite partition.

        Do you have any suggestions as to what I should try next (tomorrow)?

      • I’ve just reread a comment by Hennesie stating that mikeboss succeeded in booting the Yosemite Recovery HD by replacing the kernel cache with the regular version (the one not missing 28 bytes). I haven’t replaced the kernel cache. Was I supposed to do that?

      • Fine. I’ve asked mikeboss to publish “his” build of boot.efi. If he does, I’ll let you know when I test it, presumably tomorrow, unless my production Mac Pro 1,1 shows very little activity later today.

      • Both Hennesie and mikeboss have published their respective builds, but I don’t think I’ll be testing any of them in the near future, because I’ve just retested mine after finding out (thanks to Hennesie) that, instead of pressing Option at startup and choosing the Recovery 10.10 disk, I should press Cmd-R instead. If I do that, a verbose version of boot.efi appears which, near the end of the boot process, is replaced by the “black” visual version, which does indeed boot to the recovery OS X tools that let you reinstall Yosemite.

        I have two questions:

        1) Why doesn’t pressing Option and selecting the Recovery HD actually boot the Recovery HD, but pressing Cmd-R works?
        2) Can the boot of the Recovery HD be made fully visual (i.e. non-verbose)?

      • That is more like it. We are making progress here. Great!

        1.) Option -> Recovery HD works with Mavericks/Tiamo boot.efi Mavericks? If yes, then there must be something that I missed.

        2.) Sure. I’ll change it back to normal boot mode with a next cleanup. You don’t have to wait, because you can remove “BOOT_MODE_VERBOSE |” (without the quotes) in Options.cpp

      • Yes, Option and selecting Recovery 10.9 used to work with Tiamo’s boot.efi (with Mavericks), but it doesn’t with your Yosemite-capable boot.efi (with Yosemite) (though Cmd-R works just fine; go figure!).

        As for removing “BOOT_MODE_VERBOSE”, I’ll try that the next time I compile your source code, unless you create a newer commit that is entirely visual from start to finish.

        Thank you so much. By the way, Hennesie seems to be having serious trouble with his old Mac Pro: it won’t start.

      • Hi Pike and Peter and all,
        works perfectly for me. Recovery boot (with option key as well) and regular boot.
        Just wanted to confirm. Compiled from latest commit, I only switched off verbose mode.

      • From what I’ve been reading on the Internet, it would appear that several Yosemite users are experiencing the impossibility of having their Startup Manager boot the Yosemite Recovery Partition, although Cmd-R always works. In a number of cases, the Startup Manager issue has to do with core storage options. In my case, however, entering “diskutil cs list” in Terminal just returns “No CoreStorage logical volume groups found” and no further action can be taken to return anything to vanilla HFS+.

        Be that as it may, it seems to confirm, I think, that the issue is UNRELATED to your awesome boot.efi. Apparently, during the Yosemite beta phase, Apple released Yosemite Recovery Updates (1.0 and 2.0!). I remember installing at least one of them on a Fusion virtual machine (I suppose it didn’t do anything, of course), but for those who tried it on their physical machines, it might have prevented the Startup Manager issue others of us are having.

      • PS. Naturally, for the above theory to be valid, the users of unsupported Macs must have applied the Yosemite Recovery Update(s) on their systems wherein a Yosemite Developer Preview had been previously installed using Chameleon or Clover.

  2. For Yosemite:
    With a MacPro1,1 (and ATI Radeon HD 5770 ) I can also confirm that I have the Recovery partition booting with commit bf5115b (No swap()) …

    I built the Win32 Release version, mounted the Recovery partition, and replaced boot.efi in after unlocking it with sudo chflags nouchg … I also copied over the kernelcache from /System/Library/Caches/ to /Volumes/Recovery\ HD/

    In fact, I now have my full set up working, including a core storage Fusion Drive that I fused from an existing SSD that had a prior Recovery partition, and a bigger HD, and now with above commit, FileVault2 is also working on this setup, great and many thanks!!!

    The FileVault FusionDrive only shows a command line login, but works perfectly.

    The Recovery volume needs to be entered with Command-R, rather then selecting a volume … this might be due to the Fusion Drive.

    Also, I did replace the boot.efi file inside the BaseSystem.dmg on the Recovery partition, but not sure if this is necessary (same two places as in the main volume : /usr/standalone/i386/boot.efi and /System/Library/CoreServices/boot.efi .

  3. Complete re-install starting from original Apple Store version of the

    I used a Debug black 2c19983303 replacing the usual culprits on the fresh installation media, and successfully loaded a running Yosemite.

    Cmd+R boot into Recovery HD 10.10 gives me this:

    PIKE: Calling BlDecompressLZVN().
    PIKE: BlDecompressLZVN() returned: 2147483649!
    PIKE: Returning from LdrLoadKernelCache(2147483649).
    PIKE: Calling BlDecompressLZVN().
    PIKE: BlDecompressLZVN() returned: 2147483649!
    PIKE: Returning from LdrLoadKernelCache(2147483649).

    With a perpetual wait…

    Option > Recovery HD 10.10 boot gives me:

    PIKE: Calling BlDecompressLZVN().
    PIKE: BlDecompressLZVN() returned: 2147483649!
    PIKE: Returning from LdrLoadKernelCache(2147483649).

    With a short wait, then successful boot into Yosemite.

    For fun, I dropped mikeboss’s boot.efi posted on the MR forums (grey, Release AFAICS) into /, and received a successful boot into the Recovery HD 10.10

    Dunno where the .diff lies, as I’m just building from current sources without any editing.

    Regards, splifingate

    • Ok so it is somehow related to how you compile the source code. That is good to know, but other people may as well run into this problem/limitation so we should document this. Perhaps mikeboss can help you/us/everyone understand what the difference is. Mike?

      • I’ve just compiled commit 2ed42fe2a6eaa4ec348096d111ff25e4461332c0. Oddly enough, there are 434 differences between the boot.efi this generates and the version published by 666sheep over at Macrumors (out of a total de 313,344 bytes. I suppose those differences may be due to different versions of VS running in different Windows versions under different virtual machine environments. Be that as it may, I’ve tested both “his” version and “mine”. As far as I could detect, both behave identically. They are non-verbose and show the newer, black background with the while Apple logo and the progress bar underneath. Neither of them will load the Recovery HD if Option is pressed at the initial chime and selecting “Recovery 10.10”, but both will load the Yosemite Recovery HD if Cmd-R is pressed immediately after the chime.

        Is there a way to make this work pressing Option and selecting Recovery 10.10?

      • The 434 differences you see may as well (in part) be caused by different versions of NASM.

        The Option -> Recovery HD failure should be fixable. I only wonder if selecting another partition, other than the default Yosemite one, also fails or if that works as expected. Can you or anyone else confirm this please?

      • I don’t need to replace boot.efi in BaseSystem.dmg to get my MP to boot Recovery partition with option. I’m just replacing boot.efi in with latest commit. That’s all.

        It isn’t related to VS or NASM version which were used to compile the boot.efi, because Peter tested his own and my build as well.

      • I guess it works for you because you have three partitions on that drive (EFI, boot partition and the Recovery HD). Other people may have more partitions, and then the Recovery HD isn’t the third one (I think) but boot.efi doesn’t check that. It simply increases the partition number. That may be the problem.

    • Results of pressing Option when the chime is heard, followed by the selection of the relevant boot disk/partition:

      Snow Leopard: Snow Leopard boots.
      Windows: Windows 7 boots.
      Windows (old, no longer used Chameleon boot): Chameleon boots.
      Recovery 10.10: Regular Yosemite (not the Yosemite Recovery HD partition) boots.
      Macintosh HD: Regular Yosemite boots.

      According to a post by splifingate at Macrumors, proper operation with Option can be achieved if your boot.efi is injected within the BaseSystem.dmg in the Yosemite Recovery HD partition. I haven’t tested that myself, but it does appear he might be right. The odd thing I find is why a Mac would follow one route when pressing Alt and selecting Recovery 10.10 (presumably noticing that the boot.efi of BaseSystem.dmg isn’t compatible with it) and an altogether different route when pressing Cmd-R (presumably ignoring the incompatibility of the boot.efi of BaseSystem.dmg). When I have the time later today, I’ll try modifying that BaseSystem.dmg, unless you have a better suggestion.

      • I don’t think that it has to do with compatibility issues, but rather with something that I (must have) missed. The only thing we can do now is to add debug output. This should show us the route it takes with Cmd+R and Option -> Recovery HD.

        p.s. Thank you for testing all this!

      • You are most welcome. Notwithstanding your very expert opinion, if splifingate is right, including your boot.efi within BaseSystem.dmg achieves the correct functionality of Option -> Recovery 10.10. How can that be explained? Be that as it may, I’m willing to test a new debug version with Cmd-R and Alt and see what on earth is going on here.

      • It may be a path error somewhere in the source code. We can test this by unpacking BaseSystem.dmg and removing boot.efi from it. Then you repack it again and try to boot with Mavericks/Tiamo’s boot.efi. If that fails, then we know that it is using it. If not, then we can add debug dumps and try to follow the route that it is using in the source code.

      • Hmmm. I don’t think I can do the Tiamo/Mavericks part myself in the near future. I would need to buy a new SATA disk to try that, as I can’t install Mavericks right now (I have nowhere to put it). But I’m certainly willing to try a debug version of boot.efi in the Yosemite Recovery HD.

      • But maybe someone else can try and do the Mavericks check?

        I’ll see what I can come up with (debug data stuff) but it may not be today. So tired that I thought that today was friday already.

  4. AFAIR I used commit f519966 to compile this particular boot.efi. only thing I did was to remove verbose-mode and enable grey bootscreen. I built the binary using the “Release” setting in VS2013. no magic tricks…

    • Thanks. This means that commit 8387465 should also work, as long as “Release” is being used.

      Note: I committed the LZVN packed Panic Dialog data/CLUT minutes ago, but it may not compile error free yet.

      • I’ve a Release built of 2c1998 waiting at home–will pop that in to see what happens.

        I’ve been using VS2013 Desktop in Win7 SSD on a dual Xeon 5620 Dell T5500

        Clean, then Build Debug/Release win32each time

        No mods to settings/preferences.

        Regards, splifingate

  5. So; it’s so.

    I dropped the Release version of 2c1998 into /, and subsequently experienced a successful boot into the Recovery HD 10.10 environment!

    # sw_vers
    ProductName: Mac OS X
    ProductVersion: 10.10
    BuildVersion: 14A389


    “Release”, it is.

    Thank you, Pike, for your timely works; mike for your persistence, Peter for your diligence, H for your sanity, Tiamo for offering us the Red Pill, and all those who said “Yes!”.

    Mis dos gatos son muy contento de que tengo que mirar menos a la pantalla.

    Now . . . let me attend to my two kitteis before I dive into 2ed42fe2a6 . . .

    Regards, splifingate

      • Incorporated 2ed42fe2a6 ‘Release’ into /Volumes/Recovery\ HD/, /Volumes/Revovery\ HD/ (using ‘hdiutil’ majik), and Volumes/Yosemite/Where_It_Applies/ and achieved a successful boot into the Recovery HD 10.10 with Cmd+R /and/ re-boot -> Option -> Recovery HD 10.10

        No more waiting, or unexpected side-steps into Yosemite.

        Good Stuff, Pike.

        I don’t have the slightest idea of the things you do to to make possible the things we do, but they are Successful.

        Personally, I have no real need to boot into Recovery HD, but it seems a desirable goal, if only for Completeness.


        Regards, splifingate

  6. Thank you PikerAlpha for all your work on this !

    I’ve been putting commit 2ed42fe (gray boot screen if that matters) through it’s paces for a couple of days, and everything (so far) seems work as it should.

    Also, thanks to MikeBoss, Hennesie, and all the other folks who were bouncing between the MR forums and here, sharing their builds for testing.

    It was kind of fun, entertaining, (and maybe even a little educational), watching the teamwork between all you guys over the last few weeks sorting this out.

    So, I’m kind of curious about the “aforementioned” surprise at this point.

    Is it that the new boot.efi file is fat binary, so I run Yosemite on my graphite G4 file server, in the basement ? 🙂

    – Jay

  7. I tried hennesys instruct page and have done your ready made usb, but on my 1,1- I seem to get waiting for root error or something like that booting in command v. if graphical boot, progress bar goes away and get either black or grey whichever boot loader is being used and just stays on that color. Seems to be a problem in the no. 1 pcie slot, was using a powered 4870 and worked fine in mavericks with tiamos boot loader but if I put the hd2600 in that slot, there is no boot with video ie: power button immediately shuts it down. Anyway, tried the was it gt 120 from the 4,1 (non powered)? And it did not work in that slot either. I do get the the hd2600 boot screen in another slot. Could that be the cause of the “waiting for” error because it wants the non powered cards in the the 1st slot? I have not tried the 4870 cause im using the power cables for my 4,1 mac pros gtx 660 ti. I also tried intalling to the drive from the other mac pro and replacing the boot efis and adding the ids to the platform.plist where the boot efi is but I just get the folder with the question mark. So just wondering if you have any thoughts or suggestions.

    • Sorry. I have no idea. I wish I could help you, but the honest truth is that I have never even used a first and/or second generation Mac Pro. The third generation Mac Pro was the first Mac I used, but even that was sporadically because it wasn’t mine. In short. The guys in the forums are the real pro users and could have the answer, but if they get it working then something is obviously wrong in your setup.

  8. Hi — I was looking at the macosxbootloader git project and didn’t see anything about the xcode version of the project. Saw a comment in one of your blog posts that talked about that being on the list of things being worked on. What’s the status of this? I don’t have a Windows system anymore so xcode is my only choice for now. Thanks…

  9. Hi !!! I also have a MacPro 1,1 with Yosemite 10.10.2 installed (and re-patched) with your boot loader. Same here: Recovery doesn’t work. All I have achieved is the same result with Alt and with Cmd+R: screen stuck at Apple logo, computer getting hot and fans spinning.
    If I can help by trying some stuff, please tell me. Thanks.

      • Nope. My drives are not encrypted.
        I recently updated to 10.10.3. No problem at all. Using PikeYoseFix.
        Unable to boot from Recovery HD, either via Cmd+R or via Option. No other partition than the system one would boot. Unsuccessful trying to modify the Recovery HD partition and its BaseSystem.dmg.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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