It is the year 2020 and replicating APFS containers still sucks. One would expect it would be a simple copy and paste in the Disk Utility app but this is still far from reality.
Last year I wrote how I managed to clone my macOS system under Catalina.
The main trick was to create a DMG file with multiple volumes, mount it on target machine and drop to command-line to do asr restore
from synthetised disk while avoiding possible pitfalls.
The good news is that Apple devs definitely worked on improving this under Big Sur and added some documentation (see man asr).
But I didn't understand it fully on first read. Maybe someone could explain how is this supposed to work?
Unfortunately they broke the workflow I described in the previous article.
The problem is that asr newly tests source of restore operation and if it contains multiple system/data volumes then it simply gives up.
For example:
> diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 499.4 GB disk0s2
3: Windows Recovery 552.6 MB disk0s3
4: Apple_Boot 134.2 MB disk0s4
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +499.4 GB disk1
Physical Store disk0s2
1: APFS Volume BismarckOS - Data 439.6 GB disk1s1
2: APFS Volume Preboot 82.1 MB disk1s2
3: APFS Volume Recovery 529.0 MB disk1s3
4: APFS Volume VM 2.1 GB disk1s4
5: APFS Volume BismarckOS 11.5 GB disk1s5
6: APFS Volume Nix Store 616.0 MB disk1s6
...
/dev/disk6 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 1.0 TB disk6
1: EFI EFI 209.7 MB disk6s1
2: Apple_APFS Container disk7 500.8 GB disk6s2
3: Apple_APFS Container disk8 499.5 GB disk6s3
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +500.8 GB disk7
Physical Store disk6s2
...
> asr restore --source /dev/disk1 --target /dev/disk7 --erase
Validating target...done
Validating source...
Source "/dev/disk1" contains multiple system/data volumes.
You must pass --sourcevolumename or --sourcevolumeUUID to specify which volume to restore.
Could not validate source - Invalid argument
Not sure if non-standard Nix Store volume has anything to with it. Feel free to comment with your experiences.
And if you try to pass in --sourcevolumename, it answers in gibberish:
> asr restore --source /dev/disk1 --target /dev/disk7 --erase --sourcevolumename BismarckOS
Validating target...done
Validating source...done
Erase contents of /dev/disk7 ()? [ny]: y
Couldn't set up partitions on target device - operation AddAPFSVolumeToContainer, line #5334 - error 49165
Well, we could try to specify container partition as the source of restore operation. I'm 99% sure this didn't work last year...
> sudo asr restore --source /dev/disk0s2 --target /dev/disk7 --erase
Password:
Validating target...done
Validating source...
Source "/dev/disk1" contains multiple system/data volumes.
You must pass --sourcevolumename or --sourcevolumeUUID to specify which volume to restore.
Could not validate source - Invalid argument
Hmm... what about this?
> sudo asr restore --source /dev/disk0s2 --target /dev/disk7 --erase --sourcevolumename BismarckOS
Validating target...done
Validating source...done
Erase contents of /dev/disk7 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk7s2.
Restore completed successfully.
Wut?
> diskutil list
...
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +500.8 GB disk7
Physical Store disk6s2
1: APFS Volume BismarckOS - Data 439.5 GB disk7s1
2: APFS Volume BismarckOS 11.5 GB disk7s2
3: APFS Volume Preboot 82.1 MB disk7s3
4: APFS Volume Recovery 533.8 MB disk7s4
...
This /dev/disk7 system turned out to be bootable and was a good copy of the previous system (as expected).
- It is possible to clone/copy APFS-resident bootable macOS system from command-line.
- I don't know how to do it with DMGs anymore. Instead, by accident, I found a way how to do it directly with
asr restoredisk-to-disk (I used target disk mode to connect old machine to new machine). asr restorehas a custom logic how to copy system/data volumes, it does not do what would be normally expected, I mean: "to copy all volumes one-by-one". See thatNix StoreandVMvolumes were not copied/restored.
Please note that all this info is relevant to public release of macOS 11.0.1 (Big Sur). I expect this behaviour to be subject of future changes.
Pro tip: If you need to boot into some other macOS system to do some asr work please make sure you are
using latest versions of these tools because they differ between OS releases.
> sw_vers
ProductName: macOS
ProductVersion: 11.0.1
BuildVersion: 20B29
THANK YOU! I’ve been looking for a solution for weeks! I can tell this works in 11.2.3 at a Mac with T2 chip.