Become a MacRumors Supporter for $25/year with no ads, private forums, and more!

rthpjm

macrumors 6502a
Jan 31, 2011
699
293
U.K.
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

macrumors 65816
Original poster
Aug 13, 2009
1,453
661
switzerland
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

macrumors 65816
Sep 23, 2009
1,310
242
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

macrumors 65816
Original poster
Aug 13, 2009
1,453
661
switzerland
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" :D
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
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.
 
Last edited:

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,453
661
switzerland
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...
 
Last edited:

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
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

macrumors 65816
Sep 23, 2009
1,310
242
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!
 

Attachments

  • boot4d81f58f59335c1080b412e1740aa72b6f25fa07.zip
    204.7 KB · Views: 293

rthpjm

macrumors 6502a
Jan 31, 2011
699
293
U.K.
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

macrumors 65816
Sep 23, 2009
1,310
242
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!
 

Attachments

  • boot 903de61ab09e7a46438ffd8f7063c2b509eada65.zip
    206.5 KB · Views: 332

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
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.
 
Last edited:

mikeboss

macrumors 65816
Original poster
Aug 13, 2009
1,453
661
switzerland
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.
 
  • Like
Reactions: PeterHolbrook

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
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!
 

Attachments

  • boot 910ebd0fa8aa63a65062ab730fea121930ed981a.zip
    206.5 KB · Views: 318

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
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:
Panic.jpg

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

macrumors 6502
Oct 4, 2015
377
216
Spain
/.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

macrumors 6502
Oct 4, 2015
377
216
Spain
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

macrumors 65816
Sep 23, 2009
1,310
242
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.
 
Last edited:

Pike R. Alpha

macrumors 6502
Oct 4, 2015
377
216
Spain
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

macrumors 6502
Oct 17, 2009
285
59
Germany
...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

macrumors 65816
Sep 23, 2009
1,310
242
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

macrumors 65816
Original poster
Aug 13, 2009
1,453
661
switzerland
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.

01.PNG

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


02.JPG
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,310
242
@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

macrumors 6502
Oct 4, 2015
377
216
Spain
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?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.