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

[flyinmac]

It would be interesting to find out if there are any modules / api’s, coding, etc. in the rest of the 2018-001 update that have any dependencies on the updated kernel.

It could be that the kernel portion is more stand alone and only addresses the cpu vulnerability.

But if the updates are meant to work together, then we could have a potential problem somewhere.

I’d be curious if we could come up with a hack similar to Boot64 that would prevent the kernel from being overwritten. Or even possibly script it to put the old kernel back prior to reboot or during reboot.

Like a boot audit that interrupts the startup long enough to verify the kernel, and replaces the kernel with the old one if it determines that it’s not there. And then rebuilds the links as needed.

 

[jbarley]

Might be of interest to some, this 2018 update fails even on my so called El Capitan supported MacPro3,1.
Same ole "boot-loop", same kernel swap needed to fix it.
edit:
found a workaround for this, cloned a fully updated El Capitan system complete with ehe 2018-001 security update from my wife's laptop to my MacPro 3,1 and it works.
Now just have to do some cleaning up and get rid of all her "stuff".

 

[plentyoftimeto69]

Took the 2018 pactch on my 2,1 and borked it. Easy fix is to create a Pikify USB boot, extract the 2017 kernel from the 005 patch, copy it to the Pikify disk, then boot the Pikify in the Mac Pro. You have to remount /Volumes/Macintosh HD as read/write and then you can use the Terminal util on the install disk to copy over the Kernel. Follow the steps in the previous how-to, just adjust paths as needed.

 

[Mystere65]

Rebuilding and copy back is not the same

Rebuilding means the system does it

And for the next updates? In practice, the Mac would become a Hackintosh

 

[rthpjm]

And for the next updates? In practice, the Mac would become a Hackintosh

The next Security Update will most probably contain the same "problem" kernel file, or another updated kernel with similar issues.

I agree that we are now "hacking" the OS to keep "up to date". However, as I stated earlier rolling back the kernel seems to work, but may introduce unexpected behaviour due to incompatibilities, now or at some point in the future.

Having decided that the issue lay with the kernel file, I gambled that the changes were going to be specific for MacPros that are affected by Spectre and Meltdown. I assumed the changes to the kernel were unlikely for other aspects, therefore rolling back to the previous kernel would be a workable solution. My assumption is that Apple rarely change the kernel, and that they would not necessarily change the El Capitan kernel beyond what was absolutely deemed necessary since it is 2 generations older than the current OS that is in development (High Sierra). I did no NO investigation, I guessed. I do NOT know what the impact will be. There was no code-base to check (although I might go and take a look at the Open Source web site later, just from professional curiosity).

The "safe" thing to do is to stop at 10.11.6 and the all updates up to and including Security Update 2017-005. This is no different to many end-of-life situations. The MacPro 1,1 and 2,1 should have stopped at 10.7.5. All of the work that has happened since has enabled us to continue to operate with the newer versions of Mac OS X up to El Capitan. Those of us that chose to do so have been operating "at risk".

Ultimately, only you (the person reading this) can make the decision about what level of risk you are willing to take.
[doublepost=1517216477][/doublepost]

But if the updates are meant to work together, then we could have a potential problem somewhere.

Exactly!
[doublepost=1517216623][/doublepost]

I’d be curious if we could come up with a hack similar to Boot64 that would prevent the kernel from being overwritten. Or even possibly script it to put the old kernel back prior to reboot or during reboot.

I'll take a look. If I can I will update Boot64.

Warning: don't hold your breath!

 

[dreamersofeden]

Well,

I got my borked Mac Pro 2,1 back to work simply by taking the kernel from my sister's iMac with 2017-005 update installed. I did the touch thing ("sudo touch /System/Library/Extensions") ando also verified and repaired disk permissions.

Now, the only issue I'm having is that when installing nVidia Web Drivers, it fails since the kernel is "untrusted".

This is what log shows:

Jan 29 11:54:09 Danny installd[792]: PackageKit: kextcache -system-caches
Jan 29 11:54:10 Danny installd[792]: PackageKit: kextcache -update-volume / -Installer
Jan 29 11:54:10 Danny installd[792]: kextcache: Untrusted kernel '/System/Library/Kernels/kernel' cannot be used
Jan 29 11:54:10 Danny installd[792]: kextcache: Child process /usr/sbin/kextcache[847] exited with status 77.
Jan 29 11:54:10 Danny installd[792]: kextcache: Error 107 rebuilding /System/Library/PrelinkedKernels/prelinkedkernel

How can I force system to make that swapped kernel trusted?

Thanks in advance and hope we can make this badass aluminum machines live longer!

 

[rthpjm]

Well,

I got my borked Mac Pro 2,1 back to work simply by taking the kernel from my sister's iMac with 2017-005 update installed. I did the touch thing ("sudo touch /System/Library/Extensions") ando also verified and repaired disk permissions.

Now, the only issue I'm having is that when installing nVidia Web Drivers, it fails since the kernel is "untrusted".

This is what log shows:



How can I force system to make that swapped kernel trusted?

Thanks in advance and hope we can make this badass aluminum machines live longer!

• Boot into your Recovery HD
• Turn off SIP

csrutil disable

• reboot to your usual MacOS
• use a Terminal

sudo -s
{type your usual password}
cd /System/Library/Kernels
chflags restricted kernel

• reboot into your Recovery HD
• Turn SIP on

csrutil enable

• reboot to your usual MacOS

Try that. There's no guarantee. Nvidia may be checking independently, we're in an odd situation now, the kernel will be older than expected.
[doublepost=1517243031][/doublepost]

I did no NO investigation, I guessed. I do NOT know what the impact will be. There was no code-base to check (although I might go and take a look at the Open Source web site later, just from professional curiosity).

Hmm, replying to myself. Is that the first sign that I'm going MAD!


Anyway, The Open Source web site has not yet been updated (as far as I can see).

I took a closer look at the two kernels. There are some new functions (symbols) and some existing symbols are changed/moved in the binary

New symbols
_NMIPI_enable
_cpshadows
_cpu_data_master
_dblallocs
_dblmapL3
_dblmap_base
_dblmap_dist
_dblmap_max
_dblsyscall_patch_point
_doublemap_init
_dyn_dblmap
_dyn_ldts
_hdescseg
_idt64_unix_scall
_idt64_zero_div
_ks_32bit_entry_check
_ks_64bit_return
_ks_dispatch
_ks_dispatch_kernel
_ks_dispatch_user
_ks_idt64_debug_kernel
_ks_idt64_nmi_kernel
_ks_kernel_trap
_ks_return
_ks_trap_check_kernel_exit
_ldt_alias_offset
_mldtsz
_npz
_pcid_data
_pmap_alias
_pmap_uanchor_zone
_scdatas
_scdtables
_scfstks

changed/moved symbols
__intr_0x20
:
: There is a large number of these symbols, presumably interrupts. The symbols increment in number
:
_hi64_syscall
_hi64_sysenter
_idt64_alignment_check
_idt64_bounds
_idt64_db_task_dbl_fault
_idt64_db_task_stk_fault
_idt64_debug
:
: There are a large number of these idt64 prefixed symbols
:
_master_ktss64
_master_ldt

The new NMI PI (non-maskable Interrupt) seems to me to be the most likely candidate for our troubles... Those with more chip/hardware experience might be able to throw more light on the subject...

 

[Macschrauber]

I made a copy of my El Capitan (pre Security update 2018-001) and fiddled a bit:

in few words: Backed up the old Kernel to Desktop, run the Security update 2018-001, rebuild in Recovery)



>
before security Update 2018-001

reboot in recovery


open Terminal:

csrutil disable


reboot into system


open Terminal:

cd /system/library/kernels
cp kernel ~/desktop


do security Update 2018-001


after security Update 2018-001

bootloop, shut down,


boot into recovery

in Terminal:

mount -uw /
touch /volumes/yourharddrivename/System/Library/Extensions
cd /volumes/yourharddrivename/System/Library/Kernels
cp kernel kernelsecurityupdate

(just to have a backup)

rm kernel
cp /volumes/yourharddrivename/Users/yourusername/desktop/kernel kernel



(reboot)

(System got up)

nvidia driver was disabled - as I had a supported GPU in it asked for an update without glitch

 

[Xenomorph]

Thank you for the updates! I had to look up this thread again after my Mac Pro went into a boot loop from the 2018-001 update.

I was able to get back up and running:

* booted to 10.7 / Lion on another partition
* download the El Capitan 2017-005 update
* extracted the 2017 kernel from it using Pacifist
* copied the 2017 kernel over the 2018 kernel on my El Capitan partition
* ran 'touch /System/Library/Extensions' on the El Capitan partition

My system booted right back into 10.11!

 

[Macschrauber]

So at least we have a workaround...

 

[Mystere65]

So at least we have a workaround...

Restoring the old Kernel I would not consider it a real solution

 

[mani girafe]

So for my part, I just made the updates SAFARI and ITUNES, hidden the 2018-001 while waiting for a solution.

Otherwise I cloned my hard disk, and I will try the update soon. We'll see about that.

 

[F1Mac]

For me the it's not worth the trouble, considering these chips are not even affected... If 2017-005 is the last security update to be installed on my 2006 Mac Pro, so be it!

 

[Inspector42]

The new NMI PI (non-maskable Interrupt) seems to me to be the most likely candidate for our troubles... Those with more chip/hardware experience might be able to throw more light on the subject...

I have to admit that my knowledge has become quite rusty as the last time I did hard core assembler programming and processor boards design was in the times of the 8086. However I took the plunge, downloaded the https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf and started reading. Now in the old days NMIs were triggered by a signal to one of the processors I/O pins only, the modern processors allow a software trigger (INT n, where n=2 triggers the NMI). That has been available since the Pentium days at least.
Don't really know, for what that non-maskable interrupt is used for in a Mac, in the old days it was used to drive the display routines that needed to adhere to Tube-TV timing.
So without gaining any insight into where the interrupt vector tables are stored and what addresses they contain, this is a dead end for me.
Someone posted that the verbose mode did not really reveal any useful hints regarding the cause of the reboot either and I don't know, if there is more information logged elsewhere.
The only other hint I saw in the postings was the case where the same boot loop occurred on a compatible MacPro3,1 - but the solution of cloning another hard disk form a compatible laptop does also not ring any bell.

So in conclusion, a lot of words but no real progress

Update: Found some more documents and it seems the NMI in a MacPro is triggered either by ECC-RAM errors or in debug-mode.
https://developer.apple.com/library/content/qa/qa1264/_index.html
I have not found any circuit diagrams to get more info about involvement of the SMC in this.

 

[the bug]

Things that make you go Hmmmm...
Coincidence ?
I know we are talking about mostly Clovertown CPUs here but...
I don't know, just sayin'.

https://redmondmag.com/articles/2018/01/22/intel-meltdown-patch-reboot-problems.aspx

- Jay

 

[prosinader]

Hello, I am having the same issue of reboot loop after updating to the security update (didn’t even think about it until the problems started). To protect against updates, I’ve always maintained a second hard drive with 10.11 on it to copy the EFI file back when things don’t work.

Naturally, I (still without thinking) booted into my “backup OS” and copied the EFI file and tried booting and still had the reboot loop.

So, my question is - can it be saved still using my backup OS drive? Is it as simple as copying the kernel over?

 

[joeberk]

Like a few others, the kernel copy seems a bridge too far and it looks like I should start saving to replace my old Mac Pro 1,1 with a newer machine that isn't older than both of my children.

I share this because I wanted to offer a heartfelt THANK YOU to everyone who has invested time and effort to create and share the tools needed to keep old Mac Pros running for this long.

 

[Inspector42]

Things that make you go Hmmmm...
Coincidence ?
I know we are talking about mostly Clovertown CPUs here but...
I don't know, just sayin'.

https://redmondmag.com/articles/2018/01/22/intel-meltdown-patch-reboot-problems.aspx

- Jay

Good catch - however I am afraid it is just a coincidence.
Those reboots happen randomly after installing the Intel provided microcode updates for the processors through Firmware of the computers/mainboards. The only firmware update included in the security update 2018-001 for the MacPros was for the 6,1. Those are based on Ivy Bridge architecture and considering the struggle Intel went through to provide those updates to the more recent processors suggests that there are no microcode updates for Ivy bridge included, but that is just my 5 cents.
[doublepost=1517380367][/doublepost]

Hello, I am having the same issue of reboot loop after updating to the security update (didn’t even think about it until the problems started). To protect against updates, I’ve always maintained a second hard drive with 10.11 on it to copy the EFI file back when things don’t work.

Naturally, I (still without thinking) booted into my “backup OS” and copied the EFI file and tried booting and still had the reboot loop.

So, my question is - can it be saved still using my backup OS drive? Is it as simple as copying the kernel over?

The culprit is not a replaced boot.efi by the update.
There seems to be an incompatibility with the updated kernel - only option for now is rolling back the kernel.
Please follow instructions in post #3896 by @rthpjm.

 

[Rocketman83]

Hello, I am having the same issue of reboot loop after updating to the security update (didn’t even think about it until the problems started). To protect against updates, I’ve always maintained a second hard drive with 10.11 on it to copy the EFI file back when things don’t work.

Naturally, I (still without thinking) booted into my “backup OS” and copied the EFI file and tried booting and still had the reboot loop.

So, my question is - can it be saved still using my backup OS drive? Is it as simple as copying the kernel over?

After I encountered the boot loop issue, I used Recovery Mode to restore my pikified Mac Pro 2,1's main drive from Time Machine. I chose a dated backup created shortly before I had installed the problematic security update. I knew it was a risky move, but I restored onto my El Capitan OS drive (rather than a fresh drive) effectively erasing everything on it. (If I couldn't boot into the El Cap drive, the data on it wasn't much use to me anymore anyway.) Long story short, the restore worked pretty seamlessly. I was back up and running in maybe 3 hours. I cleared the PRAM on my next reboot. It hiccupped a bit during the boot up process, but eventually booted up normally. After several days now, my machine seems to be working perfectly. I have since hidden all Apple updates on the App Store.

 

[nebojsak]

Got stuck in a boot loop twice before reading this thread updated. Fortunately I have been able to boot into recovery mode and then boot from Time Machine backup, then install Safari and iTunes updates manually. Everything is working fine by now, except the boot screen is now black with a white Apple logo, and it used to be old white one. Any ideas on it?

edit: Radeon 5770 original one from OWC, not a PC version

 

[Argyboy]

Like a few others, the kernel copy seems a bridge too far and it looks like I should start saving to replace my old Mac Pro 1,1 with a newer machine that isn't older than both of my children.

I share this because I wanted to offer a heartfelt THANK YOU to everyone who has invested time and effort to create and share the tools needed to keep old Mac Pros running for this long.

You can still continue to use this machine on El Capitan. As others have said, we've been running an unsupported OS since 10.7.5. No reason to stop now, really, especially seeing as our Xeon chips don't seem to be affected by the recent security issues.

Or, why not just install Windows 7/10 on it? I've had both Windows 7 and Windows 10 on my 2,1 and they both run great. Lots of life left in these machines yet!

 

[joeberk]

You can still continue to use this machine on El Capitan. As others have said, we've been running an unsupported OS since 10.7.5. No reason to stop now, really, especially seeing as our Xeon chips don't seem to be affected by the recent security issues.

Oh, I'll keep using it, but in a year or two ... too many of the apps I use will no longer support El Cap. I'd rather save up some money and be ready when the right machine or deal comes along ... heck, if I save up waiting for a new Mac Mini, I might be rich by the time a new model is actually released...

I spent $250 on my 1,1 a couple years ago and probably spent $200 on WiFi, Bluetooth, better graphics, and a couple drives. I got my money's worth and then some.

Or, why not just install Windows 7/10 on it? I've had both Windows 7 and Windows 10 on my 2,1 and they both run great. Lots of life left in these machines yet!

I'm not that desperate! I get enough Windows at work!

 

[chrisinoakland]

Thank you for the updates! I had to look up this thread again after my Mac Pro went into a boot loop from the 2018-001 update.

I was able to get back up and running:

* booted to 10.7 / Lion on another partition
* download the El Capitan 2017-005 update
* extracted the 2017 kernel from it using Pacifist
* copied the 2017 kernel over the 2018 kernel on my El Capitan partition
* ran 'touch /System/Library/Extensions' on the El Capitan partition

My system booted right back into 10.11!

Thank you! This was exactly the quick info I needed after rather clumsily applying the 2018-001 update earlier this evening. My steps were even easier as I had a backup of the previous kernel file (CCC saves the day).

You (and all the others that worked through this issue) got me back up and running really quickly!

Oddly, I am now experiencing my MacPro's 1,1 internal Bluetooth not being found with this update installed; it's reporting "Bluetooth: Not Available" but I can live with that for now until I can suss that out.

Thanks again everyone. This thread has kept me happily using my 1,1 far longer that I would have ever expected.

 

[Mjsais]

So for my part, I just made the updates SAFARI and ITUNES, hidden the 2018-001 while waiting for a solution.

Otherwise I cloned my hard disk, and I will try the update soon. We'll see about that.

---------------
Did the safari update worked? I hid all the updates in order o prevent an accidental problem.

 

[waimtrp]

Yes, safari update work , no problem .