2006/2007 Mac Pro (1,1/2,1) and OS X El Capitan

[Mortimus]

Hello, i update today capitan 10.11.1 to 10.11.2
I changed manually the two boot.efi
The macpro boot on black screen with Apple but the progression bar blocked on 2/3
An issue ?
Sorry for my approximative english of frenchie

i try capitanfixe but the problem stay

it was perfect with 10.11.1,
is what I have to wait for a new update boot.efi ??

thx for help

 

[sarthak]

Does anyone have the link to CapitanPikeFix?

Also, any chance of disabling SIP without going into recovery (I could never boot into it for some reason on any previous version of OS X either, just went back to standard desktop)

 

[rthpjm]

i try capitanfixe but the problem stay

it was perfect with 10.11.1,
is what I have to wait for a new update boot.efi ??

thx for help

Hello Mortimus,

It sounds like you may have installed 10.11.2 okay, but the boot.efi files have stayed with the Apple ones. Your machine won't boot from that partition, so it moves to the next available partition that it can find that is bootable. Do you still have the installer disk connected?

Reboot, then hold down the ALT key immediately after the startup chime to enter the boot picker.
There will be an arrow marker underneath the default boot disk. Please confirm that this is the volume you are expecting to boot from...

Try to boot from your recovery partition, open a Terminal and replace the boot.efi files with the Pike versions

 

[rthpjm]

Does anyone have the link to CapitanPikeFix?

Also, any chance of disabling SIP without going into recovery (I could never boot into it for some reason on any previous version of OS X either, just went back to standard desktop)

Hello sarthak,

You can only disable SIP from a Recovery partition (under normal circumstances, there is one other way I know but it's not for the inexperienced).

To fix your Recovery partition, open a Terminal

diskutil list

Find the device number for your recovery partition, if your boot disk is /dev/disk0, then the Recovery partition is usually slice 3 or /dev/disk0s3.
Let's assume it is /dev/disk0s3 (substitute yours if necessary)

diskutil mount /dev/disk0s3

You should now find the Recovery partition is now mounted.
Open the recovery partition, you should find a folder called com.apple.recovery.boot, inside here is a boot.efi file. Copy a Pike boot.efi file into this location. If you do it correctly you will at least be able to boot into the recovery.

 

[rthpjm]

Everyone....

You cannot use CapitanPikeFix (or Boot64) on their own. SIP is enabled so you must either disable SIP, or follow my instructions at post #1391

 

[Mortimus]

Hello Mortimus,

It sounds like you may have installed 10.11.2 okay, but the boot.efi files have stayed with the Apple ones. Your machine won't boot from that partition, so it moves to the next available partition that it can find that is bootable. Do you still have the installer disk connected?

Reboot, then hold down the ALT key immediately after the startup chime to enter the boot picker.
There will be an arrow marker underneath the default boot disk. Please confirm that this is the volume you are expecting to boot from...

Try to boot from your recovery partition, open a Terminal and replace the boot.efi files with the Pike versions

hello,
thx for help, i install the pike grey on 10.11.2 to be sure, and black on the other partition with is on 10.10.5.
when i boot on my DD with 10.11.2, i have primary a grey screen with the bar of progression, then a grey screen only for a while, more longer than normally and then grey screen with bar progression blocked
on 2/3. i try to wait but the progression is stop.

i don't understand

 

[rkanaga]

HI, I'm trying to update to 10.11.2. I have run the updater from the App Store on a spare copy of my HD. When it failed to re-boot I booted into the recovery partition and turned off SIP. I then booted into another partition (running El Capitan). I was able to change the Boot EFi in usr/standalone and the one in the recovery partition, but when I try to replace the one in System/Library/Core Services it is locked and I cannot delete it. The locked box is greyed out and I cannot alter it. If I try to give myself read/write permissions for the Boot Efi I am told I don't have permission to do that! I have also tried booting into an old Tiger partition and I still cannot replace the file from there

I would be very grateful for any advice on where to go. Luckily I am working on a clone of my system drive so nothing is broken irrevocably!

Thanks


Robin.

 

[mossman1120]

I wanted to start out by saying thank you to everyone for all the hard work they have done to breath life into Mac Pro 1,1. I have been reading over everything and I just wanted to confirm that my steps are correct before I attempt to upgrade my machine.

My current machine is a Mac Pro 1,1 running 10.10.4. I have 6GB of RAM (4x 512MB and 4x 1GB). I have installed the PikeYoseFix.pkg to make me 10.10.X update safe.

I do want to call out the fact that I only have 6GB of RAM. If the do the method outlined below do I need to be concerned or is the RAM issue people have been encountering related to something with the method done in the pikify3.1.v5 in post #1390?

Based on what I have been reading it seems the easiest way to upgrade my machine would to mount it in target mode and use my MacBook Pro to do the initial install of El Capitan.

What I am little unsure on is how to proceed from there so please correct me if I am wrong. Once the installer is complete I would allow my MacBook Pro to restart using the target mode drive from Mac Pro. Once the system has booted up I would need to first replace the boot.efi on my Recovery Drive using the following steps:

# Mount the Recovery HD

# Unlock boot.efi
sudo chflags nouchg /Volumes/Recovery\ HD/com.apple.recovery.boot/boot.efi

# Replace with the Piker-Alpha boot.efi
# http://piker-alpha.github.io/macosxbootloader

# Lock boot.efi
sudo chflags uchg /Volumes/Recovery\ HD/com.apple.recovery.boot/boot.efi

# Eject the Recovery HD

Once I have done this I would then shut down my MacBook Pro and my Mac Pro. I would then boot my Mac Pro up using the recovery partition. I would then follow the steps in post #1391 which I copied below for expedience sake:

# Unlock boot.efi
chflags nouchg /Volumes/Macintosh\ HD/System/Library/CoreServices/boot.efi

# Except the following paths from SIP - This is to allow CapitanPikeFix or Boot64 to replace the boot.efi if needed
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
echo "/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths" >> /Volumes/Macintosh\ HD/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

I would then need to run the following commands to remove the file installed by PikeYoseFix.pkg:

# Remove the old launch service
sudo rm /Library/LaunchDaemons/com.pike.yosefix.plist

# Remove the old boot.efi
sudo rm /usr/standalone/i386/boot.efi.pike

I would install CapitanPikeFix or Boot64. If I wanted to go the CapitanPikeFix route I would use the version found in post #1253 and choose the grey or black version based on the version I used on the Recovery Drive.

At this point I should be good to go for updates released from Apple provided they do not revert or alter the following file:

/Volumes/Macintosh\ HD/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths​

I do have a question for rthpjm about the last line in the steps. Are we exempting the paths file from SIP because the default does not include the exemption for the boot.efi files? What happens if we do not add the paths file to the paths file? If we exempt the paths file would it be possible for some other malicious application to insert additional paths into the paths file?

Thanks again everyone!

 

[sarthak]

Hello sarthak,

You can only disable SIP from a Recovery partition (under normal circumstances, there is one other way I know but it's not for the inexperienced).

To fix your Recovery partition, open a Terminal ...

Thanks for the instructions.

Got the Recovery partition working and was able to disable SIP. Now my SCSI Card (ATTO) is finally recognized as otherwise with SIP enabled, it would not load the driver.

 

[rthpjm]

I do have a question for rthpjm about the last line in the steps. Are we exempting the paths file from SIP because the default does not include the exemption for the boot.efi files? What happens if we do not add the paths file to the paths file? If we exempt the paths file would it be possible for some other malicious application to insert additional paths into the paths file?

Thanks again everyone!

Hello mossman1120

You are correct to highlight your RAM. You will achieve your install booting in target disk mode from your MBP. The install method in post 1390 requires more RAM. We have not yet managed to isolate why the memory requirement is so high. We have a suspicion that there may be a memory leak in a kernel routine in the Pike 3.1 efi file that the installer makes use of. It doesn't appear to affect normal day to day running of Mac OS X (just the installer).
It turns out that the installer assistant treats the method as if it were running from a DVD. Therefore, the first action it makes is to create some RAM-disks, it then copies the installer files to the RAM-disks and reboots (re-root) from the RAM-disks. THEN, the installation starts. At various points during the installation it will decompress the distribution files, the data is decompressed into a temporary folder, this folder is located on the RAM-disk. Therefore, to decompress the biggest distribution file, it needs a lot of RAM (acting as disk).

To answer your questions, in order,

1. Yes
2. Apple updates (at least the first 2 El.C updates) overwrite the paths file, and therefore undo the change to exempt the boot.efi files. If we don't add paths to the file then the Launch Daemons cannot re-add the entries. Remember the goal is to achieve an updatable system without manual post processing. If you are concerned, then you do not have to add this support, or add just the amount you are comfortable with. In most cases if you trim back the setup, you will find that you will need to perform a manual intervention after the next Apple update you install...
3. Yes

You must personally assess the risk. In my mind the risk is relatively low. SIP remains enabled and is protecting more of the system than any time in the past (compared to Yosemite, Mavericks, and older). Apple is closing the easier attack vectors. Those of us that are choosing to keep our 32-bit Macs running are at least aware that we are modifying our systems. The understanding may vary from person to person, but we must accept that we are on a different path to a fully SIP protected Apple-supported system.

If you don't mind post processing after an update, then by all means the additions to the paths file are not needed. If you want the convenience of being able to install an update and get straight back to work, then you do need them.

BTW, CapitanPikeFix does not yet repair the paths file. I must remember to chat with 666sheep to see if he wants to modify it.

For now, if you want the "full" convenience, I would recommend using my Boot64.v2 tool.

 

[rthpjm]

hello,
thx for help, i install the pike grey on 10.11.2 to be sure, and black on the other partition with is on 10.10.5.
when i boot on my DD with 10.11.2, i have primary a grey screen with the bar of progression, then a grey screen only for a while, more longer than normally and then grey screen with bar progression blocked
on 2/3. i try to wait but the progression is stop.

i don't understand

Hello Mortimus,

Okay. Let us try to boot in verbose mode and observe where the boot process stops...

Reboot your machine, as soon as you hear the boot chime hold down the Apple key and the V key together (Apple V, also known as Command V).

You should start to see text as your machine boots ( you can let go of the keys once you see the text start).

Please watch the text, and report the last few lines when the system appears to stop booting....

 

[Inspector42]

snip ...
All well and good. Except......

The bad news, it looks to me like the /S/L/C/boot.efi file is still protected by SIP in 10.11.2.
I'm still investigating, all the mods seem to be in place, so I'm wondering if that efi file is now "hard coded" into SIP in some way.

I would be interested in feedback from others, if you could verify that /S/L/C/boot.efi is protected on your systems at 10.11.2?

I can confirm the effect in 10.11.2. "sudo touch" and "sudo chflags" return "operation not permitted" despite the amended entry "/System/Library/CoreServices/boot.efi" in "/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths".
I recognise that the paths-file was compressed when initially installed, and will be stored uncompressed after amending the paths. Although this should not have any affect.
The attributes displayed with "ls-lO" still show "restricted" in 10.11.1 as well as 10.11.2, but file can only be touched in 10.11.1 :-(.
Maybe "/System/Library/Sandbox/rootless.conf" must also be edited in 10.11.2 as it protects "/System/Library/CoreServices" altogether ? But this has´t changed since 10.11.1.

EDIT:

Just deleted and recopied 'boot.efi' into "/System/Library/CoreServices" under 10.11.1, and now the "restricted" flag is gone.

 

[rthpjm]

I can confirm the effect in 10.11.2. "sudo touch" and "sudo chflags" return "operation not permitted" despite the amended entry "/System/Library/CoreServices/boot.efi" in "/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths".
I recognise that the paths-file was compressed when initially installed, and will be stored uncompressed after amending the paths. Although this should not have any affect.
The attributes displayed with "ls-lO" still show "restricted" in 10.11.1 as well as 10.11.2, but file can only be touched in 10.11.1 :-(.
Maybe "/System/Library/Sandbox/rootless.conf" must also be edited in 10.11.2 as it protects "/System/Library/CoreServices" altogether ? But this has´t changed since 10.11.1.

EDIT:

Just deleted and recopied 'boot.efi' into "/System/Library/CoreServices" under 10.11.1, and now the "restricted" flag is gone.

It is strange! It seems to be applied at some point during the Apple update for 10.11.2.

I re-downloaded the 'Install Mac OS X El Capitan.app' from the MAS. The current version on the MAS will immediately install 10.11.2, no need to update. If I use pikify3.1.v5 built from this copy of the installer, the resulting OS is 10.11.2, the mods are in place, and the boot.efi and paths files are editable (as we desire).

I think there may be some caching going on. I have an idea, which I will test and then report back...

 

[rkanaga]

It is strange! It seems to be applied at some point during the Apple update for 10.11.2.

I re-downloaded the 'Install Mac OS X El Capitan.app' from the MAS. The current version on the MAS will immediately install 10.11.2, no need to update. If I use pikify3.1.v5 built from this copy of the installer, the resulting OS is 10.11.2, the mods are in place, and the boot.efi and paths files are editable (as we desire).

I think there may be some caching going on. I have an idea, which I will test and then report back...

Thanks, I think this is my problem as well. I can't unlock the boot efi in System/Library/CoreServices on my updated 10.11.2 system even with SIPP turned off.

I will wait patiently to hear of the workaround as currently I can't use the updated system!

Strange that some people seem not to have had this issue though, it clearly is not consistent?

regards


Robin

 

[mossman1120]

Hello mossman1120

You are correct to highlight your RAM. You will achieve your install booting in target disk mode from your MBP. The install method in post 1390 requires more RAM. We have not yet managed to isolate why the memory requirement is so high. We have a suspicion that there may be a memory leak in a kernel routine in the Pike 3.1 efi file that the installer makes use of. It doesn't appear to affect normal day to day running of Mac OS X (just the installer).


To answer your questions, in order,

1. Yes
2. Apple updates (at least the first 2 El.C updates) overwrite the paths file, and therefore undo the change to exempt the boot.efi files. If we don't add paths to the file then the Launch Daemons cannot re-add the entries. Remember the goal is to achieve an updatable system without manual post processing. If you are concerned, then you do not have to add this support, or add just the amount you are comfortable with. In most cases if you trim back the setup, you will find that you will need to perform a manual intervention after the next Apple update you install...
3. Yes

You must personally assess the risk. In my mind the risk is relatively low. SIP remains enabled and is protecting more of the system than any time in the past (compared to Yosemite, Mavericks, and older). Apple is closing the easier attack vectors. Those of us that are choosing to keep our 32-bit Macs running are at least aware that we are modifying our systems. The understanding may vary from person to person, but we must accept that we are on a different path to a fully SIP protected Apple-supported system.

If you don't mind post processing after an update, then by all means the additions to the paths file are not needed. If you want the convenience of being able to install an update and get straight back to work, then you do need them.

BTW, CapitanPikeFix does not yet repair the paths file. I must remember to chat with 666sheep to see if he wants to modify it.

For now, if you want the "full" convenience, I would recommend using my Boot64.v2 tool.

Thanks for replying so quickly!

Ah I see, so by exempting the path file your tool is able to correct any changes made by the Apple Installer.

In terms of the post processing you mean after applying an Apple update I would need to boot the Recovery Drive and manually copy the boot.efi file to the required locations?

I will take a look at your Boot64.v2 tool.

Out of curiosity could your tool / CapitanPikeFix be expanded to do a hash check of the paths file? Seems like the file should only be what Apple includes in it plus the three lines added to support the old macs. If that hash differed it could alert / send an email? I know this might seem like overkill but it is security professional in me nagging.

 

[rthpjm]

Thanks for replying so quickly!

Ah I see, so by exempting the path file your tool is able to correct any changes made by the Apple Installer.

In terms of the post processing you mean after applying an Apple update I would need to boot the Recovery Drive and manually copy the boot.efi file to the required locations?

I will take a look at your Boot64.v2 tool.

Out of curiosity could your tool / CapitanPikeFix be expanded to do a hash check of the paths file? Seems like the file should only be what Apple includes in it plus the three lines added to support the old macs. If that hash differed it could alert / send an email? I know this might seem like overkill but it is security professional in me nagging.

I don't think I will necessarily do it. I am content with it as it stands.

That said, you can take a look at the script and make any modifications you deem fit for your purpose. You will see that the script already does something similar for the boot.efi files. I encourage you to have a go, please do modify...

I come back to the risk analysis. For me SIP adds protection, even if "we" lessen it slightly. Let us think about the attack vector for a minute...

Malicious code would need to be downloaded. I have "open safe files after download" turned off. I must then choose to run the downloaded file. The app must then elevate privileges, typically by prompting (yes I know it could try to exploit known or undisclosed vulnerabilities to gain root access). I've done some code development in this area so I know that Apple has tightened up on code privilege escalation. A privileged helper tool needs to be installed by a signed app. This means malicious code is quickly stopped from spreading once identified since Apple can revoke the signing certificate. SIP is enabled and largely counters root-privilege attack vector.

We have chosen to make the boot.efi files replaceable, but Boot64 or CapitanPikeFix will detect a change and perform the repair/replace. I guess the way I've implemented Boot64 for the paths file could be strengthened, but for the changes to have an effect a reboot would be required. Yes the Boot64 toolset could be a weak point but I can live with that.

Ultimately it is the choice of the user. If security is more important than convenience, then choose not to install the automation tools

 

[Sandleford]

I downloaded the el capitan boot.efi from pikes page but not getting the checker to work. It says to put :

openssl md5 boot.efi = 036476dc081da904f50736eb56acbcfa

Into a terminal but I get get: "no such file or directory" No matter changing to that directory or using the files path

 

[mossman1120]

I downloaded the el capitan boot.efi from pikes page but not getting the checker to work. It says to put :

openssl md5 boot.efi = 036476dc081da904f50736eb56acbcfa

Into a terminal but I get get: "no such file or directory" No matter changing to that directory or using the files path

You need to make sure that you are in the same directly as that file in order for the command to work. Might I suggest you try this, in terminal type the following: openssl md5 boot.efi then press the space bar to ensure you have at least one space after the "i". Next drag the boot.efi file and drop it on the the terminal window. This will put the full path to the file. Next press enter.

 

[iMattux]

Mac terminal for noobs: Drag & drop works

 

[mossman1120]

Mac terminal for noobs: Drag & drop works

We all have to start somewhere

 

[Sandleford]

Tried your suggestion and it still said "no such file or directory" but it did show the checker and its good.

Thank you

Had been trying use the el capitan boot.efi anyway and was getting a crash every 2 minutes. Was worse if trying to use the app store updates. Maybe the 12 gb ram min is still needed for now? anyway went back to yose and its good for now I guess.

 

[mossman1120]

Tried your suggestion and it still said "no such file or directory" but it did show the checker and its good.

Thank you

Had been trying use the el capitan boot.efi anyway and was getting a crash every 2 minutes. Was worse if trying to use the app store updates. Maybe the 12 gb ram min is still needed for now? anyway went back to yose and its good for now I guess.

Sorry to hear that didn't work. If you wouldn't mind sharing can you copy and paste the whole line you are trying to run in Terminal?

 

[Sandleford]

openssl md5 boot.efi /Users/lysanderlenihan/Downloads/boot.efi

boot.efi: No such file or directory

MD5(/Users/lysanderlenihan/Downloads/boot.efi)= 036476dc081da904f50736eb56acbcfa

 

[Sandleford]

so worked but not sure what error is

no openssl probably...

10.10.5 runs quite good just a bit disappointed going through install and have failure

 

[cbiker]

Yes Got it working You Guys Rock Thanks