macOS boot.efi developer's thread

[rthpjm]

Hello guys. just to let you know that I am alright. Still suffering a bit from double vision, but I can workaround it by using a cloth for one eye. But only temporarily only of course. Will be corrected with a small operation next week.

Anyway. I added some new debug output to see if the memory modules are detected correctly. Should be fine, and I cannot look into memory leaks right now, but since the same (compiled) source code works with Yosemite... I'd say this is an issue with the installer and friends.

Hello Pike,

It's great to have you back. I am so pleased to hear that you are on the mend. I'm sure you are more pleased (and mightily relieved too)! Don't push yourself too hard, take the time to recuperate... Don't vegetate though, keeping the brain active is important too

I decided to see if I could prove a memory leak. My first test may show that there is an apparent leak. I built an installer, booted from it, before starting the installer I opened a terminal from the Utilities and created a launchd plist. The plist called vm_stat every 5 seconds. Once I confirmed it was running I quit the terminal and ran the installer.
My MacPro was at full configuration with it's 32GB RAM, so the install completed cleanly.

I have briefly examined the vm_stat output and can see definite trends up and down. There's a distinct period where free memory is continually dropping, then free memory springs back up. Which I assume is once the decompression completes near the end of the Installer progress. (For anyone interested, I've attached the vm_stat file)...

A picture paints a thousand words:


vm_stat reports free pages, a page is 4KB. I found the lowest free figure and crunched the numbers:
5159861 free pages
4096 * 5159861 = 21134790656 bytes ~= 19.7 GB free

I have 32MB installed
32 - 19.7 ~= 12.3 GB used

Whilst not conclusive it does sort of tally with the tests observations by Inspector42.

When I was doing this test, I did notice that the log file was recording font errors at approximately the same frequency as the 'tick' of the progress bar. I'll focus my next tests to see if I can pin down the culprit. I'm starting to suspect it's the Language Chooser, which acts as the progress manager, I think it may be this process that is throwing the font errors. If the code, which is likely to be in a loop is allocating memory for fonts (but then not releasing) it might be a possible explanation. Admittedly this just guess-work at the moment.

============================ EDIT ============================

So I have now fixed the font "issue". The only effect this had was to remove the log file entries. The good news is that the log file is MUCH easier to read now. The bad news is that it had no effect on the memory profile.



I have updated post #807 with the Version 2 of the createpikeinstallmedia tool

I have also run the installer-with-fonts using 8GB of RAM. It still fails. The graph is interesting, it shows the install stopping short...



I'm going to try to identify which process is consuming the RAM, but I have a sneaking feeling that it may be intentional because of this log file line

Mac-Pro OSInstaller[485]: Activated virtual memory backing store at mount point '/Volumes/El Capitan'

 

[javirnat]

Hello guys. just to let you know that I am alright. Still suffering a bit from double vision, but I can workaround it by using a cloth for one eye. But only temporarily only of course. Will be corrected with a small operation next week.

Anyway. I added some new debug output to see if the memory modules are detected correctly. Should be fine, and I cannot look into memory leaks right now, but since the same (compiled) source code works with Yosemite... I'd say this is an issue with the installer and friends.

---------------------------------------------------------------------
I´m very happy to know that you are back with us. Take care and welcome . We wish the best for you .

 

[Inspector42]

Hello guys. just to let you know that I am alright. Still suffering a bit from double vision, but I can workaround it by using a cloth for one eye. But only temporarily only of course. Will be corrected with a small operation next week.

Anyway. I added some new debug output to see if the memory modules are detected correctly. Should be fine, and I cannot look into memory leaks right now, but since the same (compiled) source code works with Yosemite... I'd say this is an issue with the installer and friends.

Hi Pike, welcome back. I am truely relieved by your recovery.
As Peter suggested, please take it slowly although I can understand your eagerness to get engaged again

 

[F1Mac]

Hello guys. just to let you know that I am alright. Still suffering a bit from double vision, but I can workaround it by using a cloth for one eye. But only temporarily only of course. Will be corrected with a small operation next week.

So great to have you back Pike. Don't spend too much time in front of this damn computer now... take care m8

 

[Pike R. Alpha]

Thanks. No worries. Will only be here for five minutes or so. Need time to recover, but I am still here

 

[RaimisFr]

Hello,
I have an external drive named USB. After this "./createpikeinstallmedia /Volumes/USB I get the next message: "
/Users/xxx/Desktop/piki/createpikeinstallmedia /Volumes/USB
Cannot find copy of Pike's boot.fi
Place a copy of Pike's boot.efi into the same folder as this script"
Where is the problem?
Thanx

 

[rthpjm]

Hello,
I have an external drive named USB. After this "./createpikeinstallmedia /Volumes/USB I get the next message: "
/Users/xxx/Desktop/piki/createpikeinstallmedia /Volumes/USB
Cannot find copy of Pike's boot.fi
Place a copy of Pike's boot.efi into the same folder as this script"
Where is the problem?
Thanx

Hello RaimisFr

Well that is odd. I presume you successfully unzipped the file, and that you haven't moved any of the files?
You should have a pikify3.1 folder with the following contents:

OSInstall.collection
boot.efi
boot_black_3_1.efi
boot_grey_3_1.efi
bootbase.efi
createpikeinstallmedia
missing-fonts.tgz
pikify.pkg

You may or may not see the missing-fonts.tgz - it depends which version of pikify.zip you downloaded.

The error message you are getting tells me that boot.efi is missing. Whilst you are using the terminal, list the contents of the folder ls -1 (that's the number 1) and compare with the list above...

 

[rthpjm]

I've moved this post to the original Mac Pro (1,1/2,1) and El Capitan thread.

If you are looking for my Boot64 tools, you will find them updated at post #1391

 

[Inspector42]

While Pike is recuperating (take your time Pike ), I have figured out how to set up our working El-Capitan installs so that they will survive the Apple update mechanisms. You will need to install your choice of "pike yos fix" (search the forums for it), or my very own Boot64 stuff, they both pretty much do the same thing. My Boot64 stuff installs a Launch Daemon that watches the boot.efi files, if they get changed (by the Apple update) it simply puts the Pike copies back!

"Ah, but SIP stops them working!" I hear you cry. True!

But, we can exclude the boot.efi files from SIP - here's how:

I will assume your working El-Capitan is on the hard disk named Macintosh HD - change it to suit

1. Boot off another partition, I use the Recovery partition.
2. Open a Terminal

3. chflags nouchg /Volumes/Macintosh\ HD/System/Library/CoreServices/boot.efi
   echo "/System/Library/CoreServices/boot.efi" >> /Volumes/Macintosh\ HD/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths
   echo "/usr/standalone/i386/boot.efi" >> /Volumes/Macintosh\ HD/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

4. Reboot from your other partition back into your normal El Capitan disk (Macintosh HD)
5. Install pike yos fix, or my Boot64 (attached)
6. If you are going to install my Boot64, download the zip file below, unzip it, and double-click it, follow the installer prompts (you might need to allow it with Gatekeeper - if you get a "can't install" message, try opening System Preferences > Security & Privacy > General, look for the "Open anyway" button). If that doesn't work, choose 'Anywhere' from the options and try again... (Don't forget to put this option back to your preference after Boot64 is installed!)
7. Sit back and enjoy El-Capitan

I don't claim to have discovered this fix. I'm simply good at using search engines, and then realising how this fits together. The credit goes to the Hackintosh community again. See http://www.idelta.info/archives/sip-rootless-internal-in-el-capitan/

I've tested this with a clean install of El Capitan 10.11 and successfully installed the 10.11.1 update from the App Store, and from a clean install using the 10.11.1 downloadable update.

I will modify my pikify3.1 script bundle with this mod already in. Look out for pikify3.1.v3.zip at post #807...

Excellent work ! For the paranoid, one option to maintain comfort but reduce exposure, could be to limit access rights of changing boot.efi to the launch daemon. As I am not familiar with the details of sand boxing and SIP I started a search. While I haven't figured out how to do the above, I discovered this https://derflounder.wordpress.com/2...dding-another-layer-to-apples-security-model/.
The author mentions that when talking to Apple engineers they stated that those files controlling SIP are "owned" by Apple and will be overwritten when modified. Hence we need to carefully watch, if that will happen with the pending 10.11.2 update. It may defeat this approach.

 

[rthpjm]

Excellent work ! For the paranoid, one option to maintain comfort but reduce exposure, could be to limit access rights of changing boot.efi to the launch daemon. As I am not familiar with the details of sand boxing and SIP I started a search. While I haven't figured out how to do the above, I discovered this https://derflounder.wordpress.com/2...dding-another-layer-to-apples-security-model/.
The author mentions that when talking to Apple engineers they stated that those files controlling SIP are "owned" by Apple and will be overwritten when modified. Hence we need to carefully watch, if that will happen with the pending 10.11.2 update. It may defeat this approach.

That is true. Under normal circumstances, all items under /System are considered to be exclusive to Apple (to do with as they please). That's why there is (user accessible) /Library that mirrors the layout of /System/Library. Normally, non-Apple files are placed in /Library, items here are persistent and not typically overwritten by Apple.

Yes it's possible that Apple will continually overwrite the SIP paths file, but at the moment the technique will work because changes become resident after reboot. The current Apple update processes (App Store and DMG download) reboot after the installer has made its changes.

The paths file is SIP protected, that's why step 1 requires us to boot from another partition. The Boot64 folder in /Library/Applications Support is a little more exposed. I'll have a look to see if I can bring that under SIP protection. From a security perspective we have to accept that we're making a conscious choice to allow access to the boot.efi file. We are a relatively small group of owners that are continuing on with our 32-bit machines, from a risk profile I'd say it is a low likelihood, low impact risk. The good news is that any malware that has an attack vector to overwrite the boot.efi file directly would simply be subject to the pikeyosfix or Boot64 replacement. If we can protect our files, the attack vector window closes further.

When Pike is well enough, his approach of using a kernel extension may prove to be more secure...

 

[Inspector42]

I fully support rthpjm's assessment. The limited number of El Capitan users with "old hardware" is not very attractive to attackers and a simple boot.efi replacement would be cured with the daemon before it can do any damage, I had overlooked that in my thoughts.
Since one can always choose to not install the automated replacement, this is more of a personal preference issue.
If Apple was really concerned about modified Sandbox/SIP they would have chosen to replace the files with 10.11.1 update already.

EDIT:
Just revisited how Pike´s yosefix is working as I had it installed on my SSD and wanted to finally put El Captan on it without wiping the disk. The spare boot.efi.pike is located at /usr/standalone/i386 and hence it is protected by SIP. I just replaced it with the El Capitan version sitting there anyway. The com.pike.yosefix.plist is placed in /Library/LaunchDaemons, the script code for replacement is embedded there. This is then the only file exposed somewhat.

 

[666sheep]

snip.

PikeYoseFix contains Yosemite boot.efi. While it works OK, there's an ElCapitan updated version of original tobyg's script containing Pike's v3.1 boot.efi:
https://forums.macrumors.com/thread...os-x-el-capitan.1890435/page-51#post-22236546

 

[nathanonlaptop]

Hey Guys, I'm new to this tread.
I have a Mac Pro 1,1 , bios patched to 2,1.
x2 2.66ghz Xeon X5355, 16 GB ram

I've done the manual boot.fi patches to the install files in the past, but this time I'm using pikify 3.1v3 to automate the process. I'm having some trouble getting things to work. First try, install hung up at 14 min ~10% mark. Rebooted, second and third try, didn't get past install boot screen without a panic. See images below. What might be the culprit here? I just upgraded from 10GB to 16GB ram to be able to use this patch.

 

[rthpjm]

Hey Guys, I'm new to this tread.
I have a Mac Pro 1,1 , bios patched to 2,1.
x2 2.66ghz Xeon X5355, 16 GB ram

I've done the manual boot.fi patches to the install files in the past, but this time I'm using pikify 3.1v3 to automate the process. I'm having some trouble getting things to work. First try, install hung up at 14 min ~10% mark. Rebooted, second and third try, didn't get past install boot screen without a panic. See images below. What might be the culprit here? I just upgraded from 10GB to 16GB ram to be able to use this patch.View attachment 604620
View attachment 604621

Hello Nathan,

Almost everyone that has reported similar KPs has found that their RAM was the cause. You say yours is new, so my best advice would be to power-off. Pull the RAM riser cards from the machine, work through each RAM stick and make sure your have fully pressed it home in its socket. Be firm. Then put the riser cards back into the machine, but don't put the side panel back on, leave it open. Power on the machine, look at the exposed parts of the RAM riser cards, are any of the LEDs illuminated? if so it's an indication of bad ram, or bad connection. If you do see lit LEDs, power off, pull the riser cards, eject your RAM sticks, maybe shuffle (in pairs) them a bit, then re-insert all your RAM. Re-insert the riser cards, power on, check for LEDs lit.

If you still have LEDs lit, this time try to make a note of the LED position (there's usually two rows of two on 1,1 riser cards, each corresponding to a RAM slot). Repeat the pull, eject, shuffle re-seat, re-install, but this time try to be specific about where you put the stick that was marked by the LED (e.g. if it was slot 3 that was illuminated, during the shuffle put that stick back into slot 1). Power on, see if the LED follows the stick of RAM. If it does then you've found a potential culprit.

If there are no lit LEDs, then perform a visual check and make sure you have matched pairs in the slots...

Also, just to be clear, pikify3.1 is only intended to install new copies of El Capitan (onto a new/spare disk for example - if you are brave it should be okay to upgrade from Yosemite by this method too).

I'm not sure what you mean by automate, but if you already have El Capitan installed and just want to automate the "putting back of the modifications when the Apple updates overwrite them", then you should be looking at CapitanPikeFix or my Boot64....

 

[nathanonlaptop]

Hello Nathan,

Almost everyone that has reported similar KPs has found that their RAM was the cause. You say yours is new, so my best advice would be to power-off. Pull the RAM riser cards from the machine, work through each RAM stick and make sure your have fully pressed it home in its socket. Be firm. Then put the riser cards back into the machine, but don't put the side panel back on, leave it open. Power on the machine, look at the exposed parts of the RAM riser cards, are any of the LEDs illuminated? if so it's an indication of bad ram, or bad connection. If you do see lit LEDs, power off, pull the riser cards, eject your RAM sticks, maybe shuffle (in pairs) them a bit, then re-insert all your RAM. Re-insert the riser cards, power on, check for LEDs lit.

Thanks for that advise! After re-pikifying my drive with 10.11.2, I am now back to the 13 minutes-then-hang issue. I tried re-seating all of my 2GB ram modules, rearranging them, checking lights, etc. to no success. I ran the install with 2GB of ram with the exact same hangs in the same spots as with 16GB, just took a bit longer. I have two drives in this mac, an SSD for OS boot, and a HDD for storage. Back last year when updating to Yosemite, I installed mountain lion on the storage drive just in case of catastrophic failure with my SSD. If I boot into mountain lion, I can see all 16GB registered in system profiler. I have another mac that is El Capitan friendly; is there a step-by-step guide to manually swapping the boot.efi files without having to run the pikified installer locally?

Thanks in advance!

 

[rthpjm]

Thanks for that advise! After re-pikifying my drive with 10.11.2, I am now back to the 13 minutes-then-hang issue. I tried re-seating all of my 2GB ram modules, rearranging them, checking lights, etc. to no success. I ran the install with 2GB of ram with the exact same hangs in the same spots as with 16GB, just took a bit longer. I have two drives in this mac, an SSD for OS boot, and a HDD for storage. Back last year when updating to Yosemite, I installed mountain lion on the storage drive just in case of catastrophic failure with my SSD. If I boot into mountain lion, I can see all 16GB registered in system profiler. I have another mac that is El Capitan friendly; is there a step-by-step guide to manually swapping the boot.efi files without having to run the pikified installer locally?

Thanks in advance!

There is a guide on page 32 of this thread (post #783) written by Peter Holbrook.

Out of interest, take a look at the (incomplete) contents of your target drive. You should find the log file at /Volumes/[your drive]/var/log/install.log. If you still have the log file, compress it and post it, I'll take a look at it for you....

 

[nathanonlaptop]

Out of interest, take a look at the (incomplete) contents of your target drive. You should find the log file at /Volumes/[your drive]/var/log/install.log. If you still have the log file, compress it and post it, I'll take a look at it for you....

Here you go. I was monitoring the log during the install, saving it to a flash disk periodically to make sure it was saved. Didn't know it was writing to the install disk. I noticed this chunk of the log seemed to be culprit

Dec 10 14:53:46 Mac-Pro OSInstaller[456]: OSIInstallElement <OSIInstallElement: 0x7fad8e839ff0> errored out:Error Domain=PKInstallErrorDomain Code=110 "An error occurred while extracting files from the package “Essentials.pkg”." UserInfo={NSUnderlyingError=0x7fad90961f00 {Error Domain=PKXARArchiveErrorDomain Code=101 "archive verify failed" UserInfo={NSURL=file:///System/Installation/Packages/Essentials.pkg#Payload, NSFileOwnerAccountID=0, NSFileHFSTypeCode=0, NSFileSystemFileNumber=350, NSFileExtensionHidden=false, NSFileSystemNumber=16777225, NSFileSize=5585759678, NSFileGroupOwnerAccountID=0, NSFileOwnerAccountName=root, NSFilePosixPermissions=420, NSFileHFSCreatorCode=0, NSFileCreationDate=2015-12-03 17:18:11 +0000, NSFileType=NSFileTypeRegular, NSFileGroupOwnerAccountName=wheel, NSFileReferenceCount=1, NSFileModificationDate=2015-12-03 17:20:27 +0000, NSLocalizedDescription=archive verify failed}}, NSFilePath=/Volumes/Macintosh HD/.OSInstallSandboxPath/Root, NSURL=Essentials.pkg -- file:///System/Installation/Packages/OSInstall.mpkg#Distribution, PKInstallPackageIdentifier=com.apple.pkg.Essentials, NSLocalizedDescription=An error occurred while extracting files from the package “Essentials.pkg”.}
Dec 10 14:53:46 Mac-Pro OSInstaller[456]: ------- Install Failed -------
Dec 10 14:53:46 Mac-Pro OSInstaller[456]: Operation: Install packages failed, Failure Reason: Error Domain=PKInstallErrorDomain Code=110 "An error occurred while extracting files from the package “Essentials.pkg”." UserInfo={NSUnderlyingError=0x7fad90961f00 {Error Domain=PKXARArchiveErrorDomain Code=101 "archive verify failed" UserInfo={NSURL=file:///System/Installation/Packages/Essentials.pkg#Payload, NSFileOwnerAccountID=0, NSFileHFSTypeCode=0, NSFileSystemFileNumber=350, NSFileExtensionHidden=false, NSFileSystemNumber=16777225, NSFileSize=5585759678, NSFileGroupOwnerAccountID=0, NSFileOwnerAccountName=root, NSFilePosixPermissions=420, NSFileHFSCreatorCode=0, NSFileCreationDate=2015-12-03 17:18:11 +0000, NSFileType=NSFileTypeRegular, NSFileGroupOwnerAccountName=wheel, NSFileReferenceCount=1, NSFileModificationDate=2015-12-03 17:20:27 +0000, NSLocalizedDescription=archive verify failed}}, NSFilePath=/Volumes/Macintosh HD/.OSInstallSandboxPath/Root, NSURL=Essentials.pkg -- file:///System/Installation/Packages/OSInstall.mpkg#Distribution, PKInstallPackageIdentifier=com.apple.pkg.Essentials, NSLocalizedDescription=An error occurred while extracting files from the package “Essentials.pkg”.}

 

[rthpjm]

Here you go. I was monitoring the log during the install, saving it to a flash disk periodically to make sure it was saved. Didn't know it was writing to the install disk. I noticed this chunk of the log seemed to be culprit

Hi Nathan,

I have compared your log file to a successful one of mine. Everything looks the same up to around line 307, then your log file differs significantly from mine. It might have something to do with you saving your log file periodically.

I have attached my log file so that you can compare. You will notice that your log file fills up with SFLList entries, opendirectoryd, and "Folder Manager" entries. If you ignore those entries (or use a text editor to remove them), our log files are similar until you get to the error message you show in the code box above.

Looking more closely at the error message, the good news is that it is not the one I expected to see if it was a memory related issue - if it was the known memory issue, it usually fails during stream decoding (decompressing) of the Essentials.pkg. Your message says "verify failed".

This leads me to think there are a number of possibilities:
A drive issue, that has corrupted the Essentials.pkg file. Can you tell me what media you are using for the installer? Is it a USB memory stick, an internal drive/partition, an external drive, or something I haven't thought of?
Have you run Disk Utility on the drives you are using? If not can you do so? (you might be best to boot from a different drive to perform a full check on the installer drive and the target drive).
My best guess at the moment is that your installer drive is corrupted and/or failing. I would suggest that you try to reformat and rebuild the installer drive, then try again. If it still fails, use disk util to check both the installer drive and the target drive. Try again. If that fails, try to build an installer on different media, try again. If that fails, try to install on a different target drive.

A final thought; Is your copy of 'Install OS X El Capitan.app' unmodified? If you have previously attempted to modify it then that could also be the cause of the failure to verify the Essentials.pkg. If you need to download a new copy of 'Install OS X El Capitan.app', you must first remove all copies of it from your system, otherwise the App Store will look like it starts to download and then immediately stops.

 

[rthpjm]

Whilst checking out Nathan's issue above, I noticed that his installer was reporting the Base System as 10.11.2.

I went to the App Store, re-downloaded OS X El Capitan (becomes /Applications/Install OS X El Capitan.app).

Indeed the BaseSystem is 10.11.2, but so is the rest of the deployment. Installing with the latest copy gets you to 10.11.2 directly. And of course pikifying (createpikeinstallmedia) works. I wonder if it has done anything to the memory requirement?...

------ edit ------

No it doesn't

 

[dgwilson]

Thanks for the information about the latest El Capitan installer on the App Store being 10.11.2 - I'll do a clean download.

Anyway... I wanted to report a couple of things.
a. I have 2 x MacPro1,1 machines with 16GB of RAM - one of which I'm happy to play with.
b. I have upgraded via the Appstore to 10.11.2 successfully. The upgrade involved letting the AppStore download/install do it's thing... and the reboot after install went to the alternate OS on the machine. I then replaced the boot.efi files on the El Capitan drive and rebooted (after checking the startup volume). At this point I have not updated the RecoveryHD. I'm just missing some manual instructions for that.

... NOTE BELOW - Where I'm copying boot_pike.efi - you need this to be the same EFI that was used with pikify - or later as appropriate. 


cd cd /Volumes/El\ Capitan/usr/standalone/i386/
sudo cp boot_pike.efi boot.efi

cd /Volumes/El\ Capitan/System/Library/CoreServices/
sudo chflags nouchg boot.efi
sudo cp boot_pike.efi boot.efi
sudo chflags uchg boot.efi

- David

 

[PeterHolbrook]

At this point I have not updated the RecoveryHD. I'm just missing some manual instructions for that.

Look for my complete installation guide, above (written weeks ago). It contains a thorough explanation of everything that needs to be done.

 

[dgwilson]

Look for my complete installation guide, above (written weeks ago). It contains a thorough explanation of everything that needs to be done.

Excellent Peter. Thank you.

I've got the instructions - they're in this post: https://forums.macrumors.com/threads/boot-efi-developers-thread.1924434/page-32#post-22213699

I have encountered an issue when I try to change the flags on the boot.efi file.

sudo chflags nouchg boot.efi
chflags: boot.efi: Operation not permitted

According to the finder I can only "read" ... assuming that's my Admin user.
And it appears that sudo does not have write permission either.


I've missed something.

- David

 

[rthpjm]

Excellent Peter. Thank you.

I've got the instructions - they're in this post: https://forums.macrumors.com/threads/boot-efi-developers-thread.1924434/page-32#post-22213699

I have encountered an issue when I try to change the flags on the boot.efi file.

sudo chflags nouchg boot.efi
chflags: boot.efi: Operation not permitted

According to the finder I can only "read" ... assuming that's my Admin user.
And it appears that sudo does not have write permission either.


I've missed something.

- David

Hi David

I have encountered a strange effect when I upgraded from 10.11.1 to 10.11.2. I have tested and confirmed that it is repeatable. Here is how I tested:

I used my pikify3.1.v5 script to create an installer, based on the original 10.11.0 download.
Installed 10.11.0 with no problems.
Confirmed my mods to /S/L/Sandbox/Compatibility.bundle/Contents/Resources/paths were in place
Installed my Boot64.v2 automated protector
Upgraded to 10.11.1 using the Support download disk image for 10.11.1 successfully
Reconfirmed my mods were in place
Reconfirmed that Boot64 was able to replace/protect the boot.efi files
Upgraded to 10.11.2 using the MAS.
Reconfirmed my mods were in place
However, I find that those mods to the paths file do not seem to be "active"
/S/L/C/boot.efi is SIP protected as is the paths file.

I've done some investigation, and I think that I have figured it out. There is some caching going on. There is a command (rootless-init) that appears to read the configuration files and most likely builds a binary cache for the kernel. I say "most likely" because there is no information available for rootless-init, and I haven't taken a close look at the binary yet.

I have now tested the complete upgrade sequence as above with a new version of my Boot64 tool. This time it worked and I got to 10.11.2 with /S/L/C/boot.efi and the paths file exempt from SIP (/u/s/i/boot.efi was never a problem as far as I can see).

BTW, chflags is a SIP protected operation. Even if the file is excluded from SIP, chflags is not permitted. You have to boot from another partition, or disable SIP from the Recovery HD, make the change, then re-enable SIP. (I prefer to boot from another partition, I'm lazy and it cuts out a couple of steps).

I will upload Boot64.v3 to the main 2006/7 El Capitan thread today...

I will assume you have performed my suggested modifications to the /S/L/Sandbox/.../paths file
If you find yourself in this 10.11.2 situation try the following:
Boot from the Recovery HD of your main boot drive
Open a terminal
Disable SIP (csrutil disable)
Reboot back to your main OS partition
SIP should be off, type

/usr/libexec/rootless-init

You should not get any errors when running that command
Reboot to your Recovery partition
Open a terminal
Enable SIP (csrutil enable)
Reboot to your main OS partition
Confirm the /S/L/C/boot.efi file is now replaceable
Confirm /S/L/Sandbox/Compatibility.bundle/Contents/Resources/paths file is editable

 

[PeterHolbrook]

I have encountered an issue when I try to change the flags on the boot.efi file.

If you read my guide with due attention, you'll notice that all such operations are supposed to be carried out using the Terminal on the INSTALLER partition, not the live El Capitan partition. If you run all the relevant commands from the installer, you'll be root by default, and you'll be able to bypass whatever SIP configuration you may have on your El Capitan partition(s). Please, note that changing SIP settings or using sudo is unnecessary. The Terminal of the installer has EVERYTHING you might deem necessary.

 

[rthpjm]

At this point I have not updated the RecoveryHD. I'm just missing some manual instructions for that.

- David

If you originally started with pikify3.1, then the recovery partition should already be modified (pikify does it for you ).

It is possible that the 10.11.2 Recovery HD update may have overwritten things.

The simple change is posted at #1454 on the main thread.

If you feel the need to change the BaseSystem.dmg as well...
Assuming the recovery partition is mounted at /Volumes/Recovery HD

rsync -ah --progress /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg /tmp
hdiutil attach -nobrowse -noverify -owners on -kernel /tmp/BaseSystem.dmg -shadow
cp [pike-boot.efi] /Volumes/OS\ X\ Base\ System/System/Library/CoreServices/boot.efi
cp [pike-boot.efi] /Volumes/OS\ X\ Base\ System/usr/standalone/i386/boot.efi
cd /
hdiutil detach /Volumes/OS\ X\ Base\ System/
rm /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg
hdiutil convert -format UDZO -imagekey zlib-level=9 /tmp/BaseSystem.dmg -shadow -o /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg
rm /tmp/BaseSystem.dmg /tmp/BaseSystem.dmg.shadow

The Recovery HD is not usually large enough to make the changes in-place, hence the copy to /tmp