<< Solved >> How to make a perfect clone of my boot disk?

Hi everyone. I'd like to clone my Hackintosh boot disk for a simple reason: I want to install the Apple system updates in the clone disk, in my second Hackintosh, before doing it on the fully functional HD of my first hackintosh.
Put simply, I would like to have two identical disks that can boot the same way, so that I can test the compatibility of updates first on one disk, the "second Hackintosh", and then on the other. I cloned the system disk with Carbon Copy Cloner and then the UEFI partition, sector by sector, using a windows software: the cloned disk, however, does not start...
I definitely have to do something else, but I don't know what. I attach a screenshot of OpenCore Configurator where you can see all the UEFI partitions of the computer: it is evident that in the description of the working disk partition, BigSur, there are some features that are missing in the cloned disk, CarbonCopy. Let's say I don't know what I have to do for the same characteristics to be present there too.

I don't want to diagnose your setup, but I can explain an approach that works:

0. Get latest version of CCC
1. You must be booted from the system you want to clone.
2. CCC needs to be able to see a mounted target drive, so if you were starting from scratch you would erase the target and format as APFS, but in your case the target is prolly already visible
3. Set up a CCC task with your current boot drive as the source, then when choosing the target drive as the destination, right click to choose Legacy Bootable Backup Assistant. CCC will reformat the target and copy the entire source. Wiping the target is mandatory. There's no incremental option. I believe the target EFI will not be touched. If the copy fails there were hard errors on either the source or the target and the clone will be useless. Hopefully the copy completes without error.
4. Mount the EFI partition on the target and copy your working EFI to it.
5. It should boot.
6. From there, as long as you don't run SW update on either, you can use CCC in normal incremental mode to update the target and keep a live backup.
7. To update, sync with an incremental, boot the clone and run SW Update. If this works out. Boot back into main and run SW again.

Under Big Sur There's a bug where the clone's volume label which is seen the bootpicker doesn't get changed if you rename it after cloning. The clone will keep the volume boot label of the of the source even after you rename the volume, which doesn't hurt anything but can be very confusing. There's a hidden file that can be edited to correct this but it's in the Preboot volume.

If you can go to Monterey, do so as this bug is fixed and this clone approach still works fine.
UPDATE I've since seen this bug this under Monterey too, so nvm. Not sure why it happens. Maybe need to rename while booted from it? Idk.

The pathname for the volume label file on a running system is:

/System/Volumes/Preboot/<UUID>/System/Library/CoreServices/.disk_label.contentDetails

Where:
• /System/Volumes/Preboot is the preboot partition mountpoint for the running system. If you are changing a target but not booted from it, you will need to mount the target's preboot partition to some other folder, just as you would any other foreign volume.
• <UUID> is a long dash-separated number (UUID), which may be installation dependent.
• .disk_label.contentDetails is the text file containing the volume label for boot picker. Note the leading "." on the file which hides it in Finder. It's a ordinary text file
• This label file does not affect the way the volume appears when mounted, it's just for Mac firmware (or OpenCore).
• As part of Mac history, there was a time when the Mac's firmware couldn't render text at boot and the volume name was stored as a pure bitmap (no standard image file format) which was bit-blatted onto the screen under the drive icon. These backwards compatible image files can also be found in the same folder. Idk why these still exist.

Lastly—

Don't run incrementals between diff macOS revs as this may break operation of the target.

Consider using 3 drives for max safety:
1 Known working backup
2 Current sys
3 Clone to update

Rotate them to always have a previously working backup.

In worst case, you can still use Migration Assistant to recover your personal data from a clone to a fresh install of same or later OS, so you're solid for recovery even if the source and backup are out of sync and something goes really wrong like drives dying.

HTH

P.S., More than once, I have seen a weirdness where a clone made to an internal NVMe drive that is removed and placed in a type-C USB enclosure causes macOS to go wonky when the clone is attached. The clone will mount but if you try to do anything with it, access will be slow, quickly hang, and it can't be ejected. Trying to work with the drive may or may not result in a corrupted volume that is useless. Putting the drive back in an M.2 slot it works fine. Connecting the drive with USB3 to an older macOS also works normally. ***If anyone sees something similar please post. It could be a serious bug in macOS... But given the ways that USB port-mapping can go wrong and the fact that's not easiy to reproduce I can only wave my hands. If others have a had s similar experience, this explains why cloning under Big Sur and Monterey has a bad reputation for some users.

Perfect! Always the best in this forum! Thanks

Hi all

I on't have the Legacy Bootable Backup Assistant option in my CCC, it's a 6.1.4 CCC. Is it gone now ? CCC forces me to format the destination in APFS, does this mess up with the whole hackintosh cloning system ?

I don't think you can create bootable clones in CCC anymore. If you have Windows, you can use this to make a bootable clone. It is free for personal use. I even cloned to a larger SSD and then expanded the partition using Disk Utility.

You can still create bootable copies of system, including Ventura.

The Legacy Bootable Backup Assistand (Apple APFS System Replicator) is still present in CCC 6.x.

The option will not appear unless the destination is APFS and the source is an macOS Big Sur or later system drive.

There was an edge case a year ago where it was learned you must be booted from the drive you want to copy or the destination may end up not working.

c-o-pr said:

You can still create bootable copies of system, including Ventura.

The Legacy Bootable Backup Assistand (Apple APFS System Replicator) is still present in CCC 6.x.

The option will not appear unless the destination is APFS and the source is an macOS Big Sur or later system drive.

There was an edge case a year ago where it was learned you must be booted from the drive you want to copy or the destination may end up not working.

Click to expand...

Hi,

I have followed your advice in this thread for creating a bootable CCC clone but without success. I don't seem to have any system files in the clone as if that has not worked even though I selected the erase destination disk option in CCC.

Any ideas where I might be going wrong?

Can you say a bit more about what you think has gone wrong?

BTW—Don't forget to copy your EFI over to the clone, or boot one on another connected drive.

c-o-pr said:

Can you say a bit more about what you think has gone wrong?

BTW—Don't forget to copy your EFI over to the clone, or boot one on another connected drive.

Click to expand...

Thanks,

I will get some more specific information.

The missing Apple files are in the System partition which gets firmlinked with the Data partition to create a mix which you see as one folder on the running system.

Boot it and it will all come together.

When you access an macOS APFS container, you may see the one or the other of the System or Data partitions depending on how you come at it. Typically through Finder you see Data which is user accessible but missing the system files including standard apps.

The System partition is in a form called a Signed System Volume which has integrity maintained by an elaborate hash tree that gets wrecked if anything changes in it. So it's read only except at installation when Apple applies a chain-of-trust from its security corporate resources to build that tree, which is the meaning of "signed". It's mgmt of this chain-of-trust that leads to multiple reboots during install. The system becomes un-runable if anything in SSV changes after the fact of installation, and only Apple has the private secrets to sign it into a runable state.

There's practical discussion of what this means to Mac admin on web, including places like Bombich.com and Eclectic Light Co.