El Capitan support for macosxbootloader

FYI: I committed the first changes for El Capitan support into a new branch – El Capitan – for the macosxbootloader.

Advertisements

406 thoughts on “El Capitan support for macosxbootloader

  1. I also tried it when booted into the regular El Capitan installation (no success either). should this work now? your screenshot in your latest blog post is implying that…

  2. As a side note, I won’t be around for several hours from about 17:30 (your time, Pike) until possibly late at night. I’ll compile whatever new commits I see before 17:30 and after my return. Good luck.

  3. Commit 4380ddd3c6802a90c12d5dbe5daa1d77074e5414 compile error:
    Error 1 error C2220: warning treated as error – no ‘object’ file generated C:\Users\PJH\Desktop\macosxbootloader-El-Capitan\src\boot\BootArgs.cpp 791 1 boot
    Commenting the line out makes compilation possible.
    Should I post the result?

  4. Shouldn’t the new line 807 of BootArgs.cpp be
    if(EFI_ERROR(status = EfiRuntimeServices->GetVariable(CHAR16_STRING(L”csr-active-config”), &AppleNVRAMVariableGuid, attributes, &dataSize, &csrActiveConfig)))
    ?

  5. On second thought, the line ought to be, I think,
    if(EFI_ERROR(status = EfiRuntimeServices->GetVariable(CHAR16_STRING(L”csr-active-config”), &AppleNVRAMVariableGuid, &attributes, &dataSize, &csrActiveConfig)))

  6. before testing a new version of boot.efi I’m always clearing the PRAM.

    4380ddd3c6802a90c12d5dbe5daa1d77074e5414: Recovery HD did not boot, hang at grey screen with Apple logo. same for El Capitan, can’t boot successfully.

    • I vaguely remember an issue where booting into the RecoveryHD with Yosemite failed. Can’t recall if that was with Command+R or the Startup Manager. Perhaps you know?

      Edit: Wait. I think I found it! Let me fix this.

  7. yeah, I also remember that there was an issue. no idea what exactly the issue was though… what I know for sure: I never use the command-r key combination (except for the new 2015 MacBook Pro where the Recovery HD isn’t showing up with press & hold of the option key).

    I now started into the Recovery HD with command-R method: results are the same. csrutil status gives enabled (Apple Internal). and csrutil disable fails.

    • I think that this is my fault. There’s BOOT_MODE_EFI_NVRAM_RECOVERY_BOOT_MODE and BOOT_MODE_FROM_RECOVER_BOOT_DIRECTORY. and I only checked the former. New commit available for compilation.

  8. commit f3ec1b1 allows me to disable SIP via terminal on 10.11 Recovery HD :

    # csrutil disable

    “Successfully disabled System Integrity Protection. Please restart the machine for changes to take effect.”

    But, a subsequent reboot into same gives SIP status as enabled (I still have yet to get your c-code compiled and placed on an accessible volume).

    Second reboot in Recovery HD 10.11 in a minute….

  9. somehow “csrutil status” gives a wrong answer when booted into the Recovery HD. I now have SIP disabled and can verify in El Capitan with csrutil and “nvram -xp” and I’m getting the correct answer. when booted into the Recovery HD, SIP is still disabled according to “nvram -xp” but “csrutil status” gives enabled…

  10. booting into El Capitan with NVRAM emptied: csrutil status -> enabled (Apple Internal). value in NVRAM is “EAAAAA”. when booting into Recovery HD with NVRAM emptied: csrutil status -> enabled. value in NVRAM is “gAAAAA”.

  11. Can’t keep timely flow, it seems ;/

    303daee commit:

    # csrutil status ->

    “System Integrity Protection status: disabled.”

    # nvram csr-active-config ->

    “w%00%00%00”

    # /Volumes/backs2tb/csrstat

    “System Integrity Protection status: enabled (0x00000077)(Custon Configuration: 0x00000077).

    Configuration:
    Apple Internal: enabled
    KextRest/FilesystemProt/DebuggingRest/DTraceRest/NVRAMProt: disabled”

  12. I’ve just arrived and have read a few of the latest messages, which I don’t fully understand. Some seem to say that what was reported as not working is working now (!?!). Well, whatever that may be, commit 303daeeb80c6fca0d04b69ab99761da6293b222c has been compiled and posted.

    As for a doubt regarding a problem with the Yosemite Recovery HD, I can mention my own experience back in the days I had such a partition (I don’t have one anymore ever since I moved my regular Yosemite partition to a 4TB SSDH). If I wanted to boot to the Yosemite Recovery HD (where one copy of Pike’s boot.efi resided) by pressing Cmd-R when I heard the chime, the Recovery HD would boot normally. However, if I pressed Option when I heard the chime and then selected the Yosemite Recovery HD from the Startup Manager, the REGULAR Yosemite partition would boot up, not the Recovery HD. From what mikeboss has said, it would appear that the El Capitan edition of boot.efi can boot the Recovery HD either way, either with Cmd-R or Option-booting and then selecting it in the Startup Manager, which is just perfect.

      • Cmd-R always (for me) boots into the lowest-common-denominator Recovery HD.

        I destroyed, and completely rebuilt (incorporating the 303daee commit, and modified BaseSystem.dmg’s for each) both my Yose and ElCap Recovery HD partitions, today, and Cmd-R gets me into the ElCap Recovery HD only when the 10.10 Recovery HD is not present.

        Next on my list is to try the 303daee commit in the 10.10 installs, et al.

      • It certainly is, Pike. It’s been a lot of work for you, I know, and the community can hardly ever pay your effort and your immense talent, other than to express our heartfelt gratitude for doing more than anyone to make these old machines “young” again and almost on a par with the best of today’s personal computers.

  13. commit 303daeeb80c6fca0d04b69ab99761da6293b222c booting into Recovery HD with NVRAM emptied: csrutil status -> enabled (Custom Configuration). value in NVRAM is “gAAAAA”. csrutil disable -> success, value in NVRAM “dwAAAA”. csrutil enable -> OK, value in NVRAM “EAAAAA”. csrutil status -> enabled (Custom Configuration).

    • Let’s see. I am trying to understand the current state. Looks like we are nearly there, but setting csr-active-config to 0x80 when that should be 0x00 is not. Is that everything left to fix now?

      • booted into 10.11 Recovery HD using 303daee commit with ‘# csrutil disable’ on previous boot with pram cleared between):

        # csrutil status ->

        System Integrity Protection status: enabled (Custom Configuration).

        Configuration:
        Apple Internal: disabled
        Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: enabled

        # nvram -p ->

        “csr-active-config %80%00%00%00”

        #/Volumes/backs2tb/csrstat ->

        “System Integrity Protection status: enabled (0x00000080)(Custom Configuration: 0x00000080).

        Configuration:
        Apple Internal: enabled
        Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled

        I will now try “# csrutil disable”, again…

  14. Good evening. I have been running your boot.efi sept 21 very successfully and would like to be included in testing . I have a MacPro1,1 and do not need hand holding, however I only have Macports running on ElCapitan GM . Where to you post the image boot.efi and if you don’t could you make it available ?
    bob@kalkwarf.com
    Bob w7wo

  15. reboot into 10.11 Recovery HD using 303daee commit:

    # csrutil status ->

    “System Integrity Protection status: disabled.”

    # /Volumes/backs2tb/csrstat ->

    “System Integrity Protection status: enabled (0x00000077)(Custom Configuration: 0x00000077).

    Configuration:
    Apple Internal: enabled
    Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled

    # nvram csr-active-config=%ff%00%00%00 ->

    “nvram: Error setting variable – ‘csr-active-config’: (iokit/common) general error”

    (e.g., any ‘nvram csr-active-config=%bla%bla’ produces the same error)

  16. I would enjoys testing boot.fi whenever you can make the image available to me. Email includes works for me. I currently run your boot.efi dated Sept 21, 2015 on my MacPro1,1 and ElCapitan GM release plus the one update from apple. I promise not to inject anything into your process that seems to be very smooth and no bickering or nonsense.

    Sincerely,
    Bob Kalkwarf w7wo
    bob@kalkwarf.com

  17. Successful update to ElCap 10.11.1 (15B17c), with only the need to replace the usual .efi culprits.

    PIKE: NVRAM csr-active-config[0x77/0x4] found (OK)!

    (repeated) on initial boot

    (from within running ElCap install (as Admin)):

    # /Volumes/backs2tb/csrstat ->

    “System Integrity Protection status: enabled (0x00000077)(Custom Configuration: 0x00000077).

    Configuration:
    Apple Internal: enabled
    Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled

    • reboot into 10.11 Recovery HD using 303daee commit after pram cleared:

      PIKE: BlInitCSRState(RecoveryOS detected)! {x5}
      PIKE: NVRAM csr-active-config NOT found (ERROR: 2147483662)! {x5}
      PIKE: NVRAM csr-active-config[0x80] set (OK)! {x5}
      PIKE: bootArgs->CsrActiveConfig[0x80] set! {x5}

      # csrutil status ->

      System Integrity Protection status: enabled (Custom Configuration).

      Configuration:
      Apple Internal: disabled
      Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: enabled

      #/Volumes/backs2tb/csrstat ->

      “System Integrity Protection status: enabled (0x00000080)(Custom Configuration: 0x00000080).

      Configuration:
      Apple Internal: enabled
      Kext/FilesystemProt/DebugRest/DTraceRest/NVRAMProt: disabled

  18. commit 5d3d273a7c49ccb5c63cf40b6100596a3ad79433: boots normal. started into Recovery HD (empty NVRAM). csrutil status is enabled. I then disabled SIP using csrutil disable. reboot into El Capitan. -> status disabled. reboot into Recovery HD: csrutil enable -> OK. reboot into El Capitan: csrutil status gives enabled (Apple Internal). value in NVRAM is “EAAAAA”. oh, and what about the “Hardware UUID” reported in “System Information.app” being different than what is displayed in Yosemite and/or Lion, is this a non-issue?

    • Cool.

      About the UUID. If your system-id in El Capitan is the same as what you get with Lion/Mavericks, then I guess so, but I need new Darwin Dumps of both OSes to see if there is anything I can do about it.

      Edit: Done. There is no “system-id” property set in Lion so the hardware UUID will be totally different. This is normal behaviour. Apple changed things for iMessage support and the system-id is one of the checked properties. In short. Everything is fine!

  19. Pingback: El Capitan support for unsupported hardware is here! | Pike's Universum

  20. Commit 740058620f1fd8827bcf0aef74a448bbaaf2a00c has been compiled and posted, together with the following comment:

    Presumably final (as far as phase 2 goes) black and grey versions of Pike’s boot.efi.

    To all parties interested: Please, test these two versions of the latest commit (740058620f1fd8827bcf0aef74a448bbaaf2a00c, created about one hour ago). The one dubbed “grey” is the compilation of said commit the way I found it. The one dubbed “black” is the compilation of a modification of StdAfx.h, whereby a couple of #define directives have been swapped. Any errors should be attributable to me, not to Pike. In theory, the “grey” version should resemble the boot.efi of the era previous to Yosemite, whereas the “black” version should resemble the boot.efi now customary with newer Apple hardware since Yosemite. Please, test BOTH versions and see if there are any shortcomings. Report your findings here and/or in Pike’s blog.

  21. Sorry, I’ve just seen that there’s an “official” download repository for both versions. Please, disregard my previous post.

    • No problem. We want everyone to use one and the same copy of boot.efi which by the way should also help me to track bugs/issues, and stop people from adding junk to it – since El Capitan is meant to protect your privacy and data, we must be careful with who does what or all hell may break lose.

      • Yes, of course. If you want me to, I’ll go on compiling whatever improvements you introduce in phase three for mikeboss to test. When I compile and publish such interim versions, I’ll include a clear reminder that they are not intended for general use, nor are they to take the place of the official repository black and grey versions, which will only be replaced when you say so.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s