macOS boot.efi developer's thread

[rthpjm]

@Sko - I've written a script to build an installer volume (what has recently been called the "legacy" installer method)

(Please test carefully - there may be errors in my scripting)

EDIT : Oops, found a bug - replaced the script attached

EDIT2: I have removed any requirement for local copies of modified files (PlatformSupport.plist for example). Everything is now built on-the-fly. You just need to put a copy of Pike's boot.efi (of your choice) in the same folder as the script, AND get a copy of pbzx. The script should be version agnostic, it'll work with v2.x, v3.x, and the frequent dev build. Run the script as root from the Terminal (sudo buildInstallerDrive.sh [pathToYourIntendedInstallerVolume])
e.g.
sudo buildInstallerDrive.sh /Volumes/Untitled


There are some prerequisites:

• Use of the Terminal
• Super User (sudo -s)
• The Hackintosh community built a handy utility to extract the Payload of an Installer Package, pbzx
  • http://www.tonymacx86.com/general-help/135458-pbzx-stream-parser.html
  • There's a pre-built binary there. (Registration required)
  • Download it, copy it to somewhere on the standard PATH (I suggest /usr/local/bin)
  • Make sure it is executable (chmod 755 /usr/local/bin/pbzx)
• Edit the script and change the variable at the top to point to the Volume that you will overwrite with the newly built Installer
• Make sure the script is executable

You can change the default volume used (variable at the top of the script) or you can call the script and pass the volume to use as the first argument

Run the script and wait....

The final output should be your installer volume (disk, SSD, USB stick, whatever...) named Install OS X El Capitan

-----------

I have tried to modify the Essentials.pkg file, but after rebuilding the package, the Installer gives up saying no items to install. I assume this is because the original Essentials.pkg file is signed by Apple (and the Installer is probably checking for this)

 

[Sko]

yeah. I know that chunklist, but I thought that it wash't there for both legacy methods. Perhaps I'm wrong.

No, you're right, it's only there on legacy. Common ground on / seems to be Install OS X El Capitan.app

 

[clawfinger]

@rthpjm

It looks like your script assumes the presence of your Boot64 Utility.

Also, there's no need to modify PlatformSupport as of Pike's v3.0 as it will end up mimicking a MacPro3,1 regardless.

 

[rthpjm]

@rthpjm

It looks like your script assumes the presence of your Boot64 Utility.

Also, there's no need to modify PlatformSupport as of Pike's v3.0 as it will end up mimicking a MacPro3,1 regardless.

@clawfinger

Yes you are absolutely correct!

I will amend to look for the v3.0 boot.efi file in the same location as the script, and remove the Platform Support entries...

 

[Sko]

I will amend to look for the v3.0 boot.efi file in the same location as the script, and remove the Platform Support entries...

Your script has no use in this thread as this is a work in progress. Try again in El Capitan thread once this is finished.

 

[rthpjm]

Your script has no use in this thread as this is a work in progress. Try again in El Capitan thread once this is finished.

and yet if you look back a few pages in this thread, the contributors have at times had difficulty building a volume containing the installer as per Hennesie2000's guide.... (@splifingate I think, possibly even Peter, and others)

Is developing a shell script some how less than other forms of development?

 

[Pike R. Alpha]

and yet if you look back a few pages in this thread, the contributors have at times had difficulty building a volume containing the installer as per Hennesie2000's guide.... (@splifingate I think, possibly even Peter, and others)

Is developing a shell script some how less than other forms of development?

That's not the issue. Script are not related to this thread (boot.efi development's thread). We need to keep things here streamlined or we will soon lose track of real development (related to boot.efi).

Anyway. Here's a quick question before I go to bed:

The restored BaseSystem.dmg launches the installer, but what was the file name again that does this? Previously it was /etc/rc.installer (or something like that) but isn't that replaced by a daemon these day?

 

[donjames]

There is currently no "correct" way to accomplish this, in a nut-shell, as you will find that the floor is littered with such.

I suggest patience, reading and experimentation.

We are standing and wobbling upon the shoulders of those among, and who preceeded, us, and it will take but a little more time till we can condense these things into a tidy package.

First-and-foremost, Pike & Co. need a well-earned break

Okey dokey. Thanks for the reply. I probably need to wait.
Thanks for getting back to me.

Sincerely,

Don James

 

[rthpjm]

The restored BaseSystem.dmg launches the installer, but what was the file name again that does this? Previously it was /etc/rc.installer (or something like that) but isn't that replaced by a daemon these day?

Hi Pike,

I am not sure, I do know that the presence of S/Installation seems to have an effect (although that is unconfirmed yet, I haven't tried removing S/I to see what happens.
The contents of S/I/CDIS appears to be the Installer + the listed utilities

If I were betting, I'd say the kernel looks for the presence of S/I/CDIS

private/var/db/dyld/shared_region_roots/Boot.paths looks promising

also

System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/Loaders/MKDrivers.bundle/Contents/Resources/boot.loader
System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/Loaders/MKDrivers.bundle/Contents/Resources/bootroot.loader

 

[splifingate]

Sorry for not having glimpsed this earlier, but it seems like the problem is with disabling SIP:

View attachment 593620

Current boot.efi doesn't disable SIP on legacy method. I disabled it via restore partition and install media booted in no time into GUI (and enabled Bluetooth wich it never did before).
With this method, the installer boots to the target media on first restart, and fails as all occurrences of boot.efi are the original ones. I'm replacing these boot.efis right now and see how it proceeds. Maybe we can skip one step.

Good call, Sko.

I dis-abled SIP from within the 10.11 Recovery, and slipped straight into the legacy installer (already had commit f1526943 added to it) <s>

Attached is cli output from both Pike's csrstat and csrutil while inside the 10.11 Recovery environment (booted after testing the installer, which was booted after booting the Recovery environ to disable SIP)

 

[rthpjm]

The restored BaseSystem.dmg launches the installer, but what was the file name again that does this? Previously it was /etc/rc.installer (or something like that) but isn't that replaced by a daemon these day?

EDIT:
In the spirit of "the Apple way", the rc.* files tend to be migrated to utilise launchd.
The installer volume includes System/Library/LaunchDaemons/com.apple.install.cd.plist

Which in turn simply calls
/bin/sh /etc/rc.install

I've had a quick look and you were right.
etc/rc.install seems to be the startup manager (might be etc/rc.cdrom?), it is here that System/Installation/CDIS is referenced and this is where the installer is called

When I've used your efi files with verbose and/or debug switched on, I think I also saw a log line that says something like /etc/rc.installer_cleanup not found. I'm not sure that's going to help.

Finally, I think there are RAMDISKs involved here. Somehow, during the boot sequence it looks like RAMDISKs are created and the "OS" is copied appropriately, then control is switch to the RAMDISK copy.

From rc.cdrom

# tell launchd to commence with loading the system.
# for the OS Install environment only, /etc/rc.install is included in this process.
launchctl load -D system

 

[splifingate]

That's not the issue. Script are not related to this thread (boot.efi development's thread). We need to keep things here streamlined or we will soon lose track of real development (related to boot.efi).

Anyway. Here's a quick question before I go to bed:

The restored BaseSystem.dmg launches the installer, but what was the file name again that does this? Previously it was /etc/rc.installer (or something like that) but isn't that replaced by a daemon these day?

Distribution, in OSInstall.mpkg plays a large part, I had thought:

(lines 259-290)

 </script>
  <installation-checkscript="installCheckScript()"/>
  <volume-checkscript="volCheckScript()"/>
  <choices-outline>
   <line choice="EssentialSystemSoftware">
    <line choice="EssentialSystemSoftwareGroup"/>
    <line choice="X11"/>
   </line>
   <linechoice="OSInstallScripts"/>
  </choices-outline>
  <choice id="EssentialSystemSoftware"title="EssentialSystemSoftware_title"description="EssentialSystemSoftware_description"start_enabled="false"start_visible="false"/>
  <choice id="EssentialSystemSoftwareGroup"start_visible="false"start_selected="true">
   <pkg-ref id="com.apple.pkg.BaseSystemResources"/>
   <system-imageid="com.apple.dmg.MacOSX"/>
   <pkg-ref id="com.apple.mpkg.OSInstall"/>
   <pkg-ref id="com.apple.pkg.Essentials"/>
  </choice>
  <choice id="OSInstallScripts"start_visible="false"start_selected="true">
   <pkg-ref id="com.apple.pkg.OSInstall"/>
  </choice>
  <choice id="X11"start_selected="true"start_visible="false">
   <pkg-ref id="com.apple.pkg.X11redirect"active="needsX11redirect()"/>
  </choice>
  <pkg-ref id="com.apple.pkg.BaseSystemResources"auth="root"installKBytes="74"version="10.11.0.1.1.1442471843">BaseSystemResources.pkg</pkg-ref>
  <pkg-ref id="com.apple.pkg.Essentials"auth="root"installKBytes="8791420"version="10.11.0.1.1.1442471843">Essentials.pkg</pkg-ref>
  <pkg-ref id="com.apple.pkg.OSUpgrade"auth="root"installKBytes="0"version="10.11.0.1">OSUpgrade.pkg</pkg-ref>
  <pkg-ref id="com.apple.pkg.OSInstall"auth="root"installKBytes="0"version="10.11.0.1">OSInstall.pkg</pkg-ref>
  <pkg-ref id="com.apple.pkg.X11redirect"auth="root"installKBytes="3877"version="10.11.0.1.1.1442471843">X11redirect.pkg</pkg-ref>
  <pkg-ref id="com.apple.mpkg.OSInstall"auth="root"version="10.11.0">OSInstall.mpkg</pkg-ref>
  <system-image id="com.apple.dmg.MacOSX">BaseSystem.dmg</system-image>
  <system-image id="com.apple.dmg.MacOSX"version="10.11.0.1.1.1442471843"sha1="5eb770257cc2dc5ab108bd19ccb5a1ff0fbea015"/>
</installer-gui-script>

OSInstall.mpkg is some serious voodoo...

 

[Pike R. Alpha]

I don't have a BaseSystem.dmg restored USB handy, so can someone here please backup /private/etc/rc.install and verify if the installer stopped launching or still works?

@rthpjm,

/etc/rc.installer_cleanup is used to cleanup afterwards.

 

[PeterHolbrook]

Pike, I don't suppose you want the source of /private/etc/rc.install, do you? What you want is for someone to rename or move /private/etc/rc.install and see if the "legacy" installer continues to work, right?

 

[Pike R. Alpha]

Pike, I don't suppose you want the source of /private/etc/rc.install, do you? What you want is for someone to rename or move /private/etc/rc.install and see if the "legacy" installer continues to work, right?

No. Thanks. Legacy check added in my latest commit. Will be away for a couple of hours. In fact. I should have been away 30 minutes ago, but I want this sorted. Laters.

 

[PeterHolbrook]

Add legacy installer detection.

To everyone interested in this project:

[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to 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). Pike alone will decide when such repository versions will be updated with a newer version.

Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!

 

[rthpjm]

I don't have a BaseSystem.dmg restored USB handy, so can someone here please backup /private/etc/rc.install and verify if the installer stopped launching or still works?

Hi Pike,

Commit 70f77b boots okay with etc/rc.install in place. When you asked for etc/rc.install to be backed up, did you mean rename it (or delete it) and test to see if this commit still boots? Is there something you want me to look for specifically?

EDIT:
Renamed etc/rc.install to etc/rc.install.apple = boots most of the way, then launchd goes into a loop on com.apple.install.cd. This LauchDaemon item tries to call etc/rc.install (which isn't there any more), hence the loop.

EDIT2: Using legacy installer with boot.efi (commit 70f77b), ran the installer okay, created new El Capitan volume, copied boot.efi (commit 70f77b) to new volume (S/L/C and u/s/i). New volume boots okay

 

[F1Mac]

Since my post in the other thread will probably go unnoticed among all the others (nothing wrong with that btw), I just wanted to let you guys know that:


------
I've successfully replaced my previous boot-efi on El Capitan with version 3.0. Everything works fine, replaced it /System/Library/CoreServices, /usr/standalone/i386 and on the RecoveryHD, in com.apple.recovery.boot.

A few things though:
- I downloaded the black version, and noticed my startup screen is black ONLY when booting into Recovery. Normal boot is still grey.

- my board id is still F4208DC8.

...Yes I got it from http://piker-alpha.github.io/macosxbootloader/ and yes openssl md5 gives me
b57d13b87226d72a31bf0aa527bc5f1f

------

 

[Pike R. Alpha]

Hi Pike,

Commit 70f77b boots okay with etc/rc.install in place. When you asked for etc/rc.install to be backed up, did you mean rename it (or delete it) and test to see if this commit still boots? Is there something you want me to look for specifically?

EDIT:
Renamed etc/rc.install to etc/rc.install.apple = boots most of the way, then launchd goes into a loop on com.apple.install.cd. This LauchDaemon item tries to call etc/rc.install (which isn't there any more), hence the loop.

EDIT2: Using legacy installer with boot.efi (commit 70f77b), ran the installer okay, created new El Capitan volume, copied boot.efi (commit 70f77b) to new volume (S/L/C and u/s/i). New volume boots okay

So legacy installation detection is fine now? Great. Thanks for testing this.

p.s. Yeah I meant rename after making a backup first, but don't bother. Detection seems to work already.

 

[Pike R. Alpha]

Since my post in the other thread will probably go unnoticed among all the others (nothing wrong with that btw), I just wanted to let you guys know that:


------
I've successfully replaced my previous boot-efi on El Capitan with version 3.0. Everything works fine, replaced it /System/Library/CoreServices, /usr/standalone/i386 and on the RecoveryHD, in com.apple.recovery.boot.

A few things though:
- I downloaded the black version, and noticed my startup screen is black ONLY when booting into Recovery. Normal boot is still grey.

- my board id is still F4208DC8.

...Yes I got it from http://piker-alpha.github.io/macosxbootloader/ and yes openssl md5 gives me
b57d13b87226d72a31bf0aa527bc5f1f

------

Odd. We've had several confirmation that the board-id replacement works, but maybe that was added in a later version. Not in v3.0. Please try the one from #466 because I lost track of all changes.

The compiler detective is either set to grey or black. It cannot be two different values, but there is an override variable ('Background Color') that mat be set. Please check this.

 

[PeterHolbrook]

Odd. We've had several confirmation that the board-id replacement works, but maybe that was added in a later version. Not in v3.0.

No, Pike. Board-id worked in version 3.0 as advertised.

 

[F1Mac]

Odd. We've had several confirmation that the board-id replacement works, but maybe that was added in a later version. Not in v3.0. Please try the one from #466 because I lost track of all changes.

The compiler detective is either set to grey or black. It cannot be two different values, but there is an override variable ('Background Color') that mat be set. Please check this.

Tx - will do. Oh and another thing, SIP was enabled after replacing the boot.efi, so I had to disable it again. And when I check the status, before it said:

$System Integrity Protection status: enabled (Custom Configuration).

Configuration:
    Apple Internal: disabled
    Kext Signing: disabled
    Filesystem Protections: disabled
    Debugging Restrictions: disabled
    DTrace Restrictions: disabled
    NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Now it just says (with boot.efi v3):

$ System Integrity Protection status: disabled.

...Ayways, I guess it's no big deal so I will try the one from post #466 and see how it goes.

 

[Sko]

Wait. Check NVRAM variables.

4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14:IASCurrentInstallPhase
4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14:IASInstallPhaseList
8D63D4FE-BD3C-4AAD-881D-86FD974BC1DF:boot-info-payload

I'm a bit lost, reading NVRAM only gives this:

Marvin:Entwicklung sko$ sudo nvram -p
Password:
bluetoothInternalControllerInfo    %06%82%ac%05%00%00 ]%00%17%f2%a2%b1%f3
fmm-computer-name    Marvin
bluetoothActiveControllerInfo    %06%82%ac%05%00%00%00%00 ]%00%17%f2%a2%b1%f3
SystemAudioVolumeDB    %c8
SystemAudioVolume    %08
LocationServicesEnabled    %01
csr-active-config    %80%00%00%00
IdlePML4    %d0%da%ce%0e%80%ff%ff%ff

Shouldn't there be more variables? I tried the better part of today to solve this mystery, but I guess it doesn't matter anymore now that installer detection works.

 

[atvusr]

Tested 70f77b1a86590bdce100b5eda2f7cd574d47be1e on MBP2,2:

· legacy Installer (Hennesie-Guide) - boots into the Installer-GUI, install starts, but Kernel Panic after 2 mins.
· createinstallmedia Installer(*) - boots into the Installer-GUI, install starts, but Kernel Panic during part 2 of the install.
· transferred OSX - boots into Desktop, but Kernel Panic shortly after.

(*) createinstallmedia-Installer: Apple-native created via Terminal-command, all 3 Boot.efi in ./IABootFiles , /S/L/C and u/s/i386 replaced. Both PlatformSupport.plist as well as OSInstall.mpkg not modified.

 

[Pike R. Alpha]

I'm a bit lost, reading NVRAM only gives this:

Marvin:Entwicklung sko$ sudo nvram -p
Password:
bluetoothInternalControllerInfo    %06%82%ac%05%00%00 ]%00%17%f2%a2%b1%f3
fmm-computer-name    Marvin
bluetoothActiveControllerInfo    %06%82%ac%05%00%00%00%00 ]%00%17%f2%a2%b1%f3
SystemAudioVolumeDB    %c8
SystemAudioVolume    %08
LocationServicesEnabled    %01
csr-active-config    %80%00%00%00
IdlePML4    %d0%da%ce%0e%80%ff%ff%ff

Shouldn't there be more variables? I tried the better part of today to solve this mystery, but I guess it doesn't matter anymore now that installer detection works.

For these you use:

nvram 4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14:IASCurrentInstallPhase
nvram 4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14:IASInstallPhaseList
nvram 8D63D4FE-BD3C-4AAD-881D-86FD974BC1DF:boot-info-payload