Become a MacRumors Supporter for $25/year with no ads, private forums, and more!

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
@Pike.
I guess that, in my desperation, I must have somehow tried safe-booting using nvram boot-args="-x" and failed, and that's when I took the picture. I've just run nvram -p and it doesn't display anything suspicious that I can see.
Ok so it is time to enable the debug output (see my previous reply).
 

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,457
677
switzerland
And /Volumes/Install OS X El Capitan/.IABootFiles/boot.efi is bootbase.efi?

NO. I wasn't aware that I should place the bootbase.efi in there. I will try in a sec.

EDIT
:D YESSS! now the installer GUI came up!!!

I used the bootbase.efi from commit 9edc64d660598beff6ef735aeacce6fa37446ce7
(renamed as boot.efi, just as it was there after creating with createinstallemdia).

with the the bootbase.efi in place, the debug output is different:

IMG_1661.PNG
 
Last edited:

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
NO. I wasn't aware that I should place the bootbase.efi in there. I will try in a sec.

EDIT
:D YESSS! now the installer GUI came up!!!

I used the bootbase.efi from commit 9edc64d660598beff6ef735aeacce6fa37446ce7
(renamed as boot.efi, just as it was there after creating with createinstallemdia).

with the the bootbase.efi in place, the debug output is different:

View attachment 589507
That is correct. The debug output was moved recently. You'll need a newer copy of boot base.efi

Note: What I want, and I am currently working on – hence the output – is a way to detect that the installation process is about to launch, and set a flag that changes the settings. After that nobody should ever need a special version of boot.efi (bootbase.efi) anymore.
 

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,457
677
switzerland
hm, when I'm attempting to actually install El Capitan, I'm getting this:

IMG_1662.JPG

of course I then removed all the other disks that were installed in the system.
but this didn't change anything...

EDIT

ha! after adding the appropriate Board-IDs to "Distribution" in
/Volumes/Install OS X El Capitan/Install%20OS%20X%20El%20Capitan.app/Contents/SharedSupport/OSInstall.mpkg
the installation process runs right now as I'm typing :cool:
 
Last edited:
  • Like
Reactions: splifingate

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,339
278
Ok so it is time to enable the debug output (see my previous reply).
All right. I'll compile an especial debug version of boot.efi for my own use and will install it, to begin with, in my Installer, and then, reinstall El Capitan (when I can) and copy that version to the two usual places, reboot twice and see what that does. Thank you, but it may be several days, even weeks, before I can pull that off.
 

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
hm, when I'm attempting to actually install El Capitan, I'm getting this:

View attachment 589509

of course I then removed all the other disks that were installed in the system.
but this didn't change anything...

EDIT

ha! after adding the appropriate Board-IDs to "Distribution" in
/Volumes/Install OS X El Capitan/Install%20OS%20X%20El%20Capitan.app/Contents/SharedSupport/OSInstall.mpkg
the installation process runs right now as I'm typing :cool:
Good news.

We could use the board-id of a MacPro3,1 during the download of/installation process, but you definitely don't want to mess with the SMC/EFI update for it.
 

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,457
677
switzerland
in the end, I didn't get a working install of El Capitan. the installer routine replaced the boot.efi on the installer media (in .IABootFiles) with Apple's own copy. okay, I then replaced it again with our boot.efi. but the installer stopped again at some point, stating that "OS X could not be installed on your computer" and "OS X El Capitan is already installed on this Mac"... I guess this is because of the two unmodified diskimages.
 

splifingate

macrumors 6502a
Nov 27, 2013
589
501
ATL
in the end, I didn't get a working install of El Capitan. the installer routine replaced the boot.efi on the installer media (in .IABootFiles) with Apple's own copy. okay, I then replaced it again with our boot.efi. but the installer stopped again at some point, stating that "OS X could not be installed on your computer" and "OS X El Capitan is already installed on this Mac"... I guess this is because of the two unmodified diskimages.

In the same place as you, mike (edit: with the exception being that the Pike boot.efi's were not overwritten).

I deleted the El Cap install disk, and rebooted into the creatinstallmedia Install, and "Install OS X" still gives me "OS X El Capitan is already installed on this Mac."

Clearing PRAM results in the same.

One thing I'm trying is to get modified files copied-over to the installation partition(s) post-boot:

https://pbs.twimg.com/media/CQelgPsUYAEG9sK.jpg:large

/Volumes/Mac OS X Install DVD holds the really good tid-bits that I'd like to edit, but it's ro

-bash-3.2# mount -uw /Volumes/Mac\ OS\ X\ Install\ DVD

Gives me rw

I am now in the process or editing the parts I want to copy-over prior to re-booting the createinstallmedia (performed a bunch of same steps in Terminal just a few minutes ago while in the createinstallmedia Install environment, but terminal crashed, and the system became command-insensitive, so I need to make it swift-like when I return)...I'll incorporate the Production version of boot.efi from Pike's GitHub repository as a baseline.
 

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,457
677
switzerland
And in case you modify the images, you'll end up with "installer was modified" pretty soon.

:mad: thnx! in that case I won't try again and go any further on this route. I feel being stuck ATM with no solution in sight for a fully working installer media...
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,339
278
:mad: thnx! in that case I won't try again and go any further on this route. I feel being stuck ATM with no solution in sight for a fully working installer media...
My installer media is fully working, except that, in my case, it seems to be good only for one shot. The second one requires another install, although such a circumstance might be due to legacy contents of my Yosemite partition. Perhaps creating an El Capitan partition from scratch would be more successful. Can anyone replicate the steps I used to create my install media, create a brand-new El Capitan partition and reboot it at least three times on the old Mac Pro and see if that is successful?
 
Last edited:

splifingate

macrumors 6502a
Nov 27, 2013
589
501
ATL
--8<------

https://pbs.twimg.com/media/CQelgPsUYAEG9sK.jpg:large

/Volumes/Mac OS X Install DVD holds the really good tid-bits that I'd like to edit, but it's ro

-bash-3.2# mount -uw /Volumes/Mac\ OS\ X\ Install\ DVD

Gives me rw

I am now in the process or editing the parts I want to copy-over...

So; it's so:

I boosted BaseSystem.dmg with the Production boot.efi from Pike's github, added the modified Distribution to OSInstall.mpkg, modified the InstallableMachines.plist, and centralized all with the Production boot.efi in an easily-accessible location from which I could copy all to their respective places in the createinstallmedia Installation environment . . .

I was able to successfully cp everything but the boot.efi (/ is persistently ro, no matter what I tried) over via terminal in said environment, but--upon closure of terminal--the Environment becomes un-responsive (I tried something like five times to no avail) ;(

The createinstallmedia route made me mad, before, but it's pissin' me right-teh-fsck-off atm!

I'm'a gana' try once more, Pike, but after that I'd best call it quits with createinstallmedia before I blow my personal, internal, power supply ;)
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,339
278
p.s. Verify that /S*/L*/Prelinkedkernels/prelinkedkernel is there.
Pike, I haven't rebooted my system, because, as you can imagine, doing so is quite costly the way it is now. In any case, I've rechecked the situation of the prelinked kernel on my El Capitan partition. It is where it ought to be. It belongs to root, or system, in the group wheel, the way it should be, but I find it odd that it is a different size from the prelinkedkernel of the Installer media. The latter's size is 18,915,592 bytes, whereas the prelinkedkernel size on the El Capitan disk is 12,461,091 bytes. Is this normal?
 

splifingate

macrumors 6502a
Nov 27, 2013
589
501
ATL
So; it's so:

I boosted BaseSystem.dmg with the Production boot.efi from Pike's github, added the modified Distribution to OSInstall.mpkg, modified the InstallableMachines.plist, and centralized all with the Production boot.efi in an easily-accessible location from which I could copy all to their respective places in the createinstallmedia Installation environment . . .

I was able to successfully cp everything but the boot.efi (/ is persistently ro, no matter what I tried) over via terminal in said environment, but--upon closure of terminal--the Environment becomes un-responsive (I tried something like five times to no avail) ;(

The createinstallmedia route made me mad, before, but it's pissin' me right-teh-fsck-off atm!

I'm'a gana' try once more, Pike, but after that I'd best call it quits with createinstallmedia before I blow my personal, internal, power supply ;)

Re-try with same procedures, but with closure of Terminal after each command.

This did not crash the system, but--upon performing the 'Install OSX', continue left me with the sBBOD ;(

In the interim, I made a handful of partitions on a spare disk to which I can image each with various types of installers, one of which is in the traditional (?) manner, per Jabbawok, Hennessie, Holbrook, et al.

I am currently re-Installing El Cap from this partition using the Production boot.efi's
 

splifingate

macrumors 6502a
Nov 27, 2013
589
501
ATL
Re-try with same procedures, but with closure of Terminal after each command.

This did not crash the system, but--upon performing the 'Install OSX', continue left me with the sBBOD ;(

In the interim, I made a handful of partitions on a spare disk to which I can image each with various types of installers, one of which is in the traditional (?) manner, per Jabbawok, Hennessie, Holbrook, et al.

I am currently re-Installing El Cap from this partition using the Production boot.efi's

Still necessary to add the Production boot.efi's in their respective places to get El Cap to boot.
 

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
Pike, I haven't rebooted my system, because, as you can imagine, doing so is quite costly the way it is now. In any case, I've rechecked the situation of the prelinked kernel on my El Capitan partition. It is where it ought to be. It belongs to root, or system, in the group wheel, the way it should be, but I find it odd that it is a different size from the prelinkedkernel of the Installer media. The latter's size is 18,915,592 bytes, whereas the prelinkedkernel size on the El Capitan disk is 12,461,091 bytes. Is this normal?
No worries. It is quite understandable. Too much work. We first need to iron out the kinks.
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,339
278
No worries. It is quite understandable. Too much work. We first need to iron out the kinks.
My favourite theory for my predicament is that I probably have some "legacy" kext inhered from Yosemite or earlier days that causes the kernel cache not be of genuine "El Capitan grade" (I think something similar happened with early versions of Chameleon and/or Clover for El Capitan on Hackintoshes). Is there a way I can make certain all my kexts are acceptable for El Capitan and that they won't corrupt the kernel cache? Is there a way to rebuild the kernel cache in such a manner that it won't be corrupted on reboot? In the worst-case scenario, would it be possible to erase the El Capitan kernel cache, say, from the Installer Terminal? Would that help at all?
 
Last edited:

Sko

macrumors 6502
Oct 17, 2009
285
59
Germany
In that case I won't try again and go any further on this route.
I have the feeling that this route is still promising. I was almost there, only one second estimated install time left, and then it stalled (on a different setup, of course. Just altered InstallESD and left BaseSystem alone.)
 
Last edited:
  • Like
Reactions: splifingate

splifingate

macrumors 6502a
Nov 27, 2013
589
501
ATL
Looks like you made it huh?

Alas, this is a product of the legacy installer method (jabbawok, hennessie, et al.), but incorporating your Production boot.efi ;/

Teh fsck'n createinstallmedia pathway has made my head hurt, so, so many times....

I'm still game to try, however you want, whichever way you so may choose . . . I would not be here, still, but for your Works <smile>

Thanks for this/that, btw, Pike
 

the bug

macrumors regular
Feb 21, 2014
103
14
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 supported machine.

I have to leave (appointment with a customer). will be back in the evening.

Wow, I didn't see this message before, but just noticed the same thing was happening here.

I just had a crash in FaceTime and when I looked at the console log it said "System Integrity Protection: disabled", but when I run csrutil status it says "enabled (Apple Internal)".

So is it partially enabled, is that what Apple Internal means ?

I downloaded the distribution gray_boot.efi file from the github page on the day you guys set up that page.
I was wondering if the files in the github distribution have been changed to fix this, or is this still being worked on ?

Thanks again guys for all the work you've put in here !

- Jay
 

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,457
677
switzerland
Wow, I didn't see this message before, but just noticed the same thing was happening here.

I just had a crash in FaceTime and when I looked at the console log it said "System Integrity Protection: disabled", but when I run csrutil status it says "enabled (Apple Internal)".

So is it partially enabled, is that what Apple Internal means ?

I downloaded the distribution gray_boot.efi file from the github page on the day you guys set up that page.
I was wondering if the files in the github distribution have been changed to fix this, or is this still being worked on ?

Thanks again guys for all the work you've put in here !

- Jay

with the version from post #11 SIP will be in effect.
 

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
Wow, I didn't see this message before, but just noticed the same thing was happening here.

I just had a crash in FaceTime and when I looked at the console log it said "System Integrity Protection: disabled", but when I run csrutil status it says "enabled (Apple Internal)".

So is it partially enabled, is that what Apple Internal means ?

I downloaded the distribution gray_boot.efi file from the github page on the day you guys set up that page.
I was wondering if the files in the github distribution have been changed to fix this, or is this still being worked on ?

Thanks again guys for all the work you've put in here !

- Jay
What mike said, and we're going to update the files later today (don't have Windows myself and thus I have to wait for a friend to do this for me).
 

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
My favourite theory for my predicament is that I probably have some "legacy" kext inhered from Yosemite or earlier days that causes the kernel cache not be of genuine "El Capitan grade" (I think something similar happened with early versions of Chameleon and/or Clover for El Capitan on Hackintoshes). Is there a way I can make certain all my kexts are acceptable for El Capitan and that they won't corrupt the kernel cache? Is there a way to rebuild the kernel cache in such a manner that it won't be corrupted on reboot? In the worst-case scenario, would it be possible to erase the El Capitan kernel cache, say, from the Installer Terminal? Would that help at all?
I don't know what is going on, but using the prelinkedkernel from the installer is a good starting point I guess.

Note that recreating the prelinkedkernel (the kernel cache is deleted by the installer) can be done, but having the -x boot argument in NVRAM will make it skip a whole lot of kexts, so please don't use that.

If you delete the "prelinkedkernel" then the booter will search for "kernelcache" but that may be outdated/include unsupported/the wrong kexts in it. Not a good idea.

I still want/need to add code to the booter to support kernel and kext loading, which doest work right now, but I also have other work to do. Like fixing a serious installer issue... so things go slow but should eventually be good.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.