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.
macOS boot.efi developer's thread
- Thread starter mikeboss
- Start date
- Sort by reaction score
NO. I wasn't aware that I should place the bootbase.efi in there. I will try in a sec.
EDIT
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:
Last edited:
That is correct. The debug output was moved recently. You'll need a newer copy of boot base.efiNO. I wasn't aware that I should place the bootbase.efi in there. I will try in a sec.
EDIT
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
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.
hm, when I'm attempting to actually install El Capitan, I'm getting this:
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
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
Last edited:
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.
Good news.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
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.
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.
And in case you modify the images, you'll end up with "installer was modified" pretty soon.
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:
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
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?
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
Still necessary to add the Production boot.efi's in their respective places to get El Cap to boot.
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:
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:
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
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).
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.