1

I've received a new Mac that has come preconfigured with lots of junk.

Naturally, my first order of business is to wipe the disk and clean install macOS. But first, I want to create a bit-perfect, bootable clone of the disk (which is formatted APFS Encrypted) and keep it on a flash drive, in the unlikely event that I ever need to boot into the original environment.

I tried to create this clone by booting the machine into Recovery mode, attaching a flash drive of the exact same capacity as the disk and running dd if=/dev/rdisk0 of=/dev/rdiskX bs=64k. I expected this to create an exact clone, especially reading at a raw level via /dev/rdisk. However, the resulting drive is not only unbootable, but none of the APFS structure is preserved - I'm left with an FDisk_partition_scheme partition type and a 0xEE volume.

Nothing in this answer proved useful in making this bootable.

More than "how can I do this," I'm wondering "why can't I do this."

Why doesn't dd perform the low-level, bit-by-bit replication that I'm looking for? Or, is it doing what I'm telling it to, but there's another factor at play that I'm not aware of?

1
  • There should be nothing on a new Mac. Is the junk things a third party loaded or the system apps Apple delivers?
    – bmike
    Sep 22 '20 at 0:50
2

I am going to go out on a limb and assume the OP's new Mac has a boot drive with a 4096 byte sector size and the flash drive has a 512 byte sector size. Using the dd command (as the OP has described) would result in a flash drive, where the Master Boot Record (MBR) partition table could be read, because this occurs in the same place regardless of sector size. This would be the first sector (also known as sector 0). However, the GUID Partition Table (GPT) starts at the beginning of the second sector (also known as sector 1). The second sector on the Mac boot drive has a byte offset of 4096. When you used the dd command, the GPT would be placed starting at byte offset 4096, but the actual location should have been at byte offset 512. The result is documented in the OP's question.

BTW, the same type of problem would occur with the backup (also known as the secondary) of the GPT stored at the end of the flash drive. Although, it would seem unlikely that Mac boot drive and the flash drive have exactly the same total size in bytes. I assume this is what the OP meant by the use of the phrase "a flash drive of the exact same capacity as the disk".

2
  • This is definitely the right answer!
    – jksoegaard
    Sep 22 '20 at 13:07
  • @David Anderson: you are absolutely right. BTW I meant obs=512 and not what I typed thinking of bytes. I'll remove my stupid comment.
    – dan
    Sep 23 '20 at 14:01
1

There are unique identifiers embedded in APFS volumes, so if you copy the entire disk, it breaks the unique information that each disk needs by design.

My guess is that DD does the deed, but the results aren’t what you expect.

There is excellent software that make bootable clones and respect the design of APFS.

  1. Disk Utility - you can restore the boot drive to an external drive and that will be bootable on Catalina and lower. Big Sur is still pre-release so this may or may not hold at launch for the new OS.
  2. Carbon Copy Cloner - superlative, excellent software and service - https://bombich.com/
  3. SuperDuper! - excellent software and service, superlative - https://shirt-pocket.com/SuperDuper/SuperDuperDescription.html

The why is the design of the filesystem. Some care has to be added to make a clone bootable as opposed to making a forensic copy for analysis or needing that care added afterwards.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .