macOS boot.efi developer's thread

[rthpjm]

nope, AFAIK nobody/nothing is allowed to mess with system files if SIP is enabled.

Soo we could be faced with a trade-off. Lose a bit of system integrity/security whilst allowing auto-replacement of the efi files (boot.efi with SIP forced off), or stick with SIP and "find" another way to deal with updates....

How about modifying the Recovery Partition?
After an Apple update where they overwrite the boot.efi files, we guide users to boot into Recovery, run the fix, reboot?

(That'll work until Apple updates the Recovery too !)

 

[mikeboss]

Soo we could be faced with a trade-off. Lose a bit of system integrity/security whilst allowing auto-replacement of the efi files (boot.efi with SIP forced off), or stick with SIP and "find" another way to deal with updates....

How about modifying the Recovery Partition?
After an Apple update where they overwrite the boot.efi files, we guide users to boot into Recovery, run the fix, reboot?

(That'll work until Apple updates the Recovery too !)

yes, using the broken boot.efi is one possible solution. but I don't like this approach because it clearly compromises security. we don't want to go that route...

I also thought about possibilities we could have with a modified Recovery HD. but, as you mentioned, Apple might update it at some point. also, what if the target volume containing El Capitan isn't named "Macintosh HD"? how would you know the path to the boot.efi files?

 

[PeterHolbrook]

A few comments on your latest messages:

• Modifying the BaseSystem.dmg of the installer so that it will include Pike's boot.efi is certainly possible, but it requires a somewhat complicated process: copying its contents to some empty folder (located, for instance, on your Desktop), replacing the two boot.efi files, recreating a new BaseSystem.dmg with the modified contents of that temporary folder, making it invisible and returning it to the installer, replacing the previous one. Later on, this same modified BaseSystem.dmg could be used for the Recovery HD as well, making sure the trash is fully erased (as the Recovery HD is very small. In addition to the work involved, one must be aware that the modified BaseSystem.dmg won't have the Apple security signature, so it might eventually be detected as counterfeit.
• The PikeYoseFix won't work with SIP in place, and I fail to see how FileGuard or other similar conceptions can fix that. Other than using a hack, the only thing I can think of for "manually" making sure no future system updates overwrite the crucial boot.efi, et cetera, is for the user to boot into the Recovery HD, disable SIP, reboot into El Capitan. Then, and only then, will the PikeYoseFix, CaptainPike or CapitánPike (that would be its Spanish name, with a pun, considering Pike lives in Spain), or whatever we want to call it, be able to do its job at the end of a system update. When the updated version of El Capitan boots up, the user would need to reboot to the Recovery HD and turn SIP on again.
• Pike mentioned something about creating some kind of "sanctuary" (my name) in the El Capitan partition, which, duly blessed, might work as an emergency boot-up option, but I might have misinterpreted him. I don't know how this would work. Naturally, the modified Installer could always be used as an emergency replacement procedure after disaster strikes.

 

[mikeboss]

ugh. modifying the "Essentials.pkg" (if possible at all) also seems to be a complicated task ->
https://coolaj86.com/articles/how-to-unpackage-and-repackage-pkg-osx.html

 

[mikeboss]

a few weeks back when I created an installer media, I also modified the BaseSystem.dmg. unfortuantely this did not give a fully working system. I still had to replace the boot.efi manually. my conclusion: the installer took the boot.efi residing in the Essentials.pkg.


"CapitánPike"

 

[PeterHolbrook]

a few weeks back when I created an installer media, I also modified the BaseSystem.dmg. unfortuantely this did not give a fully working system. I still had to replace the boot.efi manually. my conclusion: the installer took the boot.efi residing in the Essentials.pkg.

Yes, you are probably right. Wouldn't the Flat Package Editor allow you to change the boot.efi in there? It works with "Distribution", so it might as well work with boot.efi.

Edit: Forget about it. Just tried and it doesn't seem to see the contents of BOM. Pacifist can look and it, and extract it, but, to my knowledge, it's unable to replace it within the pkg itself.

 

[mikeboss]

Yes, you are probably right. Wouldn't the Flat Package Editor allow you to change the boot.efi in there? It works with "Distribution", so it might as well work with boot.efi.

I tried this and it didn't work. right now, the only possible way I can think of is to use pkgutil from Xcode. and yes, Pacifist is read/extract-only.

edit
AFK until late afternoon...

 

[PeterHolbrook]

I know for a fact that a pkg file is, in reality, a xar archive, which can be opened and manipulated with applications such as 7ZIP, BetterZip and others. The greatest problem is that, as far as I know, none of these applications will let interactively change the BOM or the Payload of the archive.

 

[PeterHolbrook]

Enable some of the debug output.

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]

yes, using the broken boot.efi is one possible solution. but I don't like this approach because it clearly compromises security. we don't want to go that route...

I also thought about possibilities we could have with a modified Recovery HD. but, as you mentioned, Apple might update it at some point. also, what if the target volume containing El Capitan isn't named "Macintosh HD"? how would you know the path to the boot.efi files?

I was thinking of "asking the user"!

So I can report back that the Boot64 approach using launchd and a script is not going to work with SIP enabled.

Luckily for my day job I have just written an application that uses Security Management frameworks and a privileged helper tool. This is working on the SIP enabled ElC.

I will repurpose that code to do what needs to be done, then report back....
(it might take me a few days!)

I'm going to go out on a limb and suggest that the 10.11.1 update process is going to go something like this:

• Updater uses the /.IABootFiles folder (creates it if necessary)
• blesses that folder,
• reboots
• System comes up with SIP disabled
• installer runs to perform the update
• blesses the standard folder
• reboots

Any thoughts?

Of course it might not, Apple is the master of its own destiny so maybe the update installer will have privileges

 

[PeterHolbrook]

Back to boot.efi.

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!

 

[PeterHolbrook]

Updater uses the /.IABootFiles folder (creates it if necessary

The first place I read about the /.IABootFiles folder was in Pike's blog. I thought that therein was the key to boot.efi's survival after a system update. It appears, however, that that folder only exists briefly during the installation process and is automatically erased afterwards by the Installer itself. Perhaps that's a path that leads nowhere.

 

[mikeboss]

The first place I read about the /.IABootFiles folder was in Pike's blog. I thought that therein was the key to boot.efi's survival after a system update. It appears, however, that that folder only exists briefly during the installation process and is automatically erased afterwards by the Installer itself. Perhaps that's path that leads nowhere.

/.IABootFiles definitely exists on an installer volume created using the createinstallmedia command.

 

[PeterHolbrook]

Adding /.IABootFiles to the check.

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!

 

[PeterHolbrook]

When I sat in front of my computer this morning, I was greeted by an ugly sight. Sometime during the night, there was a power outage, and my UPS and its Mac software shut down my old Mac Pro (this has happened in the past; for instance, when Yosemite was installed on the computer, and it's always worked fine). When the electricity came back, the computer tried to reboot, but, alas, it didn't work. A very bad-quality photo of part of the screen is as follows:

My El Capitan partition was created by installing the system on top of my previous Yosemite partition. The installer was created as indicated in message #19 of this thread. Both the Installer and the El Capitan partition (in addition to the Recovery HD partition) use Pike's "black" boot.efi in the repository. In addition, the Installer's /Library/Preferences/SystemConfiguration/com.apple.Boot.plist was altered when I first created it with the explicit path to the prelinked kernel, as otherwise it wouldn't boot on my old Mac Pro.

Now, this is the second time this ugly kernel panic has appeared when rebooting the Mac. This time I tried to follow Pike's advice to fix it. Instead of using Yosemite, which I don't have anymore, I used the Installer disk again and, from Terminal, I entered:

touch /Volumes/Macintosh\ HD/System/Library/Extensions [sudo isn't necessary from the Installer's Terminal, nor does it work]

That didn't do anything, as trying to reboot to El Capitan failed again with the same kernel panic. The first and only time I tried to boot from the modified El Capitan Recovery HD, it showed the same panic, so I don't actually know if the Recovery HD is flawed by itself (like being unable to find the kernel cache or something), or it simply fails for another reason and then tries to boot the regular El Capitan partition, which is flawed by an unknown reason (that is, unknown to me).

The first time I saw this panic, I fiddled with various boot-up settings, such as setting nvram boot-args, etcetera, but none of the attempts were successful. The only way out of this predicament I know for now is to reinstall El Capitan (using the custom-made Installer). Letting it finish and then, reapplying Pike's boot.efi using the Terminal successfully boots El Capitan. Does anyone have an idea how to troubleshoot this situation?

The only thing I've come up with is that the "official" boot.efi in Pike's repository is "broken" (as far as my computer is concerned) and, as a result of its "brokenness" the Installer creates an El Capitan partition that will only boot correctly the first time after creation, but the partition itself will be unbootable after shutting down the computer. How is that possible?

 

[Pike R. Alpha]

When I sat in front of my computer this morning, I was greeted by an ugly sight...

Yeah that definitely looks ugly. What I would do is try to boot without -x to see if that is the problem. If not, then I would set
DEBUG_LDRP_CALL_CSPRINTF to 1 (enable debug) and see if it indeed can't find the kernel cache.

 

[Pike R. Alpha]

/.IABootFiles definitely exists on an installer volume created using the createinstallmedia command.

Plus when you install OS X from drive X to Y. Otherwise is will create a folder with the name 'OS Install Data' and then bless boot.efi in this folder.

 

[Pike R. Alpha]

I was thinking of "asking the user"!

So I can report back that the Boot64 approach using launchd and a script is not going to work with SIP enabled.

Luckily for my day job I have just written an application that uses Security Management frameworks and a privileged helper tool. This is working on the SIP enabled ElC.

I will repurpose that code to do what needs to be done, then report back....
(it might take me a few days!)

I'm going to go out on a limb and suggest that the 10.11.1 update process is going to go something like this:

• Updater uses the /.IABootFiles folder (creates it if necessary)
• blesses that folder,
• reboots
• System comes up with SIP disabled
• installer runs to perform the update
• blesses the standard folder
• reboots

Any thoughts?

Of course it might not, Apple is the master of its own destiny so maybe the update installer will have privileges

The launchdaemon I have here works for '/.IABootFiles' and '/OS X Install Data' – used by bless for the next reboot – due to the fact that there is no SIP for these directories. At least not yet.

The other files could, in theory, also be replaced automatically, but then you would need one extra step, and is to launch the Terminal.app from the installer and launch it. Either that or a script that looks for changes in the target folders.

 

[PeterHolbrook]

Yeah that definitely looks ugly. What I would do is try to boot without -x to see if that is the problem. If not, then I would set
DEBUG_LDRP_CALL_CSPRINTF to 1 (enable debug) and see if it indeed can't find the kernel cache.

So, if I interpret you correctly, the first thing I should try is to boot, let's say, to the Installer and, from its Terminal, enter nvram boot-args="-x", and then try to reboot to El Capitan, correct? I tried that the first time it happened, to no avail.

 

[Pike R. Alpha]

So, if I interpret you correctly, the first thing I should try is to boot, let's say, to the Installer and, from its Terminal, enter nvram boot-args="-x", correct? I tried that the first time it happened, to no avail.

No. Look at your picture. It's already set (Boot args: -x) so you need to get rid of it.

p.s. Verify that /S*/L*/Prelinkedkernels/prelinkedkernel is there.

 

[Sko]

...It's already set (Boot args: -x) so you need to get rid of it.
p.s. Verify that /S*/L*/Prelinkedkernels/prelinkedkernel is there.

I have the same kernel panic on a freshly created install HD (external via Firewire). I have no boot arguments set. The prelinked kernel ist there, 21.837.607 Bytes in size. The boot.efi is the black one from official repository.

 

[PeterHolbrook]

No. Look at your picture. It's already set (Boot args: -x) so you need to get rid of it.

p.s. Verify that /S*/L*/Prelinkedkernels/prelinkedkernel is there.

I see. I'll try to follow your advice, but it will take time. Unfortunately, I can't turn it off this computer whenever I want. As for the prelinkedkernel being in /S*/L*/Prelinkedkernels/ (of my regular El Capitan disk), it certainly is (at least when booted to it). The next time I reboot, I figure it will fail. If so, I'll look for it from the Installer Terminal.

 

[mikeboss]

commit: 910ebd0fa8aa63a65062ab730fea121930ed981a

I created an installer media using the official createinstallmedia command.
I then replaced all the boot.efi files I could find:

/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

added the SupportedBoardIds in
/Volumes/Install OS X El Capitan/.IABootFiles/PlatformSupport.plist
/Volumes/Install OS X El Capitan/System/Library/CoreServices/PlatformSupport.plist

I did not yet modify any of the two DMG files.



this is were the journey ended, the installer GUI didn't start

 

[PeterHolbrook]

@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.

 

[Pike R. Alpha]

commit: 910ebd0fa8aa63a65062ab730fea121930ed981a

I created an installer media using the official createinstallmedia command.
I then replaced all the boot.efi files I could find:

/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

added the SupportedBoardIds in
/Volumes/Install OS X El Capitan/.IABootFiles/PlatformSupport.plist
/Volumes/Install OS X El Capitan/System/Library/CoreServices/PlatformSupport.plist

I did not yet modify any of the two DMG files.

View attachment 589505

this is were the journey ended, the installer GUI didn't start


View attachment 589506

And /Volumes/Install OS X El Capitan/.IABootFiles/boot.efi is bootbase.efi?