Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
--8<----

I tried to remove my Airport card, but one screw sits so tight I'd have to remove the mainboard to get it loose and while I haven't done that in a while and could use some practice, I won't do that.
Is there another way, maybe 'unmount' the airport card from the device tree early in the process?

Don't waste the turns . . . removed mine temporarily, and still sit at "Waiting for DSMOS..."

"
[...]
Can't get kextd port.
Sun Oct 18 07:50:41 2015 Mac-Pro com.apple.xpc.launchd[1] (com.apple.bsd.helper.492) <Warning>: Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.bsd.dirhelper
Waiting for DSMOS...
"

Worth a try, I guess ;)
 

Attachments

  • image.jpeg
    image.jpeg
    1.4 MB · Views: 398
  • image.jpeg
    image.jpeg
    1.7 MB · Views: 244
Last edited:
I started out trying to do an Upgrade from Yosemite via the .app on a friend's Mac Pro 1,1, but we got a crash on update_dyld_shared_cache during the migration step of Stage 2 (OSInstaller).

We then started a clean install from USB via the createinstallmedia method...
The problem I see with this method is that it alters the install media half way and you'll have to replace boot.efi in multiple places multiple times during the install.

I'm seeing evidence to corroborate what Sko said:
Code:
InstallAssistant[513]: Extracting Boot Bits from Inner DMG:
InstallAssistant[513]: Copied prelinkedkernel
InstallAssistant[513]: Failed to delete existing boot.efi: Error Domain=NSCocoaErrorDomain Code=513
"“boot.efi” couldn’t be removed because you don’t have permission to access it." UserInfo=
{NSFilePath=/Volumes/Image Volume/.IABootFiles/boot.efi, NSUserStringVariant=(
        Remove
    ), NSUnderlyingError=0x7fcc33d4bae0 {Error Domain=NSPOSIXErrorDomain Code=1
"Operation not permitted"}}
InstallAssistant[513]: Ejecting disk images

I had gotten a little over zealous and locked down the permissions on the USB drive from Yosemite:
Code:
sudo chflags uchg,schg /Volumes/Install\ OS\ X\ El\ Capitan/.IABootFiles/boot.efi

Rerunning the Installation with the USB bootloaders unprotected and clean System drive:

BOOT #1 - USB - Success

Begin installation from USB Drive
Instead of above, we get this:
InstallAssistant[253]: Extracting Boot Bits from Inner DMG:
InstallAssistant[253]: Copied prelinkedkernel
InstallAssistant[253]: Copied Boot.efi
InstallAssistant[253]: Copied PlatformSupport.plist
InstallAssistant[253]: Ejecting disk images
InstallAssistant[253]: Generating the com.apple.Boot.plist file
Stage 1 (InstallAssistant) completed
Remove USB and Reboot
BOOT #2 - System - Fail
Fails to boot due to 64-bit bootloader
Replace USB and Reboot
BOOT #3 - USB - Fail
Attempts to from USB by pressing "C" are unsuccessful
LED on USB drive indicates successful reading and bootloop
Put USB in another Mac and (re)replace the bootloaders with Pike's
BOOT #4 - USB - Success
Replace System bootloaders with Pike's
Remove USB and Reboot
BOOT #5 - System - (?)
Continuing installation (?)
Stage 2 (OSInstaller) (?)
Stage 3 (SetupAssistant) (?)
Successful installation (?)

(?)
Waiting on friend to get back in front of screen, I'm remote....


ETA: clarifying steps taken
 
Last edited:
Replacing bootloader on USB got us booting from USB again, crossing fingers and waiting for SetupAssistant (Flying blind due to Flashed HD5770 on 1,1)...
Maybe I don't understand or I am doing something that is not required, but on the standard El Capitan install media I created this morning (using the Apple-blessed method), I was able to replace boot.efi in all three places from El Capitan without any trouble, even with SIP in place. Now, I haven't run said installer. Do you think it would fail to boot or do its work?
 
Maybe I don't understand or I am doing something that is not required, but on the standard El Capitan install media I created this morning (using the Apple-blessed method), I was able to replace boot.efi in all three places from El Capitan without any trouble, even with SIP in place. Now, I haven't run said installer. Do you think it would fail to boot or do its work?

I'll try to clarify the original post better, but to answer your question:

Yes, it will boot the first time, and then do Stage 1 of the installation (InstallAssistant). But then it will do what you see above (and succeed) and when you reboot, it will no longer boot from the USB drive (because it "refreshed" the bootloader on the USB drive).

While I'd like to think this happens to ensure that the USB drive is definitely bootable in case something goes wrong, the cynic in me says it's a subtle FU towards what we are trying to accomplish in this thread.

ETA: spelling/grammar
 
Ok. New game plan to attack this problem:

1.) I'll write a new kernel extension (boot-efi.kext) to detect upcoming restarts and let it move /Extra/boot.efi to the required target locations.

2.) Add a new kernel patch, right under the already added kernel patch, so that our new kernel extensions loads in installation mode and installation mode only (or perhaps always?).

3.) Test, verify and proceed with the installation like on a supported Mac.
 
I'll try to clarify the original post better, but to answer your question:

Yes, it will boot the first time, and then do Stage 1 of the installation (InstallAssistant). But then it will do what you see above (and succeed) and when you reboot, it will no longer boot from the USB drive (because it "refreshed" the bootloader on the USB drive).

While I'd like to think this happens to ensure that the USB drive is definitely bootable in case something goes wrong, the cynic in me says it's a subtle FU towards what we are trying to accomplish in this thread.

ETA: spelling/grammar

Verified with fresh createinstallmedia on fixed disk partition . . .

.IABootFiles locked . . . I unlocked, and boot.efi ~605kb (stock) replaced with latest commit proceeds to 'Installing on "El Capitan"' with about 18 minutes remaining...S/L/C and u/S/i386 boot.efi remained Pike's
 
@clawfinger

Thank you for your explanation. It seems the createinstallmedia method, even if "official", isn't as ideal as I thought it would be, at least for us. Oddly enough, I used the "legacy" method with Pike's 2.0 boot.efi and that worked well in one go. I suppose that if I had used version 3.0 of boot.efi in the same environment, it would have failed. I wonder what may have been so different between the two that now the legacy installation method is said to consistently fail.
 
@clawfinger

Thank you for your explanation. It seems the createinstallmedia method, even if "official", isn't as ideal as I thought it would be, at least for us. Oddly enough, I used the "legacy" method with Pike's 2.0 boot.efi and that worked well in one go. I suppose that if I had used version 3.0 of boot.efi in the same environment, it would have failed. I wonder what may have been so different between the two that now the legacy installation method is said to consistently fail.

Just so we're clear, here is the most concise listing I've found of OS X installation methods:

http://www.macworld.com/article/236...otable-os-x-10-10-yosemite-install-drive.html

If we call #1 from that page the "Official" Method, which are you referring to by "Legacy", #2 or #3? Or do you mean installing from a spare partition on hard drive?

Regardless, I'm not sure why moving from Pike's 2.0 to 3.0 would cause it to fail if it worked before.

ETA: AFAICT Method #3 is effectively Hennesie2000's Guide, but without the board-id stuff which is no longer necessary as of 3.0.

ETA: Looking at it closer Method #2 and #3 on that page are effective equivalent, just that one is from GUI and the other command-line. So I guess we all agree that "Legacy" means "BaseSystem.dmg Restore" as Pike puts it.
 
Last edited:
New commit available for compilation/testing. Look for: "Kernelpatcher: Found symbol @ 0x[value]". There should be two of them.

Note: This is step 2 of #430.

Edit: If something isn't working in v3.0 but v2.0/2.1 then we should try to reproduce it, and when confirmed, then I can start searching for the problem.
 
Last edited:
commit f1526934 compiled, and placed in createinstallmedia environ x3

Kernelpatcher: Found symbol @ 0xfffffffff4ee003b
Kernelpatcher: Found symbol @ 0x189

Hangs @ "Waiting for DSMOS..." like previous builds...

[edit]

I'm out-of-play for the rest of the evening (off to Mom's to cook some dinner, &c.).

[/edit]
 

Attachments

  • boot_commit-f1526934.zip
    205 KB · Views: 449
  • image.jpeg
    image.jpeg
    1.2 MB · Views: 176
New commit available for compilation/testing. Look for: "Kernelpatcher: Found symbol @ 0x[value]". There should be two of them.

I'm trying to see if my friend has an old analog monitor lying around so we can help test. Currently we're flying blind during boot because we are using an EFI Flashed PC HD 5770 on a Mac Pro 1,1.

ETA: Peter, are you going to be available to do compilations this evening? I can look into getting the developer environment set up if not.
 
Last edited:
If we call #1 the "Official" Method, which are you referring to by "Legacy", #2 or #3? Or do you mean installing from a spare partition on hard drive?
What I called the "official" method, as indicated by the context in which I said it, is Apple's "createinstallmedia" method. I've never used it myself. Ever since Mountain Lion days, I've used the Jabbawok/Tiamo/Hennesie's method. If the "createinstallmedia" method requires several reboots, it seems to me it is far from satisfactory for our purposes, even if creating the installer itself is trivial. And I know that Pike 2.0 boot.efi worked with the "Tiamo/Hennesie" installer, because that's what I used, but several testers have pointed out that the latest commits, including the 3.0 repository version, don't work with that installer anymore.
 
@pike:

I think what splifingate and others have mentioned about "Waiting for DSMOS..." is what causes the latest commits NOT to work with the Tiamo/Jabbawok/Hennesie installer.
 
Sorry for not having glimpsed this earlier, but it seems like the problem is with disabling SIP:

Bildschirmfoto 2015-10-18 um 21.12.40.png

Current boot.efi doesn't disable SIP on legacy method. I disabled it via restore partition and install media booted in no time into GUI (and enabled Bluetooth wich it never did before).
With this method, the installer boots to the target media on first restart, and fails as all occurrences of boot.efi are the original ones. I'm replacing these boot.efis right now and see how it proceeds. Maybe we can skip one step.
 
Last edited:
  • Like
Reactions: splifingate
Sorry for not having glimpsed this earlier, but it seems like the problem ist with disabling SIP
Yes, that would explain it. Version 2.0 of boot.efi had an imperfect SIP implementation. It would report that SIP was on, when, in fact, you could still do "forbidden" things.
 
@PeterHolbrook

Okay, I'm not disagreeing with you regarding the Legacy method possibly being more fit for our use case. I'm just used to using createinstallmedia because most of the Macs I install on have 64-bit EFI and it also still worked for Yosemite with Pike's bootloader. Obviously Apple has upped the ante with SIP (not that better security is unwelcome).
 
Last edited:
Replacing boot.efi in /S/L/CS/ and /u/s/i on target drive took me right into post install configuration.
 
2.) Add a new kernel patch, right under the already added kernel patch, so that our new kernel extensions loads in installation mode and installation mode only (or perhaps always?).
Wouldn't always be nice as it integrates PikeYoseFix if I understand it right?
 
Sorry for not having glimpsed this earlier, but it seems like the problem is with disabling SIP:

View attachment 593620

Current boot.efi doesn't disable SIP on legacy method. I disabled it via restore partition and install media booted in no time into GUI (and enabled Bluetooth wich it never did before).
With this method, the installer boots to the target media on first restart, and fails as all occurrences of boot.efi are the original ones. I'm replacing these boot.efis right know and see how it proceeds. Maybe we can skip one step.
Excellent catch! Indeed. We only check for two specific directories. Please compile and retest with the latest commit with new debug output. What do you get?
 
Adding new debug output.

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 2b15c74cc1c21a12d7736f866c663753eedad70c.zip
    205.2 KB · Views: 399
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.