since Pike is doing all the heavy lifting in this project, it would be nice if people who think that the boot.efi is useful to them would make a donation -> https://pikeralpha.wordpress.com/2014/10/24/now-accepting-donations/
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
2006/2007 Mac Pro (1,1/2,1) and OS X El Capitan
- Thread starter Mr. Zarniwoop
- Start date
-
- Tags
- mac pro 2006 mac pro 2007
- Sort by reaction score
since Pike is doing all the heavy lifting in this project, it would be nice if people who think that the boot.efi is useful to them would make a donation -> https://pikeralpha.wordpress.com/2014/10/24/now-accepting-donations/
We ought to identify where on earth the installer gets the source for that stock boot.efi. I take it for granted that when you edit the dmg you replace both occurrences of boot.efi in the usual folders. You mentioned a .efi file with another name (was it bootbase.efi or something like that?). Have you also written the experimental El Capitan boot.efi on top of it, or is that an entirely different kind of thing? Is there a third or a fourth occurrence of boot.efi somewhere in the dmg? Perhaps it is being downloaded while you install the system?
right now I'm doing all the testing with the stock BaseSystem.dmg. I wanted to do the tests with as little modifications as possible. I'm pretty sure that the installer takes the file from this image. this is the highest priority now on my todo list: tweaking the dmg.
I might be mistaken, but perhaps it would be a good idea to use Pacifist or something similar to see if the stock boot.efi is hidden deep inside a package or a resource inside the dmg. I haven't used Pacifist since last year's installation of Yosemite, so my recollection might be a little bit fuzzy, but I think it can easily search for one particular filename.
you might be right. I will have a look into it and search through the packages.
Pike mentions "Let’s take it one step further" on his blog. new commit already?
found one already in /System/Installation/Packages/Essentials.pkg
is there a way to edit the Essentials.pkg? Pacifist is only able to ectract files. and the Flat Package Editor seems to be unable to handle the pkg file structure.
is there a way to edit the Essentials.pkg? Pacifist is only able to ectract files. and the Flat Package Editor seems to be unable to handle the pkg file structure.
Last edited:
I can't actually remember whether packages are read-only for Pacifist. In any case, I recall reading that unpacking/repacking could be done via line instructions with Xcode, but I've never done it myself. I'm sure there's bound to be a tutorial or something like that online, or maybe one of the forum members can advise on this matter.
I think he means that the debugging lines had better remain in place for a while, maybe until the next change(s) is/are verified. In any case, I haven't seen any more changes. If I see them, I'll recompile. If you see them first, send me a message.
installation of yesterday's update went fine. the boot.efi got overwritten during the process. I then manually replaced the files again and El Capitan boots just fine.
aha, this error message when attempting to install El Capitan:
OS X could not be installed on your computer
No bless setting for a primary boot program was found.
Quit the installer to restart your computer and try again.
occurs as soon as I try to run the install procedure with a modified BaseSystem.dmg placed on the stick.
OS X could not be installed on your computer
No bless setting for a primary boot program was found.
Quit the installer to restart your computer and try again.
occurs as soon as I try to run the install procedure with a modified BaseSystem.dmg placed on the stick.
That's probably related to the signatures that guarantee the integrity of files. I don't know how to bypass such a thing.
it seems not neccessary to replace the boot.efi files in the BaseSystem.dmg in order to make the Recovery HD bootable. I only replaced the /Recovery HD/com.apple.recovery.boot/boot.efi and then I was able to successfully boot into recovery mode.
With Cmd-R, I suppose. Oh, well, not having the possibility of Option-booting the Recovery HD is not that important. So, unless Apple introduce further changes in the next developer preview, are we ready for the golden master of El Capitan? Do you think Pike will include further functions into his boot.efi? Any idea as to how to make a PikeCapitánFix work with SIP enabled?
nope, I chose the Recovery HD using the boot-volume menu after starting the system with the option-key pressed.
right now I'm having trouble with my test system. pike advised me to try to boot with boot-argument "-x" and the system panicked. I then cleared PRAM to get rid of the boot-argument. afterwards I was not able to boot my El Capitan installation anymore. doing a complete re-install right now...
at this point I'm not sure if we'll ever get
a) a fully working solution to create reliable install media
b) a fully working solution for the "PikeElCapFix" if SIP is enabled
right now I'm having trouble with my test system. pike advised me to try to boot with boot-argument "-x" and the system panicked. I then cleared PRAM to get rid of the boot-argument. afterwards I was not able to boot my El Capitan installation anymore. doing a complete re-install right now...
at this point I'm not sure if we'll ever get
a) a fully working solution to create reliable install media
b) a fully working solution for the "PikeElCapFix" if SIP is enabled
wow, you sound confident
my system now halts during the boot process with "Waiting for DSMOS..." this is after after a complete re-install
My 1,1 still boots DP8 but is now doing verbose mode. Has some permissions issues.
But gets to desktop and runs fine.
I'm going to build the recovery partition and test tonight. I'm still using the Yosemite boot.efi.
But gets to desktop and runs fine.
I'm going to build the recovery partition and test tonight. I'm still using the Yosemite boot.efi.
peter, this is for you:
pikeralpha | September 1, 2015 at 8:59 pm
New commit with a couple more changes. Please wait for Peter to compile it for you and let me know what – if any – debug output you see. Note that you should get two different versions. The second version of boot.efi should set the csr-active-config NVRAM variable for you. After this the output should change.
pikeralpha | September 1, 2015 at 8:59 pm
New commit with a couple more changes. Please wait for Peter to compile it for you and let me know what – if any – debug output you see. Note that you should get two different versions. The second version of boot.efi should set the csr-active-config NVRAM variable for you. After this the output should change.
Hmmm. I'm not sure I understand what Pike means by the "second version of boot.efi". How, precisely, am I supposed to build it? Or does he mean I should build one as "Debug" and the other as "Release". While I get that clarified, herein is what I suppose must be the "first" new version, which is Release/Win32. Good luck.
OK. I've come to the conclusion that Pike simply meant that I should change one line of BootArgs.cpp back to the way it was a few days ago, so that it is now bootArgs->Flags |= kBootArgsFlagCSRActiveConfig;
If my interpretation is wrong, Pike will let us know in due course. Let's see how this changes things.
If my interpretation is wrong, Pike will let us know in due course. Let's see how this changes things.
Please, disregard messages #269 and 270. Here are the two versions Pike intended, both compiled on his latest commit, fe3c638bcbc7ea320d4355c94baed457d86e093f.
1st version bootbeb2d918e49eecf19bd4cb50419af5848ac056b1.zip
booting with boot argument "-x" (save mode) works. nothing about csr in NVRAM to be found.
boot second version of beb2d918e49eecf19bd4cb50419af5848ac056b1.zip
booting with boot argument "-x" (save mode) works. nothing about csr in NVRAM to be found. according to Pike's last post I expected to not find anything about csr in NVRAM.
peter, there's instructions about what modification pike meant on his blog.
booting with boot argument "-x" (save mode) works. nothing about csr in NVRAM to be found.
boot second version of beb2d918e49eecf19bd4cb50419af5848ac056b1.zip
booting with boot argument "-x" (save mode) works. nothing about csr in NVRAM to be found. according to Pike's last post I expected to not find anything about csr in NVRAM.
peter, there's instructions about what modification pike meant on his blog.
yep, saw that... I tested both these two new versions. they work with boot-args="-x" but none of them gives any entries in NVRAM about csr. of course I posted this already to pike's blog (approval of post pending...).
excuse me a question, but on a MacPro 2006 32-bit and can make a change and take a 64-bit? and if you like to do?
thank you.
thank you.