FYI: I committed the first changes for El Capitan support into a new branch – El Capitan – for the macosxbootloader.
Pike's Universum
Great people share their wisdom without asking for anything in return…
FYI: I committed the first changes for El Capitan support into a new branch – El Capitan – for the macosxbootloader.
Pike's Universum 
I also tried it when booted into the regular El Capitan installation (no success either). should this work now? your screenshot in your latest blog post is implying that…
No. Not on your Mac Pro. It can be done, but I used a special version. Should not be done as that will make you less secure. Was for testing only.
okay, good. I see, we both agree that SIP should stay intact as intended by Apple.
As a side note, I won’t be around for several hours from about 17:30 (your time, Pike) until possibly late at night. I’ll compile whatever new commits I see before 17:30 and after my return. Good luck.
and I will be away for 3-4 hrs from now on.
Commit 4380ddd3c6802a90c12d5dbe5daa1d77074e5414 compile error:
Error 1 error C2220: warning treated as error – no ‘object’ file generated C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\BootArgs.cpp 791 1 boot
Commenting the line out makes compilation possible.
Should I post the result?
Yes please. The attributes where only used for the call to EfiRuntimeServices->SetVariable.
Shouldn’t the new line 807 of BootArgs.cpp be
if(EFI_ERROR(status = EfiRuntimeServices->GetVariable(CHAR16_STRING(L”csr-active-config”), &AppleNVRAMVariableGuid, attributes, &dataSize, &csrActiveConfig)))
?
On second thought, the line ought to be, I think,
if(EFI_ERROR(status = EfiRuntimeServices->GetVariable(CHAR16_STRING(L”csr-active-config”), &AppleNVRAMVariableGuid, &attributes, &dataSize, &csrActiveConfig)))
We’d better wait for a reply from Mike, or anyone else that used this version. Mike should also start without csr-active-config set in NVRAM, otherwise it will read that value instead.
Yes, naturally. Commit 4380ddd3c6802a90c12d5dbe5daa1d77074e5414 (minus one line) compiled and posted!
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.
Ok. I reverted to a former commit and added new debug output. Let’s see what this brings.
Edit: If the last one also fails, then I need to know the NVRAM content (RecoveryHD).
Commit e48f10dc77a3e30c7cc420c503a7488fa778cb40 compiled and posted!
e48f10dc77a3e30c7cc420c503a7488fa778cb40: system boots normal, recovery & standard. csrutil disable failed, status -> enabled (Apple internal).
Apple Internal is an unexpected value for the RecoveryHD. What debug output do you get?
http://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-el-capitan.1890435/page-18#post-21965224
Strange. It fails to detect the Recovery HD and set the BOOT_MODE_EFI_NVRAM_RECOVERY_BOOT_MODE global.
nothing has changed in my test environment except for the countless boots/restarts and the boot.efi file of course.
Yeah we are just missing something, but you should now see the text: “PIKE: BlInitCSRState(RecoveryOS detected)!” and if not then it is forced into RecoveryOS mode.
Edit: I removed the RecoveryHD text some days ago. Thinking that we got this covered. Apparently not. Say. How do you boot into the RecoveryOS? Are you using Command+R? That I see should set the global.
I’m invoking the startup manager (press & hold the option key).
I vaguely remember an issue where booting into the RecoveryHD with Yosemite failed. Can’t recall if that was with Command+R or the Startup Manager. Perhaps you know?
Edit: Wait. I think I found it! Let me fix this.
yeah, I also remember that there was an issue. no idea what exactly the issue was though… what I know for sure: I never use the command-r key combination (except for the new 2015 MacBook Pro where the Recovery HD isn’t showing up with press & hold of the option key).
I now started into the Recovery HD with command-R method: results are the same. csrutil status gives enabled (Apple Internal). and csrutil disable fails.
I think that this is my fault. There’s BOOT_MODE_EFI_NVRAM_RECOVERY_BOOT_MODE and BOOT_MODE_FROM_RECOVER_BOOT_DIRECTORY. and I only checked the former. New commit available for compilation.
we’ll have to wait for peter being back again…
Ok I thought that he was back already. I guess not then. Anyway. Going to get some food now. Be back later!
commit f3ec1b1 allows me to disable SIP via terminal on 10.11 Recovery HD :
# csrutil disable
“Successfully disabled System Integrity Protection. Please restart the machine for changes to take effect.”
But, a subsequent reboot into same gives SIP status as enabled (I still have yet to get your c-code compiled and placed on an accessible volume).
Second reboot in Recovery HD 10.11 in a minute….
Thank you for this confirmation.
holy ****! status is not “Apple Internal” anymore. csrutil disable works! rebooted into El Capitan and status is DISABLED 😉
And booting back into the RecoveryHD now also gives “disabled”?
nope, rebooting into the Recovery HD from El Capitan with SIP disabled indeed gives “status: enabled”.
And the NVRAM variable is set/can be found from the Recovery HD? You should get something like this:
“PIKE: NVRAM csr-active-config[0x../0x..] found (OK)!”
Edit: Perhaps the variable is removed (I think it is) after you boot back into El Capitan.
PIKE: BIInitCSRState(RecoveryOS detected)!
(repeated 5x)
PIKE: NVRAM csr-active-config[0x77/0x4] found (OK)!
(repeated 5x)
# csrutil status -> “enabled” in Recovery 10.11
Ok the first two stages are fine. Remove the last if clause in function BlInitCSRState (BootArgs.cpp) and recompile.
http://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-el-capitan.1890435/page-18#post-21966487
aha. issued “csrutil disable” and then immediately “csrutil status” which again gives status. enabled.
This is most likely caused by the (test) if clause I talked about in my reply to splifingate.Ehm. You should reboot first. You may want to check this on your MacBook to see if I am right.
yup, tried it both ways. but the value in NVRAM reads “dwAAAA” which should be status disabled, right?
Yes. You can check this online.
Edit: You mean that the NVRAM variable isn’t gone after booting into El Capitan?
somehow “csrutil status” gives a wrong answer when booted into the Recovery HD. I now have SIP disabled and can verify in El Capitan with csrutil and “nvram -xp” and I’m getting the correct answer. when booted into the Recovery HD, SIP is still disabled according to “nvram -xp” but “csrutil status” gives enabled…
Hmm. I knew that csrutil status sucked, but this is crazy. Have you checked this on your MacBook? Are you getting the same results, otherwise we might be chasing a ghost 😉
of course I checked it on the MacBook before posting my findings 😉 and now that you asked I doublechecked this. I’m getting the correct answer on the MacBook.
Cool. Thank you for testing/confirming this. Let’s add another flag… commit done.
Edit: I’ll be off-line for the next couple of hours!
I’d say now we’re almost there. this is a minor, only cosmetic issue. thank you for all your hard work, well done!
another small issue: when booted into El Capitan with SIP enabled, “csrutil status” gives enabled: (Custom Configuration). the value in NVRAM reads “gAAAAA”.
booting into El Capitan with NVRAM emptied: csrutil status -> enabled (Apple Internal). value in NVRAM is “EAAAAA”. when booting into Recovery HD with NVRAM emptied: csrutil status -> enabled. value in NVRAM is “gAAAAA”.
Can’t keep timely flow, it seems ;/
303daee commit:
# csrutil status ->
“System Integrity Protection status: disabled.”
# nvram csr-active-config ->
“w%00%00%00”
# /Volumes/backs2tb/csrstat
“System Integrity Protection status: enabled (0x00000077)(Custon Configuration: 0x00000077).
Configuration:
Apple Internal: enabled
KextRest/FilesystemProt/DebuggingRest/DTraceRest/NVRAMProt: disabled”
I’ve just arrived and have read a few of the latest messages, which I don’t fully understand. Some seem to say that what was reported as not working is working now (!?!). Well, whatever that may be, commit 303daeeb80c6fca0d04b69ab99761da6293b222c has been compiled and posted.
As for a doubt regarding a problem with the Yosemite Recovery HD, I can mention my own experience back in the days I had such a partition (I don’t have one anymore ever since I moved my regular Yosemite partition to a 4TB SSDH). If I wanted to boot to the Yosemite Recovery HD (where one copy of Pike’s boot.efi resided) by pressing Cmd-R when I heard the chime, the Recovery HD would boot normally. However, if I pressed Option when I heard the chime and then selected the Yosemite Recovery HD from the Startup Manager, the REGULAR Yosemite partition would boot up, not the Recovery HD. From what mikeboss has said, it would appear that the El Capitan edition of boot.efi can boot the Recovery HD either way, either with Cmd-R or Option-booting and then selecting it in the Startup Manager, which is just perfect.
Thanks Peter. I hope that more people can confirm this. Nice to see things mature isn’t it. Up to the next step.
Cmd-R always (for me) boots into the lowest-common-denominator Recovery HD.
I destroyed, and completely rebuilt (incorporating the 303daee commit, and modified BaseSystem.dmg’s for each) both my Yose and ElCap Recovery HD partitions, today, and Cmd-R gets me into the ElCap Recovery HD only when the 10.10 Recovery HD is not present.
Next on my list is to try the 303daee commit in the 10.10 installs, et al.
It certainly is, Pike. It’s been a lot of work for you, I know, and the community can hardly ever pay your effort and your immense talent, other than to express our heartfelt gratitude for doing more than anyone to make these old machines “young” again and almost on a par with the best of today’s personal computers.
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).
Let’s see. I am trying to understand the current state. Looks like we are nearly there, but setting csr-active-config to 0x80 when that should be 0x00 is not. Is that everything left to fix now?
booted into 10.11 Recovery HD using 303daee commit with ‘# csrutil disable’ on previous boot with pram cleared between):
# csrutil status ->
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: enabled
# nvram -p ->
“csr-active-config %80%00%00%00”
#/Volumes/backs2tb/csrstat ->
“System Integrity Protection status: enabled (0x00000080)(Custom Configuration: 0x00000080).
Configuration:
Apple Internal: enabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled
I will now try “# csrutil disable”, again…
as far as I can tell, yes, this is the only remaining issue.
Fine. Let’s get to it then 😉
Edit: Done!
Good evening. I have been running your boot.efi sept 21 very successfully and would like to be included in testing . I have a MacPro1,1 and do not need hand holding, however I only have Macports running on ElCapitan GM . Where to you post the image boot.efi and if you don’t could you make it available ?
bob@kalkwarf.com
Bob w7wo
reboot into 10.11 Recovery HD using 303daee commit:
# csrutil status ->
“System Integrity Protection status: disabled.”
# /Volumes/backs2tb/csrstat ->
“System Integrity Protection status: enabled (0x00000077)(Custom Configuration: 0x00000077).
Configuration:
Apple Internal: enabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled
# nvram csr-active-config=%ff%00%00%00 ->
“nvram: Error setting variable – ‘csr-active-config’: (iokit/common) general error”
(e.g., any ‘nvram csr-active-config=%bla%bla’ produces the same error)
303daee commit boots successfully into existing Yose install…
303daee commit boots successfully into existing 10.10 Recovery HD (without incorporation into BaseSystem.dmg)
graph mode mod of 303daee commit boots into Yose fast . . . really> fast &lgt;smile&rgt;
I would enjoys testing boot.fi whenever you can make the image available to me. Email includes works for me. I currently run your boot.efi dated Sept 21, 2015 on my MacPro1,1 and ElCapitan GM release plus the one update from apple. I promise not to inject anything into your process that seems to be very smooth and no bickering or nonsense.
Sincerely,
Bob Kalkwarf w7wo
bob@kalkwarf.com
Herein, the link to my latest compiled boot.efi:
http://forums.macrumors.com/attachments/boot-303daeeb80c6fca0d04b69ab99761da6293b222c-zip.586554/.We must now link to this page. Thanks!
Thanks, BobK
the latest build of the boot.efi can be downloaded here.
Successful update to ElCap 10.11.1 (15B17c), with only the need to replace the usual .efi culprits.
PIKE: NVRAM csr-active-config[0x77/0x4] found (OK)!
(repeated) on initial boot
(from within running ElCap install (as Admin)):
# /Volumes/backs2tb/csrstat ->
“System Integrity Protection status: enabled (0x00000077)(Custom Configuration: 0x00000077).
Configuration:
Apple Internal: enabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled
reboot into 10.11 Recovery HD using 303daee commit after pram cleared:
PIKE: BlInitCSRState(RecoveryOS detected)! {x5}
PIKE: NVRAM csr-active-config NOT found (ERROR: 2147483662)! {x5}
PIKE: NVRAM csr-active-config[0x80] set (OK)! {x5}
PIKE: bootArgs->CsrActiveConfig[0x80] set! {x5}
# csrutil status ->
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: enabled
#/Volumes/backs2tb/csrstat ->
“System Integrity Protection status: enabled (0x00000080)(Custom Configuration: 0x00000080).
Configuration:
Apple Internal: enabled
Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled
Commit 5d3d273a7c49ccb5c63cf40b6100596a3ad79433 compiled and posted!
Thank you Peter. If this one works then there will only be one more commit to compile for development phase 2.
commit 5d3d273a7c49ccb5c63cf40b6100596a3ad79433: boots normal. started into Recovery HD (empty NVRAM). csrutil status is enabled. I then disabled SIP using csrutil disable. reboot into El Capitan. -> status disabled. reboot into Recovery HD: csrutil enable -> OK. reboot into El Capitan: csrutil status gives enabled (Apple Internal). value in NVRAM is “EAAAAA”. oh, and what about the “Hardware UUID” reported in “System Information.app” being different than what is displayed in Yosemite and/or Lion, is this a non-issue?
Cool.
About the UUID. If your system-id in El Capitan is the same as what you get with Lion/Mavericks, then I guess so, but I need new Darwin Dumps of both OSes to see if there is anything I can do about it.
Edit: Done. There is no “system-id” property set in Lion so the hardware UUID will be totally different. This is normal behaviour. Apple changed things for iMessage support and the system-id is one of the checked properties. In short. Everything is fine!
Shouldn’t the value in NVRAM be “gAAAAA” (just enabled, without “Apple Internal”) after enabling SIP again?
I will send you fresh Darwin Dumps.
Nope. The value 0x80 should never be visible on the user-end side.
Thanks!
sorry, of course you’re right. checked with the MacBook and it behaves exactly the same as the old Mac Pro with your boot.efi.
Perfect. Thank you for the confirmation.
Commit 0395f815b8b32097a582739f8b4a831375243782 compiled and posted. I’ll be away for three or four ours from right now.
Pingback: El Capitan support for unsupported hardware is here! | Pike's Universum
Commit 740058620f1fd8827bcf0aef74a448bbaaf2a00c has been compiled and posted, together with the following comment:
Presumably final (as far as phase 2 goes) black and grey versions of Pike’s boot.efi.
To all parties interested: Please, test these two versions of the latest commit (740058620f1fd8827bcf0aef74a448bbaaf2a00c, created about one hour ago). The one dubbed “grey” is the compilation of said commit the way I found it. The one dubbed “black” is the compilation of a modification of StdAfx.h, whereby a couple of #define directives have been swapped. Any errors should be attributable to me, not to Pike. In theory, the “grey” version should resemble the boot.efi of the era previous to Yosemite, whereas the “black” version should resemble the boot.efi now customary with newer Apple hardware since Yosemite. Please, test BOTH versions and see if there are any shortcomings. Report your findings here and/or in Pike’s blog.
Sorry, I’ve just seen that there’s an “official” download repository for both versions. Please, disregard my previous post.
No problem. We want everyone to use one and the same copy of boot.efi which by the way should also help me to track bugs/issues, and stop people from adding junk to it – since El Capitan is meant to protect your privacy and data, we must be careful with who does what or all hell may break lose.
Yes, of course. If you want me to, I’ll go on compiling whatever improvements you introduce in phase three for mikeboss to test. When I compile and publish such interim versions, I’ll include a clear reminder that they are not intended for general use, nor are they to take the place of the official repository black and grey versions, which will only be replaced when you say so.
Hi Piker!
Does the el capitan boot.efi (3.1) works with yosemite 10.10.5?
I don’t know. Don’t have old Mac hardware myself. Please visit the macrumors.com forum.
Hi Pike,
Have you seen this? Some generous folks are offering up an old Mac Pro, if you want/need one to help continue your work on macosxbootloader!
http://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-macos-sierra.1977271/page-7
Hi Piker I moved here the conversation posted in the wrong area (License section, my bad sorry about that :|)
[…]
freakqnc | March 26, 2017 at 5:46 am
Thank you a ton Pikeralpha! I have been running El Capitan on Mac Pro 2,1 for more than 1 year, stable and nice. Shame on you Apple for not supporting owners of perfectly good Mac Pro and other 32-bit EFI macs to be forced into obsolescence for no real reason other than forcing them to retire their macs and get new ones. When moving from OS 9 to OS X from IBM chips to Intel, Apple included Rosetta and created universal binaries to support all macs during and even more complex transition from one platform to the other, but nothing to allow 32-bit EFI macintosh computers to run 64-bit OS which thanks to Piker’s bootloader have been proven to be more than capable to run extremely well. So much for thinking different Apple!
freakqnc | March 28, 2017 at 2:40 am
PS: I guess there won’t be no Sierra version of the bootloader since even if allowing to boot unsupported macs, the lack of SSE4.1-capable CPUs won’t let us use Sierra on older macs… am I correct?
pikeralpha | March 28, 2017 at 8:46 am
It should work with a kernel for AMD processors, which includes the required patches.
freakqnc | March 30, 2017 at 12:54 am
Hi Pike and thanks for the fast reply…
Posted a followup question, but looks like did not go through… so I am trying again.
How would one go about it? I gathered some info on the dosdude1 page http://dosdude1.com/sierrapatch.html and on the thread of the YT video where he’s explaining how to use the patch here: https://www.youtube.com/watch?v=eQz5OQHOTAA
I commented asking the following: “Looks like that with this patch one could install macOS Sierra ONLY on machines that had 64-bit EFI and natively supported running El Capitan. This is not going to perform what PikerAlpha’s modified boot.efi used to do and allow unsupported macs with 32-bit EFI (although they had 64-bit CPUs like my mac pro 2,1). Would that be a correct assumption? Thanks disdude1 :)”
Then dosdude1 replied by saying: “Not exactly. It WOULD actually work using that method, but the reason it doesn’t is because the CPUs used in those machines don’t support SSE4.1, and the chipset doesn’t support any CPUs that do.”
I was led to think that due to lack of SSE4.1-capable CPU Sierra would have no chance to work on Mac Pros (1,1 2,1 3,1 and 4,1 which dosdude1 reports ad unable to use his patch).
If that’s not the case and a way to make things work does exist by using a kernel for AMD as you said above, that would be great news!… if one would had any idea of what that means and how to go about accomplishing it. Due to my limited knowledge on the inner workings of the mac OS kernel, I wouldn’t know where to start. Any way you could shed some light on it? I am willing to learn and experiment on my 2,1 and if I get things working I will more than gladly pass the info along.
Thanks much Pike!
[…]