Cloning an image using Thunderbolt and Disk Utility (post–El Capitan)

I have a longer post on this, including why you would want to clone using Thunderbolt and Disk Utility, but Apple decided to switch up Disk Utility's interface completely in El Capitan (10.11). Even though the process is similar, the exact steps are different.

One procedural difference worth noting: In Yosemite (10.10), Mavericks (10.9), etc., you would select the source, and then select what you wanted to restore the source to. In El Capitan (10.11) and supposedly beyond, you start by selecting the destination, and then select what source you want to restore from.

diskutilityrestoreelcapitan01 Open up Disk Utility (from /Applications/Utilities). Select the disk you want to restore to. And then select Edit > Restore.

diskutilityrestoreelcapitan02 You have the option to restore from another disk (if you have a computer connected via Thunderbolt, it should show up in the drop-down list) or to restore from a disk image (click Image... to find the image you want to restore from), and then click Restore.

diskutilityrestoreelcapitan03 Wait for it to restore.

diskutilityrestoreelcapitan04 Click Done when it's done restoring.


hdiutil: create failed – error -5341

Usually if I have an .app I want to import into Munki, I just use munkiimport, and Munki automatically creates a read-only disk image (.dmg) with the .app inside. For some reason, with the, I kept getting a 5341 error. I tried this workaround, but I still got the same error.

What worked for me (your mileage may vary, of course) was just using Disk Utility to create a read-write disk image (of about 500 MB, becuase the mBlock program is a little less than that), and then converting it to a read-only disk image.

I don't believe it has to do strictly with the large size of the app, because I've used Munki to import Xcode, which is typically 5-6 GB, much larger than a roughly 490-MB app.


Restoring a Mac partition to its full size

Usually, when you add a new partition to a Mac using Disk Utility, you can then just (minus sign) delete the new partition and Disk Utility will automatically expand your first partition to take up the free space.

Occasionally, Macs will act weird and not fill up the free space and, more importantly, not let you manually drag the old partition to fill up the free space. You're just stuck with unusable free space.

There is a relatively simple solution that involves only a couple of terminal commands. (Thanks to the Restore Macintosh HD to its original partition configuration thread on Stack Exchange for the tip.)

Boot up into recovery mode (Cmd-R at startup). If you want to be extra safe, use Disk Utility to back up your first partition in case something goes wrong.

Go to Utilities > Terminal.

Enter in this command:

diskutil cs list
and get the Logical Volume UUID of your partition-to-expand.

Then run


You should see the progress of your partition expanding.

Then you'll see it verifying the volume.

That's it. Your partition should now be fully expanded.


Still waiting for root device on an iMac

I've had fairly good luck cloning Macs using Disk Utility and a Thunderbolt cable. Recently I ran into one stubborn one that wouldn't boot up properly after the re-image.

It went straight to a flashing Do Not Enter symbol. That was a bit confusing. Was there a physical connection problem with the drive? I could boot into recovery mode (Cmd-R), and that was fine—and in recovery mode I could see the newly-imaged partition. Rebooted again. Same deal with the Do Not Enter symbol. Maybe it was just a bad image.

Imaged from another machine. Same deal. Let me boot into verbose mode (Cmd-V) to see what's going on.
I got Still waiting for root device repeated. Same deal if I tried to boot into single-user mode (Cmd-S).

When I Googled "still waiting for root device," all the top results had to do with Hackintoshes and not native iMacs. even if I Googled "still waiting for root device imac," all the top results have to do with Hackintoshes. Not very helpful, since this is a genuine Apple computer I'm working with.

Just on a lark. I held down the Option key at boot-up to see what drives were available. This actually got me somewhere, because I saw two options—Macintosh HD and the name of the partition I had just imaged. Now usually (and this is how it appears in Disk Utility in recovery mode) there is a larger disk called Macintosh HD with a partition underneath it. When that's the case, holding down the Option key at boot-up will show you only the bootable partition underneath.

When I tried to boot to Macintosh HD, I got the Do Not Enter sign again.

When I booted to the newly created partition, it booted just fine, though.

I had to explicitly select it at boot, though, every time. So I knew something was funky with the filesystem.

So I thought maybe I could just change the Startup Disk to use the working partition. When I tried to do that I got an error message that said you can't change the startup disk to the selected disk building boot caches on boot helper partition failed. None of the Google searching on that phrase helped me fix the issue.

I tried a fresh reinstall of OS X through recovery mode, but that failed:

Then I tried to see if I could verify and repair the disk using Disk Utility: mp_boot_os_x_could_not_be_repaired
It said, after I tried to repair it that I had to repair it. Thanks.

So I tried repairing it using recovery mode. mp_disk_needs_repair
Same deal. And same deal using the iMac in target disk mode (T) and then running Disk Utility repair on it from another Mac.

No matter what I did—trying to repair the drive, or to delete and re-create partitions; the partition table was super messed up, for whatever reason.

Now, I don't know if this is the solution, but it ended up being a working solution, even though it took a really long time! What I ended up doing was—instead of using Disk Utility—straight up copying entire partitions off another iMac to get the partition table corrected.

So I put the troublesome iMac in target disk mode. Same deal for a working iMac. And then I had a third iMac I hooked each of those into using Thunderbolt cables.

In the terminal, I used

diskutil list
to get all of the actual disks/partitions in question. There were three listed for each. I started with the top and just went down—copying disk8 to disk5 and then disk7 to disk4. Here's an example:
sudo dd if=/dev/disk7 of=/dev/disk4 bs=128m conv=noerror,sync
Be very careful using the dd command. It can be very destructive if you don't know what you're doing. if is the input filesystem and of is the output filesystem. You won't see any visual feedback on the progress, but you can press Control-T (not Cmd-T) to see it from time to time.

Overall, across a Thunderbolt connection, it took about two full days (48 hours) to complete a 1 TB drive transfer... but it worked! (Your mileage may vary.)

P.S. Once it was done, I was able to boot into single-user mode, run an fsck to clean the filesystem, and then reboot into normal mode and verify the disk from Disk Utility with no errors.


Restore Failure: An error (32) occurred while copying. (Broken pipe)

The problem

If you are Cloning an image using Thunderbolt and Disk Utility (or even using Firewire instead of Thunderbolt), you may come across this error message:

I've actually never experienced that with Thunderbolt (not saying it can't happen), but I've had it happen twice using Firewire. At first I thought it was the cable ("broken pipe" would indicate to me a patchy physical connection of some kind), so I switched out the cable, and that didn't help. In another situation, I knew the cable was good, because I'd used it several times.

A possible solution

Try switching the direction. So if Mac A is in target disk mode and Mac B is in recovery mode, make it so Mac A is in recovery mode and Mac B is in target disk mode.


I don't know that this is the official workaround/fix or that this will always work, but I've gotten this error twice, and this workaround/fix worked in both cases.


How many times do you have to write zeros or random data to a drive to securely delete data?

Conventional wisdom says that you need to do many passes of zeros, ones, combination of zeros/ones, and then random numbers in order to securely erase a drive so that its data cannot be recovered. But is this true?

The folks at HowToGeek make a good case for one pass of zeros being enough:
HTG Explains: Why You Only Have to Wipe a Disk Once to Erase It

From StackExchange, here is a shorter sum-up of the situation, though:
StackExchange answer to "Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?"

And an even shorter tl;dr version:
Summary: it was marginally better on older drives, but doesn't matter now. Multiple passes erase a tree with overkill but miss the rest of the forest. Use encryption.

The bottom line seems to be that there are some misinterpretations or misapplications of the Gutmann method, but more importantly that it's all about what can be done in theory. When it comes to practice, a single wipe of zeros is pretty much enough to take care of any basic data recovery methods.

If you're dealing with highly sensitive data, it probably still won't be recovered in any meaningful way after a single wipe of zeros, but you may not want to chance it, and end up doing several passes of zeros, ones, and then randoms, in addition to physically incinerating the drive.

DBAN's "autonuke" setting does three passes, and the nice thing about DBAN is that you can use it on pretty much any computer (it's a live CD or USB—so good for Windows, Mac, or Linux).

Mac OS X's Disk Utility has several built-in options.

If you launch up Disk Utility, select the drive you want to delete, and then click Erase, and then Security Options..., you'll see a pop-up window with a slider.

The first option doesn't do a secure wipe at all. It just "deletes" the data by marking it available for use.

The next option will be secure enough in 99% of use cases (e.g., you have a personal computer with family photos and other personal documents that will not financially benefit any criminals or politically benefit any governments).

This third option is about the same as the "autonuke" setting for DBAN.

And this last option—according to Gutmann himself, to HowToGeek, and to a bunch of other folks who've examined the issue closely lately—is just overkill.

A lot of the discussion you'll read in the links I posted above have to do with theory (could someone with limitless time and really expensive equipment possibly recover some tiny scrap of data from your hard drive) and a lot less to do with practicality. More importantly, it's difficult to track down actually successful (and verifiable) experiments of the theory [that traces of previous data exist even when you zero out everything or write random data over the previously existing data].

Practical security focuses a lot more on how badly criminal elements want your data and how difficult you make it for them to get to the data. If all a criminal gets is unusable scraps of what might have been a text file, and all that's really on the drive to begin with is some music, family photos, and Word documents, who is really going to spend hours trying to get that stuff back?

If, however, I have a computer with millions of people's financial data or with highly classified military documents... I'm probably going to do at least three passes before totally incinerating (Terminator 2–style) the drive. And that drive would have been fully encrypted to begin with.

As a simple, practical test, though, I did the second Disk Utility setting (one pass of zeros over the entire disk) on a 500 GB drive. Then I did data recovery on it using both Photorec and Recuva.

Here are the results...

Photorec took about 10 hours to scan the 500 GB drive, and it came up with 3 files—three .plist files and one .xml. I'm not 100% certain, but I believe those might be created by OS X itself when formatting the drive to HFS+

Recuva took a little over 2 hours to scan the 500 GB drive, and it came up with 3 files. Again, not 100% certain on this, but I believe those may be hidden files created by Windows when formatting the drive to NTFS (Recuva wouldn't recognize an HFS+ drive, so I had to use Windows' disk management to reformat the drive as NTFS before scanning).

If you're inclined to say 3 passes isn't enough...

  1. Make sure you know what you're disagreeing with. I am not (nor is the StackExchange response or the HowToGeek post) saying that a drive with highly sensitive documents should be disposed of after a single pass of zeros. Those should have been encrypted to begin with, have three passes, and then be incinerated. But doing the full 35 is overkill and, worse yet, doesn't offer any additional security over the three passes. So if you're going to disagree, disagree with the correct assertion. Don't engage in any of this business.
  2. I am, however, saying that for a basic home user with no extremely sensitive information (maybe some family photos and a handful of documents with no financial information), you can safely dispose of a drive after doing a three-pass on it (and, most likely, even a one-pass).
  3. Don't say "I have software that can easily recover one-pass deletions" without saying what software you use. I used Photorec and Recuva. If you believe another piece of software can actually recover data that's been wiped, say what software it is, and then prove that using it you were able to recover usable data after a one-pass or a three-pass.
  4. If you can recover fragments of data that are totally useless, who cares? If it's a text file, it has to have readable text. If it's an image file, it has to be a viewable image. You can't just prove that there used to be "in theory" data there previously, but it's data you can't recover.

I'd love to hear that I (and the wise StackExchange user, and Gutmann, and HowToGeek) are all wrong, but if that's the case... prove it.

Further reading:
Securely disposing data on hard drives and other storage media
The urban legend of multipass hard disk overwrite and DoD 5220-22-M
Overwriting Hard Drive Data: The Great Wiping Controversy


Fix for disk erase failed couldn’t unmount disk

If you're trying on a Mac using Disk Utility to erase a hard drive and it won't unmount, giving you an error similar to Disk erase failed. Couldn't unmount disk, then you may have to force an unmount through the terminal.

Launch up (through /Applications/Utilities or through a Spotlight search).

Then paste in the command:

diskutil list
to list out the different disks. You should see some disks appear like /dev/disk0, /dev/disk1, /dev/disk2.

Find the one you want to force unmount. For this example, let's say it's /dev/disk2.

Run a command similar to this one

sudo diskutil unmountDisk force /dev/disk2
If you're prompted for a password, enter it (yes, your account does need to have administrative privileges). You should not physically unplug the drive.

You should now be able to erase the drive.


Cloning an image using Thunderbolt and Disk Utility

Why would you do this?

  • It's fast. Over Thunderbolt, cloning a roughly 30 GB (of used space) image takes only a few minutes.
  • Minimal additional cost. Sure, you probably paid money for your Macs, but this method uses only included software... and one US$40 cable.
  • No external media or extra setup. You don't have to network your computer, install additional software, or have an external hard drive. You can go straight from computer to computer with just a Thunderbolt cable.


  • Two Macs—one source, one target.
  • Rename the hard drive on the source Mac to something unique (don't call it Macintosh HD, which is the default). Easiest way to do this is to go to Finder > Preferences and then check or tick Hard Disks under Show these items on the desktop. Then, when you see the hard drive icon appear on your desktop, you can rename it.
  • A Thunderbolt cable.
  • The main hard drive partition of the source Mac must be equal to or lesser in size than the target Mac hard drive. For example, if you are imaging from 250 GB to 250 GB, that's okay; if you're imaging from 250 GB to 500 GB, that's also okay; but if you're imaging from 1 TB to 500 GB, that won't work.


Note: If you're using El Capitan (10.11) or later, the procedure has changed. More details at Cloning an image using Thunderbolt and Disk Utility (post–El Capitan)

The procedure below is for Yosemite (10.10) and earlier.

  1. lightningboltOn the target Mac, reboot the computer while holding down the T key on the keyboard to boot it into Target Disk mode. If you have done so successfully, you will see what appears to be a white lightning bolt on the screen.
  2. On the source Mac, reboot the computer while holding down the Cmd and R keys on the keyboard to boot into Recovery Mode.
  3. Then, connect the Thunderbolt cable to both Macs.
  4. On the source Mac, select Disk Utility from the available options.
  5. diskutility
    Once Disk Utility launches up, click on the main partition (the one you renamed earlier) of the source Mac. Since Disk Utility can sometimes load up the target Mac visibly higher or lower than the source Mac, it's critical that you have them uniquely named (that's why we renamed the drive earlier). So click on that unique name.
  6. Click Restore. You should see the source as the uniquely-named drive.
  7. Then drag the main partition of the target Mac over to the Destination area.
  8. Click Restore.
  9. That's it! Once it's done, you can boot your target Mac into regular mode, and it should be a clone of your source Mac.