Contribute
Register

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

I ended up going back to Clover. The no-restart issue was a hang because of a cups.cupsd issue. I removed the offending printer and the related caches and now everything runs great in Mojave. I really thought I was going to have to pull the CPU and go back to the Z370.
 

Attachments

  • M5 Multitronic Unit in Action.png
    M5 Multitronic Unit in Action.png
    275.4 KB · Views: 76
Daystrom M5 Multitronic Unit
Z390 DESIGNARE |  i9 9900K |  RX 6600 Pulse 8GB
The Guardian of Forever
Z370 AORUS Gaming 7 |  i7 8700K |  RX 580 Pulse 8GB
*** Comments on the CCC Backup Script ***​

  • Suffering from data loss defeats the very purpose of the backup script.
  • We do not take this lightly. Even if it affects one person, it means it could happen again. It might be the user's fault or it might not be the user's fault.
  • It is not my intention to play the blame game. It is neither my intention to remove the EFIClone script.
  • Reading through this or any other build guide, we can see that different users can have different hardware and software configurations.
  • A guide that works for some configurations may not work for all configurations. Although we list the components and configurations that were used in creating the guide, we don't test all possible configurations or all likely configurations.
  • But for something as critical as a backup script, there should be more failsafe mechanisms in place.
Adding Failsafes to EFIClone Script
  • The EFIClone script was written by another user. We're leveraging his work for our purposes.
  • The script uses rsync with the --delete option. This means that any files in the destination that do not exist on the source will be deleted.
    • Failsafe #1 is to remove the --delete option.
  • The script uses diskutil to find an EFI volume in both the source and destination. If it does not find "EFI" by name, it searches for CorePhysicalDeviceNumber. If it does not find that, it looks for APFSPhysicalDiskNumber. If the user did not format their destination disk as GUID Partition Map, then it likely won't contain an explicitly named EFI partition. So this failsafe guards against the use of such drives.
    • Failsafe #2 is to error out and terminate if an explicitly named EFI volume does not exist.
  • The script also has a TEST_SWITCH that performs a dry-run where the script will only log the changes to be made, but will not make any changes. This let's us verify that the script will work correctly. TEST_SWTICH is currently turned off.
    • Failsafe #3 is to set TEST_SWITCH to Y by default. This forces every user to examine the dry-run log, ensure that it looks correct, and then manually set the switch to N. This also places full responsibility on the user.
Summary of Proposed Changes:
  • Three failsafes to be added as follows:
    • Failsafe #1
      • Remove --delete option from rsync.
    • Failsafe #2
      • Abort the script if an explicitly named EFI partition does not exist on both source and destination.
    • Failsafe #3
      • Enable dry-run mode by default and require users to manually set TEST_SWITCH to N when they're ready.
If anyone has other suggestions please let me know. Changes will be made to the script and the two CCC Backup Guides in the next day or two.

UPDATE: 24-Dec-2019
  • After further reflection on the three proposals, Failsafe #1 might not be a good idea after all. This is because:
    • Clover loads all drivers that are present in the drivers folder.
    • Clover loads all kexts present in the kexts folder.
    • Clover loads all aml files in the ACPI/patched folder.
    • If a driver or a kext or an ACPI (aml) file is removed from a working EFI folder in order to get the system working properly, but the problematic file or files are still present in the previous backup disk, then those problematic files will continue to exist in the backup disk even after a new backup is performed.
  • OpenCore, however, behaves differently:
    • OpenCore does not load all drivers in the Drivers folder.
    • OpenCore does not load all kexts in the Kexts folder.
    • OpenCore does not load all aml (ACPI) files in the ACPI folder.
    • Instead, OpenCore only loads those files that are explicitly named in its config.plist.
    • So for OpenCore, Failsafe #1 is still perfectly viable.
 
Last edited:
CaseySJ said:
The EFI was originally configured for use with the standard DSDT. After the modified version was posted by @hylkepylke all of those SSDTs became unnecessary except for Thunderbolt. (By the way I’m not sure if Thunderbolt hot plug works. It needs to be tested.)
Click to expand...

I tried OpenCore and the kernel panics after loading ACPI tables. Does the DSDT rely on any specific hardware configuration? I have a Define R6 with my RX 580 in slot 2 (and use the corresponding SSDT's you created in my working Clover configuration.)

I think this is the relevant information:

ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160930/psobject-310)
ACPI Exception: AE_ALREADY_EXISTS, (SSDT: DTPG) while loading table (20160930/tbxfload-319)
ACPI ERROR: 2 table load failures, 10 successful (20160930/tbxfload-342)
panic(cpu 0 caller 0xffffff80004dd9bd): Kernel trap at 0xffffff7f8285e760, type 14=page fault, registers:
.......
Click to expand...

but maybe that's normal?
 
CaseySJ said:
My Experience Performing
In-Place Upgrade of Mojave 10.14.6 to Catalina 10.15​

Updates:
  • 13 October 2019: Before upgrading from Mojave to Catalina, make a full bootable backup. Then install latest versions of the following kexts on the Mojave system beforebeginning the Catalina upgrade:
    • Lilu
    • WhateverGreen
    • AppleALC
Click to expand...
Hey, @CaseySJ. I have a question. Is this the latest info? I mean to upgrade to Catalina?
Thanks everyone. Merry Christmas.
 
qmediaservices said:
Hey CaseySj, I have a question, is this the latest info? I mean to upgrade to Catalina?
Thanks everyone, Merry Christmas.
Click to expand...
This is still a valid procedure for upgrading from Mojave to Catalina. However, if you're using an AMD RX 5700-series GPU it's necessary to also add the Boot Argument agdpmod=pikera. An MSI RX 5700-series GPU may not work during installation or upgrade of macOS (regardless of boot arguments), but other RX 5700-series GPUs are okay as far as we know (we haven't tested them all). The Sapphire and PowerColor versions have been tested successfully.
 
oopsmybad said:
I tried OpenCore and the kernel panics after loading ACPI tables. Does the DSDT rely on any specific hardware configuration? I have a Define R6 with my RX 580 in slot 2 (and use the corresponding SSDT's you created in my working Clover configuration.)

I think this is the relevant information:



but maybe that's normal?
Click to expand...
That message indicates that another DTGP method already exists. So when SSDT-DTPG attempts to define DTGP, there's a conflict with the already-defined method. Suggestions:
  • Option 1: Disable the SSDT-DTPG aml file itself by setting its Enable field to false at the top section of OpenCore config.plist.
  • Option 2: Search all existing aml files to see where method DTGP is defined, and let me know.
P.S. Notice the confusion between DTPG in the filename and DTGP as the method name.
 
CaseySJ said:
That message indicates that another DTGP method already exists. So when SSDT-DTPG attempts to define DTGP, there's a conflict with the already-defined method. Suggestions:
  • Option 1: Disable the SSDT-DTPG aml file itself by setting its Enable field to false at the top section of OpenCore config.plist.
  • Option 2: Search all existing aml files to see where method DTGP is defined, and let me know.
P.S. Notice the confusion between DTPG in the filename and DTGP as the method name.
Click to expand...

I tried disabling (just) SSDT-DTPG.aml in the config.plist, and bizarrely, OpenCore then complained the tables didn't exist at all! For kicks and giggles, I then deleted all the ACPI entries and created new ones for all the aml files that Clover uses (in ACPI/patched). OpenCore appeared to load all those successfully (no errors), but the boot still ended with the same kernel panic as in previous tests. It must not be related to ACPI.

I'll keep playing with it in the coming days...
 
CaseySJ said:
Some constructive criticism... please punctuate! :) After reading the above paragraphs twice, here's what I think you meant to say:

"I removed the MLB and items from RtVariables before posting. You mentioned to remove serial info so I removed the same info that is normally removed.

I will mention since finishing I’ve been testing a few things out. One of the things I’ve noticed is if I leave the computer on and idle, when I return to it, it’s back at clover boot screen. I had this issue before and it was fixed using the DSDT files on the patch section. However, this time around I already have those files in patch folder of EFI so not sure what’s causing it to reboot. I recall recently somewhere in the thread it being mentioned someone else is having a similar issue. I can’t recall whether it was solved, but I did see someone mentioning leaving their computer on overnight and not having any issues. Was there a fix that was found? I haven’t run Io registry yet to see what all is being recognized."

To address the long-term sleep problem, we asked a user (arvids) to add a 300-Series RTC patch to Clover Configurator --> ACPI as described here. That seemed to work for a couple of days.
  • Find* [HEX] = A00A9353 54415301
  • Replace* [HEX] = A00A910A FF0BFFFF
  • Comment = Fix 300-series RTC Bug
Another user (totototo) reported no problems with long-term sleep when booting with OpenCore instead of Clover.
Click to expand...

Sorry about my punctuation. At times I just type a mile a minute and do not stop to think. That being said, prior to going in and making these adjustments to my config file. When I read the post, it seems this is to address a long period of sleep. Would it matter at all if I have display and computer sleep set to "Never" in Energy Saver section of system preferences? I also have "wake for network access- disabled"

If not, I assume then this ACPI fix is meant to address a reboot after extended period of inactivity on the computer.
This is a item I want to try to get fixed. The computer will be doubling as a media server. So there will be times I want it to be on for extended periods even if I am not using it so the drives can be accessed remotely.
 
iMac Pro 1,1
Z390 DESIGNARE |  i7 9700K |  Radeon Nitro+ RX 5700 XT 8GB
Ploddles said:
Instead of powering the machine off and on again, have you tried just unplugging the video cable and replugging it back in again?
I had a similar issue with a Windoze machine a few years back and that was a quick fix at the time.
Click to expand...
Just tried, nope, it does not work, still no signal :(
 
CaseySJ said:
*** OpenCore 0.5.4 (pre-release) Experimental Setup for Designare Z390 ***​
Click to expand...
Thanks for the great Guide(s).

After Resetting the Memory Map to pass the memory allocating errors at boot, it worked great. So, as a beta tester, I want to give you some feedback on what also worked for me:

It worked on BIOS version F8 & F9b. It also works on SSD EFI and a 64GB USB 3 flash disk.

With unlocked MSR (native NVRAM) it was possible to uncheck:
DevirtualiseMmio & DisableVariableWrite in the Booter section and
also uncheck AppleCpuPMCfgLock & AppleXcpmCfgLock in the Kernel section.

Disable Watchdog & LegacyEnable also unchecked.
Regarding the boot-args only slide=0 & agdpmod=pikera were used.

BTW, when using Clover with unlocked MSR, it was also possible to use AptioMemoryFix.efi alone and remove FwRuntimeServices, OcQuirks and EmuVariableUefi.

Of course, I don't know if this can work for everyone. But I just registered to say thank you, and share what I have found with everyone.
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top