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

[DeltaMac]

"Recognizing a system disk" is not the same as "boots successfully"
Your Mac tries to boot from D1. Something in the boot process (testing the drive, usually), and the hardware tries the boot another couple of times, testing the "boot blocks", etc. Your D1 boot drive is not passing that part of the POST , and the hardware shuts off.
D1 is not passing boot tests, despite D1 showing as a bootable disk. The drive is simply failing.
So, shutdown at boot is your clue to copy off anything from D1 that is not already backed up, and swap that drive out.
You could try a reinstall of whatever macOS system is booting that drive, which will reload the system files, making a "freshened" system. Might help, but if the drive is failing enough to shut off your Mac, then I suspect that the reinstall will not be successful. But no harm in trying that -- just don't be surprised if the drive still will not boot your Mac.

 

[rthpjm]

Hey

Thanks for the replies.

I erased the system disk (D1) that I wanted to restore and manually copied over the entire disk from the pre-recent dodgy software install state (5 June) from Time Machine. Startup Disk in System Prefs recognises D1 as a system disk.

I have retained a mirror disk (D2) which has the post-recent install state.

I can boot from D2 no problem with either graphics card.

When I boot from D1 the disk starts up and then shuts down around 5 seconds in to the boot process.

I ran Disk Repair for D1 and it made some changes to file system. However when I boot from D1 same issue of shut down 5 seconds in. I suspect that copying over the whole disk from TM has not configured D1 as bootable.

If I boot from D2 I can access D1 no problem and Startup Disk still recognises D1 as a system disk.

So I tried to restore D1 using TM app and over-write my manual file transfer. However, when I open TM (as an internal or external drive) and select 5 June "Recover" is greyed out and all the days' files appear with a red bar on the right.

I have tried to boot from D2 using old graphics card holding down R and Command but the Recovery screen does not come up and it just boots as normal.

I have overwritten the pikify boot file from D2 to D1 in case the boot file on D1 was somehow corrupted.

Any ideas on why D1 is closing down mid startup (given it is recognised as a system disk in Start Up)?

Would copying over the entire disk from June 5 from TM have configured the system properly?

Any help gratefully received.

NC

Hey Nick,

I'm not sure what you mean by "manually copied over the entire disk", but in theory it "should" work for El Capitan. However, you're probably missing some steps too. There's the kernel cache to consider. Whenever Mac OS (of this era) gets a change to the kernel, and/or the kernel extensions (KEXTs), the OS would normally trigger a rebuild of the cache(s). If you MANUALLY copied, there's high probability that the kernel cache is either not present or it's out of step with the binaries.

You say that you can boot into disk2. Do that. Then see if you can rebuild the caches on disk1. Use kextcache from the Terminal command line to try and force a rebuild of the disk1 caches. You'll have to read the man pages for kextcache to figure out how to do this, or do some searching (I don't have a working El Capitan rig to check it out). I would suggest trying...

kextcache -update-volume /Volumes/d1 -volume-root /Volumes/d1

(Change /Volumes/d1 to whatever your D1 is named, also I'm not sure if '-volume-root path' exists as an option in the El Capitan era kextcache command!)

OR you can try the simpler method of...

touch /Volumes/d1/System/Library/Extensions

The other issue might be that you have allowed the D1 to update with Security Update 2018-001 (or higher). These later security updates broke everything, and the community didn't find a way to fix it. These later security updates included a new kernel file which was incompatible with the Pike versions of boot.efi. It causes a boot loop (almost immediate crash/reboot). There is a hacky roll-back procedure see my profile signature...

Finally, If you can boot into a recovery partition now, it might be quicker to do that, use Recovery's Disk Utility to format your D1 volume for a clean start, and then use Recovery's "from Time Machine" option, targeting D1 as the destination...

 

[Nick Cox]

Hey

Thanks for the replies.

I erased the system disk (D1) that I wanted to restore and manually copied over the entire disk from the pre-recent dodgy software install state (5 June) from Time Machine. Startup Disk in System Prefs recognises D1 as a system disk.

I have retained a mirror disk (D2) which has the post-recent install state.

I can boot from D2 no problem with either graphics card.

When I boot from D1 the disk starts up and then shuts down around 5 seconds in to the boot process.

I ran Disk Repair for D1 and it made some changes to file system. However when I boot from D1 same issue of shut down 5 seconds in. I suspect that copying over the whole disk from TM has not configured D1 as bootable.

If I boot from D2 I can access D1 no problem and Startup Disk still recognises D1 as a system disk.

So I tried to restore D1 using TM app and over-write my manual file transfer. However, when I open TM (as an internal or external drive) and select 5 June "Recover" is greyed out and all the days' files appear with a red bar on the right.

I have tried to boot from D2 using old graphics card holding down R and Command but the Recovery screen does not come up and it just boots as normal.

I have overwritten the pikify boot file from D2 to D1 in case the boot file on D1 was somehow corrupted.

Any ideas on why D1 is closing down mid startup (given it is recognised as a system disk in Start Up)?

Would copying over the entire disk from June 5 from TM have configured the system properly?

Any help gratefully received.

NC

Problem solved. I weeded out dodgy install. Although still would like to know why Time Machine is greyed out if anyone knows why.

 

[tnbriggs]

Thanks for the confirmation. At least I'm not alone. I did submit a ticket to WD but doubt I'll get anything worthwhile from them.

On a separate note, but unrelated to this El Cap conflict, I think, I also had a 1TB WD MyBook (bought about 2008) which failed about 7 months or so ago, but the drive inside (3.5" form factor) turned out to be ok, was just the MyBook enclosure chipset which had failed. I removed it and put it in a different external drive case (an OWC model) and it works fine there, connected with Firewire 800, on the MacPro 1,1.

Update to this issue. After a couple of months of exchanging emails and a couple of voicemail messages with WD support, their official position is that they don't support what Apple doesn't support. Since ElCap is no longer supported by Apple, if their software creates problems or issues that's too bad for you, but it's your fault. I've had a heckuva lot of WD disks over the years but think I'll be using someone else's stuff now. I bought a 4TB Seagate Expansion to recovery the files from the reformatted 4TB WD Elements drive. Seems ok and came with a recovery coupon from Seagate if it goes bad.

So the conclusion is:
If you've got any WD software anywhere on a system that isn't currently supported by Apple you should remove it.

 

[LuckyOldMan]

@rthpjm

At the weekend I had to reinstall my Yos & EC (10.11.6) that I set up in 2016 due to an HDD defect. Both OS are running again.
At EC I know to avoid security update 2018-001 due to kernel crash/bootloop. It's not offered to me either. Does this also apply to update 2018-004 (as I suspect). that is offered to me?
2017-005 was approved as permissible, but is a security update even important for 10.11.6?

 

[rthpjm]

@rthpjm

At the weekend I had to reinstall my Yos & EC (10.11.6) that I set up in 2016 due to an HDD defect. Both OS are running again.
At EC I know to avoid security update 2018-001 due to kernel crash/bootloop. It's not offered to me either. Does this also apply to update 2018-004 (as I suspect). that is offered to me?
2017-005 was approved as permissible, but is a security update even important for 10.11.6?

Yes, Sec Updates released after 2018-001 will all have the “new-incompatible“ kernel. My advice? Don’t go beyond the 2017-005 update.

 

[rthpjm]

Yes, Sec Updates released after 2018-001 will all have the “new-incompatible“ kernel. My advice? Don’t go beyond the 2017-005 update.

Whilst I enjoyed being a part of the community that kept the classic MacPros alive, there does come a point where one has to retire the combination. For me it’s in the attic. I moved on and joined the Hackintosh crowd (specifically, the Ryzentosh AMD style). Running a Ryzentosh IS A LOT OF WORK, even though OpenCore is a fantastic project.

I’m now considering the jump back to Apple products, but I’ll probably wait to see what the MacMini with an M3 looks and feels like!

 

[EugW]

Whilst I enjoyed being a part of the community that kept the classic MacPros alive, there does come a point where one has to retire the combination. For me it’s in the attic. I moved on and joined the Hackintosh crowd (specifically, the Ryzentosh AMD style). Running a Ryzentosh IS A LOT OF WORK, even though OpenCore is a fantastic project.

I’m now considering the jump back to Apple products, but I’ll probably wait to see what the MacMini with an M3 looks and feels like!

Yeah I got annoyed with the work involved and idiosyncracies with running newer OSes on unsupported machines. So, I went to a used 2014 Mac mini temporarily from 2021-2022, and then to a used M1 Mac mini in 2022 and it’s been great. My main beef with it is that it only has 2 TB/USB-C ports (one taken up by my monitor) and 2 USB-A ports, so when it comes time to upgrade, I may get an Mx Pro Mac mini with more ports. An M4 Pro Mac mini in 2025 sounds good…

 

[tnbriggs]

El Cap EFI hack won't run.

Had a kernel panic on waking from sleep on Mac Pro 1,1 running hacked El Capitan (modified EFI to boot on 32 bit EFI); likely because of more failed OWC ram - don't think I'll use their lifetime warranty replacements this time. Machine boots to ElCap login screen & I can enter my user accout password but then it never loads any farther. Just the spinning gear like its loading, but it doesn’t and then it reboots and reboots and reboots, etc, etc, etc. Same for the other two user accounts on the machine. Booted to the ElCap 10.11 recovery partition and ran repair disk, no change. PRAM reset, then SMC reset with no change, although after the SMC reset it actually loaded my desktop but then rebooted again. Started in safe boot, still no change. Started in single-user mode, deleted sleep image file, still no change. Boots ok into Lion, Windows 10 & Windows 7. Thinking of copying my user files for the ElCap disk to a backup drive and reinstalling the EFI hacked ElCap from scratch.

Are there any other easier things to try before I start this laborious process?

Thanks.

 

[EpilepticGerbil]

testing the edit (little rusty ya know)🤨

 

[tnbriggs]

Bit the bullet and did the El Cap reinstall.

Totally fresh restore of El Cap disk image onto the old hard disk and with no migration of user data or apps from Lion. But when trying to set up the El Cap users the machine would hang on keyboard and/or mouse inputs and then reboot. Finally got a user set up but the reboots persist. Tried different keyboards, different mice (wired & wireless) different USB ports, still unreliable. And occasionally it’ll just reboot with no user inputs (mice or keyboard) at all. No such problems whatsoever in Lion on the same machine with the same keyboard and mouse, so it must be related to the hack of El Cap.

This one is going to take a while to figure out.

PS. Since 12 GB of RAM failed & I now have only 3GB in it (more is on the way) I'm wondering if the current weirdness could be related to lack of RAM. But if that's the case, why is Lion working ok? Curiouser and curiouser.

 

[tnbriggs]

Been through many of the pages here and can’t find this subject specifically addressed. Not sure anyone will know the answer to this but I’ll ask it anyway.

If Apple says the original El Capitan only needs 2 gb of ram to run, why does the modified version need at least 16 gb of ram to run, as many of the threads on this subject suggest. Is there an overlay instruction set on top of the source code? Once the code is exeuted past the EFI boot changes, is the rest of the code identfical to Apple’s original or has it been changed? My sense from what I’ve read is that it is the same code that was issued by Apple. If so, why the added ram requirements?

 

[DeltaMac]

Maybe you are confusing RAM with storage space?
The system needs a minimum 16 GB of available disk space to install, but will run on 2GB of RAM
A 2011 MBAir might have only 2GB of RAM (not upgradable, of course), but the standard storage space (SSD) was 128GB.
So, you would need at least 16GB of space available to install El Capitan, but the MBAir would run on the 2GB of installed RAM. (not happily, and you would likely not like the performance on only 2GB.)

 

[tnbriggs]

Thanks for the reply.

Not confusing installed ram with storage. Have plenty of storage and EFI hacked El Cap is installed, occupying just 15 gb on a 1 tb platter hard drive, but not capable of running on the 3 gb of installed ram (2x512 gb sticks — Apple original in the machine & 2x1gb sticks from DMS installed years ago). Kernel panics and then dies & reboots after login to user account. Lots of posts in this thread indicating low ram as a cause of problems and recommendations for at least 16 gb installed with no 512s or 1s. I’ve got replacement ram on its way to me and hopefully that will solve the problem. Had no issues when I had 15gb ram installed but 12gb of it failed a week or so ago.

Just curious if anyone knew why the hacked EFI ElCap on the 1,1 needed more ram to run that stated by Apple.

 

[rthpjm]

Thanks for the reply.

Not confusing installed ram with storage. Have plenty of storage and EFI hacked El Cap is installed, occupying just 15 gb on a 1 tb platter hard drive, but not capable of running on the 3 gb of installed ram (2x512 gb sticks — Apple original in the machine & 2x1gb sticks from DMS installed years ago). Kernel panics and then dies & reboots after login to user account. Lots of posts in this thread indicating low ram as a cause of problems and recommendations for at least 16 gb installed with no 512s or 1s. I’ve got replacement ram on its way to me and hopefully that will solve the problem. Had no issues when I had 15gb ram installed but 12gb of it failed a week or so ago.

Just curious if anyone knew why the hacked EFI ElCap on the 1,1 needed more ram to run that stated by Apple.

The installation media has a number of compressed (in Windows terminology “zipped”) files. These files need to be unpacked (decompressed) during the installation. One of these files is over 10Gb when it is unpacked.

When we built the Pikify toolset, we used Apple’s “createinstallmedia” tool. This creates install media that you initially boot from (before El Capitan is offered for install). When the machine is initially booted from this installation media, it effectively creates RAM disks, and runs the install environment from these RAM disks.

Apple does it this way so that all of the directly attached disks are “not in use” and are therefore all available as targets for the installation process.

So, we’re in a RAM-disk-based install environment and we choose to install onto our internal HDD. BUT…

The install media needs to unpack the large files. It unpacks them to the RAM disk before it can then copy them to the HDD. To unpack the large file (>10Gb) the RAM environment needs to be large enough for the installer software AND the large unpacked files.

THAT is why we say 12Gb of RAM (or more).

Once you have a successful installation on your HDD, then Mac OS El Capitan “can” run with just 2Gb of system RAM. Therefore you “could” remove the extra RAM but we wouldn’t recommend doing so. El Capitan runs better with more RAM. If you’ve gone to the trouble of getting your hands on the 12GB (or more) of RAM in order to utilise the Pikify tool(s) then why wouldn’t you keep the RAM installed for daily operation?

(I suppose you might have borrowed some RAM and need to give it back, but again 4 or 8GB would be recommended so why not do your best to buy/keep the RAM you’ve got?!)

There was probably a method of setting up the installer environment to use a hybrid of RAM disk and HDD such that the unpacking phase was done on a HDD rather than a RAM-disk, but we never figured it out. Most users seemed content to buy additional RAM so we left it there…


Also, I note that you say you’re using 3Gb of RAM. If you have read through all the posts in this forum thread (a daunting task I know), you will find many, many users who’ve also tried to run with the original 512Mb RAM sticks in the mix. In ALL of these reported cases, El Capitan was unstable in the same manner you describe. In ALL cases we recommend removing/replacing the 512Mb sticks. If replacing, use 2Gb sticks or higher.

In ALL cases where users ditched the 512s, and replaced with 2Gb pairs (or indeed 4Gb pairs), they all reported back that their systems became rock-steady.

We don’t know why!

We speculate that when Apple dropped the original classic MacPros (and other hardware), that freed them to “tune” the kernel with the expectation of a minimum of 2Gb RAM sticks. But I repeat, we don’t know! My guess would be that clib malloc is expecting to be able to grab contiguous memory regions larger that 512Mb (or even 1Gb - 2Gb), but the hardware memory controller will interrupt and Mac OS will struggle when it hits a 512Mb physical boundary, and that causes the panic. No proof! Just speculation.

 

[tnbriggs]

Thanks for the explanation. Some of it is over my head, but I think I've got the gist of it.

My recent issues were related to ram failure on my machine. It was running with 15gb installed, 2x512s Apple originals, 2x1s from DMS, and 2x2s & 2x4s from OWC. The 2x2s from OWC were the second set; one had failed before. Both the 2x2s & 2x4's reported by profiler were indicated as failed. Sent them back to OWC who tested & told me that the 2x4s were ok but sent me replacements for them as well as the failed 2x2s.

On my setup, I continued to have the no-run/kp issues with the 3gb of installed ram which was left after the ram failure. El Cap was installed, it just would not run at all on that 3gb ram. Once I got the replacement ram (12gb) installed to provide a total of 15gb ram (same as before the ram failure) it ran fine & I was able to migrate my settings from the Lion install on another hard disk. Now running as well as before, and this ram doesn't create the high speed fan issues that the failed ram did. I think OWC sent me incorrect ram (2x2s) when they replaced it before.

I noticed the complaints about the 512s & 1s in my reading the thread & thought they were perhaps the culprit but decided to leave them in & see what happened when I added the 12gb. Still have 2x512s & 2x1s installed and see no problems but if it starts to show quirkiness I will likely replace with a couple of 2x4s, although they are getting tougher to find; the 2x2s are even rarer.

Thanks much to you and all the others who have invested their brains, time and efforts in enabling us to still be able to use these old, but trustworthy and capable machines.

 

[porcupin19]

Trying to upgrade an old MacPro 1,1 to be semi-functional with MacOS El Capitan and running into a snag with the pikify V14 script.

After downloading MacOS El Capitan .dmg from Apple website here, I have modified the .pkg file to allow it to run and successfully install the "Install OS X El Capitan" app in the applications folder (followed the instructions provided here). From there, I run the Pikify script as instruction in earlier post here, but encounter the error pictured below. System specs also posted below for reference - the MacPro 1,1 firmware was updated previously so it shows as MacPro 2,1.

I've completed this process twice with fresh downloads of the installer .dmg file from the Apple website. Same result.

Any ideas why this is occurring and how to proceed with the installation?

Thanks in advance!

 

[tnbriggs]

Can't help you with your pikify script issues but there is another alternative to it. It's doing a disk restore in Disk Utility from a El Cap .dmg file that has already been modified to include all the necessary items for the El Capitan hack to run. You can search this thread for the specifics on it & I know there are those who think it is not the best way to do it but it has worked for several, including me. See this link on YouTube.

 

[rthpjm]

Trying to upgrade an old MacPro 1,1 to be semi-functional with MacOS El Capitan and running into a snag with the pikify V14 script.

After downloading MacOS El Capitan .dmg from Apple website here, I have modified the .pkg file to allow it to run and successfully install the "Install OS X El Capitan" app in the applications folder (followed the instructions provided here). From there, I run the Pikify script as instruction in earlier post here, but encounter the error pictured below. System specs also posted below for reference - the MacPro 1,1 firmware was updated previously so it shows as MacPro 2,1.

I've completed this process twice with fresh downloads of the installer .dmg file from the Apple website. Same result.

Any ideas why this is occurring and how to proceed with the installation?

View attachment 2320312

View attachment 2320311
Thanks in advance!

When you download the DMG from the Apple site, you are downloading an installer that “installs the installer”. It’s a bit weird, but that’s the way Apple does it.

Firstly, you should remove any copy of “Install Mac OS El Capitan” from the Applications folder. (Or rename them).

Open the DMG that you downloaded from the Apple web site, then run the package directly from there (double-click the package). This installation will decompress the “Install Mac OS El Capitan” app and put the “real” installer into your Applications folder.

Once that’s done you should be good to go with the Pikify script (or App).

There’s no need to “modify” the installer from the DMG…

 

[rthpjm]

When you download the DMG from the Apple site, you are downloading an installer that “installs the installer”. It’s a bit weird, but that’s the way Apple does it.

Firstly, you should remove any copy of “Install Mac OS El Capitan” from the Applications folder. (Or rename them).

Open the DMG that you downloaded from the Apple web site, then run the package directly from there (double-click the package). This installation will decompress the “Install Mac OS El Capitan” app and put the “real” installer into your Applications folder.

Once that’s done you should be good to go with the Pikify script (or App).

There’s no need to “modify” the installer from the DMG…

Apologies.

I forgot to say that the DMG-package installer will not launch on any model of MacPro newer than the MacPro6,1 trashcan Mac. For example, I just tried with a MacPro7,1 (return of the cheese grater design) and the package will not install. This is because El Capitan is supported up to and including the 6,1, but no further.

You might need to modify the package to allow it to launch on a newer machine model.

As mentioned by @porcupin19 follow the instructions he/she/they linked to for a way to modify the DMG-package.

The process then becomes:

1. Download the DMG from the Apple Support web site
2. double-click the DMG to open it
3. Open a Terminal
4. Follow the linked instructions
5. Go to your Downloads folder
6. You should see a modified package (ElCapModified.pkg).
7. Double-click ElCapModified.pkg to "install the Installer"
8. Now go to your Applications folder, you should see the App called "Install OS X El Capitan"
9. If you've performed the previous steps on a computer other than the MacPro 1,1 or 2,1, then copy the "Install OS X El Capitan" App from here to the Applications folder on your 1,1 (2,1) machine
10. Finally run the pikify script (or App) on your 1,1 (2,1) machine

 

[KestiriX]

hi, ive seen people getting 7300 or other older cards working PROPERLY under el captian for example this video (

)
1. can i do this on existing instalation of el capitan.
2. if not, can someone give me link how do i get el capitan.app on unsupported mac under lion

 

[Nguyen Duc Hieu]

Can't help you with your pikify script issues but there is another alternative to it. It's doing a disk restore in Disk Utility from a El Cap .dmg file that has already been modified to include all the necessary items for the El Capitan hack to run. You can search this thread for the specifics on it & I know there are those who think it is not the best way to do it but it has worked for several, including me. See this link on YouTube.

This solution worked for me like a charm.
No need to search for the El Capital app.
No need to create a USB installer.
No need to wait for the system to unzip and copy the file from the slow USB ports.

Just download the disk image file and restore it to a blank new disk.
I could do it all from my Mac Pro 1,1, 7300GT with OS X Lion.

For me this is perfect.

 

[flygbuss]

Anyone with an idea how to keep watching netflix on 10.11?
Seems like a DRM issue and wants to update the browser, but none of the major ones still support 10.11?

 

[EugW]

Anyone with an idea how to keep watching netflix on 10.11?
Seems like a DRM issue and wants to update the browser, but none of the major ones still support 10.11?

Does Netflix not work? Their website claims it should work on OS X 10.11, as long as you have the right browser and browser version installed.

Netflix supported browsers and system requirements

You can use Netflix on Windows 8 or later, macOS 10.15 or later, Chrome OS version 76 or later, and iPads with iPadOS 16 or later using Safari, and some Linux computers.

help.netflix.com

That said, I've personally retired all machines that can't support OS X 10.13 High Sierra or later.

 

[flygbuss]

Does Netflix not work? Their website claims it should work on OS X 10.11, as long as you have the right browser and browser version installed.

Netflix supported browsers and system requirements

You can use Netflix on Windows 8 or later, macOS 10.15 or later, Chrome OS version 76 or later, and iPads with iPadOS 16 or later using Safari, and some Linux computers.

help.netflix.com

That said, I've personally retired all machines that can't support OS X 10.13 High Sierra or later.

Yeah the support document is confusing but it just stopped working. I tried Firefox, Brave, Opera, Chrome..
Preview works but as soon as one wants to play actual content it shows just an error screen demanding to update the browser.
I think I’m just a bit disappointed. I know the machine is like super old but still capable, so it would be a waste to retire it over this.
I have long moved on to newer Macs but the 1,1 is still serving as a Time Machine Server and to watch some Netflix from time to time.