macOS boot.efi developer's thread

[splifingate]

#########
What is the correct way to install El Capitan on a 2006/2007 Macpro that is currently running Lion?

Thanks,

Don James

There is currently no "correct" way to accomplish this, in a nut-shell, as you will find that the floor is littered with such.

I suggest patience, reading and experimentation.

We are standing and wobbling upon the shoulders of those among, and who preceeded, us, and it will take but a little more time till we can condense these things into a tidy package.

First-and-foremost, Pike & Co. need a well-earned break

 

[Pike R. Alpha]

#########
What is the correct way to install El Capitan on a 2006/2007 Macpro that is currently running Lion?

Thanks,

Don James

Hi Don,

This is the developer thread, and for installation issue you visit:
https://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-el-capitan.1890435/page-36
Thanks.

 

[Pike R. Alpha]

regression to commit 46a02b4f:

splifingate$ ioreg -p IODeviceTree -d 2 -k board-id | grep board-id

"Mac-F42C88C8"

All-across the board....

[edit: I can d/l ElCap from the App Store with 46a03b4f]

In commit a6d29c77, line 31 in StdAfx.h was:

31: #define BOARD_ID_REPLACEMENT "Mac-F42C88C8"

commit c7494b78

replaced that with:

31: #define MACPRO_31
32: #define MACBOOKPRO_31

I just don't understand #if and #else enough to play with the code...

What is the exact problem? Ok. You said that you cannot download El Capitan from the App Store, but "Mac-F42C88C8" is the board-id of a MacPro3,1 and not "Mac-F4208DC8" or "Mac-F4208DA9".

Wait. Some of the Geekbench results of the MacPro2,1 show a board-id of a MacPro1,1 so now I am getting confused. Let me add one more check. I'm also going to reenable verbose mode/debug output.

Edit: New commit available for compilation/testing.

 

[PeterHolbrook]

Now checking for MacPro[1/2,1] and MacBookPro2,2.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] 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, [these] versions ARE NOT FOR YOU!

 

[splifingate]

What is the exact problem? Ok. You said that you cannot download El Capitan from the App Store, but "Mac-F42C88C8" is the board-id of a MacPro3,1 and not "Mac-F4208DC8" or "Mac-F4208DA9".

Wait. Some of the Geekbench results of the MacPro2,1 show a board-id of a MacPro1,1 so now I am getting confused. Let me add one more check. I'm also going to reenable verbose mode/debug output.

Edit: New commit available for compilation/testing.

I have classes with the kids this (my) morning, and will be away until 5/6pm yours.

I'll not be able to test, till then . . . sorry ;/

[edit: to be clear, I am able to d/l ElCap from the App Store with the builds prior to commit c7494b78 when my board-id "claims" F42C88C8]

 

[PeterHolbrook]

to be clear, I am able to d/l ElCap from the App Store with the builds prior to commit c7494b78 when my board-id "claims" F42C88C8

I don't know how significant my observation might be, but here it goes: Last night I was able to update the boot.efi on my old Mac Pro with version 3.0 of Pike's repository. Everything went fine. Running the customary ioreg command in Terminal displays the now-expected "Mac-F42C88C8" board-id, and it seems the App Store would let me download El Capitan "again". Actually, it tells me El Capitan is already installed on my computer, but if I click "Continue", it will, in theory, let me download it "again". The point is, it doesn't tell me my machine is unsupported (as it would previously), but I don't see it downloading anything, nor does the App Store tell me anything is wrong. All I see is a spinning wheel, as if it were executing something, but I can't detect a download in progress.

 

[Pike R. Alpha]

I may have located a bug. Possibly the root cause of the stall issues people have been reporting. New commit available for compilation/testing.

@PeterHolbrook,

Had the same issue here, then I remembered that you need to remove the previously downloaded DMG and then everything is fine.

 

[PeterHolbrook]

Additional check for prelinkedkernel.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] 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, [these] versions ARE NOT FOR YOU!

 

[donjames]

There is currently no "correct" way to accomplish this, in a nut-shell, as you will find that the floor is littered with such.

I suggest patience, reading and experimentation.

We are standing and wobbling upon the shoulders of those among, and who preceeded, us, and it will take but a little more time till we can condense these things into a tidy package.

First-and-foremost, Pike & Co. need a well-earned break

########
Okey dokey. I understand. Thanks for getting back to me.

Don

 

[donjames]

Hi Don,

This is the developer thread, and for installation issue you visit:
https://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-el-capitan.1890435/page-36
Thanks.

Hi Pike,

Okey dokey. Thanks for the response.

Don

 

[PeterHolbrook]

you need to remove the previously downloaded DMG and then everything is fine.

That may be the explanation for most cases of this occurrence, but I don't think it applies in my case, as I no longer have the "Install OS X El Capitan.app" in my Applications or Downloads folders. What DMG are you talking about?

 

[Pike R. Alpha]

That may be the explanation for most cases of this occurrence, but I don't think it applies in my case, as I no longer have the "Install OS X El Capitan.app" in my Applications or Downloads folders. What DMG are you talking about?

Sorry. DMG -> app

Did you check the Purchased tab in the App Store? Is the Download button for El Capitan greyed out?

 

[PeterHolbrook]

Sorry. DMG -> app

Did you checked the Purchased tab in the App Store? Is the Download button for El Capitan greyed out?

El Capitan wouldn't appear there, as I got it from one of my kids' compatible Macs (they used their own Apple ID). Oddly enough, I still have a Yosemite entry in my Purchased tab in the state "Downloaded". If I remember correctly, I got that one from the App Store last year using a Mavericks virtual machine running on the Mac Pro.

 

[Pike R. Alpha]

El Capitan wouldn't appear there, as I got it from one of my kids' compatible Macs (they used their own Apple ID). Oddly enough, I still have a Yosemite entry in my Purchased tab in the state "Downloaded". If I remember correctly, I got that one from the App Store last year using a Mavericks virtual machine running on the Mac Pro.

Odd. You may want to enable the debug menu and see what is going on. Look here https://www.macstories.net/news/enable-hidden-mac-app-store-debug-menu/

 

[PeterHolbrook]

Odd. You may want to enable the debug menu and see what is going on. Look here https://www.macstories.net/news/enable-hidden-mac-app-store-debug-menu/

Thanks, Pike. I've tried. As far as I can see, the menu is now, indeed, a menu, not an applet, but I don't know where to look for threads, App Store logs or anything like that. Everything seems to be working fine, but there's no download. It isn't one of my priorities, though. Don't worry about it.

 

[atvusr]

Now checking for MacPro[1/2,1] and MacBookPro2,2.

Tested on MBP2,2: patched Installer (createinstallmedia) - boots, but Kernel Panic after 2 mins like in older builds.

If the Board-ID must really be contained in the Boot.efi, then the other older EFI32 Mac models should be integrated too (List of Board-IDs):

- MacBook Air 1,1
- MacBook 2,1
- MacBook Pro 2,x
- Mac mini 1,1 (upgraded to C2D)
- iMac 4,x (upgraded to C2D)
- iMac 5,x
- iMac 6,1
- Xserve 1,1

But imho the name of the target partition (or similar data) should not be linked firmly in the Boot.efi - it could have undesired side effects in different Mac models.

 

[Sko]

I tried the latest commit c9a5c6f70cef870f858660257d6c2e8b7e5f2833.zip with BaseSystem.dmg aka Hennesie method.
After PRAM reset and booting from install media, I get this debug output:



Finally it hangs here:



Note the lengthy pause between the two timestamps. It goes to "en2: channel..." and hangs there for almost four minutes.
I've waited another five minutes after this picture was taken and finally gave up.

 

[readyfordustoff]

I may have located a bug. Possibly the root cause of the stall issues people have been reporting. New commit available for compilation/testing.

@PeterHolbrook,

Had the same issue here, then I remembered that you need to remove the previously downloaded DMG and then everything is fine.

I had the same issue with the app store last night. I simply made sure that my El Capitan installers were on a volumes that could be unmounted prior to launching App Store app. The download could then proceed. See progress bar below... screen grab of portion of App store window.

 

[splifingate]

commit c9a5c6f7:

boots to Mav/Yose/ElCap perfectly.

boot to each gives me:

[...]

PIKE: SMBIOS kSMBTypeBaseBoard found

PIKE: SMBIOS board-id found

PIKE: SMBIOS factory board-id: Mac-F4208DC8

PIKE: SMBIOS board-id: Mac-F42C88C8 replaced with Mac-F42C88C8

PIKE: SMBIOS fake board-id: Mac-F42C88C8

d/l of ElCap.app via App Store proceeds as expected in Mav/Yose…d/l from ElCap 10.11.0 gives me a persistent spinner in App Store (as attached; not entirely unexpected).

[edit: I have ElCap installers littered througout multiple, mounted partitions]

Still have yet to try createinstallmedia, legacy installer (Jabawok, Hennessie, et al.) or Recovery HD...back in a few....

 

[splifingate]

commit c9a5c6f7 in createinstallmedia environment successfully boots, and allows installation

[edit]
-bash-3.2# ioreg -p IODeviceTree -d 2 -k board-id | grep board-id -->

"board-id" = <"Mac-F42C88C8">
[/edit]

 

[splifingate]

commit c9a5c6f7 boots into legacy installer, but stalls when getting to the wireless (en2) AirPort detection (~same as @Sko ), and hangs @ "Waiting for DSMOS"

Teh Legacy Installer method (Jabbawok, Hennessie, et al.) is a complete Frankenstein, from incept, so I can't fully qualify it a failure.

I will re-build, from scratch, and try, again.

 

[Pike R. Alpha]

Legacy is BaseSystem.dmg restore right?

If yes, then make sure that you have: /System/Library/Kernels/kernel or the prelinkedkernel cannot be rebuilt – you may need to boot with -f.

You can either copy the kernel from a working setup of El Capitan, extract the kernel from the /System/Installation/Packages/Essentials.pkg in the OS X Install ESD.dmg or use my LZVN to extract the kernel from a pre linked kernel.

@atvusr,

Thanks for the links and no target path is set/hardcoded in boot.efi

@PeterHolbrook,

You probably need to use debug=[some value] as boot argument to get the output.

@readyfordustoff,

Thank you for the confirmation.

@Sko,

Thanks for testing all this, and hang in. We're nearly there. Check Kernels/kernel!!!

Edit: New commit available for compilation/testing.

Thanks to all participating here!

 

[splifingate]

latest commit b744c92e boots quickly into Mav/Yose/ElCap/createinstallmedia with initial output as attached (correct factory -> fake replacement notation).

AFAICT, Everything works as expected (these images are from previous daily-lifter, working installs--my own, little time machines, if you will).

My current legacy/basesystem-restore installer has the Pacifist-extracted kernel from Essentials.pkg in the appropriate place.

I can't attest to its veracity, on the whole, and it will take a few more minutes to get a new one re-built...

 

[PeterHolbrook]

I had the same issue with the app store last night. I simply made sure that my El Capitan installers were on a volumes that could be unmounted prior to launching App Store app. The download could then proceed. See progress bar below... screen grab of portion of App store window.

I have an 8GB partition on one of my four internal disks with the "legacy" El Capitan installer (created following the Tiamo/Jabbawok/Hennesie method). I've just unmount it (from diskutil), but the App Store download of El Capitan continues to do nothing. Perhaps the disk needs to be unmounted when the computer starts?

It isn't easy for me to restart this old computer, as it works as a server for a company, and it can only be brought down when certain conditions of network traffic are met. In any case, figuring this out is not a high priority for me, but thanks for the suggestion.

 

[PeterHolbrook]

Sorry not to have posted this before. I was sick last night.

Fix output.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] 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, [these] versions ARE NOT FOR YOU!