macOS boot.efi developer's thread

[clawfinger]

Okay I'm all set up to build and have the output folder set to Dropbox, with a call to curl at the top of my replaceBootloader script to pull down the latest boot.efi. I will look at adding the board id myself here so I can start testing.

Edit: Ack, on further inspection it appears the MacBook4,1 (Mac-F22788A9) has a 64-bit EFI and is just artificially limited to only booting 32-bit kernels.

 

[PeterHolbrook]

Unleash 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!

 

[randyoo]

Unleash debug output.

Commit 09ba6c...
(bootarg slide=0, "createinstallmedia" usb installer, OS X 10.11.0)

Debug output attached. By the way, we're looping through error messages saying root can't be mounted.

 

[PeterHolbrook]

we're looping through error messages saying root can't be mounted.

Unless it skipped my attention before, this time, however, it says "loadExecutable found @ ..." That sounds kind of hopeful to me.

 

[Sko]

Commit 09ba6c3

Booting ok into installer GUI for legacy and official.

 

[Sko]

Commit 09ba6c3

Booting ok into Recovery and live system.

 

[Pike R. Alpha]

Unless it skipped my attention before, this time, however, it says "loadExecutable found @ ..." That sounds kind of hopeful to me.

Yup. It certainly does. The new commit will be faster, by skipping to the desired offset. Output address will now be 0x189 (again).

Edit: To all testers; thank you for testing my changes!

Edit-2: Stupid me. Had an error in the second search pattern. Should be fine now.

Patterns can be checked with (see comments in: StdAfx.h):

grep '\x48\x89\xc3\x48\x85\xdb\x74\x70' /S*/L*/Kernels/kernel
grep '\xe8\x25\x00\x00\x00\xeb\x05\xe8' /S*/L*/Kernels/kernel

/note to self: Get new glasses!

 

[PeterHolbrook]

Fixed search pattern and comment-only change.

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!

 

[Sko]

Commit bf0b21a
debug output

 

[Pike R. Alpha]

Commit bf0b21a
debug output

Hehe. Finally!

Thank you guys!

Special thanks @splifingate for his excellent help.

The main problem was that I failed to notice the difference between an 8 and B. Boy does that suck. So much time wasted. Sorry about that!

@PeterHolbrook,

I will make one more version, and then we can release v3.1 (black and grey).

@Sko,

Does it boot or not?

 

[Sko]

Does it boot or not?

Yes, it boots. I didn't try Recovery and Live, but can do so in no time.
Edit: all tests with 10.11.0, cold boot, PRAM-reset.

 

[Pike R. Alpha]

Yes, it boots. I didn't try Recovery and Live, but can do so in no time.
Edit: all tests with 10.11.0, cold boot, PRAM-reset.

Okay. Thanks.

Edit: Source code for boot.efi v3.1 available for compilation/testing.

 

[PeterHolbrook]

Releasing boot.efi v3.1.

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!

 

[Pike R. Alpha]

Version 3.2 of boot.efi will be concentrated on getting the booterProtection kext working and what I plan on doing next is to incorporate this kext into boot.efi so that it can inject itself into the prelinkedkernel and that nobody should ever have to mess with launch daemons and what not anymore.

Simplified attack plan:

1.) Step one is to load a dummy kext from /Extra/ to see if that works.
2.) Step two is to add the dummy plist and binary into boot.efi to see if that works.
3.) Step three, the final step, is to replace the dummy kext with the boot protector kext.
4.) Step four is a testing phase to see if everything goes as planned.

@PeterHolbrook,

What are the MD5 and SHA1 checksums?
Can you please also compile a version with a black background/white Apple logo?

 

[Sko]

Commit 8f70eff boots every environment, legacy, official, recovery and live. Waiting for black edition to put on my main drive with 10.11.1 on it.

 

[PeterHolbrook]

@ Pike:

md5 of grey boot.efi posted above (this is of boot.efi itself, not the zip) =
23348e2baff575405f527cf0a26e2838

sha1 of same =
41ec2b9ac115cb6def687b1bfdef891df6556b74

Please, bear in mind that this was compiled with MVS 2013 Professional in Windows 8.1 on a VMware Fusion 8.0.1 VM running in El Capitan 10.11.1.

I'll prepare the black version presently in the same environment.

 

[PeterHolbrook]

Releasing boot.efi v3.1. Black version.

md5 of grey boot.efi posted herein (this is of boot.efi itself, not the zip) =
036476dc081da904f50736eb56acbcfa

sha1 of same =
0b1864bdec2ae28a1b7538724e1732b31ab466e5

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!

 

[PeterHolbrook]

Right, folks. I'll be leaving with the wife in about one hour. Will be back tomorrow morning, ready for a new batch of compilations. Have a good night.

 

[bubez]

Just tried the 3.1 boot.efi. Still continuous kernel panics, even using the -pmap_pagetable_corruption_deassert boot arg.
I even tried to recompile using VS2015, same panics (but curiously the new compiler produces a file of different size).
If you'd like to take a look, here's the kextstat output.
What's wrong with my Mac??? Am I missing something??

 

[splifingate]

Thank you for testing this...

You are most-welcome.

Edit2: LOL I just realise something. I am using his computer, in his bedroom, when he sleeps. Well so I hope.

Simply mystifying . . . I have no idea how in the #fsck you accomplish the thing you do, but I am glad things are working.

I'd rather slowly insert a 10cm nail into my left eye than do the things I imagine you do....

Thank you for all the time, attention, product, and patience given.

Un gran "gracias" a su Esposa, también <sonrisa>

Regards, splifingate

 

[splifingate]

I've added self-compiled commit 8f70eff8 to createinstallmedia, legacy installer, El Cap (10.11.0), Mavericks (10.9.5), Yosemite (10.10.5) . . . app store d/l of ElCap fails on Mavericks10.9.5 (pre-AppleID change (personally)); currently at 1.45GB of 6.08GB on Yosemite 10.10.5 (I want to get a 10.11.1 installer setup active, for testing--I have four 128GB partitions awaiting different installs, as I may need them).

I may have to report-back with cognitively-correct feedback, tomm . . . ah was really busies, today <s>

 

[Pike R. Alpha]

Just tried the 3.1 boot.efi. Still continuous kernel panics, even using the -pmap_pagetable_corruption_deassert boot arg.
I even tried to recompile using VS2015, same panics (but curiously the new compiler produces a file of different size).
If you'd like to take a look, here's the kextstat output.
What's wrong with my Mac??? Am I missing something??

This has nothing to do with the development of boot.efi but the difference in size is normal. Also. I would recommend to re-install OS X 10.11.1 and see of that help, but please, don't post here about boot issues.

 

[splifingate]

I've added self-compiled commit 8f70eff8 to createinstallmedia, legacy installer, El Cap (10.11.0), Mavericks (10.9.5), Yosemite (10.10.5) . . . app store d/l of ElCap fails on Mavericks10.9.5 (pre-AppleID change (personally)); currently at 1.45GB of 6.08GB on Yosemite 10.10.5 (I want to get a 10.11.1 installer setup active, for testing--I have four 128GB partitions awaiting different installs, as I may need them).

I may have to report-back with cognitively-correct feedback, tomm . . . ah was really busies, today <s>

d/l of 10.11.1 from app store from within both Mavericks and Yosemite fail somewhere at the tail-end after downloading the entire 6GiB app. … seems like an iClod/account prob (later).

All other instances successfully boot, except createinstallmedia, which throws a kp early in the boot (attached)

Successful use of csrutil booted into 10.11 Recovery HD (though I don't know who to believe, with all the enable/disable crossover).

 

[Pike R. Alpha]

And the app store download and 'createinstallmedia' method used to work, right? Works with v3.0?

 

[splifingate]

And the app store download and 'createinstallmedia' method used to work, right? Works with v3.0?

Createinstallmedia: yes.

Download accepted before, but I do not think I took the time to let it fully download (moved-on to trying commits at that time in their respective places).

d/l of current ElCap .app from app store in both Yosemite and El Cap currently just wait indefinitely with the spinner in the app store

[edit]

I have pulled commit 8eb2a259, and set DEBUG_KERNEL_PATCHER = 1, and re-enabled verbose for personal diag.

Also, App Store > Menu > Store > 'Check for Unfinished Downloads...' gets me from just a spinner, to the actual download (progress bar, etc.). Paused for one boot into createinstallmedia...
[/edit]