Today, I updated my sister's MacBook with an SSD, something I've done many times with many different Macs in the past. I used the same procedure I always used, which is first replacing the HD by the SSD, then installing a fresh copy of the latest OS X on the new SSD, then connecting the old HD via an external USB housing and using Migration Assistant to copy the applications and user accounts.
Only, this time, the migration assistant only found 157k of data (on the 120G disk!) to migrate!
Apparently this is a known issue - there are many reports of Migrations Assistant not seeing the connected external source disks properly.
However, I did not find a convincing recipe for how to work around this problem.
What I found was the explanation what is different in Mavericks' migration assistant: It logs out of the user account it was started from before actually starting its task. Only, this causes all mounted disks (and disk images) to be unmounted. For some reason, it fails to remount them properly, so even if you can choose the name of an external disk as a source for migration, the disk is not really online and the assistant only sees those ominous 157k of data.
So the problem was to find a way to remount the disk, while migration assistant was already running. As it takes over the machine full screen, you can't start any tools or change users at this point.
But you can login from another machine via ssh, and you can mount disks from the commandline easily, thanks to the powers of diskutil.
So the solution was as follows:
- Enable ssh login for the target machine: Set the checkbox in "System preferences"->"Sharing"->"Remote login. To the right, there will be a green dot and a text saying "Remote login: On - to login to this computer remotely, type "ssh user@192.168.1.11".
- This is exactly what you need to type on another computer in the same network to log in via ssh (preferably a Mac, BSD or Linux box, but anything capable of ssh, even a WinXP with putty will do, if you know how to use that). You need to enter your target computer's admin account password to get access.
- Now, back on the target machine, start the Migration Assistant, enter the password when asked and confirm terminating all other apps. The welcome screen of Migration Assistant appears. This is the point where Migration Assistant has unmounted all volumes.
- Go back to the ssh session on the other computer. Here you can enter the commands to mount a disk. In my case (original HD, connected via external USB housing) it was simply:
- sudo diskutil list # showing the available disks. Usually /dev/disk0 is the internal disk, /dev/disk1 the first external one.
- sudo diskutil mountDisk /dev/disk1
- Now, on the target computer, click through the Migration Assistant dialogs step by step as usual, and everything works as expected :-)
Instead of using diskutil to mount real disks, you might want to use hdiutil to mount images (.dmg, sparse bundles etc.) with a command line like "sudo hdiutil mount /path/to/some/diskimage.dmg". Or maybe both combined, first diskutil to mount an external HD containing disk images, and then hdiutil to mount one of those.
There's plenty of examples and howtos about how to work with mount, diskutil and hdiutil on the net. But I did not find a single hint using these tools to mount volumes and images for Mavericks' buggy Migration Assistant - so I wrote this. Hope it will save others a bit of time...
Hallo luz!
Vielen Dank für den Tipp – ich habe mich schon gefragt, was den MA in Mavericks von den früheren unterscheidet. Das Problem hatte ich schon bei x Kunden – v.a. mit 10.6-Backups oder auch Maschinen… Die Idee ist gut und funktioniert :-)
Herzliche Grüße,
Christian
What apparently works as well, is only plugging in the external disk (or Mac in target disk mode in my case) after you entered the password. No need to ssh.
Thanks! That indeed is a much simpler solution!
I would think I did try all sorts of connecting variants before resorting to desperate measures like ssh, but maybe I did not and missed that simple solution.
Still, for using source volumes that need some preparation steps (like a .dmg on a external disk etc.) the ssh workaround is still useful.
Thanks for the workaround. I was trying to restore data from a cloned (external) drive to a recently imaged mac. Migration Assistant didn’t see the data, it would only display applications and settings, but no users. I ssh’d into my new mac, ran the commands, and Migration Assistant worked fine. I tried the method of disconnecting and reconnecting the drive and it didn’t work for me. In any case, thanks for the tip.
Thank you! This worked perfectly.
When trying to mount the partition from ssh the mount operation timed out, so that Migration Assistant wasn’t able to access the external usb drive.
In order to lock and avoid unmounting of the usb drive I logged into ssh from another pc before opening Migration Assistant, then changed the working dir to the usb drive.
Upon the logout triggered by MA the usb drive kept mounted, and then was accessible in MA.
I have tried the way as described by Luz. Everything worked fine including the mounting the USB-Disk. When I started the migration process all folders were visible and calculation of transfer volume started. But after about 10secs the app crashed. I’ve tried this several times with success. (On the USB-Disk is a bootable clone of an other MacBook with OS x 10.9)
MANY thanks for this pointer. This saved me hours of messing around trying to figure out how to get my CCC backup image migrated to Mavericks. The software is not the same without Steve Jobs
Thanks the Target mode did not work for me but the SSH sure did. Thanks for the help.
Is there any reason this wouldn’t work with an Ethernet cable? When I SSH in and enter “diskutil list”, only the internal volume of the target (an iMac) is reported, not the external volume of the source (a Mac Mini). There’s only /dev/disk0. When I run Migration Assistance after mounting the internal volume, I still get “157 KB selected, about 963.4 GB available” reported.
Tomorrow I’ll pick up a FireWire and try setting the source Mac to Target Disk Mode.
just start the migration assistant on new computer and get to screen where it is scanning for disk BEFORE you plug in firewire/thunderbolt cable.
Apparently (see other comments above), this seems to work in some cases, but not always. For the cases it *does* work, it’s clearly the much simpler solution :-)
If, like me, the disk will not mount because it’s badly screwed up. You can use the following command sudo /System/Library/Filesystems/hfs.fs/hfs.util -MU diskXsX /Volumes/MyVolume fixed readonly nosuid nodev
Where diskXsX is the partition containing your user data and /Volumes/MyVolume is your mount point.
Thanks for the article!
SSH worked perfect! Beautiful!
Habe vorgestern von Air auf Pro migriert ueber ein Time Machine backup. Ging perfekt
Apple saved my day:
http://apple-critic.com/?p=53
This works perfectly – and is a mandatory way of doing it I think if you have your TM Backup as a sparsebundle on the USB drive. Thank you, thank you!
Wish there was a way to push this article up in google searches – it took me a while. Not sure if it will help but I searched the phrase:
migration assistant cannot find sparsebundle
Thank you! Very helpful.
This doesn’t work with a target machine running El Capitan.
Once you run MA on the target machine it freezes the SSH session on the other other computer. However….
By accident I found that this sequence works.
Establish the SSH session between the to machines, CD to the folder with the disk or sparse image on the remote computer. On the target machine mount the disk image and than run MA. For some reason this prevents the disk image from unmounting once MA is launched. Odd, but it worked for me.