Contribute
Register

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

Thanks @CaseySJ! I'm interested in this as well. What are your restore steps if the user folder is on a separate drive?
The restore process can be as follows:
  • If we backed up the Home folder with Carbon Copy Cloner, we can restore it very easily by switching the Source and Destination disks.
  • If we backed up using Acronis True Image, we can restore selected disks from the Acronis backup. When Acronis backs up the entire computer, it keeps the identify of each drive in the system. Recovery, therefore, consists of choosing which drive(s) to restore.
 
The restore process can be as follows:
  • If we backed up the Home folder with Carbon Copy Cloner, we can restore it very easily by switching the Source and Destination disks.
  • If we backed up using Acronis True Image, we can restore selected disks from the Acronis backup. When Acronis backs up the entire computer, it keeps the identify of each drive in the system. Recovery, therefore, consists of choosing which drive(s) to restore.
That's great, super easy! What about when you have to do a fresh install of Mac OS but want to use your existing user folder that is on a separate drive?
 
As far as the path to the clone volume goes, your assumption is correct, though you could also just point it straight at "/Volumes/Catalina Clone" instead, the script can figure out the actual data location on its own (when it works). I specifically instructed you to do it this way because I want to emulate the exact arguments that CCC hands to the script, to replicate the actual situation as faithfully as possible. Hence we do it with the "- Data" suffix for now.

The output of the script looks better now, it correctly identifies the two EFI partitions without doubling up on anything, we can see that the entire process ran through without failure, which is good.
I would thus now suggest we try the original script with this slight modification (and the test switch still turned on!) and closely examine its output to determine whether everything is now fixed or whether there's still something off.

To this end I would suggest you try and run the attached modified version of the full EFIClone-v3 script (via Terminal, again) and upload:
- The terminal output
- The EFIClone log file
- The output of the command diskutil list

These three combined will allows us to assess whether everything is now kosher.
Yay! We're making progress! Here are the files.
 

Attachments

  • EFIClone-v3-experimental.sh terminal output.rtf.zip
    1.3 KB · Views: 79
  • EFIClone.log.zip
    3.6 KB · Views: 75
  • diskutil list output.rtf.zip
    2 KB · Views: 80
  • We can follow Step 1, Bullet #4 in the Catalina Mini-Guide to update Clover.
  • After the update, download the ZIP file from the same Catalina Mini-Guide and copy the kexts and drivers from the ZIP to the corresponding folders in CLOVER.
  • The SSDTs have not changed so no need to modify the ACPI/patched folder.
  • Note that we are now using:
    • OcQuirks.efi
    • OcQuirks.plist
    • FwRuntimeServices.efi
    • These 3 files will be copied into the new CLOVER/drivers/UEFI folder.
  • After making these changes, delete the old CLOVER/drivers64UEFI folder (or move it to someplace else such as your Documents or Downloads folder).

I'm assuming that I would in fact select "Install RC scripts on target volume" when following Step 1, Bullet #4 as I'm not installing to a USB drive but updating my actual boot drive. Correct?

Thanks Again CaseySJ.
 
Yay! We're making progress! Here are the files.

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.
 
  • When you put the system to sleep, it will "uncleanly" eject USB drives. To prevent this, we have two options:
    • Reduce memory speed to max 2933MHz or 2666MHz. See Post #1:
      View attachment 445002
    • Use a utility like Jettison to cleanly eject external drives prior to sleep.
I did it!! The problem its one of the USB dock. I tried a disk speed test, and in one of dock the speed is 80 Mb/s and in the other dock only 10Mb/s. After seconds in this dock, the HDD froze.

Well, thanks for your patience!!
 
@byteminer @EliM

The latest results look absolutely correct. Thanks to you both! A great example of collaboration.

Let's get some volunteers to test the experimental script attached below and post their EFIClone.log files from the /System/Volumes/Data/Users/Shared folder. No changes will be made by the script.

I'll do the same this evening. Subsequently, I'll update both the Mojave and Catalina Backup guides and change the version to EFIClone-v4.
 

Attachments

  • EFIClone-v3-experimental.sh.zip
    4.7 KB · Views: 86
Hi,

Can you re-test with Geekbench 5.1 ?

Also, have you done any overclocking ?

Thanks for your interest and reply. I did not overclock this machine prior to any GB test. Could I ask what would Geekbench 5.x show that is different to GB 4, just curious.
 
I'm assuming that I would in fact select "Install RC scripts on target volume" when following Step 1, Bullet #4 as I'm not installing to a USB drive but updating my actual boot drive. Correct?

Thanks Again CaseySJ.
Yes that's correct. We require RC Scripts in order to properly emulate NVRAM.
 
Thanks for your interest and reply. I did not overclock this machine prior to any GB test. Could I ask what would Geekbench 5.x show that is different to GB 4, just curious.
GeekBench 4 and GeekBench 5 compute their scores differently and therefore we cannot compare GB 4 scores against GB 5 scores. GB 5 scores are typically much smaller than GB 4 scores.
 
Back
Top