Thanks everyone. We should only have two test versions left before we're really done.
Edit: New commit available for compilation/testing.
Edit: New commit available for compilation/testing.
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
The model identifier should remain as is. For us it's only required to fake the board-id.
Pike, now that it appears we are really close to our ultimate goal, it seems to me that, basically. all that remains is to ensure your boot.efi's survival across system updates. You probably have some wonderful ideas on how to achieve that, but, in case you find some light in my musings, here is my idea:
Ideally, your boot.efi ought to do the following:
Ideally, your boot.efi ought to do the following:
- When run from the installer media, on successful (re)installation, copy itself transparently to the two target folders of the normal El Capitan disk/partition AND to the target folder in the Recovery HD partition immediately before shutting down/rebooting. If no (re)installation is effected, it shouldn't copy itself anywhere. This would make it possible to manually update your boot.efi via the Installer's Terminal.
- When run from the Recovery HD partition, on successful reinstallation, copy itself transparently to the two target folders of the normal El Capitan disk/partition immediately before shutting down/rebooting.
- When run from the regular El Capitan disk/partition, copy itself transparently to the two target folders of the normal El Capitan disk/partition AND to the target folder in the Recovery HD partition immediately before shutting down/rebooting.
What we can do right now is to update/replace the old launch daemon and let it replace: /.IABootFiles/boot.efi and
/OS X Install Data/boot.efi with the one we want there so that the first reboot works out of the box, but after that we have to use a script/do it manually.
Luckily there is a NVRAM variable called "bootercfg-once" which we can set in the installer mode, and remove on the first reboot. This allows people to replace the files without first having to disable SIP with csrutil. Please note that we are not setting/checking it, right now, but my first goal was to get the installer going.
commit cf024fcf (compiled in VSE2015/Win10; boot.efi added to /System/etc. and /usr/etc. in a stock ElCap install):
splifingate$ ioreg -p IODeviceTree -d 2 -k board-id | grep board-id
"board-id" = <"Mac-F42C88C8">
splifingate$ ioreg -lw0p IODeviceTree | grep -e 'SMBIOS"' | awk '{print$5}' | sed 's/[<>]//g'
"AppleSMBIOS"
"...4170706C6520496E632E004D61632D4634324338384338..." (Apple Inc. Mac-F42C88C8)
Good stuff.
I have yet to replace the createinstallmedia, and report from there . . . later . . . .
splifingate$ ioreg -p IODeviceTree -d 2 -k board-id | grep board-id
"board-id" = <"Mac-F42C88C8">
splifingate$ ioreg -lw0p IODeviceTree | grep -e 'SMBIOS"' | awk '{print$5}' | sed 's/[<>]//g'
"AppleSMBIOS"
"...4170706C6520496E632E004D61632D4634324338384338..." (Apple Inc. Mac-F42C88C8)
Good stuff.
I have yet to replace the createinstallmedia, and report from there . . . later . . . .
Thanks. Please also try my latest commit. If that also works for you, then I will switch to non-verbose boot mode and disable all debug messages.
commit cf024fcf still hangs at "Waiting for DSMOS..." (after a lengthy polling of the wireless en2 (crazy-slow, and non-plussed)).
I'm re-imaging the stock createinstallmedia from 10/4/2015 AIT, and will report (I wait, and wait, for things to progress, for the process/es is/are not entirely expeditious).
re-image of createinstallmedia; successful boot (no extended polling of wireless) into createinstallmedia environ.
-bash-3.2# ioreg (etc.) commands produce stdout exactly as in my aforementioned post wrt testing in stock ElCap.
-bash-3.2# /Volumes/backs2tb/csrstat -->
System Integrity Protection status: enabled (0x00000000)
Configuration:
Apple Internal: enabled
Kext/Filesystem/Debug/DTrace/NVRAM: disabled
Now, pulling commit 46a02b4f, and will test, the same....
[edit]
Install OS X -->
"To set up the installation od OS X 10.11, click Continue."
[/edit]
[edit:edit]
Every, single, time I find I have some mission-critical need to access the Dell on the network, I find that it doesn't become shared on the Mac, and I wait, and wait, and wait . . . be back in a few.
[/edit:edit]
Last edited:
boot into createinstallmedia with commit 46a02b4f successful
[edit]
-bash-3.2# ioreg (et al.) stdout mirrors all previous reports
-bash-3.2# /Volumes/backs2tb/csrstat stdout mirrors previous
[edit:/edit]
[edit:edit]
Install OS X --> "To set up the installation of OS X 10.11, click Continue."
*props*
[/edit:edit]
[edit]
-bash-3.2# ioreg (et al.) stdout mirrors all previous reports
-bash-3.2# /Volumes/backs2tb/csrstat stdout mirrors previous
[edit:/edit]
[edit:edit]
Install OS X --> "To set up the installation of OS X 10.11, click Continue."
*props*
[/edit:edit]
Last edited:
So, is commit 46a02b4f4f043313ec7d1fcf29a2e52374bfb31c the new repository version, or is there going to be a new one?
Perhaps. I hope so. I mean with more confirmations that it is working, but after that we can disable all debug output and switch off verbose boot mode.
Another step would be to get the 'bootercfg-once' NVRAM variable going. Shouldn't be that hard. We probably want that set when entering installation mode, and check for it on every boot. When found wipe it.
-----------------------------------------------------------------------------------------------------------
I only want to say to (Tiamo) Pike R. Alpha , PeterHolbrook, Mikeboss, Splifingate, Randyoo, Busitech and the others persons who work very hard and spend a lot of time working for us and making posible that an old Mac Pro 1.1 could continue working like the first day, but with the most recent OS X "El Capitan", THANK YOU VERY MUCH
ALL YOU ARE THE BEST.
Your friend from Valldemossa-Mallorca (Baleares, Spain), Javier Bernat Vistarini.
Sorry for my bad english and again I´m happy and very glad with you.
I'm glad to see that others carried out all the testing over the last few days. currently, I am swamped with work...
Can we conclude that version 46a02b4f4f043313ec7d1fcf29a2e52374bfb31c is repository-worthy, then? Perhaps Pike can make one more commit making it non-verbose.
I want at least a few more confirmations. Just to be sure that things are working.
I have some spare time this evening and I'm going to test all kind of scenarios.
Switching off board-id debug output (pre 3.0 final).
Edit: Version 3.0 final has been released. 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).
Edit: Version 3.0 final has been released. 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).
Last edited: