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
I don't understand what those "release" numbers are. Do they involve some modification of a header file before compiling or something like that?
I tested 60c40c79d1306a6b8b60ca30ff516c7420bc5480 on my external FW install drive, created with the BaseSystem.dmg method:
First messages immediately, the other three after about 15 seconds. After that the misery starts and I'm left with the usual "Unable to find driver for this platform" panic. Funny thing is, with createinstallmedia method it boots into GUI.
First messages immediately, the other three after about 15 seconds. After that the misery starts and I'm left with the usual "Unable to find driver for this platform" panic. Funny thing is, with createinstallmedia method it boots into GUI.
Last edited:
60c40c79d1306a6b8b60ca30ff516c7420bc5480: booted into standard El Capitan, everything looks normal.
congrats, pike! with commit 60c40c79d1306a6b8b60ca30ff516c7420bc5480 the install-mode detection seems to work. copied this version into all three destinations on the installer media (created using the createinstallmedia command) and it starts right into the installer GUI 
EDIT:
when booting the installer volume, there's still this 25 second delay before the debug output of the boot.efi comes up. with standard El Capitan booting, there's no such delay...
EDIT:
when booting the installer volume, there's still this 25 second delay before the debug output of the boot.efi comes up. with standard El Capitan booting, there's no such delay...
Last edited:
I interpret that, instead of manually creating the install media from scratch, you are using an automated process that ends up with a universal stand-alone self-booting El Capitan installer that is later adapted for booting an old Mac Pro. Be that as it may, can you clarify for me what you mean by "all three destination on the installer media? Would that be the two boot.efi files in the usual places plus the bootbase.efi file?
Didn't previous iterations of boot.efi achieve the same thing, i.e. starting "right into the installer"? In what way is 60c40c79d1306a6b8b60ca30ff516c7420bc5480 different?
the official method to create an installer media goes like this:
/Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/stick --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app --nointeraction
on this USB stick you'll find three boot.efi files:
/Volumes/Install OS X El Capitan/usr/standalone/i386/boot.efi
/Volumes/Install OS X El Capitan/System/Library/CoreServices/boot.efi
/Volumes/Install OS X El Capitan/.IABootFiles/boot.efi
the one in .IABootFiles being a bootbase.efi in disguise (the kind of boot.efi with SIP globally disabled). the latest boot.efi from Pike detects if we're booting into an installer and then it switches off SIP accordingly.
OK. Two questions:
- Other than being slightly "easier" than the method recommended by Jabbawok, Hennesie2000 or myself, is the "createinstallmedia" more reliable or something like that? I take it for granted you still have to include the old Mac Pro board IDs in three files and, naturally copy the 32-bit boot.efi.
- Was there a problem using previous iterations of boot.efi in install media created with "createinstallmedia"?
Edit: The repository boot.efi had ALL root rights when booted from the Installer. No need for sudo, et cetera.
so far I haven't been successful with an installer created using the createinstallmedia command. see here -> #57
and yes, it is still needed to edit dmg files and place the BoardIDs into various files.
with the latest version only one boot.efi from Pike is needed, before we had to place the bootbase.efi into
/Volumes/Install OS X El Capitan/.IABootFiles/boot.efi
I have no idea if we ever will get a fully working installer. the createinstallmedia method is just another attack...
I sneaked away for a brief moment (need to go back a.s.ap.) but I wanted to let you know that a new commit is available. Now with actual kernel patching enabled.
Note: Have boot issues? Then please try this version of boot.efi The first version with support for booting without a prelinkedkernel. Come one people. We need data!
Note: Have boot issues? Then please try this version of boot.efi The first version with support for booting without a prelinkedkernel. Come one people. We need data!
Last edited:
fe7829911c8cae34e96031d6876ed64061c94b13
booting into El Capitan works just fine:
booting into the Recovery HD also worked flawless:
did not test it on the installer media.
_
booting into El Capitan works just fine:
booting into the Recovery HD also worked flawless:
did not test it on the installer media.
_
Thanks. Another step forward.congrats, pike! with commit 60c40c79d1306a6b8b60ca30ff516c7420bc5480 the install-mode detection seems to work. copied this version into all three destinations on the installer media (created using the createinstallmedia command) and it starts right into the installer GUI
EDIT:
when booting the installer volume, there's still this 25 second delay before the debug output of the boot.efi comes up. with standard El Capitan booting, there's no such delay...
The delay looks normal. I see the same here. It's Bluetooth related. Here that is.
A third option would be to restore the BaseSystem.dmg to USB media, but only as a last resort. We just want it to work properly! The Apple way
Thank you. Looking great. And we should now be nearly there... so fire up the installer and let it run?
Hey guys,
I've been concentrating on the watching LaunchDaemon.
I'm willing to help test too, not sure where you would like me to start?.... If I'm reading it correctly we are aiming for a pre-patched installer?...
Whilst doing the LaunchDaemon stuff, a thought occurred to me:
SIP is kernel-level protection, right? This means Apple's update process will be subject to the same limitations if SIP is enabled during "normal" operation. This is probably why the known install process uses either /.IABootFiles or "/OS X Install Data".
The Installer process (and presumably the Updater process when we get to 10.11.1) boots from one of these two locations with the Apple bootbase (SIP disabled) EFI, and is configured to run the installer (or the the Updater). What we need to know is whether, after the reboot, launchd is still running. If it is, then the launchd method of watching our usual suspects will continue to work. When the Updater (potentially) replaces the Pike versions, we put them back like "normal".
I know I'm making a few assumptions here, and until we get a handle on the method Apple plans to use to update, we won't really know. For me though there is a solution, it's just a two stage approach.
1. Watch the Installer/Updater locations, if we find an Apple EFI file, replace it with bootbase.efi.
2. Once rebooted, and assuming launchd is running, we can then replace the /S/L/CS and /u/s/i locations as normal.
I've been concentrating on the watching LaunchDaemon.
I'm willing to help test too, not sure where you would like me to start?.... If I'm reading it correctly we are aiming for a pre-patched installer?...
Whilst doing the LaunchDaemon stuff, a thought occurred to me:
SIP is kernel-level protection, right? This means Apple's update process will be subject to the same limitations if SIP is enabled during "normal" operation. This is probably why the known install process uses either /.IABootFiles or "/OS X Install Data".
The Installer process (and presumably the Updater process when we get to 10.11.1) boots from one of these two locations with the Apple bootbase (SIP disabled) EFI, and is configured to run the installer (or the the Updater). What we need to know is whether, after the reboot, launchd is still running. If it is, then the launchd method of watching our usual suspects will continue to work. When the Updater (potentially) replaces the Pike versions, we put them back like "normal".
I know I'm making a few assumptions here, and until we get a handle on the method Apple plans to use to update, we won't really know. For me though there is a solution, it's just a two stage approach.
1. Watch the Installer/Updater locations, if we find an Apple EFI file, replace it with bootbase.efi.
2. Once rebooted, and assuming launchd is running, we can then replace the /S/L/CS and /u/s/i locations as normal.
That takes me a bit further down the road, ending here:
ps: I catched /"name" not a kext/ somewhere, not related, I guess?
fe7829911c8cae34e96031d6876ed64061c94b13
the installer media boots right into the GUI. apart from replacing the 3 boot.efi files I only modified
/Volumes/Install OS X El Capitan/.IABootFiles/PlatformSupport.plist
/Volumes/Install OS X El Capitan/System/Library/CoreServices/PlatformSupport.plist
/Install%20OS%20X%20El%20Capitan.app/Contents/SharedSupport/OSInstall.mpkg
the two DMGs remained untouched
when attempting to actually install OS X I'm getting
"This copy of the Install OS X El Capitan application is damaged, and can't be used to install OS X."
When exactly does this happen? I changed the images and get this message after selecting a drive to install to.
Yes. SIP is a kernel-level protection. And Apple is using two different copies of boot.efi but we only need one. One of the last versions and things will be fine (SIP disabled automatically for installers).
No. The LaunchDaemon on the HDD/SSD will no longer be running. You can also not launch one in single-user mode. Another option is to use a script or to add the launch daemon to the installer media.
Yes. We can watch the installer locations and replace the files before the first reboot.
You only changed OSInstall.mpkg to add your board-id? Correct?
Like I said earlier. We could fake it and set the board-id to that of a MacPro3,1 (
Mac-F42C88C8) and see what happens. Can't find any EFI/SMC updates so it should be fine.
Like I said earlier. We could fake it and set the board-id to that of a MacPro3,1 (
Mac-F42C88C8) and see what happens. Can't find any EFI/SMC updates so it should be fine.