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

macOS boot.efi developer's thread

randyoo said:
Okay, I'm in, and the only difference I can spot in NVRAM variables is the following new variable:
Code: 
install-product-url x-osproduct://<<<disk UUID here>>>/OS%2520X%2520Install%2520Data

This is after the first reboot from performing an install using a "createinstallmedia" installer, having booted into single user mode.

I'll try rthpjm's suggestion now, after rebooting and completing the installation.

EDIT: After completing installation, prior to restart timer, checked NVRAM variables, and they are identical to beginning of installation. (install-product-url is gone, exactly same as post #523 now)
Click to expand...
Thanks guys. Let's move on. Still busy with work, but I'll get back hacking on boot.efi and the new bootEfiProtector.kext a.s.a.p.
 
  • Like
Reactions: OGNerd
Pike R. Alpha said:
Hi,

Thing is. There should be a second set of lines, with different values, but they are still missing.

Another thing. Have you checked the NVRAM variables in the installer (open a terminal window if you can) that I asked for a little while ago?
Click to expand...

Testing commit 918ca4 (from legacy installer)

IMG_1212.jpg

nvram output before and after attached.
 

Attachments

  • nvram-before.txt
    1.4 KB · Views: 520
  • nvram-after.txt
    1.4 KB · Views: 413
In Post #391 I had posted a list of older Macs and a list of Board-IDs.

But not all of the older Macs have EFI32, e.g. the MacBook4,1 has already EFI64.

Here's a Overview which of the older Macs have either EFI32 or EFI64. Here again the list of Board-IDs.

According to the list above, these are the Macs with EFI32:

- MacBook Air 1,1
- MacBook 2,1
- MacBook Pro 2,x
- Mac mini 1,1 upgraded to C2D
- iMac 4,x upgraded to C2D
- iMac 5,x
- iMac 6,1
- Mac Pro 1,1/2,1
- Xserve 1,1

Mac models officially supported by OSX 10.11 El Capitan:
http://www.apple.com/osx/how-to-upgrade/#hardware-requirements
 
Last edited:
atvusr said:
In Post #391 I had posted a list of older Macs and a list of Board-IDs.

But not all of the older Macs have EFI32, e.g. the MacBook4,1 has already EFI64.

Here's a Overview which of the older Macs have either EFI32 or EFI64. Here again the list of Board-IDs.
Click to expand...
Thank you. My plan was to wait for people to ask for a board-id change, since you were having such a hard time getting things going. Need to know what the root cause of that issue is.

Edit: New commit available for compilation/testing.

Also. boot.efi checks for these:

MacBookPro1,1
MacBookPro1,2
MacBookPro2,1
MacBookPro2,2
MacBookP1,1
MacBookP1,2
MacBookP2,1
MacBookP2,2
MacBook1,1
MacBook2,1
Macmini1,1
Macmini2,1
iMac4,1
iMac4,2
iMac5,1
iMac5,2
iMac6,1
MacPro1,1
MacPro2,1
XServe1,1
 
Last edited:
Re-enable limited debug output.

PeterHolbrook said:
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!
Click to expand...
 

Attachments

  • boot b04723fdeb7198f707f5eab2ad82bf38d729a4d8.zip
    205.5 KB · Views: 357
Commit b04723f

Debug output didn't change, nvram variables not present in both install environments. Is there a variable that has to be there so I could test that the 'nvram 4d1...' command is working properly?
 
Sko said:
Commit b04723f

Debug output didn't change, nvram variables not present in both install environments. Is there a variable that has to be there so I could test that the 'nvram 4d1...' command is working properly?
Click to expand...
Here are some example:

4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:FirmwareFeatures
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:FirmwareFeaturesMask

Do NOT show the result of the first two in a public forum!
 
Stricter checks for MS compiler.

I don't suppose this will bring in any significant changes.

PeterHolbrook said:
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!
Click to expand...
 

Attachments

  • boot 6646899a2b3ca2fd9b5512d0e71098531ec048af.zip
    205.5 KB · Views: 330
It appears OS X 10.11.1 has just been released. Does anyone know if the update includes a new stock boot.efi?
 
PeterHolbrook said:
It appears OS X 10.11.1 has just been released. Does anyone know if the update includes a new stock boot.efi?
Click to expand...

It does appear so (Updates can be found in /Library/Updates on working El Capitan install), also there is an 125MB FimwareUpdate.pkg as well:

upload_2015-10-21_14-2-40.png


Edit: shrunk image some
 
Last edited:
  • Like
Reactions: PeterHolbrook
PeterHolbrook said:
Stricter checks for MS compiler.

I don't suppose this will bring in any significant changes.
Click to expand...
Commit 6646899, debug output just two lines, as follows:
Code: 
Kernelpatcher: offset[0x929950], startAddress[0x11729950]
Kernelpatcher: Found symbol @ 0x109

Any need to run the installer, check NVRAM variables, or anything else?
 
randyoo said:
Commit 6646899, debug output just two lines, as follows:
Code: 
Kernelpatcher: offset[0x929950], startAddress[0x11729950]
Kernelpatcher: Found symbol @ 0x109

Any need to run the installer, check NVRAM variables, or anything else?
Click to expand...
No thanks. My focus is on getting the missing lines to output the data that I expect (offset should show 0x950). Perhaps OS X 10.11.1 is a little different – which is what I am using for some time already – but the latest commit works in a test tool on the kernel (keeping my fingers crossed). Let's see what this brings.

New commit available for compilation/testing.
 
  • Like
Reactions: randyoo
Best bits combined.

PeterHolbrook said:
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!
Click to expand...
 

Attachments

  • boot bdc820cf3e3f0891bfe24385f0a155dba7ecb28b.zip
    205.6 KB · Views: 414
  • Like
Reactions: Pike R. Alpha
boot into commit b23ba0ae added to createinstallmedia:

Code: 
Kernelpatcher: offset[0x950], startAddress[0xffffff801d3cf950]

:ROM/:MLB sent via email

otré dos from Terminal during countdown (following Install), and output from previous nvram queries, attached
 

Attachments

  • image.jpeg
    image.jpeg
    1.8 MB · Views: 185
  • image.jpeg
    image.jpeg
    1.9 MB · Views: 199
Last edited:
boot into commit b23ba0ae added to legacy install:

Code: 
Kernelpatcher: offset[0x950], startAddress[0xffffff801d7cf950]

(install of ElCap awaiting ~16min)

output captured during countdown after Install in legacy environ
 

Attachments

  • image.jpeg
    image.jpeg
    1.8 MB · Views: 177
  • image.jpeg
    image.jpeg
    1.8 MB · Views: 170
Last edited:
I want to help, I downloaded 10.11.1 and created USB installer using createinstallmedia.
I then replaced the boot.efi files (3) with commit bdc820cf3e3f0891bfe24385f0a155dba7ecb28b.
When booted from USB, after verbose is done it switched to grey background apple logo and booted into recovery mode ( OS X Utilities).

Is this correct? I was expecting the OS X Installer.
 
New commit available for compilation/testing.

@dfritchie,

We're testing a specific piece of code, and I don't even know right now if it can boot properly. Wait for a confirmation from others (I don't have any unsupported Apple hardware).
 
I know we've moved on from trying to detect the install phase from nvram (for now at least), but I just wanted to point out that every reference I've seen regarding the Install Phases within the installer logs from many different iterations and installation methods indicates that the Installer can't find them there either.

This is all of the references to InstallPhase within the two installer logs from my official installation via createinstallmedia on my Mac Pro 3,1 (with 64-bit EFI):

ia.log:
Code: 
InstallAssistant[473]: IASGetCurrentInstallPhaseList: no install phase array set
InstallAssistant[473]: IASGetCurrentInstallPhase: no install phase set

install.log:
Code: 
Installer Progress[426]: IASGetCurrentInstallPhaseList: no install phase array set
Installer Progress[426]: IASGetCurrentInstallPhase: no install phase set
loginwindow[71]: IASGetCurrentInstallPhaseList: no install phase array set
loginwindow[71]: IASGetCurrentInstallPhase: no install phase set
mbsystemadministration[191]: IASGetCurrentInstallPhaseList: no install phase array set
mbsystemadministration[191]: IASGetCurrentInstallPhase: no install phase set
Installer Progress[426]: IASGetCurrentInstallPhaseList: no install phase array set
Installer Progress[426]: IASGetCurrentInstallPhase: no install phase set
 
clawfinger said:
I know we've moved on from trying to detect the install phase from nvram (for now at least), but I just wanted to point out that every reference I've seen regarding the Install Phases within the installer logs from many different iterations and installation methods indicates that the Installer can't find them there either.

This is all of the references to InstallPhase within the two installer logs from my official installation via createinstallmedia on my Mac Pro 3,1 (with 64-bit EFI):

ia.log:
Code: 
InstallAssistant[473]: IASGetCurrentInstallPhaseList: no install phase array set
InstallAssistant[473]: IASGetCurrentInstallPhase: no install phase set

install.log:
Code: 
Installer Progress[426]: IASGetCurrentInstallPhaseList: no install phase array set
Installer Progress[426]: IASGetCurrentInstallPhase: no install phase set
loginwindow[71]: IASGetCurrentInstallPhaseList: no install phase array set
loginwindow[71]: IASGetCurrentInstallPhase: no install phase set
mbsystemadministration[191]: IASGetCurrentInstallPhaseList: no install phase array set
mbsystemadministration[191]: IASGetCurrentInstallPhase: no install phase set
Installer Progress[426]: IASGetCurrentInstallPhaseList: no install phase array set
Installer Progress[426]: IASGetCurrentInstallPhase: no install phase set
Click to expand...
Thanks. Yeah I have given up on that (for now). Future will tell us what this is used for. Broken installations perhaps.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back