Contribute
Register

The everything works Asus Z390-I Gaming * i7-8700K * SAPPHIRE NITRO+ Radeon RX Vega 64 Build

The EFIs form this post are deprecated, please go to Post #1 to get current EFIs.

@Monkey303 and others following this thread, I dug deep into the issues and spent the better part of 6 hours trying to find a common thread.

A few facts came out, with the last, being the most significant:

  1. Toleda, one of the developers of AppleALC specifically told me to use Audio layout 1 in Clover Configurator, devices, Audio inject. While this worked perfectly for me, many, if not all of you with a different video card experienced issues and had to use 7
  2. Some have had install issues, granted I wasn't clear that a hung black screen means you need to manually reboot because of emulated NVRAM.
  3. Others have had graphics issues or glitching on wake from sleep
  4. OsxAptiofixdrv is old and was replaced by Aptiomemoryfix. Please visit the linked GitHub to see reasons why
When I originally started my build, I read whatever Z390 guides I could and several mentioned that Aptiomemoryfix had to be used during install, then replaced with OsxAptiofixdrv2, Emuvariable, and RC-Scripts post install to get sleep, shutdown, and restart working.

To test this, I deleted OSXAptioFix3drv, RC Scripts (in /etc/rc.boot.d/), and my nvram.plist, and rebooted. The system booted fine but sleep, wake, and shutdown were completely broken, and I mean BROKEN.

Based on a thread I found (and forgot where), and based on the advice of the developer, I re-enabled emuvariable and lo and behold, everything worked again. I did not have to use slide=0 or RC scripts. I also cleaned up a few things:
  1. Removed the uninjectable BrcmFirmwareRepo.kext that I inadvertently left in when I added BrcmFirmwareData.kext. May have caused issues with Bluetooth, depending on your card.
  2. Removed the SAT0=SATA rename because I saw that WhatEverGreen did it already
  3. Removed some Kernel and Kext patches that I was testing and forgot to remove. They were disabled anyway
  4. I hid the preboot and recovery volumes to prevent noobie installer confusion.
  5. I removed a bothersome legacy entry scan that showed a Windows legacy drive. CC did not disable it in config like it was supposed to
  6. Probably a few other items I forgot
To install:

IMPORTANT: DO NOT REBOOT UNTIL YOU ARE INSTRUCTED TO!
  1. Backup your EFI folder and nvram.plist by copying them to a FAT32 formatted USB drive. You can always boot from USB if things go sideways. Yes, it that's easy! You can use a tiny drive, the folder is only about 32 MB (NOT GB!)
  2. Enable Above 4G Decoding in BIOS
  3. Boot and delete the 3 RC scripts in /etc/rc.boot.d/ on your main drive
  4. Download the appropriate EFI file attached to the end of THIS post
  5. Start Clover Configurator and mount your EFI partition
  6. Delete your whole EFI folder and nvram.plist
  7. Copy the EFI folder found in the unzipped EFI file you downloaded onto your EFI partition
  8. Reboot
You may have an issue with the screen going black and freezing at first. Don't panic, just use the reset button and everything will work once the nvram.plist is rewritten.

My system is currently running perfectly. I would really appreciate if some of you could lend the community a hand by testing the new EFIs attached to the bottom of THIS and report back with the results.

When I get confirmation it works I will update post #1

Thanks!
 
Last edited:
Okay. Just tried placing both only into /L/E, as well as only into Others, no luck.

My System Information -> Bluetooth tab only displays the text "No information found."

I was in the process of cleaning my EFI and realized that I left a copy of the BrcmFirmwareRepo.kext which would probably interfere with the BrcmFirmwareData.kext.

I fixed that and some other issues, give it a shot and let me know what happens.
 
@pastrychef I would like to take a moment to apologize if I caused you any issues by invoking your name in the great "Where should Kexts be installed" debate. Your response in that thread was definitive, to say the least. I hope we are good because the last I want is to cause you any grief, especially after all the help you gave me and others in this thread!

I also want to thank for cluing me into the device ID. I matched it to what HackinTool reported and ended up patching just the Device ID and not the Platform ID. That way I can easily create EFI configs with different Platform IDs but identical Device IDs for DGPU and IGPU users. Feedback is good so far.

I did remove the SAT0 rename because I saw that WhatEverGreen does it automatically in HackinTool, unless I am misunderstanding what I see, so please correct me if I am wrong:

393725


I also took a new Aptiomemoryfix + EmuVariable approach that seems to work for me, anxious to hear from a few people to see if it resolves outstanding issues. I'm afraid I am about to start another "Great Debate" about using emuvariable with Aptiomemoryfix.

I know that Aptiomemoryfix emulates nvram but it doesn't work on our MBs. It seems like it somehow writes the nvram.plist with a future date. When the system tries to shut down, sleep, or reset, the system prevents writing the new nvram.plist because it is older. I am going through my system to see if this issue is particular to me, or in general but I did report it on GitHUb in the meantime.

Cheers!
 

Attachments

  • Screen Shot 2019-03-18 at 2.34.25 PM.png
    Screen Shot 2019-03-18 at 2.34.25 PM.png
    80.8 KB · Views: 64
@pastrychef I would like to take a moment to apologize if I caused you any issues by invoking your name in the great "Where should Kexts be installed" debate. Your response in that thread was definitive, to say the least. I hope we are good because the last I want is to cause you any grief, especially after all the help you gave me and others in this thread!

I also want to thank for cluing me into the device ID. I matched it to what HackinTool reported and ended up patching just the Device ID and not the Platform ID. That way I can easily create EFI configs with different Platform IDs but identical Device IDs for DGPU and IGPU users. Feedback is good so far.

I did remove the SAT0 rename because I saw that WhatEverGreen does it automatically in HackinTool, unless I am misunderstanding what I see, so please correct me if I am wrong:

View attachment 393725

I also took a new Aptiomemoryfix + EmuVariable approach that seems to work for me, anxious to hear from a few people to see if it resolves outstanding issues. I'm afraid I am about to start another "Great Debate" about using emuvariable with Aptiomemoryfix.

I know that Aptiomemoryfix emulates nvram but it doesn't work on our MBs. It seems like it somehow writes the nvram.plist with a future date. When the system tries to shut down, sleep, or reset, the system prevents writing the new nvram.plist because it is older. I am going through my system to see if this issue is particular to me, or in general but I did report it on GitHUb in the meantime.

Cheers!

I don't think WhateverGreen renames SAT0. Easiest way to check is to launch IORegistryExplorer and search for "sat", then you will see if your SATA is named SAT0 or SATA.
Screen Shot 2019-03-18 at 4.05.13 PM.png
For the Aptio fixes, I've always just used whatever worked. I just go through the trial-and-error process to find whatever works. Towards the the end of my time with my Z170 build and when I first started my Z370 build, I used OsxAptioFix2Drv. Native NVRAM was broken with this version. Then, OsxAptioFix3Drv was released and native NVRAM was restored. Shortly after that, AptioMemoryFix was released which also restored native NVRAM and was preferred by most because of more active development. Also, I think OsxAptioFix2Drv has been completely depreciated and is not even included with the Clover installer anymore.

My understanding for Z390 is that native NVRAM is broken with all the available Aptio fixes. Therefore, EmuVariableUefi will have to be used regardless of which Aptio fix you use and probably also the RC Scripts. As for which Aptio fix to use, you will have to go through the trial-and-error testing to see which works best with (1) booting and (2) sleep/wake. In short, just use whichever Aptio fix works.
 
I don't think WhateverGreen renames SAT0

I was unsure of it myself. If that's the case, what is HackinTool basing its report on?

My understanding for Z390 is that native NVRAM is broken with all the available Aptio fixes. Therefore, EmuVariableUefi will have to be used regardless of which Aptio fix you use and probably also the RC Scripts. As for which Aptio fix to use, you will have to go through the trial-and-error testing to see which works best with (1) booting and (2) sleep/wake. In short, just use whichever Aptio fix works.

I tested the Asus Z390-I using the hello world test, and it does not have native RAM, so emulation is a must. The latest AptioMemoryFix is supposed to support it but has a weird bug that causes it to post the nvram.plist with a future creation date. Any attempt to update it is blocked by the system thinking it writing an older file. I was unaware that there were multiple versions, I will certainly check that out immediately.

Although I am using EmuVariableUEFI, I completely removed the RC scripts which works perfectly and further simplifies the solution.

Thanks for the help, off to research AptioMemoryFix versions!
 
I was unsure of it myself. If that's the case, what is HackinTool basing its report on?



I tested the Asus Z390-I using the hello world test, and it does not have native RAM, so emulation is a must. The latest AptioMemoryFix is supposed to support it but has a weird bug that causes it to post the nvram.plist with a future creation date. Any attempt to update it is blocked by the system thinking it writing an older file. I was unaware that there were multiple versions, I will certainly check that out immediately.

Although I am using EmuVariableUEFI, I completely removed the RC scripts which works perfectly and further simplifies the solution.

Thanks for the help, off to research AptioMemoryFix versions!

I don't know what Hackintool is reporting. I've only used it once, a very early version which was very different from what it is now. The current version doesn't even detect my IGPU.

If it works without the RC scripts, all the better. Hopefully, vit9696 will get AptioMemoryFix working correctly for Z390.
 
@Monkey303 and others following this thread, I dug deep into the issues and spent the better part of 6 hours trying to find a common thread.

A few facts came out, with the last, being the most significant:

  1. Toleda, one of the developers of AppleALC specifically told me to use Audio layout 1 in Clover Configurator, devices, Audio inject. While this worked perfectly for me, many, if not all of you with a different video card experienced issues and had to use 7
  2. Some have had install issues, granted I wasn't clear that a hung black screen means you need to manually reboot because of emulated NVRAM.
  3. Others have had graphics issues or glitching on wake from sleep
  4. OsxAptiofixdrv is old and was replaced by Aptiomemoryfix. Please visit the linked GitHub to see reasons why
When I originally started my build, I read whatever Z390 guides I could and several mentioned that Aptiomemoryfix had to be used during install, then replaced with OsxAptiofixdrv2, Emuvariable, and RC-Scripts post install to get sleep, shutdown, and restart working.

To test this, I deleted OSXAptioFix3drv, RC Scripts (in /etc/rc.boot.d/), and my nvram.plist, and rebooted. The system booted fine but sleep, wake, and shutdown were completely broken, and I mean BROKEN.

While looking at the nvram.plist file, I notice that the Date Modified value was 5 hours in the future. This leads me to believe that the system is unable to update the file when sleeping, restarting or shutting down because it thinks it's trying to write an older file and the OS blocks it. This seems to be borne out by the system not displaying the customary wait icon as it shut down.

Based on a thread I found (and forgot where), and based on the advice of the developer, I re-enabled emuvariable and lo and behold, everything worked again. I did not have to use slide=0 or RC scripts. I also cleaned up a few things:

  1. Removed the uninjectable BrcmFirmwareRepo.kext that I inadvertently left in when I added BrcmFirmwareData.kext. May have caused issues with Bluetooth, depending on your card.
  2. Removed the SAT0=SATA rename because I saw that WhatEverGreen did it already
  3. Removed some Kernel and Kext patches that I was testing and forgot to remove. They were disabled anyway
  4. I hid the preboot and recovery volumes to prevent noobie installer confusion.
  5. I removed a bothersome legacy entry scan that showed a Windows legacy drive. CC did not disable it in config like it was supposed to
  6. Probably a few other items I forgot
To install:

IMPORTANT: DO NOT REBOOT UNTIL YOU ARE INSTRUCTED TO!
  1. Backup your EFI folder and nvram.plist by copying them to a FAT32 formatted USB drive. You can always boot from USB if things go sideways. Yes, it that's easy! You can use a tiny drive, the folder is only about 32 MB (NOT GB!)
  2. Enable Above 4G Decoding in BIOS
  3. Boot and delete the 3 RC scripts in /etc/rc.boot.d/ on your main drive
  4. Download the appropriate EFI file attached to the end of THIS post
  5. Start Clover Configurator and mount your EFI partition
  6. Delete your whole EFI folder and nvram.plist
  7. Copy the EFI folder found in the unzipped EFI file you downloaded onto your EFI partition
  8. Reboot
You may have an issue with the screen going black and freezing at first. Don't panic, just use the reset button and everything will work once the nvram.plist is rewritten.

My system is currently running perfectly. I would really appreciate if some of you could lend the community a hand by testing the new EFIs attached to the bottom of THIS and report back with the results.

When I get confirmation it works I will update post #1

Thanks!
Testing igpu with fresh install. Audio still is the same case. Allthough I will stay on layout 1 for a bit to see what we can do about it.

Installed from usb stick once and then continued with install from internal. It takes about 3 reboots to get it installed. That's the right amount I'm guessing.

Only one ghostbusters sign and that was fresh after I erased my Ssd and started the Computer booting first time from USB.
 
Last edited by a moderator:
Testing igpu with fresh install. Audio still is the same case. Although I will stay on layout 1 for a bit to see what we can do about it.

Installed from usb stick once and then continued with install from internal. It takes about 3 reboots to get it installed. That's the right amount I'm guessing.

Only one ghostbusters sign and that was fresh after I erased my Ssd and started the Computer booting first time from USB.

If 1 is still problematic and all your inputs and outputs work with 7, don’t bother with 1 anymore. I will also change over.

What I’m really looking for is whether or not it’s more stable and fixes any of your other issues.

I’m also curious to see if you have any more ghost busters once you’re fully installed.

If you do, it’s probably related to your drive setup. Make sure that the boot drive is first in BIOS boot order. Sounds like the system is looking for the drive before it’s ready.
 
Back
Top