I did. I had to reinstall the entire system with Pikify 3.1 v.14 and the boot was fixed again.
The v64 boot locker doesn't work either.
******DO NOT UPDATE EL CAPITAN Security update 2018-002 ******
It is not a security update, it is a boot.efi fix for 32bits OS X system.
(I'm on El Capitan 10.11.6 - Mac Pro 2,1)
Hello Thierry
The issue with the 2018-002 is not due to the boot.efi file. (Boot64 and CapitanPikeFix do their job, and continue to do the job well). The 2018-002 is the second security update released this year, 2018-001 and the recently released 2018-002 contain many system file updates, including an update to the kernel file itself. It is the updated kernel that causes the original MacPros an issue.
The security updates are “cumulative”, therefore update 002 will contain all the updates of 001 plus any more recent changes from Apple. Since Security Update 2018-001 causes issues for our old MacPros, it is to be expected that Security Update 002 and all future revisions will also cause problems.
Please take the time to read post #1 in this thread.....
[doublepost=1522872024][/doublepost]
I could use some help! I'm lazy/efficient by nature so downloaded the pikify 1.8 app and ran it and it ran without error and selected the black screen option and then said it was ready to reboot and then I got the following error message on the boot. Do you know of a fix or should I just build the OS back to LION and start over? I have a macPro 1,1 with 32GB RAM and 12TB RAID Stripped with an nVidia 8800 graphics card. Any help is appreciated!
Hello cajohn32
As
@Sko pointed out, the screen shot shows what looks like a REALLY old kernel being used during the boot process. (Darwin version 11.4.2 based on xnu-1699.32.7). I think something has gone very "wrong". Darwin version 11 is the designation used for the Lion series of MacOS (Darwin version 15 is the designation used for the El Capitan series of MacOS) - so it looks like you are trying to boot into Lion, but there is a residual parameter RAM setting pointing to the El Capitan installer location, basically the machine is trying to use an old version of kernel to run a new version of code. It didn't like it and it has panicked!)
Try to clear your parameter RAM, see my signature field below for a link to a post for PRAM and SMC resets... Then see if you can boot...
If you cannot boot "normally", or you boot into your Lion installation, then start over, try again with Pikify....
Please confirm that your MacPro 1,1 has at least 12GB of RAM, and that the RAM is properly installed in pairs of equal-size. (Edit: Ah, I re-read your post and I see you state 32GB of RAM)
Out of interest, once the Pikify App finished, did it present the option to reboot?
Did the crash occur during this reboot, or did you use the machine and make changes before you tried to reboot?
--------------------
For those that are interested,
The first line in the screen shot asserts the panic condition - it shows that the machine began to boot and reached the first running process which is always the launchd process (launchd always has the process ID of 1). it is launchd that has crashed. Usefully the panic also gives us a reference to the point it reached when it crashed, which was .../xnu/xnu-1699.32.7/bsd/kern/kern_exec.c:3546
So we now know that the kernel had a problem with launchd
Skip over the backtrace lines...
Then we see BSD process name corresponding to current thread: init
init is one of the very low level pieces of code that straddles the EFI pre-boot environment and the actual running of the kernel (that's a really bad description, but it will suffice here).
The next line indicates that the init process was given the Boot arguments "config=\OS X Install Data\com.apple.Boot"
\OS X Install Data is the folder on the disk that Apple/Pikify writes the installer software into.
com.apple.Boot is an XML/plist file that tells the OS how to launch the installer code
Then skip down to the Kernel version lines:
Darwin Kernel Version 11.4.2 is the Apple-friendly name, xnu-1699.32.7 is the alternate designation
We can also see that this machine is a MacPro 1,1
So the panic occurred, and gives us an indication that the kernel panicked. The panic line says xnu-1699, which concurs with the Kernel version lower down.
Using your favourite search engine it's relatively easy to look up MacOS versions and the corresponding kernel versions.
Kernel version 11.4.2 is the kernel from one of the versions of Lion.
It would appear then that
@cajohn32 has probably interrupted the boot sequence.
A working theory is perhaps the "bless" command did not get actioned properly, or that
@cajohn32 held down the ALT key after the boot chime and chose the Lion disk manually from the boot selector screen. This will have the effect of running the Lion kernel and Lion startup sequence. HOWEVER, the PRAM has boot args set to the El Capitan installer location.
When launchd attempts to run some of the El Capitan installer code, the kernel receives instructions that it is not expecting, causing the panic....
The correct sequence should be:
The bless command points to the El Capitan Installer location (OS X Install Data)
This folder contains a boot.efi file, a com.apple.Boot plist file, and a "pre-linked" kernel.
All three of these files are from the El Capitan software versions.
The boot.efi file will hand over to the prelinkedkernel file, which in turn is used to execute the unpacking of the InstallESD disk image, which in turn runs the Installation process.
@cajohn32's problem then is that the machine is launching with the lion kernel then attempting to run El Capitan era code... BOOM
Clearing the PRAM should sort it out...
It will clear the boot args, meaning the Lion sequence will launch correctly
