Have you replaced ALL occurrences of boot.efi (and of the new boot.efi-like [I can't remember its name right now]) within the dmg in the Recovery HD? I wonder if failure to disable SIP from the Recovery HD environment might be due to the fact that not ALL such occurrences have been replaced with Pike's boot.efi.
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
Hello @PeterHolbrook, I think that the Recovery HD isn't "linked" somehow with the OS X installation.
I got errors saying that csrutil can run on the Recovery Mode only. That means that it doesn't "know" that the OS X is installed on the same HDD.
Just a silly idea.
BTW. I replaced 3 instances of boot.efi (on the root, on /System/Library/Core Services and on /usr/Standalone/i386) of the BaseSystem.dmg on the Recovery HD.
I got errors saying that csrutil can run on the Recovery Mode only. That means that it doesn't "know" that the OS X is installed on the same HDD.
Just a silly idea.
BTW. I replaced 3 instances of boot.efi (on the root, on /System/Library/Core Services and on /usr/Standalone/i386) of the BaseSystem.dmg on the Recovery HD.
Thanks for the input, but, unless I misunderstood what Mike said several weeks ago, there's a fourth occurrence of boot.efi, under a different name, within BaseSystem.dmg. Perhaps it would be a good idea to replace that as well (renaming it, naturally) and see what happens.
this new, additional copy of the boot.efi can only be found on the (USB) installer volume. it's in /System/Library/CoreServices/bootbase.efi
except for the dmg, I replaced all copies of the boot.efi on my El Capitan installation. but since the Recovery HD works just fine by only replacing the copy in /Volumes/Recovery HD/com.apple.recovery.boot/boot.efi I assume that this is the one which gets loaded during system start.
another indication that it's not needed to replace the one in the dmg would be the fact that we got different behavior when testing was done with different versions of pike's boot.efi.
Mike, I tried with only /Volumes/Recovery HD/com.apple.recovery.boot/boot.efi replacement and also the PlatformSupport.plist but could not boot into Recovery HD.
Then I did all the steps @splifingate mentioned here and only then I could boot into Recovery HD partition.
huh? very strange. I just re-checked: on the Recovery HD there's /com.apple.recovery.boot/BaseSystem.dmg this is the disk-image we're talking about? mine is untouched, it still contains Apple's boot.efi. and I certainly can successfully boot into this Recovery HD.
Using that Recovery HD, is there a way to deactivate/activate SIP without using the Terminal, such as using a menu? If there is, does that work, or does it also report a failed operation?
there was such a menu in early El Capitan DPs. but it's gone since many releases/weeks.
interesting article you linked to on pike's blog. maybe the problem is not in the boot.efi at all?
Yes Mike, this is it. To me, untouched doesn't boot. Only with the mentioned procedure above.
Maybe it's because I have so many bootable drives (I doubt) or 3 Recovery HD Partitions... but with Option pressed and selecting it, it boots only with the boot.efi changes inside BaseSystem.dmg under com.apple.recovery.boot folder.
I will do a fresh install and check again...
EDIT
I did a fresh install to an emptied ssd installed in a MacPro5,1. replaced the three boot.efi files in /System/Library/CoreServices & /usr/standalone/i386/ and /Volumes/Recovery HD/com.apple.recovery.boot/ nothing more. I can start into the recovery partition, no problem at all.
EDIT
I did a fresh install to an emptied ssd installed in a MacPro5,1. replaced the three boot.efi files in /System/Library/CoreServices & /usr/standalone/i386/ and /Volumes/Recovery HD/com.apple.recovery.boot/ nothing more. I can start into the recovery partition, no problem at all.
Last edited:
bootbase.efi is extant in the .dmg in the 10.11 Recovery HD partition (see attached).
I can boot into the 10.11 Recovery HD without effort (however I choose) with an unmodified BaseSystem.dmg, the same as Mike . . . yet, with Mav and Yose, I needed to mod the .dmg to achieve boot like VAGD reports.
I currently have only a 10.10 and a 10.11 Recovery HD present.
I'll mod the Recovery BaseSystem.dmg when time permits to see if things change, esp. wrt 'csrutil disable'....
Attachments
Very interesting. I don't have a recovery partition of any kind right now, ever since I moved my Yosemite partition to a 4Tb SSHD. In any case, I never modified BaseSystem.dmg inside the Mavericks and Yosemite recovery partitions. Oddly enough, back in the days I had Mavericks (with Tiamo's boot.efi), Option-booting was still possible. Early in Yosemite's days, Option-booting didn't work, and I could only get to the recovery environment by pressing Cmd-R at boot time. As for El Capitan on a physical machine, I haven't tried yet.
My hunch is that the presence of bootbase.efi must have some significance to designate the El Capitan Recovery HD as such, and I believe that file is NOT present in the regular El Capitan partition. If my hunch is correct, the successful use of csrutil enable/disable might be achievable by simply replacing the stock bootbase.efi with Pike's boot.efi and renaming the latter. Chances are that running certain options of csrutil (such as disable) requires the execution of code routed explicitly to bootbase.efi (which is not available in the non-recovery version of El Capitan). On an old Mac Pro, an unmodified bootbase.efi will simply fail to run because of their 32-bit EFI. But I might be wrong, of course. This is only a theory.
placed this new boot.efi on the Recovery HD and also inside the BaseSystem.dmg (replaced both files, boot.efi and bootbase.efi of course). this didn't change anything. there's nothing in the NVRAM about csr-active. and the command csrutil disable still gives the same error "failed to modify...".
normal: no csr entry in NVRAM. csrutil disable fails.
modified: csr-active-config with value EAAAAA== in NVRAM! csrutil disable fails.
modified: csr-active-config with value EAAAAA== in NVRAM! csrutil disable fails.
Although these are from a later commit, I have reasons to believe they are functionally equivalent to the ones built immediately before. Just in case...
tested both new files -> they indeed seem to be the same as before. nothing has changed, same results.
I cleared the NVRAM with option-command-P-R and booted into the Recovery HD which is prepped with the latest boot.efi. NO csr-active entry to be found in NVRAM. csrutil disable failed. I then tried to reboot into standard El Capitan (which still has an older, working version of the new boot.efi installed). the system is stuck at the blurry desktop picture with the beachball of death where I should see the login screen. did an unsave shutdown (poweroff), cleared NVRAM with opt-cmd-P-R and again tried to boot into El Capitan with no luck. hard reset and boot into Yosemite. emptied NVRAM with "nvram -c". reboot into El Capitan is not working anymore. how is this possible? I will do a fresh re-install tomorrow (it's almost 1 A.M. over here in central europe).