Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

Yes that's correct. We require RC Scripts in order to properly emulate NVRAM.

Alright I followed along to the best of my abilities and crashed at the Splash Screen where I received the message "Legacy AptioMemoryFix detected". I tried removing that from the "CLOVER/drivers/UEFI" folder and it then would stall at the Splash screen upon boot. I restored my EFI from a backup and I'm now safely back at r4961.

Was I supposed to replace the "CLOVER/drivers/UEFI" folder with the version from the "Catalina Fresh Install.zip" or copy the drivers over? (I copied the drivers over last attempt).

I knew this would be a bear which is why I've put it off so long.

Thanks for your patience.
 
I moved Lilu, AppleALC, Whatevergreen & VirtualSMC kexts out of L/E back to EFI/CLOVER/kexts/other. I am wondering
if my problem stems from some leftover old kexts in L/E? Here's a screenshot. I'm thinking I can ditch the old "USBInjectAll.kext" at least..
 

Attachments

  • Screen Shot 2020-01-15 at 2.45.12 PM.png
    Screen Shot 2020-01-15 at 2.45.12 PM.png
    1.1 MB · Views: 113
Indeed we are. So much so in fact that it appears that the problem has been solved!
The script has determined the following partitions for the backup task:
Code:
sourceEFIPartition = disk1s1
destinationEFIPartition = disk0s1

Referencing these in your diskutil list output gives us the following disks:
Code:
"disk1s1" -> belongs to "disk1" -> is container for "disk4" -> is APFS volume "Catalina"
"disk0s1" -> belongs to "disk0" -> is container for "disk3" -> is APFS volume "Catalina Clone"

As such we can now see that the two partitions were correctly found!

I'd like @CaseySJ to take a look at the results as well, just to double-check everything, but I believe this issue has thus been fixed for good.
The EFIClone-v3-experimental script is exactly the same as the current one with the fix applied, so it should be good to drop-in and replace the current one after validation.

The issue lay in the getEFIVolume method. It receives as input the disk we want to find the EFI partition for, i.e. "disk4". The problem was that it was checking for string equality in a somewhat open-ended fashion using grep "$1". Given the string "disk1" as input, it would match all disks that contained this string.
This is where we find out why this issue only affected very few people, those with a large amount of drives configured. Specifically, anyone with drives in the double digits or more.
The grep would then still try to match "disk1", but if you have, say, 16 disks (including virtual ones for APFS stuff etc), it would also match every other disk starting with "disk1", which is basically every disk above and including "disk10".
In your case, only disk13 and disk14 had an EFI partition, so that is why those two also appeared in your original output.

To fix this, we remove the open-endedness of the grep command by switching to grep "$1s". This adds an "s" to every input string, so that "disk1" becomes "disk1s". macOS distinguishes partitions using the syntax disk<num>s<partition>, so we can safely match using this method since we want to find a partition anyway. This cuts off the matching string after the actual number, preventing grep from matching anything other than the actual disk number. Thus the problem is fixed.

In typical development fashion, it all came down to a fix of literally a single character.

I would recommend we wait for Casey to take a look at the results and the proposed fix and once everything's greenlit, I think we should be good for using this script in setups with large amounts of disks safely.

I have already updated the script in my original GitHub repository with this fix as well.
Great work @byteminer! I really appreciate the time and effort you and @CaseySJ have put into this! I also love that you guys take the time to make it understandable for noobs like me!
 
This was my working Efi with the RX580. I used it with iMac18,3 and iMac19,1 (I use no onboard Audio and a different Bluetooth chip). I changed the Serial Numbers.

The differences I found are:

1) I disabled HDAS to HDEF
2) I have less entries in Boot Arguments. I used no shiki with the 580 and im not sure if you really need agdpmod. I also never needed keepsyms=1
3) different platform-id in Devices/Properties (headless, I hope your iGPU is set to ON (BIOS) and NOT connected!!)

I would try with my config to look if it works and then add your additional entrys one after the other, to see where the problem came from.

The rest of your Clover folder (I hope it is called "EFI" on your Partition) seems OK to me.

Do you have drivers installed in Library/Extensions as well? Personally I would not install anything there. But if, make sure that they are the same as in your EFI/drivers/UEFI folder and also not more than there.

By the way, I never used the HDMI and DVI Outs. Only Displayport.
Your Clover configuration looks correct. Some suggestions:
  • Try disabling WhateverGreen by adding -wegoff to Boot Arguments.
  • Also try updating WhateverGreen to version 1.3.6.
  • If instability continues, also remove agdpmod=pikera from Boot Arguments.
  • What is the make/model of your RX 580?
  • What is the make/model of your monitor?
  • Are you using HDMI or DisplayPort?
  • Are you using any adapters such as a DVI or VGA adapter?
SOLVED (I think)
I got rid of the shikis and agdpmod as you suggested. I updated all my kexts including WhateverGreen. However I was still having difficulties with my monitors not coming on-- from pre-BIOS.

I was suspicious of my Corsair H100 liquid cooling because its lights weren't on and my temps were consistently in the 40s and 50s. I also suspected it might be pulling too much power. I replaced it with the Dark Rock Pro 4 and moved my GPU from the top slot to the middle slot. Now my temps are in the 20s and 30s and everything seems buttery. My monitor problems are gone, even though I'm still using 1 DP cable and 1 HDMI with my monitors (Asus VN248s).

Thank you VERY MUCH for your time and attention. Fingers crossed I can leave you guys alone for awhile. ; )
 
Alright I followed along to the best of my abilities and crashed at the Splash Screen where I received the message "Legacy AptioMemoryFix detected". I tried removing that from the "CLOVER/drivers/UEFI" folder and it then would stall at the Splash screen upon boot. I restored my EFI from a backup and I'm now safely back at r4961.

Was I supposed to replace the "CLOVER/drivers/UEFI" folder with the version from the "Catalina Fresh Install.zip" or copy the drivers over? (I copied the drivers over last attempt).

I knew this would be a bear which is why I've put it off so long.

Thanks for your patience.
Because only 1 memory fix driver is allowed, we should delete AptioMemoryFix.efi. The replacement driver consists of 3 files:
  • OcQuirks.plist
  • OcQuirks.efi
  • FwRuntimeServices.efi
 
I moved Lilu, AppleALC, Whatevergreen & VirtualSMC kexts out of L/E back to EFI/CLOVER/kexts/other. I am wondering
if my problem stems from some leftover old kexts in L/E? Here's a screenshot. I'm thinking I can ditch the old "USBInjectAll.kext" at least..
All of those files should remain in /L/E (and we should run Kext Utility to rebuild the kernel cache). Namely:
  • VirtualSMC
  • Lilu
  • WhateverGreen
  • AppleALC
  • USBInjectAll
 
Hi @CaseySJ,

First of all, thank you for your incredibly detailed guide and continued support of this thread mate, you're awesome. I just wanted to ask, has there been any movement in finding a compatible WiFi/BT card for the onboard port in the past year at all?

Cheers
 
Last edited:
Hi @CaseySJ,

First of all, thank you your for incredibly detailed guide and continued support of this thread mate, you're awesome. I just wanted to ask, has there been any movement in finding a compatible WiFi/BT card for the onboard port in the past year at all?

Cheers
Hello @Jamz0161

I'm afraid you won't like the answer! Here goes:
  • The CNVi socket is not a typical general-purpose M.2 slot.
  • Instead, it seems to be a very specialized socket whose job is to connect an Intel CNVi module to the Z390 chipset.
  • No other module will be accepted there.
This does not bother me at all because:
  • Windows happily uses the Intel CNVi module to provide WiFi 5 and Bluetooth 5 support.
  • Windows does not recognize the Fenvi FV-T919 (do not install any Broadcom drivers in Windows).
  • So when I boot into Windows, the Intel CNVi is fully operational.
  • And when I boot into macOS, the Fenvi is fully operational.
  • Hence, neither card is wasted.
If Apple ever develops a macOS driver for the Intel CNVi module, then we'll save ourselves a PCIe slot.
 
So if I do follow " Step 1, Bullet #4 in the Catalina Mini-Guide to update Clover." it says to match this screen from the installer which is what is installing "AptioMemoryFix.efi" to my new clover install. I'm thinking now I shouldn't follow Bullet #4 so precisely?
 

Attachments

  • Screen Shot 2020-01-15 at 3.29.06 PM.png
    Screen Shot 2020-01-15 at 3.29.06 PM.png
    321.4 KB · Views: 72
Back
Top