Contribute
Register

GA-Z170MX-Gaming 5 install El Capitan on NVMe

Status
Not open for further replies.
Joined
Dec 27, 2016
Messages
7
Motherboard
Gigabyte Z170MX Gaming 5
CPU
i7-6700K
Graphics
GTX 970
Working on my first build in awhile:

Components
CPU: i7-6700K
GPU: EVGA 970
Motherboard: GA-Z170MX-Gaming 5
NVMe: Samsung 960 Evo 500GB

BIOS
1. Load Optimized Defaults
Secure Boot Mode disabled
XHCI Hand-Off enabled
Serial Port disabled
VT-d disabled
(Note: NVMe shows up in BIOS)


I've used Unibeast 6.2.0 to create a USB installer of El Capitan. I was having trouble creating a bootable installer with clover directly.

In order to have NVMe drive show up in diskutil/installer

* git clone https://github.com/RehabMan/patch-nvme
* Copy KextsToPatch from NVMe_patches_10_11_6.plist to KextsToPatch in EFI/CLOVER/config.plist on USB

nvme_info_1.jpg nvme_info_2.jpg

Now I'm able to install El Capitan to the NVMe drive just fine, however when I try and boot the new install from the USB it will load for awhile and then error out with a circle with a cross through it. Booting with verbose mode doesn't help much as the screen gets garbled when the circle with a cross shows up.

Things I've tried (possibly incorrectly)
* Copying the USB EFI partition to the new install's EFI partition.
* run ./patch_nvme.sh 10_11_6 to generate HackrNVMeFamily-10_11_6.kext and install at /S/L/E [1]
* run ./patch_nvme.sh --spoof 10_11_6 to generate HackrNVMeFamily-10_11_6.kext and install at /S/L/E [1]
* installing osxupdcombo10.11.6.dmg with the above

Any suggestions on what to possibly do next to further debug things? It seems to start booting off the NVMe but I can't seem to figure out what's killing it. Please let me know which files I should upload to help clarify my setup.

[1] renamed NVMe_patches_10_11_6_sec2016-003.plist to NVMe_patches_10_11_6.plist (Real mac is on 10.11.6)
Code:
Output when generating kexts
Creating patched HackrNVMeFamily-10_11_6.kext
Vanilla MD5 matches expected MD5 entry (b3b4dd50b2bbd9cc4dc901fad12643ac)
Patched MD5 matches expected MD5 entry (6ea6fd529ee962f6308b95a854897556)
 
Last edited:
Working on my first build in awhile:

Components
CPU: i7-6700K
GPU: EVGA 970
Motherboard: GA-Z170MX-Gaming 5
NVMe: Samsung 960 Evo 500GB

BIOS
1. Load Optimized Defaults
Secure Boot Mode disabled
XHCI Hand-Off enabled
Serial Port disabled
VT-d disabled
(Note: NVMe shows up in BIOS)


I've used Unibeast 6.2.0 to create a USB installer of El Capitan. I was having trouble creating a bootable installer with clover directly.

In order to have NVMe drive show up in diskutil/installer

* git clone https://github.com/RehabMan/patch-nvme
* Copy KextsToPatch from NVMe_patches_10_11_6.plist to KextsToPatch in EFI/CLOVER/config.plist on USB

View attachment 227242 View attachment 227243

Now I'm able to install El Capitan to the NVMe drive just fine, however when I try and boot the new install from the USB it will load for awhile and then error out with a circle with a cross through it. Booting with verbose mode doesn't help much as the screen gets garbled when the circle with a cross shows up.

Things I've tried (possibly incorrectly)
* Copying the USB EFI partition to the new install's EFI partition.
* run ./patch_nvme.sh 10_11_6 to generate HackrNVMeFamily-10_11_6.kext and install at /S/L/E [1]
* run ./patch_nvme.sh --spoof 10_11_6 to generate HackrNVMeFamily-10_11_6.kext and install at /S/L/E [1]
* installing osxupdcombo10.11.6.dmg with the above

Any suggestions on what to possibly do next to further debug things? It seems to start booting off the NVMe but I can't seem to figure out what's killing it. Please let me know which files I should upload to help clarify my setup.

[1] renamed NVMe_patches_10_11_6_sec2016-003.plist to NVMe_patches_10_11_6.plist (Real mac is on 10.11.6)
Code:
Output when generating kexts
Creating patched HackrNVMeFamily-10_11_6.kext
Vanilla MD5 matches expected MD5 entry (b3b4dd50b2bbd9cc4dc901fad12643ac)
Patched MD5 matches expected MD5 entry (6ea6fd529ee962f6308b95a854897556)

If you installed FakeSMC.kext to the system volume, keep in mind kexts in EFI/Clover/kexts are not injected due to config.plist/SystemParameters/InjectKexts=Detect.

Also, you should read here: https://www.tonymacx86.com/threads/...h-ionvmefamily-using-class-code-spoof.210316/
 
I think I've made some progress but I'm running into a kernel panic (see attached picture)

So installation worked fine with the KextsToPatch in the config.plist.

After installation I did the following:

* Created a SSDT-NVMe-Pcc.aml (attached) and moved to /EFI/CLOVER/ACPI/patched
My NVMe was located at \_SB.PCI0.RP09.PXSX. I was able to use the Windows 10 USB creator to figure this out but it looks similar to the address in one of the pictures in my first post just without the _SB.
I'm unsure if this was created properly but I made sure to use the patched version of MaciASL

*_DSM->XDSM in config.plist (attached as config_panic.plist)

* Created HackrNVMeFamily-10_11_6.kext and moved to /EFI/CLOVER/kexts/10.11
./patch_nvme --spoof 10_11_6

I removed the NVMe KextsToPatch entries from the config.plist.

Other kexts in /EFI/CLOVER/kexts/10.11 from Unibeast 6.2.0
* AppleIntelE1000e
* AtherosE2200Ethernet
* FakeSMC
* RealtekRTL8111
* USBInjectAll

Edit: NVMe PCI Device ID 144d:a804 on Non-Volatile memory controller [0108]
 

Attachments

  • kernel_panic.jpg
    kernel_panic.jpg
    1.2 MB · Views: 589
  • config_panic.plist
    5 KB · Views: 379
  • SSDT-NVMe-Pcc.aml
    118 bytes · Views: 334
Last edited:
I think I've made some progress but I'm running into a kernel panic (see attached picture)

So installation worked fine with the KextsToPatch in the config.plist.

After installation I did the following:

* Created a SSDT-NVMe-Pcc.aml (attached) and moved to /EFI/CLOVER/ACPI/patched
My NVMe was located at \_SB.PCI0.RP09.PXSX. I was able to use the Windows 10 USB creator to figure this out but it looks similar to the address in one of the pictures in my first post just without the _SB.
I'm unsure if this was created properly but I made sure to use the patched version of MaciASL

*_DSM->XDSM in config.plist (attached as config_panic.plist)

* Created HackrNVMeFamily-10_11_6.kext and moved to /EFI/CLOVER/kexts/10.11
./patch_nvme --spoof 10_11_6

I removed the NVMe KextsToPatch entries from the config.plist.

Other kexts in /EFI/CLOVER/kexts/10.11 from Unibeast 6.2.0
* AppleIntelE1000e
* AtherosE2200Ethernet
* FakeSMC
* RealtekRTL8111
* USBInjectAll

Edit: NVMe PCI Device ID 144d:a804 on Non-Volatile memory controller [0108]

Again: If you installed FakeSMC.kext to the system volume, keep in mind kexts in EFI/Clover/kexts are not injected due to config.plist/SystemParameters/InjectKexts=Detect.

Note also that the spoof method is not needed in 10.11.6, although it doesn't hurt.

In the class-code spoof guide, there is a section marked "Problem Reporting". You should provide as much of that data that you can. Also, you will need to provide output from patch_nvme.sh, output from 'sudo kextcache -i /' (boot using USB if needed).
 
Last edited:
So after a lot of trial and error I was able to get the installation to boot and finalize the setup.

The following four things were needed and the NVMe boot drive would not boot the installation if any one was missing:

* _DSM to XDSM DSDT patches in config.plist
* HackrNVMeFamily.kext in EFI/CLOVER/kexts/10.11
* SSDT-NVMe-Pcc.aml in EFI/ACPI/patched
* NVMe KextsToPatch in config.plist

From reading other NMVe posts you've commented on I was under the assumption that the best way to stabilize things was to remove the KextsToPatch after the installation had been complete and force the loading of the HackrNVMeFamily. I tried removing the NVMe KextsToPatch and putting in the entries in IONVMe_disable_rename.plist but it wouldn't boot.

After setting up OS X I was able to copy the USB EFI folder to the EFI partition on the boot NVMe and things continued to boot.

I've attached my EFI folder without themes and a picture of the BIOS device name of my NVMe. EFI/ACPI/origin has been populated from the Clover boot menu with F4. Is there anything I should be doing to achieve better stability when using my NVMe as the main drive?

Edit: EFI.zip was incorrectly created. Removed.
 

Attachments

  • NVMe BIOS device name.png
    NVMe BIOS device name.png
    2.7 MB · Views: 430
Last edited:
So after a lot of trial and error I was able to get the installation to boot and finalize the setup.

The following four things were needed and the NVMe boot drive would not boot the installation if any one was missing:

* _DSM to XDSM DSDT patches in config.plist
* HackrNVMeFamily.kext in EFI/CLOVER/kexts/10.11
* SSDT-NVMe-Pcc.aml in EFI/ACPI/patched
* NVMe KextsToPatch in config.plist

From reading other NMVe posts you've commented on I was under the assumption that the best way to stabilize things was to remove the KextsToPatch after the installation had been complete and force the loading of the HackrNVMeFamily. I tried removing the NVMe KextsToPatch and putting in the entries in IONVMe_disable_rename.plist but it wouldn't boot.

After setting up OS X I was able to copy the USB EFI folder to the EFI partition on the boot NVMe and things continued to boot.

I've attached my EFI folder without themes and a picture of the BIOS device name of my NVMe. EFI/ACPI/origin has been populated from the Clover boot menu with F4. Is there anything I should be doing to achieve better stability when using my NVMe as the main drive?

Attach ioreg as ZIP: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

Provide output (in Terminal):
Code:
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc
kextstat|grep -y applehda

Attach EFI/Clover folder as ZIP (press F4 at main Clover screen before collecting). Please eliminate 'themes' directory. Provide only EFI/Clover, not the entire EFI folder.

Attach output of (in Terminal):
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

Compress all files as ZIP. Do not use external links. Attach all files using site attachments only.
 
Code:
focii$ kextstat|grep -y acpiplat
   12    1 0xffffff7f81c74000 0x60000    0x60000    com.apple.driver.AppleACPIPlatform (4.0) A29C7512-D3A8-3AED-9721-3A5FF1A32EB2 <11 10 7 6 5 4 3 1>
focii$ kextstat|grep -y appleintelcpu
focii$ kextstat|grep -y applelpc
focii$ kextstat|grep -y applehda
focii$ sudo touch /System/Library/Extensions && sudo kextcache -u /

Attached EFI/Clover & ioreg (from v2.1) in focii_EFI.zip

Note: I have not installed any audio fixes or nVidia web driver with the run commands.
 

Attachments

  • focii_EFI.zip
    3.3 MB · Views: 268
Code:
focii$ kextstat|grep -y acpiplat
   12    1 0xffffff7f81c74000 0x60000    0x60000    com.apple.driver.AppleACPIPlatform (4.0) A29C7512-D3A8-3AED-9721-3A5FF1A32EB2 <11 10 7 6 5 4 3 1>
focii$ kextstat|grep -y appleintelcpu
focii$ kextstat|grep -y applelpc
focii$ kextstat|grep -y applehda
focii$ sudo touch /System/Library/Extensions && sudo kextcache -u /

Attached EFI/Clover & ioreg (from v2.1) in focii_EFI.zip

Note: I have not installed any audio fixes or nVidia web driver with the run commands.

The class-code injection is working and HackrNVMeFamily (generated with --spoof option) is loading.
You can remove all of the IONVMeFamily patches (they are not doing anything, since IONVMeFamily is not loading, due to the class-code spoof).
 
The class-code injection is working and HackrNVMeFamily (generated with --spoof option) is loading.
You can remove all of the IONVMeFamily patches (they are not doing anything, since IONVMeFamily is not loading, due to the class-code spoof).

When I remove the 13 patches for the IONVMeFamily one of two things will happen.

1. A kernel panic with the backtrace of com.apple.iokit.IOSCSIArchitectureModelFamily (same as https://www.tonymacx86.com/attachments/kernel_panic-jpg.227739/ from above)

2. The following lines appear shortly before a reboot

Code:
OSMetaClass: Kext com.apple.iokit.IONVMeFamily class IONVMeController is a duplicate; kext com.apple.hack.HackrNVMeFamily already has a class by that name.
Kext com.apple.iokit.IONVMeFamily start failed
Kext com.apple.iokit.IONVMeFamily failed to load
Failed to load kext com.apple.iokit.IONVMeFamily

However if I keep the NVMe SSD IONameMatch patch in it will boot.
 
When I remove the 13 patches for the IONVMeFamily one of two things will happen.

1. A kernel panic with the backtrace of com.apple.iokit.IOSCSIArchitectureModelFamily (same as https://www.tonymacx86.com/attachments/kernel_panic-jpg.227739/ from above)

2. The following lines appear shortly before a reboot

Code:
OSMetaClass: Kext com.apple.iokit.IONVMeFamily class IONVMeController is a duplicate; kext com.apple.hack.HackrNVMeFamily already has a class by that name.
Kext com.apple.iokit.IONVMeFamily start failed
Kext com.apple.iokit.IONVMeFamily failed to load
Failed to load kext com.apple.iokit.IONVMeFamily

However if I keep the NVMe SSD IONameMatch patch in it will boot.

It is because you're running 10.11.x, and the native IONVMeFamily.kext in 10.11 is slightly different from 10.12. It has an IOName match for 144d,a804, which matches exactly your device. You can see it if you look at the Info.plist for 10.11.6 IONVMeFamily.kext. So... that patch is actually making the native IONVMeFamily.kext NOT match. Original purpose was to change the match so it matched on the Samsung 950 Pro, which is 144d,a802. If you were to be using the KextsToPatch technique with the idea of using IOVNMeFamily with a 960 EVO, you would need to omit that patch.

You would not be having the same issue on 10.12.x. I find it interesting that 10.11.x had direct support for the Samsung 960 EVO, as it wasn't even released by Samsung at the time. It also implies there is a way to change the block size on that device to 4k, because otherwise there would be no sense for Apple to have added that id directly.

But back to the real subject here... In order to work around that problem (eg... avoid IONVMeFamily loading...), you should inject "compatible"="pci144d,a801" (just needs to be different). You might also have to inject "IOName"="pci144d,a801". Maybe also "name"="pci144d,a801". Try first with just "compatible" though.

Code:
// Inject bogus class code for NVMe SSD so that native IONVMeFamily.kext does not load
// also inject "compatible" so that 10.11.6 IONVMeFamily.kext doesn't match
// uncomment the "IOName" inject if needed
// uncomment the "name" inject if needed
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.RP09.PXSX, DeviceObj)
    Method(_SB.PCI0.RP09.PXSX._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "compatible", Buffer() { "pci144d,a801" },
            //"IOName", "pci144d,a801",
            //"name", Buffer() { "pci144d,a801" },
        })
    }
}
//EOF

Please report back on which of the injects (one or more than one...), "compatible", "IOName" or "name" are needed.
 
Last edited:
Status
Not open for further replies.
Back
Top