Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Congratulations to the successful upgrade. Glad it worked out.
I did use wasbezine myself but did not propose it because I did not know what the proper English name was, e.g, one term „white spirit“ is used for a range of similar liquids and not all are suitable for electronics.
Thanks! I did 2 more ram sticks. Tried to put them in a wasbenzine bath of 2 mm (inside of a jewel case for cd's) hoping it would dissolve the paste faster and better but i didn't help much. Still had to clean them a lot with q tips after that. Also the temps have gone up. But that is somewhat normal because the 'cooling' effect has to set in after you change those fins and thermal pads. Although i bought new thermal pads but they are not the right size. Because i 'destroyed' 1 of the old pads.

Some pads came off with no problem but some of it sticked to the chips on the ram and even removing them carefully did not help as small part of the pad still sticked the ram chips. First time that happened i threw away the old pad but not any more. When i tried the new pads the temps were 15 degrees celsius higher than the other ones. So i only took off a pad from another old ram stick and used that. The thing is those pads are reusable. And i forgot. Even with a small hole in them. Although that would not be 100% perfect.

Now the temps are better. First 2 ram sticks i did started with 5 degrees difference. Now that is 2 degrees. Around 50 when idle. Sometimes lower.

The second pair ended up with 10 degrees difference. Now it's more like 6 degrees but i think i also didn't clean the last pair fully (the cleaning job is sooo annoying and time consuming that you get fed up with it after you done some) I think there was still some paste on the chips. I will check that later and clean them a bit more. Also with all new ram chips i done so far i didn't clean between every 2 ram chips. I mean: if you look at 1 side you see a row of 8 or 10 chips but every one of those are actually 2 above each other with a small gap in between. I got a small wood pick for cleaning teeth to do some edged but i didn't clean between those chips because i couldn't remove that paste while trying. Maybe i gave up to quick. But i'm wondering how much everybody else cleaned heir replacement ram. I searched the forum but couldn't find anybody explaining what they did.

So if anybody got tips and did have the same ram chips as me with a small gap between those 2 chips but did got them cleaned, i would like to know. Cause still 1 part of my brain says it's not needed. But i'm in doubt now.

Oh and my tip is to clean the chips until there is no paste coming of it. Wasbenzine leaves a white residue that is masking the gray paste a bit. So you need a clean q tip with wasbenzine as last not picking any paste anymore. So it needs to stay white! Also when a q tip is full with paste, you just move the paste around on the chip instead of taking it off. And i think i didn't clean the 1 with the higher temps like that. Also gonna pick up some make up removal pads because i think they clean better than q tips because they are very quickly saturated with paste.

Thanks!
 
I am still trying to figure out, why I am getting a command line type login screen after activating file vault on my upgraded MacPro 1,1 (See Post #5.013). I have the suspicion that I have missed to replace the boot.efi somewhere, but recovery partition works and there is hardly anything to find about the boot sequence when the start volume is encrypted. The command line type login screen show up almost instantly after the boot chime, so it may as well be part of the EFI.
Any idea how to move forward from here ?
 
I am still trying to figure out, why I am getting a command line type login screen after activating file vault on my upgraded MacPro 1,1 (See Post #5.013). I have the suspicion that I have missed to replace the boot.efi somewhere, but recovery partition works and there is hardly anything to find about the boot sequence when the start volume is encrypted. The command line type login screen show up almost instantly after the boot chime, so it may as well be part of the EFI.
Any idea how to move forward from here ?
Did you post about this before? I used the image install and never activated the filevault. Why would you want to do that? Are there any clear benefits besides safety?

And there are only 2 places where you have to replace the boot.efi if i'm correct. If you have followed the video like me i can't see why you have missed one of the boot.efi's

If you also used the image to install i think it has something to do with it not being an official install method. And that the boot.efi needs to be changed after you activated filevault.

I think you can make an image yourself. Maybe even make the boot.efi. But it think you can't copy an install from 1 new mac to a older 1,1/2,1 with filevault enabled. Because that must be linked to drive it's on.

And that may be reason you need to log in way before the normal way of logging in. Because the boot.efi should be locked after you replace it. And filevault may need to change something to the efi.

Maybe we can find the maker of the boot.efi and ask if he knows how to make a boot.efi with filevault enabled after you did the 'update' to el capitan. But it's a lot of speculation.
 
Anyone else having the issue where Safari 11.1.2 doesn't open after the 2017-005 update ?
 
Did you post about this before? I used the image install and never activated the filevault. Why would you want to do that? Are there any clear benefits besides safety?

And there are only 2 places where you have to replace the boot.efi if i'm correct. If you have followed the video like me i can't see why you have missed one of the boot.efi's

If you also used the image to install i think it has something to do with it not being an official install method. And that the boot.efi needs to be changed after you activated filevault.

I think you can make an image yourself. Maybe even make the boot.efi. But it think you can't copy an install from 1 new mac to a older 1,1/2,1 with filevault enabled. Because that must be linked to drive it's on.

And that may be reason you need to log in way before the normal way of logging in. Because the boot.efi should be locked after you replace it. And filevault may need to change something to the efi.

Maybe we can find the maker of the boot.efi and ask if he knows how to make a boot.efi with filevault enabled after you did the 'update' to el capitan. But it's a lot of speculation.
Thanks for your thought, Madr.

I needed FileVault to assure, none of the data that I was processing (and any snippets that may have ended up in system caches) would be retrievable and since I am using an SSD, erasing content safely would also have been an issue. The old MacPro was a perfect machine to run in isolation for that purpose and the login was a minor annoyance.
Having said that, I don't see much value using FileVault on such a hacked machine for daily work unless you process sensitive data. For usual confidential stuff an encrypted disc image would suffice.

To make a long story short: I have switched FileVault off again after I was done with the job. Now everything is back to normal and I do get the graphical login screen again.

The master mind behind the boot.efi for El Capitan is Pike R. Alpha, who unfortunately retreated after he lost his sister and wife. My knowledge is far less advanced and hence I will leave it as is.

I do think though that the challenge is indeed connected to some missing elements in that modified boot.efi that makes the MacPro default to a basic login procedure embedded in the firmware when FileVault is activated.
 
Anyone else having the issue where Safari 11.1.2 doesn't open after the 2017-005 update ?
I have installed all security updates To El Capitan beyond 2017-005 and then just reverted the kernel back. I don't recall if there were any updates to Safari in one of the 2018 updates though. I do have Safari 11.1.2 (11605.8.3.1) functioning without any issues on El Capitan (15G22010).
Without any details about the nature of the issue Safari is having it is also difficult to suggest any further analysis.
 
I've read 27 pages into this thread starting with the January saga that brought-on the 2018 security update and bricked MacPro1,1s and 2,1s all over the globe. I've read most, skimmed some, and I gathered that the most appropriate fix (that includes the most useful parts of the update, discarding the part that bricks the computer) is to replace the kernel with a copy of the kernel from the 2017-005 update using Pacifist.

Great. So I did that.

However, by some freak voodoo, I find that the computer STILL BOOTS USING THE 2018 KERNEL. And crashes/panics/loops instantly upon the progress bar appearing below the Apple logo.

I've replaced the 2018 kernel with the 2017-005 kernel about 3 times now, twice by re-extracting from the 2017-005 patch and once by downloading from an attachment here - and all times, it boot-loops and it shows a date of June 2018 when I "Cmd+V" at startup.

I'm doing this from a Catalina MacBook Air to manipulate the drive externally.

It sounds like there's some hidden routines that aren't being done - particularly in updating some hidden EFI system partition files, something Disk Utility might be responsible for - but it's not doing it? I've Googled around and I can only find people complaining or being clueless about the message "Updating boot support partitions for the volume as required"... but absolutely no way I can find to actually trigger the system to perform this operation.

I'm getting a massive headache continuing to sift through pages and seeing people just happily copying the kernel and it "just works"... but here I am, I copy the kernel into /Volumes/ElCap/System/Library/Kernels - then I touch /Volumes/ElCap/System/Library/Extensions... and. it. always. keeps. booting. the. 2018. kernel. A kernel that no longer exists.

Dammit, Apple.

Update: Solved! Created a bootable Lion (10.7) USB installer (headache ensues: had to use this method: https://apple.stackexchange.com/a/403172 ) - then booted it, and ran Disk Utility repair on it. The last thing it did - which it didn't do under Catalina - was "update boot support partitions for the volume...". Yes, that's the trick, a hidden partition! Nice. Then, I was able to boot again, and the kernel seems to have taken.
 
  • Like
Reactions: VaZ
Update: Solved! Created a bootable Lion (10.7) USB installer (headache ensues: had to use this method: https://apple.stackexchange.com/a/403172 ) - then booted it, and ran Disk Utility repair on it. The last thing it did - which it didn't do under Catalina - was "update boot support partitions for the volume...". Yes, that's the trick, a hidden partition! Nice. Then, I was able to boot again, and the kernel seems to have taken.
Partitions don't hide. diskutil list lists all partitions.

Catalina is installed in an APFS container. The APFS container includes a Preboot volume. You can mount that with the diskutil mount disk#s# command. Lion doesn't know about APFS, so it's probably talking about something else. Maybe Recovery HD partition or EFI partition? Usually there's nothing in the EFI partition that's used for booting macOS. A raid partition or a fusion drive has an Apple_Boot partition.

Did you try this?
sudo touch /Volumes/ElCap/System/Library/Extensions
 
Did you try this?
sudo touch /Volumes/ElCap/System/Library/Extensions
Yeah, we're long past that ;) The two (copying the kernel and touching the extensions) are usually quoted together, and I'm not kidding when I said I went through twenty. six. pages. 😳 of replies. Mostly hoping that someone had come up with a patch for the more modern kernel, but the changes seem like they're too deep to patch, and swapping the kernel appeared to be a reliable fix.

But no... when I swap the kernel and touch extensions, unmount the drive, plug it back into the Mac Pro... the Mac Pro kept booting up with the ghost of the 2018 kernel (and crashing so fast I had to catch the 2018 sign-on message using slow-mo capture on my phone).

I had indeed also checked with diskutil and mounted the EFI partition, but inside was no hint of a copy of the kernel that I could see. Neither, too, with the recovery partition. Yet neither still, by running Disk Utility repair on the drive! It didn't update the boot partition, either.

It seems that Catalina might just have wholly discarded with the notion of updating the boot partition when unmounting a system drive... which is just... frustrating, a bit, because it leads to "ghost" issues like this. I was able to fix it by just kinda intuitively figuring that the kernel we touch isn't the real kernel it boots up with (not the actual "data on disk", that is), and that a sneaky mount-level process was responsible for keeping the files-on-disk and files-on-boot in sync with each other. That must've broken with Catalina.

It's all good, either way. The solution was to run a disk check from an older Mac OS - or possibly, running it on a volume seen as an internal (not external, USB) volume - since I'd done the repair with the Mac Pro itself booted from a Lion USB stick. Then, it updated the boot partition and put the kernel back in sync with its respective file.

edit: Now that I re-read, I think you might be misunderstanding my setup and issues.
Catalina: my MacBook Air that I used to fix this tangled mess.
MBA with Catalina <- USB adapter <- MacPro 1,1 SSD with El Capitan and 2018 kernel
Then I put the SSD back into the MacPro 1,1 and test things out. The Mac runs El Capitan of course, but the computer I'm doing the repairs on runs Catalina. Booting the MacPro with Lion (and the El Capitan SSD installed internally) and doing a Disk Utility repair from the install media, is all it took to get the kernel updated in the "boot partition" (out of reach of us mere mortals - because while the partition is visible, the data inside isn't formatted in an editable manner e.g. to update the kernel manually).
 
Last edited:
Yeah, we're long past that ;) The two (copying the kernel and touching the extensions) are usually quoted together, and I'm not kidding when I said I went through twenty. six. pages. 😳 of replies. Mostly hoping that someone had come up with a patch for the more modern kernel, but the changes seem like they're too deep to patch, and swapping the kernel appeared to be a reliable fix.

But no... when I swap the kernel and touch extensions, unmount the drive, plug it back into the Mac Pro... the Mac Pro kept booting up with the ghost of the 2018 kernel (and crashing so fast I had to catch the 2018 sign-on message using slow-mo capture on my phone).

I had indeed also checked with diskutil and mounted the EFI partition, but inside was no hint of a copy of the kernel that I could see. Neither, too, with the recovery partition. Yet neither still, by running Disk Utility repair on the drive! It didn't update the boot partition, either.

It seems that Catalina might just have wholly discarded with the notion of updating the boot partition when unmounting a system drive... which is just... frustrating, a bit, because it leads to "ghost" issues like this. I was able to fix it by just kinda intuitively figuring that the kernel we touch isn't the real kernel it boots up with (not the actual "data on disk", that is), and that a sneaky mount-level process was responsible for keeping the files-on-disk and files-on-boot in sync with each other. That must've broken with Catalina.

It's all good, either way. The solution was to run a disk check from an older Mac OS - or possibly, running it on a volume seen as an internal (not external, USB) volume - since I'd done the repair with the Mac Pro itself booted from a Lion USB stick. Then, it updated the boot partition and put the kernel back in sync with its respective file.

edit: Now that I re-read, I think you might be misunderstanding my setup and issues.
Catalina: my MacBook Air that I used to fix this tangled mess.
MBA with Catalina <- USB adapter <- MacPro 1,1 SSD with El Capitan and 2018 kernel
Then I put the SSD back into the MacPro 1,1 and test things out. The Mac runs El Capitan of course, but the computer I'm doing the repairs on runs Catalina. Booting the MacPro with Lion (and the El Capitan SSD installed internally) and doing a Disk Utility repair from the install media, is all it took to get the kernel updated in the "boot partition" (out of reach of us mere mortals - because while the partition is visible, the data inside isn't formatted in an editable manner e.g. to update the kernel manually).
Hello FalconFour,

I’m happy to hear that you solved it. I thought I should weigh in with my understanding in the hope that it helps you in the future...

Most versions of Mac OS X including El Capitan use a pre-linked kernel during the boot sequence. Guess what! It’s named prelinkedkernel ;) One of the effects of the advice to touch /System/Library/Extensions is that the system will rebuild the pre-linked kernel. You can also use the command line tool kextcache to rebuild the caches and prelinked kernel (read the man page, man kextcache).

For your situation, where you have the MacPro drive removed, and then connected to you MBP with a USB connector, you need to remember to add extra elements to the beginning of any path. It’s not clear whether you know this, so I’ll state it here for clarity. Your MacPro drive will be presented on the MBP via /Volumes/[volumename]. Let’s assume your MacPro disk has the typical volume name of Macintosh HD. Let’s also assume that your MBP has its main volume also named Machintosh HD. Your MBP will volume will take the path “/Volumes/Macintosh HD”, your MacPro disk will then mount and take the path “/Volumes/Macintosh HD 1”. If your MBP volume is not named Macintosh HD, then the MacPro disk will take the path “/Volumes/Macintosh HD”.

Now that we know which path the MacPro disk will use, you must prefix that to any path presented on these forums that does not start with /Volumes. For example, if a post says “touch /System/Library/Extensions”, it is assuming that the disk is in your MacPro and that you are already booted from it. In your case you have the disk removed and connected to another Mac, therefore you need the prefix, e.g. touch “/Volumes/Macintosh HD 1/System/Library/Extensions”. (Remember, the volume name differs according to your own disk volume names).

As I said, you might already know this, apologies if you do. As I read your posts I got the feeling that perhaps you didn’t, and that it might explain your symptoms. If you didn’t touch the correct location, then the prelinkedkernel would not be rebuilt, meaning it would still be based on the incompatible 2018 kernel (or higher). Hence when you restart the MacPro it will still boot-loop. Your resolution eventually got the prelinkedkernel rebuilt based on the 2017-05 kernel, voila it boots.

The sequence goes like this...
MacPro working up to 10.11.6 with Security Update 2017-005
MacPro updated with Security Update 2018-001 (or higher)
The kernel is updated to an incompatible version, the update process rebuilds the prelinkedkernel file
MacPro restarts, goes into a crash-loop (also called a boot loop) because the prelinkedkernel is now based on the incompatible kernel.
To fix it, replace the kernel file with the 2017-005 version, AND force a rebuild of the kext caches which also rebuilds the prelinkedkernel
The rebuilt prelinkedkernel file is now back to being based on the compatible 2017 kernel.
Your MacPro will now reboot.
 
Last edited:
  • Like
Reactions: Macschrauber
Follow these instructions if you have just installed El Capitan, or are already using El Capitan and want to automatically put the modifications in place during updates.

============== Edit ==================
This has been tested from initial install 10.11 to 10.11.1, and from 10.11.1 to 10.11.2.

Each successive release of El Capitan is making it harder to use this method, which is only to be expected. SIP (aka "rootless") is continually being developed and extended by Apple.

As a rule of thumb, if in doubt turn SIP off first.

If you are nervous about a particular update to El Capitan, then you should disable SIP entirely before you commence with the update. Search this thread for "csrutil" to find out how...

Upgrades from -> to:
10.11.0 -> 10.11.1 safe
10.11.1 -> 10.11.2 overwrites boot.efi files
10.11.2 -> 10.11.3 safe
10.11.3 -> 10.11.4 overwrites boot.efi files
10.11.4 -> 10.11.5 overwrites boot.efi files
10.11.5 -> 10.11.6 safe

NOTE: If you install El Capitan and then use a "combo" updater usually downloaded from the Apple web site Support /
Downloads section, then be aware ALL combo updates will replace the boot.efi files (perhaps with the exception of 10.11.0 -> 10.11.1)

===================================


SECURITY UPDATES:
All security updates up to and including Security Update 2017-005 will install without issues.

CAUTION: Security Update 2018-001 has a modified kernel that crashes the boot sequence. There is a workaround which is to roll-back the kernel file to the last known good version from the 2017-005 Security update. You will need a second working partition of MacOS (or a working Recovery HD partition) so that you can roll-back the kernel). See post #3896...


Please note: Boot64 is only designed to protect the boot.efi file. The issue with a boot loop after applying Security-Update-2018-001 or later is due to a changed kernel file. Boot64 does not protect the kernel file.
===================================

While Pike is recuperating (take your time Pike :) ), I have figured out how to set up our working El-Capitan installs so that they will survive the Apple update mechanisms. You will need to install your choice of "pike yos fix" the updated version now called CapitanPikeFix is at post #1253 (courtesy of @666sheep) , or my very own Boot64 stuff, they both pretty much do the same thing. My Boot64 stuff installs a Launch Daemon that watches the boot.efi files, if they get changed (by the Apple update) it simply puts the Pike copies back!

@666sheep's CapitanPikeFix requires that you permanently disable SIP.
My Boot64 modifies SIP, keeping most of the security advantages of SIP enabled.

CAUTION: Apple will probably alter SIP in the future to prevent Boot64 from working, but in the meanwhile....

"Ah, but SIP stops them working!" I hear you cry. True!

But, we can exclude the boot.efi files from SIP - here's how:

I will assume your working El-Capitan is on the hard disk named Macintosh HD - change it to suit

  • You don't need to do steps 1, 2, 3, and 4 if you have just used pikify3.1 (v3 or higher) to install El Capitan From the post above because it's already done for you)
  • You DO need to complete steps 6 - 8...

  1. Boot off another partition, I use the Recovery HD partition.
  2. Open a Terminal
  3. If you are NOT using the Recovery HD, you will probably need to elevate your privileges. Become the super user
    Code:
    sudo -s
    [your password]
    if you ARE using the Recovery HD there is no need for the sudo command.
  4. Now type or copy/paste
    Code:
     chflags nouchg /Volumes/Macintosh\ HD/System/Library/CoreServices/boot.efi
     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
  5. Reboot from your other partition back into your normal El Capitan disk (Macintosh HD)
  6. Install CapitanPikeFix, or my Boot64 (attached)
  7. If you are going to install my Boot64, download the zip file below, unzip it, and double-click it, follow the installer prompts (you might need to allow it with Gatekeeper - if you get a "can't install" message, try opening System Preferences > Security & Privacy > General, look for the "Open anyway" button). If that doesn't work, choose 'Anywhere' from the options and try again... (Don't forget to put this option back to your preference after Boot64 is installed!)
  8. Sit back and enjoy El-Capitan o_O
Once installed you can choose the background colour of the boot screen at any time. See post #1395 below...


I don't claim to have discovered this fix. I'm simply good at using search engines, and then realising how this fits together. The credit goes to the Hackintosh community again. See http://www.idelta.info/archives/sip-rootless-internal-in-el-capitan/

I've tested this with a clean install of El Capitan 10.11 and successfully installed the 10.11.1 update from the App Store, and from a clean install using the 10.11.1 downloadable update.

I will modify my pikify3.1 script bundle with the mods for SIP exclusions already in (but without the install of Boot64 itself - you still need to install this - or CapitanPikeFix). Look out for pikify3.1.v3.zip pikify3.1.v#.zip at post #1390 ...

===================== Version 2 ============================

V2 includes mods to watch the SIP/Sandbox paths file in addition to the boot.efi files

===================== Version 3 ============================

Fixes an issue identified with the 10.11.2 update.
If you are using Boot64 AND you have already updated to 10.11.2 then you should probably check your system, see post #1484

++++++++++++ MD5 ++++++++++++++++++++++++++++++++++++++++

MD5 (Boot64.v3.mpkg.zip) = 9ed68334f6593ff7c64c32d29317f152
Hi !, thanks for your help, I have a Mac Pro 1.1 updated to 2.1., run perfect.
But I have a problem, I can’t update the version of my El Capitan, I have the version 10.11
I have installed with the tool Pikify bootloader v3.1 (only the archive boot.efi), not with app.
I have El Capitan downloaded with torrent using google search.
My problem is with the updates, I can’t update the 10.11.6 combo update, also the combo update 10.11.2 I can’t install, at the process update my system restart and entry in “panic kernel”.
Before installing I tried to change the date to 2015/2016 2018 and it did not install either.
I have installed boot64 and I have only done steps six and eight, but it does not work for the updates.
I don't know if I should complete steps 1 through 5.
I only need to try the capitanpikerfix, but I cannot desactivate SIP because I am missing HD recovery on my system.
A lot of people have your El Capitan updated to 10.11.6.
Please you have any suggestions to solve my problems thank you very much.
Best regards.
 
Last edited:
Hi everyone, I have difficulties though downloading the El Capitan installer. On my already patched Mac Pro 1.1, where I have installed Yosemite the link from the Appstore says that on this OS can not be installed EC. The same does the installer from the .DMG file from the Apple support. Can anyone share/ or does knows a place where I can download the .app file directly? I'd be very thankful!
 
Hi everyone, I have difficulties though downloading the El Capitan installer. On my already patched Mac Pro 1.1, where I have installed Yosemite the link from the Appstore says that on this OS can not be installed EC. The same does the installer from the .DMG file from the Apple support. Can anyone share/ or does knows a place where I can download the .app file directly? I'd be very thankful!
Hello,
Watch this youtube video
this is where I got mine.
 
Hello FalconFour,

I’m happy to hear that you solved it. I thought I should weigh in with my understanding in the hope that it helps you in the future...

[...snip...]

As I said, you might already know this, apologies if you do. As I read your posts I got the feeling that perhaps you didn’t, and that it might explain your symptoms. If you didn’t touch the correct location, then the prelinkedkernel would not be rebuilt, meaning it would still be based on the incompatible 2018 kernel (or higher). Hence when you restart the MacPro it will still boot-loop. Your resolution eventually got the prelinkedkernel rebuilt based on the 2017-05 kernel, voila it boots.
Ah, alas, thank you for your very thoughtfully crafted wrapping of this advice. :) However, I am quite aware of the mounting of external volumes under /Volumes/.../ etc ;)

What I was not aware of, however, was any ability to externally coax the online system into updating an offline kextcache (and thus prelinkedkernel). That might be the entire missing piece here. Evidently, my MacBook Air didn't trigger that operation by touching /Volumes/.../System/Library/Extensions - and that was the whole problem - it didn't give two craps about me touching /Volumes/.../System/Library/Extensions since it wasn't the system's booted drive. Weird little disconnect there.

Since I dug so deep through this thread looking for a way to solve this really weird, and evidently never-before-seen issue of trying to un-bork a system drive in an external USB enclosure (scratches head ... I'd think that'd be more common?), I thought it's worth documenting here. At the very least, it prompted some useful chatter :)
 
Hi, I absolutely LOVE the loader and have used it for a few years now. I have a client that will only use Mac Pros and have given life to 2 old 1.1s to his printing business. anyway, I've been away from the machines for a while and I have to do some work on them. So the issue is since getting a new router his Fiery Command Work Station doesn't recognise his network printers, the Mac Pro itself can see them in sys pref > printers. Which would leave me to believe it's a firewall issue to the Fiery application.

I went to have a look at the firewall in sys pref > Secrity & Privacy
I go to unlock the lock 'click the lock to make changes' > correct password. Lock opens and closes immediately after.

So my issue is I can't unlock to view these settings, I remember that this might have something to do with SIP but it was a long time ago since I last dabbled.

Do I need to turn off SIP with the Pike .efi to change : sys pref > Secrity & Privacy ?
Is this possible ?

If I'm missing something any help would be much appreciated.

CHEERS
 
Fix the boot loop. I use the attached file to fix the boot loop after the last El Capitan update is installed. Open it and read the instructions.
 

Attachments

  • k-upload-file_2018-07-18-1daa6b6fffixsecupdelc.dmg.zip
    7.6 MB · Views: 245
  • bootloopinstructions.txt
    848 bytes · Views: 219
Hey Everyone

Spec
Upgraded Mac Pro.
Was 1,1 - up to 2,2, Pikefied, firmwared.
OS 10.11.6
32G of RAM
Original wifi card - Airport Extreme
Wifi firmware Broadcom BCM43xx 1.0 (5.10.131.36.16)
Supports 802.11 a/b/g/n

Wifi issue
Wifi was working pretty much ok getting 15-20 MBps from wireless router downstairs. Then TelcoMan changed the incoming Telco box on the wall by upgrading the "bridge". James Brown help me now.

Since then Mac Pro gets around 0.5MBps. The router is about 8m through the wall and floor.

However ... MacBook Air sitting next to it is getting 38MBps.

So it appears its not the positioning of the MacBook Pro.

My analysis after countless calls to the broadband supplier is that the new "bridge" means the signal is being transmitted by the router in a format that the existing MacPro wifi card can't accept properly.

Proposed Fix
So my proposed fix is to upgrade the wifi chipset or install a USB wifi dongle.

Help sought
Any advice on the following would be great

1. Have I analysed the problem correctly? Is there another reason why the MacPro is receiving very low wifi signal?
2. Is there a method to confirm that this is correct analysis i.e. check its the wifi router signal can't speak to the wifi card properly?
3. If the analysis is correct can I fix it with an upgraded card /Mini PCI/ Big PCIe / USB dongle - which would work?

Attaching (for comparison) the wifi specs of

A. Mac Pro - bad wifi signal
B. MacBook Air - good wifi signal

Cheers

Nick
 

Attachments

  • MacBook Air Wifi Spec.png
    MacBook Air Wifi Spec.png
    240.8 KB · Views: 171
  • Mac Pro 2,2 Wifi Spec.png
    Mac Pro 2,2 Wifi Spec.png
    1.1 MB · Views: 193
Hello,
ALL "SecUpd2018-XXXElCapitan" updates produce a boot loop following the Kernel fix. For now there have been 4:
-SecUpd2018-001ElCapitan
-SecUpd2018-002ElCapitan
-SecUpd2018-003ElCapitan
-SecUpd2018-004ElCapitan

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" (Kernel replacement operations explained by "Larsvonhier" and "kaosnews" (page 170 post #4237):

Fix SecUpdate ElCapitan Mac Pro 1.1-2.1 Start Loop.dmg

To use my tool you no longer need to have a clone of your ElCapitan system disk, for my part I launched my installation package from a External SSD with Lion 10.7.5 and everything worked very well ...
After 3 months EVERYTHING IS STILL STABLE
The "fix the boot loop file" is no longer there.
 
I finally was able to upgrade the Mac Pro 1,1 to 2,1 The eight-core Xeon are shown as that, no longer unrecognized, but the Mac Pro keeps running really hot even at idle under El Capitan. CPU temperatures are twice at those seen on Mavericks. How can I solve that before I undo the CPU upgrades and go back to the original four core Xeon? This issue only happens on El Capitan, Solus (linux) ran fresh as did win10 and every other macOS tested, 10.9, 10.9, 10.7 and 10.6 .. all them at about 45ºC. Under El Capitan temps are close to 100ºC!!

However RAM (32GB) runs now at a cold 35ºC degrees versus over 120ºC seen before upgrade as Mac Pro 1,1
 
Last edited:
I have undone the CPU upgrade, went back to four core Xeon. Still very hot CPU temps on El Capitan, now close to 90ºC
 
You haven't said much about what your El Capitan system is doing
Are there processes running in El Capitan that causes, or contributes to your high CPU temps?
Can you monitor your Activity Monitor, particularly the CPU tab?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.