this thread is about the boot.efi being developed to run El Capitan on EFI32 Mac Pros.
Great. Let Pike know. I don't suppose he'll be able to do much in the next few days. He has the flu.commit 81fa8702089b74dd292349865c6f1c4721eefd44: starts flawles with boot-args "-f" in NVRAM.
bootbase.efi indeed disabled SIP completely (even though csrutil status stated otherwise).
Great. Let Pike know. I don't suppose he'll be able to do much in the next few days. He has the flu.
To everyone interested in this project:
[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.
Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!
Fix compilation error (for MVS 2015, presumably). Contains BOTH boot.efi AND bootbase.efi
Hmmm. I don't know what to say about your being able to rename kexts, etc. Has that always happened with Pike's boot.efi, or only with the latest builds? Supposedly only bootbase.efi (on the Installer) should work that way. The boot.efi I have is the "official" one in Pike's repository, but I haven't tried to change kext's names. In any case, I would say it behaves the way it should.
To everyone interested in this project:
[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.
Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!
Boot without kBootArgsFlagCSRBoot (allow all). Contains BOTH boot.efi AND bootbase.efi
Thanks for sharing this, but it would appear several of the latest builds were flawed as far as security was concerned. They shouldn't be tested anymore. Apparently, commit 51b05ad5c3250ecbee1d0194e8aace5f281f79e1 is now very close to final (for now).With Boot.efi and Bootbase.efi each on their place the patched Installer (MBP2,2) hangs during boot at the same point as the Commit 804c022d9da136482580f5e96dd797e740c3b071 from Sept. 30, 5:16am.
With Bootbase.efi for all three Boot-efi-files, the patched Installer boots but hangs after 2 mins of install with the error:
"Service exited due to signal: Segmentation fault: 11
Endpoint has been activated through legacy launch(3) APIs. Switch to XPC or bootstrap_check_ln()
Kext loading now disabled
Kext unloading now disabled
Kext autounloading now disabled
Kernel requests now disabled."
To everyone interested in this project:
[P]eople must be aware that [this and other] interim future versions are NOT intended as a replacement for the official repository versions. Until further notice, those of you who want to use Pike's boot.efi ought to go to http://piker-alpha.github.io/macosxbootloader/ and download either the "black" version or the "grey" one, according to your particular preference (the change is purely cosmetic; otherwise, they are exactly the same; the choice is irrelevant as far as the operating system is concerned). Pike alone will decide when such repository versions will be updated with a newer version.
Please, notice that the [enclosed and other] upcoming experimental versions might contain bugs that could cripple your ability to boot your old Mac. So, unless you are absolutely certain of what you are doing and know how to reverse such undesirable situations, KEEP AWAY FROM THEM. In general terms, [these] versions ARE NOT FOR YOU!
No, I didn't modify the internal DMG in the install media, so I have to manually replace boot.efi in the two usual folders, in addition to the third place on the Recovery HD. I'll try to build the image tomorrow and upload it somewhere.does your install media create a working/booting El Capitan? or do you have to manually replace the boot.efi at the end? how did you create your install media? just like we used to with Yosemite (hennesie's how-to) or using the createinstallmedia command and afterwards modifying it?
paul, did you check if SIP is really working on your system? I'm pretty sure that the "official" boot.efi you can get from pike's github site is broken and even if csrutil states that SIP is working, in fact it isn't.
That would explain it
Yes csrutil says SIP is active (but I can change files)
I'll update with the latest efi files from here and report back later today.
(I might be hoping too much here but if launchd is calling maybe it has the rights to perform the file system actions even with SIP enabled and working)
creating an installer using the createinstallmedia command and afterwards modify it. this would make use of the bootbase.efi. I was looking into this last night and it looks very complicated to me, a lot of work. countless files to modify/replace. modifying both diskimages etc.