Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
commit 81fa8702089b74dd292349865c6f1c4721eefd44: starts flawles with boot-args "-f" in NVRAM.

bootbase.efi indeed disabled SIP completely (even though csrutil status stated otherwise).
 
  • Like
Reactions: HazyDave2
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.
 
Great. Let Pike know. I don't suppose he'll be able to do much in the next few days. He has the flu.

of course I posted these findings on his blog, too.

about the installer: I don't think that the bootbase.efi will help with this. maybe it will be helpful with some kind of a "PikeYoseFix"? AFAIK, the only obstacle lies in the fact that the El Capitan installer routine is taking the boot.efi from

/Volumes/Install\ OS\ X\ El\ Capitan/System/Installation/Packages/Essentials.pkg

instead from the installer volume like it did in Yosemite. I guess we would have to modify the Essentials.pkg in order to get the ability to do a full/clean install.
 
Fix compilation error (for MVS 2015, presumably). Contains BOTH boot.efi AND bootbase.efi

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!
 

Attachments

  • boot 64be04e895785b48117ea0b3cdc2b555ac836422.zip
    409.3 KB · Views: 1,093
this is strange. I have no idea since when this is the case because I never actually tested it: SIP seems to be disabled with the latest boot.efi in place. csrutil status gives enabled (Apple Internal). but I'm able to rename a KEXT file even when not logged in as root. this is not possible on El Capitan release version running on an officially supported machine.

I have to leave (appointment with a customer). will be back in the evening.
 
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.
 
Fix compilation error (for MVS 2015, presumably). Contains BOTH boot.efi AND bootbase.efi

I've tested the boot-64be04e895785b48117ea0b3cdc2b555ac836422 on a MBP2,2 with a patched Installer. Boot.efi and Bootbase.efi each replaced with their specific version.

It boots, but after 2 minutes (out of 17 mins) while the Installer copies the files to the destination I get suddenly a Kernel Panic and the MBP2,2 reboots.

panic(cpu 1 caller 0xf...): Kernel trap at 0xf..., type 13=general protection, registers:
 
Last edited:
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.

I tested this with boot.efi from sept. 27th (the official one). grep didn't return anything suspicious. csr-active-config value in NVRAM reads "EAAAAA". SIP is clearly deactivated as I am able to rename KEXTs in /System/Library/Extensions. something went wrong ;-)
 
Boot without kBootArgsFlagCSRBoot (allow all). Contains BOTH boot.efi AND bootbase.efi

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!
 

Attachments

  • boot 51b05ad5c3250ecbee1d0194e8aace5f281f79e1.zip
    409.3 KB · Views: 774
51b05ad5c3250ecbee1d0194e8aace5f281f79e1: aahhh, much better ;-) both files behave the way they should. boot.efi -> SIP is really ON and prevents me from renaming the files. bootbase.efi (installed in El Capitan as boot.efi) allows me to mess with system files.
 
  • Like
Reactions: PeterHolbrook
Boot without kBootArgsFlagCSRBoot (allow all). Contains BOTH boot.efi AND bootbase.efi

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."
 
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."
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).
 
New debug output for prelinkedkernel testing. Contains BOTH boot.efi AND bootbase.efi

Nota Bene: What Pike probably wants to test might require building install media. Mike, let me know if it would help if I were to upload an image of my installer. Any pointers on which tool to use to do such a task? I don't know if SuperDuper! would do it.

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!
 

Attachments

  • boot 9edc64d660598beff6ef735aeacce6fa37446ce7.zip
    409.3 KB · Views: 780
I prefer the unix dd command to create diskimages (this never fails). unmount the install media (not eject). use the diskutil command to list the available drives. preferably you're superuser (root) already.

Screen Shot 2015-10-02 at 22.40.21.png

of course you can compress (ZIP etc.) the image file when completed.
 
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?
 
Last edited:
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?
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.
 
Mike, uploading the installer (without considering the time it'll take you to download it) will take much longer than creating one from scratch. For this reason, I'm enclosing a relatively detailed (though imperfect) guide to the installation of El Capitan on an old Mac Pro. Let me know if you find this feasible. Also, notice that the guide DOES NOT mention the modification of /Library/Preferences/SystemConfiguration/com.apple.Boot.plist, which in my case was necessary (otherwise, the installer wouldn't boot). So, here's the guide. If you are so kind, make whatever corrections you deem fit:


Guide for installing OS X 10.11 El Capitan on a Mac Pro 1,1 or 2,1 with the boot.efi method without directly resorting to a more modern computer

Based on Hennesie2000’s similar guide for OS X 10.10 Yosemite

I have tried to be as complete and clear in this guide as possible. However, this is an intricate procedure. I am not responsible for any damages that may occur as a result of this guide.

Things you will need

1. A Mac Pro 1,1 or 2,1 with an upgraded video card (7300GT or X1900XT will not work).
2. An 8GB or larger thumb drive or, preferably, an 8GB blank partition in one of the Mac Pro internal drives.
3. The latest version of Pacifist. It can be downloaded from charlessoft.com.
4. An application called Flat Package Editor. It can be found at on https://developer.apple.com/downloads/index.action. You will need to login and then search for “Auxiliary Tools” and download the “Late July 2012” dmg. Once downloaded, mount the DMG and right-click PackageMaker then show the contents. Browse to the /Contents/Resource folder and you will see the Flat Package Editor there. Copy that to your Utilities folder.
5. A copy of the El Capitan Install App from the App Store. You can’t use your old Mac Pro to download it. For this you will need either a virtual machine running Yosemite or a more modern Mac.
6. Choose either the “black” or the “grey” version of Pike’s boot.efi and download both boot.efi and bootbase.efi according to your choice. They can be downloaded from http://piker-alpha.github.io/macosxbootloader/.

Creation of a generic stand-alone El Capitan installer

1. In Terminal you will need to show hidden file using the following commands:
defaults write com.apple.finder AppleShowAllFiles YES
killall Finder
2. Right-click on the downloaded El Capitan Installer app and click show package contents.
3. Browse to the folder /Contents/SharedSupport.
4. Double-click to mount “InstallESD.dmg”.
5. Open up Disk Utility and drag BaseSystem.dmg to the side bar (in Disk Utility).
6. Click on BaseSystem.dmg in Disk Utility and select the Restore tab.
7. Set the BaseSystem.dmg as the source and choose the thumb drive or the 8GB internal blank partition (formatted as HFS+) as the destination.
8. Restore the image to that destination.
9. If you so desire, rename the thumb drive or the internal partition. For instance, I named mine “Install”.
10. Use the Finder to browse the newly restored installer. Go to the folder /System/Installation on the installer and delete the “Packages” alias file.
11. Go back to the mounted InstallESD.dmg and drag the “Packages” folder to the installer into the /System/Installation folder where the alias file used to be.
12. Copy the “BaseSystem.dmg” and “BaseSystem.chunklist” files to the root of the installer.
13. On the installer, go to /System/Installation/Packages/ and right-click on Essentials.pkg. Open it with Pacifist. Within Pacifist, navigate to /System/Library/Kernels/. There you will see a file named “kernel”.
14. Using the Finder, on the installer, create a folder named “Kernels” [without the quotation marks] in /System/Library/ and open the new folder.
15. Drag the “kernel” file from Pacifist to the Finder window where the “Kernels” folder is open.
16. To hide the hidden files again, enter this in Terminal:
defaults write com.apple.finder AppleShowAllFiles NO
killall Finder

Modification of the generic stand-alone El Capitan installer so that it will run on an old Mac Pro

1. Using the Finder, on the installer, navigate to System/Installation/Packages.
2. Right-click OSInstall.mpkg and open it with the Flat Package Editor.
3. Click and drag the “Distribution” file to your desktop and then open that using the text editor.
4. Scroll down a little bit until you see “var platformSupportValues=[...” [without the quotation marks]. That is followed by a bunch of board ID. For the Mac Pro 1,1 and 2,1 you will need to add "Mac-F4208DC8","Mac-F4208DA9" [it is imperative that such ID be surrounded by non-curly quotation marks]. Add them to the beginning of the list. You can copy the following line, including the last comma (without the carriage return that follows it), and then paste it to “Distribution”:
"Mac-F4208DC8","Mac-F4208DA9",
5. Save the edited Distribution file.
6. In the Flat Package Editor window, with the Distribution file highlighted, click Delete.
7. Now drag the edited Distribution file into the window and save the package file.
8. Also in the Packages folder you will need to modify the InstallableMachines.plist file with the same to above board ID again following the syntax.
9. You have to modify the PlatformSupport.plist located in the System/Library/CoreServices folder, again adding the two board IDs in the correct syntax.
10. And now we come to the most crucial part: including Pike’s boot.efi on the installer. For this, replace the boot.efi files located in System/Library/CoreServices and usr/standalone/i386 with Pike’s boot.efi that you previously downloaded as indicated earlier.
11. Finally, replace the bootbase.efi file located in System/Library/CoreServices with Pike’s bootbase.efi that you previously downloaded as indicated earlier.

Installation of El Capitan on an old Mac Pro using the modified installer

1. Boot from the installer by holding option after the boot chime.
2. Follow the normal OS X install process.
3. Make sure you are in front of your computer when the process is about to end. Don’t let it reboot, because, if it does, your Mac Pro will fail to boot, as the installer does not install Pike’s boot.efi to the target disk. You’ll have to use the installer Terminal to replace the boot.efi files located in System/Library/CoreServices and usr/standalone/i386 with the file Pike’s boot.efi that you previously downloaded as indicated earlier. In case you didn’t stop the reboot, you’ll need to reboot to the installer and, without installing the system, go to the Terminal and replace both boot.efi files.
4. Although this might not be necessary, using the installer, choose Startup Disk and select your now El Capitan partition and reboot.

Modification of the Recovery HD partition so that it will be bootable on the Old Mac Pro

Finally, within El Capitan itself, open the Terminal and enter
diskutil list
You will see a list of disks and partitions. One of them, of the type “Apple_Boot”, will be named “Recovery HD” and it will be located on the same disk as your new El Capitan partition (possibly called “Macintosh HD”). Notice its disk identifier in the last column to the right. Let’s suppose the identifier is “disk3s3”. Using the Terminal, enter the following:
diskutil mount disk3s3
The El Capitan Recovery HD will appear on your desktop. Using the Terminal, you’ll have to replace the boot.efi file located in /com.apple.recovery.boot with Pike’s boot.efi that you previously downloaded as indicated earlier. Notice that this modified Recovery HD will now boot the old Mac Pro, but, if you were to use it to reinstall El Capitan, you would still need to use the Terminal to replace both copies of the stock boot.efi with Pike’s modified version. Finally, using the Terminal, enter:
diskutil unmount disk3s3
 
Last edited:
Hi Peter and Mike,

I was over at Pikes Universum and noticed he was asking if anyone had thought of using LaunchDaemons to fix-up the boot.efi files if they get changed. I've been doing this for a while now (under Yosemite) and it has really worked great for me. I didn't bother to advertise or distribute my solution because everyone else seemed to be happy using the *yosfix scripts.

However, I thought I would share with the community now. There's a brief write-up here:
http://www.rthpjm.co.uk/drupal/?q=node/2
There's an attachment on that page with a DMG that contains both an (unsigned) installer package and a gzip tar ball. GUI and command line choices ;)

I've tested it on my MacPro 1,1 (upgraded to 2,1), it seems to be working fine with El Capitan.
In brief it sets up a LaunchDaemon to watch the files of interest. If they change it calls a script to change them back.
The script and resources live in /Library/Application Support/Boot64

I've adapted the script to take the .IABootFiles location into account, but I'm uncertain if this was required. My ElC installation does not have /.IABootFiles. Can you throw any light on the subject? Is that a Recovery Partition thing?

I'm currently using the Pike Phase 2 stable boot.efi files (without flush cache if I read your threads correctly), and the boot base.efi from just before you guys started this thread.

Paul
 
  • Like
Reactions: innovaTutor
wow, thank you peter for this thorough how-to guide. I have built an installer using more or less this procedure weeks ago. of course I also had to manually replace the boot.efi in the end because the installer routine uses the boot.efi residing in the "Essentials.pkg" instead of one of the boot.efi files placed on the installer volume. with this method, there's no need for the bootbase.efi.

possible solutions:

modifying the "Essentials.pkg", is this even possible? or does the installer some kind of integrity check on the PKGs?

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.
 
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.
 
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 :eek:

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)
 
That would explain it :eek:

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)

nope, AFAIK nobody/nothing is allowed to mess with system files if SIP is enabled.
 
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.

I too tried with createinstallmedia, then gave up and reverted back to Peter's instructions o_O
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.