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

[jeanlain]

10.11.2 is out. Does it replace boot.efi?

 

[JOSECBA]

10.11.2 is out. Is safe to do it ?

 

[gw463]

10.11.2 is out. Is safe to do it ?

Download now ....... finger cross.......

 

[JOSECBA]

Download now ....... finger cross.......

GOOOOODDDD LUCK !!!!! I waiting for your test.....

 

[jeanlain]

FWIW, I don't see "boot.efi" in the "core services" location in the installer package of 10.11.2 delta.

EDIT: it is however present in /usr/sbin/standalone/i386

 

[Roland L]

When the 2x boot.efi are replaced by v3.1 counterparts in the resulting USB image generated by the vanilla createinstallmedia then the image boots successfully. Disk Utility, for example, works. All good so far.

However the main El Capitan installer does not, suggesting that v3.1 does not fully patch for 1,1 machines. Maybe it's the Board IDs in the platformSupportValues field in OSInstall.mpkg or the InstallableMachines.plist or PlatformSupport.plist files? I thought v3.1 took care of the Model Identifier?

(In the Yosemite installer I had modified all three, but then I was using an earlier version of Piker's boot.efi so knew I needed to.)

 

[the bug]

I just downloaded the combo update to run on the rest of the machines in the house, has anybody run the combo updater on a 1,1/2,1 pike-ified machine ?

I also saw that only the /u/s/i386 boot.efi is the only one present in the combo update .dmg.
Was going to back up then give it a shot, but wanted to see if some other brave souls have gone first .

- Jay

 

[rthpjm]

I installed 10.11.2. I was brave and jumped straight in!

The install went okay.

The reboot did not!!!

The machine rebooted into my Recovery partition. I manually replaced the boot.efi files on my main partition whilst still in the Recovery boot.

Rebooted okay into my main ElC partition.

The 10.11.2 update overwrites both boot.efi files, and it also overwrites the paths file (SIP exclusions).

I checked my logs and I have entries from my Boot64 Launch Daemon saying it spotted the change and replaced the boot.efi, but it seems the the update has worked around the launch daemon somehow and put the Apple ones back again. I'll take a look and see if I can figure out how it's done that...

From where I'm sitting, a post-install manual intervention is required at the moment.... I've been messing around with my installations so much, it could be just that my system wasn't in a good state.

I'll try again with one of my spare disks that is currently at vanilla 10.11.1 and report back.

 

[gw463]

Confirm after update replace two boot.efi and now run fine wow..........

 

[Ih8reno]

Did anyone try with the fix that was posted before?

 

[OGNerd]

Confirm after update replace two boot.efi and now run fine wow..........

I can also confirm this, but I noticed that a Recovery Update was offered from the MAS for my natively supported machine, but NOT for my Mac Pro 2,1.

Edit: The Recovery Update was installed even though it was not shown as an available selection in the MAS.

 

[rthpjm]

It's late.....
I'm tired.....
I've probably jumped to all sorts of inaccurate assumptions!

My previous posts about using Boot64 or CapitanPikeFix (after modifying the SIP exclusion file) are redundant for 10.11.2.

Sorry folks. It looks like 10.11.1 must have updated the system_installd, which now has its own version of SIP. So when the installer takes over, SIP is effectively reset and re-enabled. This will stop Boot64 or CapitanPikeFix from replacing the Apple boot.efi files automatically. We will have to do it manually for now...

Dec  8 23:52:14 admins-Mac-Pro system_installd[483]: rootless_apply: unrestricted file at /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager-SystemSoftware/543E6EEC-F966-4F54-8650-F7C86DB3A2CC.activeSandbox/Root/System/DeferredInstall/Root
Dec  8 23:53:02 admins-Mac-Pro com.apple.xpc.launchd[1] (com.apple.rootless.init): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

Appears as part of the installer setup

When Boot64 sees the changes to the boot.efi files, it tries to replace them but SIP is back in force...

Dec  8 23:53:07 admins-Mac-Pro.local ensureBoot.sh: Not using the grey boot.efi. Switching over...
cp: /System/Library/CoreServices/boot.efi: Operation not permitted
cp: /usr/standalone/i386/boot.efi: Operation not permitted

It's probably because I hadn't edited the path file after updating to 10.11.1. I'll go check in the morning.

Either way it looks like there's currently a need to boot from another partition after each update to either replace the boot.efi files manually, or to re-edit the path file!

I'm going to go to sleep now...
I'll be more methodical in the morning....

============= sleep, loverly sleep ===========

I have realised that I overlooked a step before I ran the 10.11.2 update. I forgot to re-edit the paths file after the 10.11.1 update. It needed to be re-edited because 10.11.1 overwrites it with the Apple version. My mistake sorry.

But it did get me to thinking.... Maybe I could adapt my Boot64 tools to take care of that too.

I have some good news and some bad news. First the good news. I have adapted both pikify3.1 and Boot64 to take care of the boot.efi files and the paths file. I will upload new versions later, pikify3.1.v5 and Boot64.v2... (done, see post #1390 and post #1391)

I tested them:

• Created an installer using pikify3.1.v5
• Wiped a spare disk
• Installed El Capitan 10.11
• Booted okay into the new disk ( pikify did its thing )
• Installed Boot64.v2
• Upgraded to 10.11.1 using the Apple DMG from Support Downloads
• Booted okay ( Boot64 did its thing )
• Upgraded to 10.11.2 from the App Store
• Booted okay ( Boot64 did its thing a second time )

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?

 

[Ih8reno]

So same old process, manually change them again and we're good?

 

[rthpjm]

So same old process, manually change them again and we're good?

worked for me

 

[charlan7]

No problem to update to 10.11.2 with CapitanPikeFix. After the upgrade, reboot, wait for 5 minutes, shut down the computer, restart and everything is perfect!

 

[rthpjm]

No problem to update to 10.11.2 with CapitanPikeFix. After the upgrade, reboot, wait for 5 minutes, shut down the computer, restart and everything is perfect! View attachment 604489

I haven't used CapitanPikeFix myself. Looks like I'll have to try it

 

[JOSECBA]

Whats the meaning of this (In terminal I wrote this: csrutil status)

System Integrity Protection status: enabled (Custom Configuration).

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

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

 

[OGNerd]

Whats the meaning of this (In terminal I wrote this: csrutil status)

System Integrity Protection status: enabled (Custom Configuration).

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

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

View attachment 604497

It means that you have disabled all user mode aspects of SIP, effectively rendering the machine to Yosemite level system security.

 

[JOSECBA]

I did it, directly from the App Store, but previously I did this:
First I disable de SIP (instructions here)

And after that I did CapitanPikeFix_grey.pkg (I include here too)

And after that I did the update directly from the APP STORE.

And WORKS PERFECT !!!!

Turning Off Rootless System Integrity Protection in OS X El Capitan 10.11 +

Again, the vast majority of Mac users should not disable rootless. Disabling rootless is aimed exclusively at advanced Mac users. Do so at your own risk, this is not specifically recommended.

1. Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot OS X into Recovery Mode
2. When the “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3. Type the following command into the terminal then hit return:
4. csrutil disable
5. You’ll see a message saying that System Integrity Protection has been disabled and the Mac needs to restart for changes to take effect.

 

[JOSECBA]

It means that you have disabled all user mode aspects of SIP, effectively rendering the machine to Yosemite level system security.

Thank you very much...
Do you think that I should TURNING ON (SIP) (after the update to 10.11.2 ) or my Mac Pro will don't boot any more if I did ?

 

[OGNerd]

Thank you very much...
Do you think that I should TURNING ON (SIP) (after the update to 10.11.2 ) or my Mac Pro will don't boot any more if I did ?

It's a matter of personal preference, however I believe that it was the intent of Pike R. Alpha to have SIP enabled after replacement of the stock boot.efi with his was accomplished. I have it enabled, but use the
--without debug argument to allow use of the XtraFinder utility.

 

[Ih8reno]

I had used that captainpikefix and still couldn't update. Went in and 1 of the boot.efi files got changed. Now just swapped them out and the install works...

 

[the bug]

Success here too, I manually swapped out the 2 .efi files and all is good !

Just a reminder too, if you ran the "Recovery Update" that went along with 10.11.2 then you have to change out the recovery partition boot.efi file also.

If you hate typing "diskutil" commands in terminal, (since Disk Utility has been neutered and won't show hidden partitions anymore) try this to mount the recovery partition:

http://www.klieme.com/MountnuoM.html

It hasn't been updated in a while, but still works well in ElCap, it is donation-ware so if you find it useful consider a small donation.

No affiliation with this, just happy that it fills a void from the gutted Disk Utility, and saves me from typing.

- Jay

 

[einhorndg]

Success here too, I manually swapped out the 2 .efi files and all is good !

I installed 10.11.2 from another Capitan-Mac to the MacPro 1,1 SSD, swapped the files

show all files,

(in CoreServices I first deleted the boot.efi with Terminal:

sudo rm -r <space> drag and drop old boot.efi to Terminal window,

Password, confirm what you are doing)

then copied PikerAlphas boot.efi to System/Library/CoreServices and usr/standalone/i386

Repairing with KextUtility -

-ready...

 

[jt_69.V]

Success here too, I manually swapped out the 2 .efi files and all is good !

Just a reminder too, if you ran the "Recovery Update" that went along with 10.11.2 then you have to change out the recovery partition boot.efi file also.
- Jay

There are two boot.efi files in the Recovery partition:

./com.apple.recovery.boot/boot.efi
./System/Library/CoreServices/boot.efi

Do we need to replace both ?

Thanks
Jean