Contribute
Register

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

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:
Code:
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:
Code:
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:
Code:
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.
 
Last edited:
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:
Code:
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:
Code:
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:
Code:
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.
 

Attachments

  • script run in terminal.rtf.zip
    1.3 KB · Views: 62
  • bdmesg.rtf.zip
    1.1 KB · Views: 75
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 :)
 

Attachments

  • EFIClone-v3-DEBUG.zip
    3.9 KB · Views: 68
@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?
 
@WhosMac

That's more like it.

Regarding shikigva, my recommendation is to start with the values in the Catalina Mini-Guide, namely:
Code:
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:
 
@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
 
@WhosMac

That's more like it.

Regarding shikigva, my recommendation is to start with the values in the Catalina Mini-Guide, namely:
Code:
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:

What DRM content should I be seeing if I have issues with? I will mention I am using iMac Pro 1,1 SMBIOS and I've always had access to AppleTV content, don't know if there is others I should try?

Also the update to WEG 1.3.6 seems to be what fixed the idle reboot and I finally can use dual DisplayPort monitors again! lol

Appreciate the link to the chart will look that over now, may I ask what the 2 shiki values are for that you mentioned from the mini guide. I don't see those on the chart what do they do for the system?
 
Also @CaseySJ had a question, or more I should say a weird occurrence and how can I check it?

So I have a Plex server on the build, and Plex allows for hardware acceleration for encoding using intel quicksync from the newer intel processors, however to my knowledge I assume I don't have IGPU enabled because its not registered anywhere in the system. However when I turned the feature on I noticed I was getting the tag on the encodings that it was using hardware acceleration for the encoding process. Is there a way to test whether I have hardware acceleration or was it possibly using the GPU somehow? the Plex support page mentions

"The following are required in general for Hardware-Accelerated Streaming, regardless of your operating system:

  • A recent Intel CPU meeting these requirements:
    • 2nd-generation Intel Core (Sandy Bridge, 2011) or newer (we recommend 5th-gen Broadwell or newer for the best experience; Sandy Bridge, in particular, is known to sometimes have poor visual output on some systems)
    • Supports Intel Quick Sync Video (Not sure? Look up your processor)
  • Plex Media Server 1.9.3 or later
  • An active Plex Pass subscription"
So I don't know how it could have been the GPU
 
For those of you that have your home folder on a separate drive from your OS, what are your backup/restore steps? I have a third drive I would like to carbon copy clone and make it a bootable backup but I'm not sure exactly how it works with two separate drives housing my data. Or, do I only clone the system drive (EFI folder included) and not backup my home folder drive? How do you all handle this?
 
I just tried your OpenCore mini guide, and I can't believe how easy that was. is it really just the serial numbers and everything works? no more kexts etc? man this is great if so.

I just realized the kexts are installed... is it the same method to upgrade? just replace kext and reboot?


The first thing I did was test NVRAM

sudo nvram TestVar=HelloWorld
reboot
sudo nvram -p | grep 'TestVar'
no output

What do I need to look at here? I'm trying to go through this thread but haven't come across any suggestions yet.
 
Last edited:
Back
Top