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

[Ploddles]

I believe it's easier to do this on a Z370 board. Please try this:

• Make sure you have a USB flash disk (formatted as scheme = GUID Partition Map) that contains a copy of the current EFI Folder in its EFI Partition.
• You can make the changes below to the EFI partition of this USB flash disk (and thus avoid any damage to the main macOS disk).
  • Move AptioMemoryFix.efi to your Documents or Downloads folder and delete it from the CLOVER drivers folder.
  • Copy all 3 files in OcQuirks-for-Z370.zip to the same CLOVER drivers folder and reboot.
  • Press F12 (or the function key needed for your board to open the Boot Menu) at the BIOS splash screen and select the USB flash disk to boot from.
  • Does it work?
  • If not, delete those 3 files and copy the 3 files in OcQuirks-for-Z390.zip to the CLOVER drivers folder and reboot.
  • Press F12 (or the function key needed for your board to open the Boot Menu) at the BIOS splash screen and select the USB flash disk to boot from.
  • Does it work?

A couple of weeks ago I tried OcQuirks-4 with both my Z390 and Z370 based systems and both worked fine. Since then I updated the Z390 board system to the OcQuirks.efi in combination with OcQuirks.plist version. That one runs fine but I haven't got round to trying it with the Z370 system.
What is the difference between the Z390 and Z370 files above, ie should I hold off updating to the .plist version for the time being?

 

[byteminer]

Thanks @CaseySJ. Here's the diskutil list. I had to do it as screenshots because when I copy and pasted the text it was very difficult to read. I can put it in a .txt file if you prefer.

View attachment 445023View attachment 445024

Could you additionally also upload the output of:

diskutil apfs list

I strongly suspect this is the part where things go awry, so that information would be very beneficial in figuring this out.

As an extra, it would be greatly beneficial if you could post this and the previous one as text documents, which would allow me to more easily emulate your setup for local testing.

 

[EliM]

The screenshot helps. Please also post the output from this command in Terminal: diskutil list

There is a very suspicious line in the log:
[Tue Jan 14 12:01:01 PST 2020] - sourceEFIPartition = disk1s1 disk13s2 disk14s1

sourceEFIPartition should be only one disk, not three. I want to understand where disk13s2 and disk14s1 are coming from, hence the diskutil command above.

And this line in the log shows the problem:
[Tue Jan 14 12:01:03 PST 2020] - rsync -av --exclude='.*'' / /Volumes/EFI 1/

It should read something like this:
rsync -av --exclude='.*" /Volumes/EFI/ /Volumes/EFI 1/

• /Volumes/EFI/ <--- this is the source EFI mount point
• /Volumes/EFI 1/ <--- this is the destination EFI mount point

The fact that the source EFI mount point is simply "/" in the log, it means something went terribly wrong.

@CaseySJ, you probably already realized this, but disk13s2 and disk14s1 are on the drive that was manually partitioned. disk13s2 is the efi for my windows backup and disk14s1 is the efi for my baseline clone (my baseline clone is not the source or destination for the ccc task).

 

[EliM]

Could you additionally also upload the output of:

diskutil apfs list

I strongly suspect this is the part where things go awry, so that information would be very beneficial in figuring this out.

As an extra, it would be greatly beneficial if you could post this and the previous one as text documents, which would allow me to more easily emulate your setup for local testing.

You got it. Files attached. Had to compress them as it wouldn't let me upload .rtf files

 

[byteminer]

Hey @EliM, would it be possible for you to try and run the script manually, from inside the Terminal?
The command would have to look like this:

sudo /Library/Application\ Support/com.bombich.ccc/Scripts/EFIClone-v3.sh / "/Volumes/Catalina Clone - Data" 0 ""

I'm asking because some of the commands that the script uses internally can output errors to the command line without actually failing and as such the only way to check at this moment is to run it in the terminal to see whether anything pops up.
This is specifically important here because *if* one of the sub-commands that determines i.e. the disk numbers for source/target fails it can return an empty value, which can lead to subsequent commands outputting multiple disks, as has happened in your original case.

Be aware that this script is running as root, meaning it has access to everything on your system, so be very careful when executing this! Also, under all circumstances, double check to verify that the TEST_SWITCH variable is set to:

TEST_SWITCH="Y"

For this you will have to open the actual script file and scroll down a few lines, to about line 85.

If possible, please additionally run the following:

bdmesg | grep 'SelfDevicePath'

This specifically is a test to check whether the drive you're booting from can actually be found by the currently employed method the script uses.

 

[EliM]

Hi @byteminer, thanks for you help on this! The results are in the two attached files.

Hey @EliM, would it be possible for you to try and run the script manually, from inside the Terminal?
The command would have to look like this:

sudo /Library/Application\ Support/com.bombich.ccc/Scripts/EFIClone-v3.sh / "/Volumes/Catalina Clone - Data" 0 ""

I'm asking because some of the commands that the script uses internally can output errors to the command line without actually failing and as such the only way to check at this moment is to run it in the terminal to see whether anything pops up.
This is specifically important here because *if* one of the sub-commands that determines i.e. the disk numbers for source/target fails it can return an empty value, which can lead to subsequent commands outputting multiple disks, as has happened in your original case.

Be aware that this script is running as root, meaning it has access to everything on your system, so be very careful when executing this! Also, under all circumstances, double check to verify that the TEST_SWITCH variable is set to:

TEST_SWITCH="Y"

For this you will have to open the actual script file and scroll down a few lines, to about line 85.

If possible, please additionally run the following:

bdmesg | grep 'SelfDevicePath'

This specifically is a test to check whether the drive you're booting from can actually be found by the currently employed method the script uses.

Hi @byteminer, thanks for your help on this! The results are in the two attached files.

 

[byteminer]

Hi @byteminer, thanks for you help on this! The results are in the two attached files.

This is great! We are now one step closer to unraveling this mystery. It looks like there is a diskutil command somewhere in there which is messing things up as it is receiving malformed input data from somewhere earlier in the script.
This goes hand in hand with the output it generates: disk1s1
Given the string "disk1", the script will gather all disks that start with a "1" (before the "s" part that denotes the partition) and contain an EFI partition, which in your case are disk1s1 disk13s2 and disk14s1, matching up with your original results.

We now have to figure out where exactly the script starts going wrong. To this extent I have attached a slightly modified version of the EFIClone-v3 script that adds additional debug output. I have also completely removed the actual file synchronization part so it's completely safe to run as it has no way of messing with the filesystem anymore.
If you could run this script the same way as before using the Terminal and supply both, the terminal output as well as the newly generated log file, that would be much appreciated

 

[WhosMac]

@CaseySJ Wanted to send an update.

So attempted to boot backup drive got blank screen again.

Turns out was still In boot sequence for updated EFI so switched boot sequence and got the backup booted and replaced all updated items with the old and was able to boot into the main drive.

Updated to AudioLayout ID 11 in Devices section.
-rebootEd. Booted fine hackintool shows audio 11 and don’t get choppiness in case jack now.

Updated Lilu next.
-reboot: booted in just fine

Updated VirtualSMC
-reboot working just fine again.

Updated AppleALC
-reboot: working just fine

Updated WEG/ Removed -wegoff arg
Kept “ adgpmode = pikera” boot arg

Rebooted: looks fine as of now, testing the idle time make sure it doesn’t do a solo reboot. As of now it’s been up and idle for 9 mins no reboot.

So process of elimination seems when I removed the adgpmode = pikera boot arg it’s what caused my black screen and wouldn’t load anything after Apple boot screen

Edit: at 10.5 mins the monitors shut down, looked a little funky in discoloration, but did not restart just put monitors to sleep. touch of the keyboard brought it back up, however at 10.5 mins that's way after what the time was for me rebooting so as of now ill see when I leave it over night if it restarts but seems that WEG is working again fro 5700XT without causing idle reboot.

Also wanted to ask there was a shake value I believe =128 that was mentioned for amd GPU is that a necc boot arg?

 

[CaseySJ]

@WhosMac

That's more like it.

Regarding shikigva, my recommendation is to start with the values in the Catalina Mini-Guide, namely:

shikigva=32
shiki-id=Mac-7BA5B2D9E42DDD94

Then see whether the DRM content you want to view is viewable. Also try WhateverGreen 1.3.6.

And have a look at this chart:

WhateverGreen/FAQ.Chart.md at master · acidanthera/WhateverGreen

Various patches necessary for certain ATI/AMD/Intel/Nvidia GPUs - WhateverGreen/FAQ.Chart.md at master · acidanthera/WhateverGreen

github.com

 

[WhosMac]

@CaseySJ Wanted to send an update.

So attempted to boot backup drive got blank screen again.

Turns out was still In boot sequence for updated EFI so switched boot sequence and got the backup booted and replaced all updated items with the old and was able to boot into the main drive.

Updated to AudioLayout ID 11 in Devices section.
-rebootEd. Booted fine hackintool shows audio 11 and don’t get choppiness in case jack now.

Updated Lilu next.
-reboot: booted in just fine

Updated VirtualSMC
-reboot working just fine again.

Updated AppleALC
-reboot: working just fine

Updated WEG/ Removed -wegoff arg
Kept “ adgpmode = pikera” boot arg

Rebooted: looks fine as of now, testing the idle time make sure it doesn’t do a solo reboot. As of now it’s been up and idle for 9 mins no reboot.

So process of elimination seems when I removed the adgpmode = pikera boot arg it’s what caused my black screen and wouldn’t load anything after Apple boot screen

Edit: at 10.5 mins the monitors shut down, looked a little funky in discoloration, but did not restart just put monitors to sleep. touch of the keyboard brought it back up, however at 10.5 mins that's way after what the time was for me rebooting so as of now ill see when I leave it over night if it restarts but seems that WEG is working again fro 5700XT without causing idle reboot.

Also wanted to ask there was a shake value I believe =128 that was mentioned for amd GPU is that a necc boot arg?

@heyelly You may want to give it a go, backup your system, and update WEG and remove the -wegoff boot arg and see if you have anymore idle or freeze issues that we were having before. I am currently back on dual DisplayPort monitors and had no issues after 10 mins I can give an actual overnight update tomorrow. But as it stands looks likes it functioning fine.
Dual Displayport from 5700XT to 2x 4k 3840x2160 60hz