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

[Postalk]

I have just installed El Capitan on my Mac Pro 1,1! Thank you all very much.

The only problem I ran into was that after I started the install, it booted into my windows 10 boot camp partition, where I then used Mac drive to replace the boot.efi files again and then restarted in OSX to continue installation and voila! Success!

 

[MacVidCards]

ok thanks.

My problem is that I am running a non Apple GPU (ATI 5770) and so I can't boot into the recovery drive as I can't see the boot screen. My main boot drive is an SSD in the optical bay so a pain to remove.

I think that the safest way for me to proceed would be as follows

clone the internal SSD onto a USB HD
boot from this and update it
When the mac fails to restart (because the Efi's have been swapped), disconnect the USB and restart it so the mac will boot from the previous version on the SSD
Then reconnect the USB drive and swap the boot Efi files
reboot from the USB drive and clone it back to the SSD
then reboot from the SSD!

Does that sound like a reasonable plan?

If I have another working system (i.e. 10.11.0 with the modified EFi's) on another hard drive in my Mac Pro will the machine after failing to boot from the newly updated 10.11.1 try to boot from one of those? or will it just hang?

This is getting to be a pain!

Thanks


Robin

Or just keep a separate HD or partition with a simple earlier OS install to work from.

People tent to forget that you can have MANY boot volumes in a Mac Pro. There are 6 SATA ports and 2 PATA. Any old HD can be tossed in and used.

 

[rkanaga]

Or just keep a separate HD or partition with a simple earlier OS install to work from.

People tent to forget that you can have MANY boot volumes in a Mac Pro. There are 6 SATA ports and 2 PATA. Any old HD can be tossed in and used.

Thanks, my only issue is that since I have a non Apple GPU I can't access the recovery screen so I need to be sure the Mac will auto boot into a working OS if the chosen volume either is not there or is faulty!

 

[roneyg]

ok thanks.

My problem is that I am running a non Apple GPU (ATI 5770) and so I can't boot into the recovery drive as I can't see the boot screen. My main boot drive is an SSD in the optical bay so a pain to remove.

I think that the safest way for me to proceed would be as follows

clone the internal SSD onto a USB HD
boot from this and update it
When the mac fails to restart (because the Efi's have been swapped), disconnect the USB and restart it so the mac will boot from the previous version on the SSD
Then reconnect the USB drive and swap the boot Efi files
reboot from the USB drive and clone it back to the SSD
then reboot from the SSD!

Does that sound like a reasonable plan?

If I have another working system (i.e. 10.11.0 with the modified EFi's) on another hard drive in my Mac Pro will the machine after failing to boot from the newly updated 10.11.1 try to boot from one of those? or will it just hang?

This is getting to be a pain!

Thanks


Robin

My solution: any bootable OS X on one of the internal drives. When the system drive (SSD in the optical bay failed to boot, the machine automatically booted from the other drive. From there I swapped the two boot.efis on the SSD, rebooted, and here we are.

Had some trouble unlocking the efi in /S/L/C. It may be trivial for most here, I figured it out with some googling:
- on the target drive, navigate in Finder to /System/Library/CoreServices
- open Terminal, type "sudo chflags nouchg " (space at the and, no quotes, no enter yet)
- drag the locked boot.efi onto the terminal window -> will complete the command with the file path
- hit enter -> boot.efi is unlocked
- replace the efi with the patched one by drag&drop, lock it in the Get Info window in Finder
- make invisible files visible (defaults write com.apple.finder AppleShowAllFiles YES)
- navigate in Finder to usr/standalone/i386, replace boot.efi by drag&drop in Finder
- make sure system drive is set as startup volume, reboot
Worked for me, good luck!

 

[OGNerd]

ok thanks.

My problem is that I am running a non Apple GPU (ATI 5770) and so I can't boot into the recovery drive as I can't see the boot screen. My main boot drive is an SSD in the optical bay so a pain to remove.

I think that the safest way for me to proceed would be as follows

clone the internal SSD onto a USB HD
boot from this and update it
When the mac fails to restart (because the Efi's have been swapped), disconnect the USB and restart it so the mac will boot from the previous version on the SSD
Then reconnect the USB drive and swap the boot Efi files
reboot from the USB drive and clone it back to the SSD
then reboot from the SSD!

Does that sound like a reasonable plan?

If I have another working system (i.e. 10.11.0 with the modified EFi's) on another hard drive in my Mac Pro will the machine after failing to boot from the newly updated 10.11.1 try to boot from one of those? or will it just hang?

This is getting to be a pain!

That is essentially what I did to finally get the update accomplished, except my El Cap clone partition and SSD are all internal.

It was a bizarre journey to say the least - Initially I could not unlock the newly installed boot.efi from either my backup El Capitan partition or a Yosemite partition so that I could replace it with Pike's. Fortunately, I also have Mavericks installed, and was able to do so from it. Upon restarting the machine, I received immediate kernel panics related to some I/O function. I pulled a recently installed USB 3.0 card without result. Just for the heck of it, I booted into the Recovery HD, ran First-Aid on the El Cap drive, re-enabled SIP (which I had previously disabled in an attempt to unlock the boot.efi in /System/Library/CoreServices), put the USB card back in, and rebooted. Presto! The machine restarted to complete the update. I had evidently jumped the gun in replacing the boot.efi files.

 

[HD Boy]

I have just installed El Capitan on my Mac Pro 1,1! Thank you all very much.

The only problem I ran into was that after I started the install, it booted into my windows 10 boot camp partition, where I then used Mac drive to replace the boot.efi files again and then restarted in OSX to continue installation and voila! Success!

Did you install 10.11 or 10.11.1, which is out today?

 

[Postalk]

Did you install 10.11 or 10.11.1, which is out today?

10.11.1

 

[andyyau]

Upgrade from 10.11.0 to 10.11.1:
1. in App Store, run the upgrade
2. restart, it will automatically start in Recovery (don't know why), the boot.efi is not modified after the upgrade
3. replace the two boot.efi
4. restart, and it is in 10.11.1

ps: I am using boot.efi v3.

 

[JOSECBA]

It's safe to upgrade to 10.11.1 AFTER install EL CAPITAN. I'm already running EL CAPITAN in my MAC PRO 1.1. and works perfect. It's was installed (in another MAC with external USB case for de SSD HD that I use on my MAC PRO) using this method:

Then, after installation, copy Pike's EFI32 boot.efi to that drive's /usr/standalone/i386 and /System/Library/CoreServices/ directories overwriting the stock Apple EFI64 boot.efi and repair permissions.

Now I want to know that IT IS SAFE to do the APP STORE UPDATE to 10.11.1. .

THANK YOU.

 

[OGNerd]

Its safe to upgrade to 10.11.1 after install EL CAPITAN with this method:

Then, after installation, copy Pike's EFI32 boot.efi to that drive's /usr/standalone/i386 and /System/Library/CoreServices/ directories overwriting the stock Apple EFI64 boot.efi and repair permissions. That drive should now be bootable on a 2006/2007 Mac Pro, although sometimes it still may need to be blessed in the 2006/2007 Mac Pro.

Alternatively, adding rootless=0 to com.apple.Boot.plist allows replacing the boot.efi in-place.

[/QUOTE]

Yes, but only the underlined part. You can no longer repair permissions as a distinct function of Disk Utility in El Capitan, and the rootless=0 option was disabled when El Capitan was released to the public.

 

[hwojtek]

Then, after installation, copy Pike's EFI32 boot.efi to that drive's /usr/standalone/i386 and /System/Library/CoreServices/ directories overwriting the stock Apple EFI64 boot.efi and repair permissions.

How exactly do you intend to repair permissions in 10.11?

 

[F1Mac]

2. restart, it will automatically start in Recovery (don't know why), the boot.efi is not modified after the upgrade

...well, because the boot.efi is not replaced in Recovery - so that's the only place where the Mac Pro can boot.

 

[charitytechsupport]

Any news on the pikeyosefix so we could install updates again?

What was the procedure again in the meantime? Install the update first then after rebooting put the Mac in target disk mode and transfer the boot.efi file again?

Is it safe to upgrade to 10.11.1 for the moment?

 

[hwojtek]

5 posts up, number #984

 

[charitytechsupport]

5 posts up, number #984

Oh, sorry, didn't notice that. What about pikeyosefix then?

 

[F1Mac]

Oh, sorry, didn't notice that. What about pikeyosefix then?

There is no El Capitan version at the moment. boot.efi has to be replaced manually.

 

[LaurentR2D2]

I've made a clean install of El Capitan, then immediately the upgrade to 10.11.1. Besides the need to copy back the boot.efi file each time, everything runs perfect. Thank you

 

[Pike R. Alpha]

There is no El Capitan version at the moment. boot.efi has to be replaced manually.

And there won't be one. We're going to do it completely different – let boot.efi handle it (via a kext).

 

[JOSECBA]

How exactly do you intend to repair permissions in 10.11?

Look my post again, thank you.

 

[Razieln64]

It's safe to upgrade to 10.11.1 AFTER install EL CAPITAN. I'm already running EL CAPITAN in my MAC PRO 1.1. and works perfect. It's was installed (in another MAC with external USB case for de SSD HD that I use on my MAC PRO) using this method:

Then, after installation, copy Pike's EFI32 boot.efi to that drive's /usr/standalone/i386 and /System/Library/CoreServices/ directories overwriting the stock Apple EFI64 boot.efi and repair permissions.

Now I want to know that IT IS SAFE to do the APP STORE UPDATE to 10.11.1. .

THANK YOU.

I just updated from the App Store.
It is safe to update but you need to replace both files at the specified locations otherwise after the computer reboots, otherwise it will not work.

To make sure the boot.efi file is copied correctly, I usually delete the original 600Kb boot.efi and copy Pike's EFI32 boot.efi afterwards.

 

[Bruce L]

I think I followed the instructions correctly given by RX2904 on page 24 of this thread. I am trying to access the HD for my Mac Pro which is currently attached via FireWire 800 to my late 2012 Mac Mini running El Capita. I was able to unlock, delete and replace the boot.efi in /System/Library/Coreservices/ without a problem. The issue I have now is that even though the Finder 'sees' this drive I cannot access /usr/standalone/i386/ because it is greyed out in the Finder. Likewise I cannot seem to access it via the terminal even though I am in the Volumes folder. Maybe this is because I have named this hard disc Mac Pro-Macintosh HD. I am guessing this is because Unix does not like the spaces in the volume name. Any help would be appreciated. I spent hours getting this done during my previous install but don't recall exactly I was able to delete and replace the boot.efi in /usr/standalone/i386/.

 

[MacRumourNic]

I think I followed the instructions correctly given by RX2904 on page 24 of this thread. I am trying to access the HD for my Mac Pro which is currently attached via FireWire 800 to my late 2012 Mac Mini running El Capita. I was able to unlock, delete and replace the boot.efi in /System/Library/Coreservices/ without a problem. The issue I have now is that even though the Finder 'sees' this drive I cannot access /usr/standalone/i386/ because it is greyed out in the Finder. Likewise I cannot seem to access it via the terminal even though I am in the Volumes folder. Maybe this is because I have named this hard disc Mac Pro-Macintosh HD. I am guessing this is because Unix does not like the spaces in the volume name. Any help would be appreciated. I spent hours getting this done during my previous install but don't recall exactly I was able to delete and replace the boot.efi in /usr/standalone/i386/.

 

[MacRumourNic]

@Bruce L ... In terminal the path to your HD would be /Volumes/Mac\ Pro-Macintosh\ HD/ note the use of reverse slashes plus the space when needed.

 

[yuser]

I still can't get acceleration for ATI Radeon HD4890 - I used "Easykext Utility" to install the files downloaded from here: http://www.insanelymac.com/forum/files/file/415-qe-ci-exotic-patch/?st=10#commentsStart

Can anybody please help?

Still no luck. What graphic cards do you use in your 1.1 ??

 

[iMattux]

Look my post again, thank you.

Josecba - This is why the Internet is so frustrating. Your post is a copy & paste of outdated instructions and unless you've got some very strange hybrid of El Capitan betas upgraded to the release version:

It is no longer a matter of simply dragging & dropping two files and repairing permissions.

First of all, you can't just drag & drop piker's boot.efi files in place. You can sudo nouchg to delete the old one, but if you check ownership & permissions on the new one, they will not be -rw--r--r- root wheel as they need to be. Your system might boot with the wrong permissions, but - in my experience anyway, it won't be stable.

Second - There is no such thing as "repair permissions" in El Capitan. You can't repair permissions on an El Capitan installation from any version of OS X. The option is simply not available.

So what the hell are you saying? Can you drag and drop critical System files on an SIP system? Does your version of Disk Utility - from any OS - allow you to repair permissions on the El Capitan installation?

If so, please post some screenshots and describe your process in detail.

The current process of replacing the boot.efi files is considerably more involved than a simple drag & drop, repair permissions & reboot.

I read all about it and did a clean install of 10.11 yesterday. If you didn't install, boot into Recovery, disable SIP, reboot into recovery, manually fix permissions with chflags, chmod, chown, chflags, re-enable SIP, and then reboot;

Please explain it to me like I'm five and include some screenshots.

I don't see how you could have done what you say you did, especially the repair permissions part.