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

[rthpjm]

I did as you suggested, and omitted the nvidia part. The Mac Pro 1,1 then booted nicely into El Capitan. So, thank you for your help. If I understand correctly, this method does not alter the Recovery Partition of El Capitan though. Am I correct? That would explain why I couldn't boot into the latter when trying to change the SIP status of the main system.

I went on and performed steps 1-7 described in posting #1391, installing the boot64 tool which is supposed to undo kernel changes induced by Apple updates. The Mac Pro booted and ran stably after all this.

Since my adjusted El Capitan was on 10.11.5, I decided to give it a go and install the 10.11.6 update through the Apple Store. I had read in an earlier posting that everything should go smothly when updating from 10.11.5. Before installing, I checked it didn't say anything about containing a Security Update 2018-xxx.

Well, the installation didn't hang and booting performs fine as well. But when I try to log in, the screen just changes the color for a half a second, then I am presented the same login screen again. I made sure I had typed in the correct passwort, rebooted several times, but no luck! Is it possible, that the current 10.11.6 update also contains kernel changes, which were not present in earlier versions of the same update? Or did I miss something else?

Hello @maruteru

My Boot64 tool only protects the boot.efi files. It does not protect the kernel file.

The kernel downgrade only happened this year. I don’t have the personal incentive to alter Boot64 to protect the kernel file. This is because I personally choose to stay at Mac OS X El Capitan 10.11.6 with all updates up to and including Security Update 2017-005. I choose not to install the 2018 Security Updates because these require the downgrade of the kernel file. The updated kernel file that arrived with Security Update 2018-001 causes the MacPro 1,1 and 2,1 machines to crash at boot. The solution is to overwrite the incompatible kernel file with the last-known-good kernel file from the 2017-005 update. Some users are happy to do this, it works. Personally, as I said earlier, I choose not to do this...

User @alphascorp has regularly reported here that his/her system is stable. @alphascorp also posted a Utility to protect the kernel....

Boot64 is fundamentally script-based. If your scripting skills are up to it, feel free to modify it with additional protection for the kernel file. Be aware that you will probably need to permanently disable SIP...

 

[flygbuss]

I did as you suggested, and omitted the nvidia part. The Mac Pro 1,1 then booted nicely into El Capitan. So, thank you for your help. If I understand correctly, this method does not alter the Recovery Partition of El Capitan though. Am I correct? That would explain why I couldn't boot into the latter when trying to change the SIP status of the main system.

I went on and performed steps 1-7 described in posting #1391, installing the boot64 tool which is supposed to undo kernel changes induced by Apple updates. The Mac Pro booted and ran stably after all this.

Since my adjusted El Capitan was on 10.11.5, I decided to give it a go and install the 10.11.6 update through the Apple Store. I had read in an earlier posting that everything should go smothly when updating from 10.11.5. Before installing, I checked it didn't say anything about containing a Security Update 2018-xxx.

Well, the installation didn't hang and booting performs fine as well. But when I try to log in, the screen just changes the color for a half a second, then I am presented the same login screen again. I made sure I had typed in the correct passwort, rebooted several times, but no luck! Is it possible, that the current 10.11.6 update also contains kernel changes, which were not present in earlier versions of the same update? Or did I miss something else?

I decided to stay at the last Security Update that works because I personally don’t see the reason for the 1,1 being upgraded to a Security Update that needs modification with older files. But that’s just my two cents.
If you did the script like I wrote earlier you can modify the recovery partition as well. Mount it via terminal and then change the boot.efi inside the recovery portion with the modified one you used for your main partition.
After that you can boot into recovery and change SIP status via terminal.

 

[maruteru]

Hello @maruteru

My Boot64 tool only protects the boot.efi files. It does not protect the kernel file.
...
Boot64 is fundamentally script-based. If your scripting skills are up to it, feel free to modify it with additional protection for the kernel file. Be aware that you will probably need to permanently disable SIP...

Hello @rthpjm
Thank you for the clarification. I had misinterpreted the explanation in your earlier posting.

As to modifying your script, thanks for the offer, but I'm more than happy with your Boot64 version. Thanks for providing it to us.

If you did the script like I wrote earlier you can modify the recovery partition as well. Mount it via terminal and then change the boot.efi inside the recovery portion with the modified one you used for your main partition.
After that you can boot into recovery and change SIP status via terminal.

Hello @flygbuss
OK, I will do that. Thanks for your help.
[doublepost=1544580346][/doublepost]Hello @rthpjm and @flygbuss

I agree with both of you on staying on Mac OS X El Capitan 10.11.6 and the updates up to and including Security Update 2017-005. That's what I had planned for my Mac Pro 1,1 as well.

As I had a stable El Capitan 10.11.5, I wanted to update it to 10.11.6 and then install the 2017 Security Updates. That's why I double checked the incremental 10.11.6 update to make sure there is no newer 2018 Security Update included.

After having updated to 10.11.6 I didn't get problems with recurring boot up cycles. The system boots up nicely and the login screen is presented correctly. But when I try to log in, the screen simply changes the color for a half a second, then the login screen reappears.

 

[flygbuss]

Does Safe Mode work? Can you log in if you boot in Safe Mode?

 

[rthpjm]

Hello @rthpjm
Thank you for the clarification. I had misinterpreted the explanation in your earlier posting.

As to modifying your script, thanks for the offer, but I'm more than happy with your Boot64 version. Thanks for providing it to us.



Hello @flygbuss
OK, I will do that. Thanks for your help.
[doublepost=1544580346][/doublepost]Hello @rthpjm and @flygbuss

I agree with both of you on staying on Mac OS X El Capitan 10.11.6 and the updates up to and including Security Update 2017-005. That's what I had planned for my Mac Pro 1,1 as well.

As I had a stable El Capitan 10.11.5, I wanted to update it to 10.11.6 and then install the 2017 Security Updates. That's why I double checked the incremental 10.11.6 update to make sure there is no newer 2018 Security Update included.

After having updated to 10.11.6 I didn't get problems with recurring boot up cycles. The system boots up nicely and the login screen is presented correctly. But when I try to log in, the screen simply changes the color for a half a second, then the login screen reappears.

Do you have another computer in the house?
Can you remote onto the MacPro? (Screen Sharing from another Mac, or secure shell ssh from a Mac, Windows (PuTTY), or Linux variant)

If you can change directory to /var/log
Take a look at the system.log file
cat /var/log/system.log

Look for any odd messages...

Also try @flygbuss’ suggestion of starting in safe mode...

 

[maruteru]

Does Safe Mode work? Can you log in if you boot in Safe Mode?

Hello @flygbuss
Thanks for the idea, I had not thought of that before. I did boot into Safe Mode in the meantime, but the login issue remained the same.

Hello @rthpjm and @flygbuss
Thanks a lot for your continued support, I really appreciate it. Sorry, if I am a little slow in replying but currently my job keeps me busy.

The Mac Pro 1,1 runs Mac OS X 10.9.5 at the moment, so I was able to check the system.log file on the El Capitan volume. But it's difficult for me to put the messages into context, as I have no experience with this kind of information. But I do see a lot of error and failure notes which I wouldn't expect in a stable system.

Regarding the login behavior I have found the following lines. Maybe they matter:
Dec 12 18:14:23 c-ff0f loginwindow[449]: ERROR | -[LoginApp continueAuthPluginRequestAfterFamilyControlsCheck] | AuthorizationRef doesn't have a username. Exiting.
Dec 12 18:14:23 c-ff0f loginwindow[449]: Login Window Application direct exit via: 0

I'm surprised that it mentions something about a missing username. The login screen is set to show the username and only ask for a password.

How would I upload the entire log file, if needed?

 

[andrew nz]

Hello Andrew, you probably want to talk about the boot loop of our Mac Pro 1.1 / 2.1 under El Capitan, after the installation of security updates since January 2018?

The solution is explained by "Larsvonhier" and "kaosnews" (page 170 post #4237), a big thanks to them!

Personally I installed "SecUpd2018-004ElCapitan" and to avoid the boot loop I created an automatic tool that replaces the new kernel with the one of "SecUpd2017-005" and with a postinstall script to repair the timestamp of the folder /System/Library/Extensions.

If i understand correctly,

There has been a second issue with a subsequent security update which produces a boot loop issue.

You fixed that by installing the el cap update or updates, then booting to another disk and from there installing the kernel fix for the updated el cap with your app?

 

[rthpjm]

If i understand correctly,

There has been a second issue with a subsequent security update which produces a boot loop issue.

You fixed that by installing the el cap update or updates, then booting to another disk and from there installing the kernel fix for the updated el cap with your app?

Hi Andrew,

The Security Update incompatible kernel presents different symptoms. Most often called a boot-loop. The system will not start. It chimes, and then crashes a couple of seconds later, chimes, chrashes, chimes, crashes,...

@maruteru can boot his machine, gets to the login window. It would appear that after entering the login details, something goes wrong, it won’t log in, and eventually returns to the login screen.

Hey @maruteru ...
I have previously helped other users with “similar” symptoms. I’d like for you to rule out this as a possibility...

Do you have more than one monitor connected to your GFX card?
Is your GFX card an Apple-branded card, or is it a generic PC-targeted brand. (EVGA, XFX, etc...)
Does your GFX card have more than one port of the same type that you are using. E.g. two DVI ports?

If you have two ports, but only one monitor, can you try moving the cable to the second (currently unused port)?

If that doesn’t help, I did a brief Google search, I found one or two reports similar to yours. One of them said that they but the bullet and installed El Capitan a second time. That fixed it.

If you are using your other Mac to re-install, remember to simply use the Apple-supplied installer directly. There is no need to use Pikify when installing this way.

(EDIT) ... and remember to replace the boot.efi files before refitting the disk to the MacPro

 

[flygbuss]

Hi Andrew,

The Security Update incompatible kernel presents different symptoms. Most often called a boot-loop. The system will not start. It chimes, and then crashes a couple of seconds later, chimes, chrashes, chimes, crashes,...

@maruteru can boot his machine, gets to the login window. It would appear that after entering the login details, something goes wrong, it won’t log in, and eventually returns to the login screen.

Hey @maruteru ...
I have previously helped other users with “similar” symptoms. I’d like for you to rule out this as a possibility...

Do you have more than one monitor connected to your GFX card?
Is your GFX card an Apple-branded card, or is it a generic PC-targeted brand. (EVGA, XFX, etc...)
Does your GFX card have more than one port of the same type that you are using. E.g. two DVI ports?

If you have two ports, but only one monitor, can you try moving the cable to the second (currently unused port)?

If that doesn’t help, I did a brief Google search, I found one or two reports similar to yours. One of them said that they but the bullet and installed El Capitan a second time. That fixed it.

If you are using your other Mac to re-install, remember to simply use the Apple-supplied installer directly. There is no need to use Pikify when installing this way.

Doesn’t he have to replace the boot.efi after installing El Capitan from an other Mac?

 

[Argyboy]

iTunes update installed fine on El Cap with most recent security update 2017-005, in case anyone is wondering.
[doublepost=1544791364][/doublepost]

I don't like chrome to be honest and I was using Opera for Netflix but it's limited to 720p.
I found an extension for Firefox wich allows it to play Netflix content in 1080p. Seems to work pretty well as fas as I can tell. I was just wondering if there would be a way to convince Safari to use HTML5 instead of Silverlight since it works like that on my newer Macs. Apparently it's not only connected to Safari and the OS but also to the machine itself.

Sorry, forgot to reply to this. It seems that you might be affected by a hardware limitation, as per this article:

https://help.netflix.com/en/node/22822

You would be best to install Chrome and just use that for Netflix.

 

[rthpjm]

Doesn’t he have to replace the boot.efi after installing El Capitan from an other Mac?

Ah, yes. I made an assumption. I’ve edited the original

 

[andrew nz]

Therefore if i install whatever is my last non-installed update , boot into another disk and apply the kernel swap and presumably point eh app at the el cap disk via the app as above, that will prevent the current batch of boot loop and kernel issues, but install security and app updates?

 

[maruteru]

I have previously helped other users with “similar” symptoms. I’d like for you to rule out this as a possibility...

Hello @rthpjm
Let me start by saying thank you again, to you and to everybody who is helping me. This support keeps me going when I find myself in a dead end.

Do you have more than one monitor connected to your GFX card?
Is your GFX card an Apple-branded card, or is it a generic PC-targeted brand. (EVGA, XFX, etc...)
Does your GFX card have more than one port of the same type that you are using. E.g. two DVI ports?

If you have two ports, but only one monitor, can you try moving the cable to the second (currently unused port)?

I only have one monitor hooked up to the graphics card. The latter is an Apple-branded ATI Radeon HD 4870 card with one DVI and one MiniDP port.

I moved the monitor to the second port and rebooted the Mac. I got the same login behavior as on the first port.

Just as a test I also reset the passwort on the El Capitan volume, but that also didn't resolve the problem.

If that doesn’t help, I did a brief Google search, I found one or two reports similar to yours. One of them said that they but the bullet and installed El Capitan a second time. That fixed it.

If you are using your other Mac to re-install, remember to simply use the Apple-supplied installer directly. There is no need to use Pikify when installing this way.

(EDIT) ... and remember to replace the boot.efi files before refitting the disk to the MacPro

I agree with you that reinstalling is the next step. So that's what I did. I started with the Apple installer 10.11.5 on my Macbook Pro and later applied the incremental update to 10.11.6. I performed the update before copying the boot.efi files. I downloaded them from Piker-Alpha's github site (Macosxbootloader v3.1). As you suggested I didn't use Pikify.

Then I tried to boot into the new El Capitan volume (with the modified boot.efi files). But that doesn't work and the Mac Pro boots the old 10.9.5 volume instead. I read something about blessing a volume (I need to google that term tomorrow). Do I have to do this here? I only took a quick glance at the system.log file, as it is getting early here..

I keep forgetting to mention, that I have 4 x 512 MB RAM (besides 2 x 2 GB) modules installed in this Mac Pro. I have read that some of you consider this type of RAM to be cumbersome. I currently can't exchange it, as I don't have spare DDR2 RAM.

I'm sorry to keep you busy.

 

[lysergilie]

Hi guys, I'm doing it, was pretty content with Snow Leopard tbo but the web is practically unusable at this point ... pretty stupid security wise too I guess ... also just bought a ton of apps, so this better works.

Before I make it much more complicated for myself than it needs to be, could you beautiful people please check if I'm on the right track, I'll be forever grateful.

1. Got an iMac 2010 (10.6.8) as well, can I use it to download 10.11 from the App Store, clean-install it on a firewire connected SSD-dock, boot and combo-update to 10.11.6 etc. then, when everything is up to date, put the SSD into the Pro and copy the Pike's EFI32boot.efi from the 10.6.8 disk - since I plan to stay at Security Update 2017-005 I'd be pretty much set and done, right?

2. I'm not sure if an iMac installs different system-files or, more likely, writes different hardware specific settings/references than are needed on a Pro. Especially if BOOTED THE FIRST TIME on the iMac. Read something to that effect at some point, maybe I misremember and it was about laptops. Can anyone share a real life experience, please?

3. OR would it be better to move the full 10.11 installer (if the App Store still downloads one) to the Pro right away and install from 10.6 drive with Pikify tools?

Thanks for your write-ups rthpjm, you're a saint!

Mac Pro 1,1: 2x3 GHz Xeon - 32 GB - ATI Radeon HD 5770 (Apple Upgrade Kit)
iMac 11,3: 2,93 GHz i7 - 20 GB - ATI Radeon HD 5750

 

[flygbuss]

Hi guys, I'm doing it, was pretty content with Snow Leopard tbo but the web is practically unusable at this point ... pretty stupid security wise too I guess ... also just bought a ton of apps, so this better works.

Before I make it much more complicated for myself than it needs to be, could you beautiful people please check if I'm on the right track, I'll be forever grateful.

1. Got an iMac 2010 (10.6.8) as well, can I use it to download 10.11 from the App Store, clean-install it on a firewire connected SSD-dock, boot and combo-update to 10.11.6 etc. then, when everything is up to date, put the SSD into the Pro and copy the Pike's EFI32boot.efi from the 10.6.8 disk - since I plan to stay at Security Update 2017-005 I'd be pretty much set and done, right?

2. I'm not sure if an iMac installs different system-files or, more likely, writes different hardware specific settings/references than are needed on a Pro. Especially if BOOTED THE FIRST TIME on the iMac. Read something to that effect at some point, maybe I misremember and it was about laptops. Can anyone share a real life experience, please?

3. OR would it be better to move the full 10.11 installer (if the App Store still downloads one) to the Pro right away and install from 10.6 drive with Pikify tools?

Thanks for your write-ups rthpjm, you're a saint!

Mac Pro 1,1: 2x3 GHz Xeon - 32 GB - ATI Radeon HD 5770 (Apple Upgrade Kit)
iMac 11,3: 2,93 GHz i7 - 20 GB - ATI Radeon HD 5750

I installed the El Capitan boot drive for my cMP 1,1 with a MBP late 2011 and another time with a rMBP 2013.
Never had trouble because of that. Just remember that you can't boot back into that drive again with your iMac after you changed the boot.efi.

 

[lysergilie]

Nice! Thank you so much flygbuss, you're the best. This might be much less painful than expected, especially now without updates to worry about.

 

[flygbuss]

You’re welcome. Just avoid the latest security updates if you don’t wanna fix those manually.

 

[godzfire]

I have a MP 1.1 flashed to 2.1, running 10.11.6 (15G17023), and updated to the last pre 04-2018 Security Update. Everything is working good, except I have no recovery partition.

I REALLY want to get one working for a number of reasons, but not sure exactly how to do that. I have spare hard drives and a 2008 MacBook Pro where I can do various copies/boots/edits/etc. The one thing is though is it's not possible for me to simply do a clean install of the OS and transfer everything over from my current setup; there's way to much customized stuff on there that would be hell to try and redo.

Is there a way to add a recovery partition?

 

[jbarley]

Carbon Copy Cloner can create a Recovery Partition, the only problem is you can't be booted and running from the system you are needing the Recovery Partition for.
I normally boot from one of my CCC backups and run the Rec HDD utility from there.
But it does the job well and has never failed me.

 

[rthpjm]

I have a MP 1.1 flashed to 2.1, running 10.11.6 (15G17023), and updated to the last pre 04-2018 Security Update. Everything is working good, except I have no recovery partition.

I REALLY want to get one working for a number of reasons, but not sure exactly how to do that. I have spare hard drives and a 2008 MacBook Pro where I can do various copies/boots/edits/etc. The one thing is though is it's not possible for me to simply do a clean install of the OS and transfer everything over from my current setup; there's way to much customized stuff on there that would be hell to try and redo.

Is there a way to add a recovery partition?

Hello @godzfire

Let me know if you want to use CCC as @jbarley suggests above, or if you’d like to work through the manual steps yourself. I’m happy to write the steps...

 

[rthpjm]

Hello @rthpjm
Then I tried to boot into the new El Capitan volume (with the modified boot.efi files). But that doesn't work and the Mac Pro boots the old 10.9.5 volume instead. I read something about blessing a volume (I need to google that term tomorrow). Do I have to do this here? I only took a quick glance at the system.log file, as it is getting early here..

I keep forgetting to mention, that I have 4 x 512 MB RAM (besides 2 x 2 GB) modules installed in this Mac Pro. I have read that some of you consider this type of RAM to be cumbersome. I currently can't exchange it, as I don't have spare DDR2 RAM.

I'm sorry to keep you busy.

Hello @maruteru

My apologies, I didn’t read your last post properly.

Blessing a partition marks it as bootable.
There are a few ways to work it...

• With the MacOS System Preferences > Startup Disk from your Lion partition. You should see your El Capitan partition in the list, simply select it.
• You can use the command line from a Terminal window.

  bless --folder “/Volumes/yourElCapitanPartition/System/Library/CoreServices” --file “/Volumes/yourElCapitanPartition/System/Library/CoreServices/boot.efi”

• Or reboot, when you hear the chime hold down the ALT key. This should bring you to the “EFI boot selector screen”. Use your mouse to select the El Capitan Partition, or use the arrow keys and hit the enter/return key. Once booted, go into the System Prefs > Startup Disk.
• Boot into the recovery partition (hold the R key after the chime, or the Alt key then select the Recovery volume). One of the tools is Startup Disk (it might live under the Apple menu). Tip: if you simply hit Apple-Q when you reach the Recovery screen, it usually asks if you want to select a Startup Disk...

 

[lysergilie]

Apropos blessing, does one have to bless the recovery partition boot.efi after switching it out?

Also, earlier in this thread this command was suggested:

sudo bless --folder /Volumes/SSDname --file /Volumes/SSDname/boot --setBoot

Reading your comment rthpjm, I must assume the CoreServices-folder and boot.efi-file will suffice?

Thank you!

 

[rthpjm]

Apropos blessing, does one have to bless the recovery partition boot.efi after switching it out?

Also, earlier in this thread this command was suggested:

sudo bless --folder /Volumes/SSDname --file /Volumes/SSDname/boot --setBoot

Reading your comment rthpjm, I must assume the CoreServices-folder and boot.efi-file will suffice?

Thank you!

To the best of my knowledge, no you do not need to bless the Recovery volume. Starting up into the Recovery HD is an edge case. I believe it is hardcoded in the EFI firmware (although I have no definitive knowledge). The Recovery HD is not “normally” visible to the “usual” boot sequence.

The “usual” boot sequence into a copy of Mac OS X goes something like this...


The EFI firmware looks for the location of the file-based EFI extension (boot.efi) in a persistent location. For flexibility, the persistent location is a “variable” stored in a HFS+ header location (that’s a part of the partition format). The bless command writes the given location into the persistent store.

The maker of Carbon Copy Cloner, Bombich Software, have a KB article that goes into a bit more depth .

In essence the firmware can produce a list of candidate disks, and understands GPT and MBR partition schemes. From here it can look at each partition (aka volume) to find a secondary boot file (boot.efi) from the HFS+ header.

If the volume is blessed then the location pointed to by the HFS+ header will resolve to the boot.efi file. This reference is actually numeric and is known as an inode value (which is basically the number of the starting block on the Disk for the boot.efi file)

If you ever delete the boot.efi file and write a new copy, the location of the file on the disk will sometimes be different. Therefore the inode value stored in the partition HFS+ header is now wrong. The firmware cannot find the boot.efi file and will not be able to boot from that partition... until you re-bless with the new file.

Notice it’s not the file name, nor its path that’s important, it’s the numeric reference to the starting block on the Disk.

Caveat, some methods of coping the boot.efi file perform an overwrite (the command line copy command (cp)), other methods perform a delete followed by a write (using the Finder). The first method preserves the inode starting point and therefore the volume remains blessed. The Finder replace causes the boot.efi file to be located at some other inode starting point, thus rendering the bless info incorrect.

The example that you give is correct in its use of switches, but it is not appropriate for the locations. Mac OS X has used /System/Library/CoreServices/boot.efi for some time.

I believe /boot is an old or incorrect reference, it may be appropriate for Linux derivatives. Again I’m a bit hazy on this area, someone else might be able to add clarity...

 

[lysergilie]

Nice! Thank you so much rthpjm, very graspable, now I feel like I know what's _actually_ going on.
Might as well just -cp those suckers over there.

What's your opinion on editing the PlatformSupport.plist(s)? Haven't seen it mentioned much in this thread.

 

[rthpjm]

Nice! Thank you so much rthpjm, very graspable, now I feel like I know what's _actually_ going on.
Might as well just -cp those suckers over there.

What's your opinion on editing the PlatformSupport.plist(s)? Haven't seen it mentioned much in this thread.

Typically the plist files are modified just once. They do not change after that. El Capitan 10.11.6 is the highest release that original MacPros can run. The plist files have not been overwritten (at least to my knowledge).

Manual installation should probably modify the PlatformSupport.plist file. The Pikify tools take care of it. If not go back further in time on this thread and possibly the Yosemite equivalent. I think post #1 of this thread still has a pointer to Mike’s roundup of the manual procedure.

PlatformSupport.plist files tend to be referenced when installing things. The Install Assistant, and the Software Update process will probably reference them. If you’re already at 10.11.6 with Security Update 2017-005 (or if you’re pioneering with the Security Update 2018-* and a rolled back kernel) there’s probably little need to amend the file. It’s probably more important when creating an “installer” because it will inform the IA what hardware models the software is intended for. That’s the main reason for the mod, so that we can install 10.11.* on our older hardware...

One of the reasons that my Pikify tools are popular is because it takes care of all this from the installer perspective. The modifications not only help the initial installation, but they are also propagated to the Recovery HD. The RHD is then fully useable not just for the Recovery tools but also as a local emergency re-Installer. Therefore you have the full suite of options available.

• Tools
• Local BaseSystem.dmg for installation from the RHD
• Network recovery, although this will download a new copy of Mac OS X from Apple and probably will not install due to the missing modifications.