But, unless I misunderstood what you mentioned in Pike's blog, it now gives you the right system id when booting after an NVRAM reset, doesn't it?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
2006/2007 Mac Pro (1,1/2,1) and OS X El Capitan
- Thread starter Mr. Zarniwoop
- Start date
-
- Tags
- mac pro 2006 mac pro 2007
- Sort by reaction score
yes, this seems to be solved now. commit 8cfc32ec09d0abecafe90766984a6c448514cf70 already gave the correct value.
bad timing of my comments ;-) yes, everything ok. commit 8cfc32ec09d0abecafe90766984a6c448514cf70 was the first to give correct system-id value. the one after that (a556a2e555bf773886ec312da7af2e3d58ee5946) gives the same (correct) results.
Mike, you mentioned that ioreg -lw0 -p IODeviceTree | grep system-id" now gives a value that is consistent with a value obtained in a memory dump you got in Lion. I wonder if that is the same as getting the right system id (Hardware UUID?) that one sees in the Hardware Overview screen. You mentioned at least once that the result you got was somehow garbled. Is it still garbled? If it is, there might be a Big Endian conversion issue that boot.efi ought to handle. If what you see after clearing NVRAM in Hardware UUID (or wherever it was you check against) is different from what you used to see in Yosemite and earlier operating systems, do let know Pike about the problem and mention the Big Endian issue.
Back porting a number of clang changes
It is unlikely any new functionality is included in this version.
It is unlikely any new functionality is included in this version.
10.11 (build 15A282a). booted into Recovery HD using latest commit 3e3623d314ff157fdddb41703cf11116677e6fae -> csrutil disable gives failed to modify...
yes, the Hardware UUID displayed in the "System Information.app" is still different from what I see in Lion & Yosemite (Peter asked).
yes, the Hardware UUID displayed in the "System Information.app" is still different from what I see in Lion & Yosemite (Peter asked).
Not sure if the 10.11.1 update would rewrite the boot.efi files (assuming the update does) I performed the update from my rMBP/external drive enclosure then replaced the boot.efi files and reinserted the drive back into my MacPro.... pretty easy procedure.
I wish I had the mad skills some of you guys have going into the boot.efi files and compiling software. Awesome work guys!
I wish I had the mad skills some of you guys have going into the boot.efi files and compiling software. Awesome work guys!
As you know, this is work still in progress, and there are several loose ends. I can't really comment on what each particular version I compile does or fails to do, as I haven't installed El Capitan on my old Mac Pro yet.
It's a curious bunch of guys working together. Pike is the brain behind the whole project, but, as he has said, he's "blind", since he doesn't have an old Mac Pro. I am sort of blind, too, because, although I do have an old Mac Pro, I can't use it to verify these things, as it's a production machine. I won't be able to install El Capitan on it until early October. Finally, Mike could probably compile just as well as me, but he doesn't have the environment properly set to do so. He's the only one who can actually "see" the result of what Pike devises and of what I compile.
Although I have been using my MacPro mostly as my main Mac, my recently acquired Mid 2012 15" rMBP will be taking over duties as my "main Mac" soon so I will be free to test updates on my MacPro.... this is the reason I went ahead and installed El Capitan GM Candidate recently on it using your procedure with successful results. I'm willing to learn and help out as much as I'm able to.... since I have never gone into this realm of modding I realize I have a lot to learn but if you want me to test anything using my MacPro by all means let me know
before testing a new version of boot.efi I'm always clearing the PRAM.
4380ddd3c6802a90c12d5dbe5daa1d77074e5414: Recovery HD did not boot, hang at grey screen with Apple logo. same for El Capitan, can't boot successfully.
4380ddd3c6802a90c12d5dbe5daa1d77074e5414: Recovery HD did not boot, hang at grey screen with Apple logo. same for El Capitan, can't boot successfully.
There was a "Revert and a new test" commit that I missed. Hopefully, it will be included in the new one: "Need data"
e48f10dc77a3e30c7cc420c503a7488fa778cb40: system boots normal, recovery & standard. csrutil disable failed, status -> enabled (Apple internal).
Last edited:
holy ****! status is not “Apple Internal” anymore. csrutil disable works! rebooted into El Capitan and status is DISABLED
Last edited:
Well same here, plus I'm on 10.11.1 (15B17c) with disabled csrutil (SIP).
The steps I've done:
1) Replaced the previous boot.efi on Recovery HD partition with the one @splifingate provided.
2) Rebooted to Recovery, run Terminal, "csrutil disable", DISABLED!
3) Rebooted to El Capitan with the previous boot.efi, tested and said it was still enabled, then I checked the App Store for updates, installed 10.11.1, iTunes 12.3 and rebooted to Yosemite.
4) Replaced on El Capitan the boot.efi to match the same as in Recovery HD.
5) Rebooted in El Capitan, installation progress of the update completed, csrutil was there DISABLED too!!!
So, I think we're getting close now to a final version thanks to Tiamo, Pike, @Hennesie2000, @PeterHolbrook, @mikeboss and of course @splifingate for the last release. Thanks to all for the hard work guys!
Now, the last step is to disable verbose on boot.efi and patch the script to auto replace the boot.efi on the respective locations. I believe in this point, the Recovery HD partition must be added to the script for more simplicity to those who don't have much time to spend on Terminal or the knowledge/patience.
Cheers to all and thanks again!
same here, plus I'm on 10.11.1 (15B17c) with disabled csrutil (SIP).The steps I've done:
1) Replaced the previous boot.efi on Recovery HD partition with the one @splifingate provided.
2) Rebooted to Recovery, run Terminal, "csrutil disable", DISABLED!
3) Rebooted to El Capitan with the previous boot.efi, tested and said it was still enabled, then I checked the App Store for updates, installed 10.11.1, iTunes 12.3 and rebooted to Yosemite.
4) Replaced on El Capitan the boot.efi to match the same as in Recovery HD.
5) Rebooted in El Capitan, installation progress of the update completed, csrutil was there DISABLED too!!!
So, I think we're getting close now to a final version thanks to Tiamo, Pike, @Hennesie2000, @PeterHolbrook, @mikeboss and of course @splifingate for the last release. Thanks to all for the hard work guys!
Now, the last step is to disable verbose on boot.efi and patch the script to auto replace the boot.efi on the respective locations. I believe in this point, the Recovery HD partition must be added to the script for more simplicity to those who don't have much time to spend on Terminal or the knowledge/patience.
Cheers to all and thanks again!
@mikeboss, @PeterHolbrook , Pike- I got a MacPro1,1 flashed to 2,1. I got the GM Seed (with the yosemite boot.efi) installed on a spare drive that can be trashed. I'm happy to help test anything (over the next few days) that you guys need... just say the word...
Thanks for the kind offers from several forum members to test Pike's boot.efi for El Capitan. Naturally, you are all welcome to test how it works (provided you know what you are doing; we can't offer much help at this point), especially when Mikeboss isn't available. The same goes for would-be compilers, who can perfectly replace me when I'm not available.
commit 303daeeb80c6fca0d04b69ab99761da6293b222c booting into Recovery HD with NVRAM emptied: csrutil status -> enabled (Custom Configuration). value in NVRAM is “gAAAAA”. csrutil disable -> success, value in NVRAM "dwAAAA". csrutil enable -> OK, value in NVRAM "EAAAAA". csrutil status -> enabled (Custom Configuration).