{"id":10454,"date":"2016-11-26T17:38:22","date_gmt":"2016-11-27T01:38:22","guid":{"rendered":"http:\/\/www.podfeet.com\/blog\/?p=10454"},"modified":"2016-11-26T17:38:22","modified_gmt":"2016-11-27T01:38:22","slug":"how-not-to-do-migration-assistant","status":"publish","type":"post","link":"https:\/\/www.podfeet.com\/blog\/2016\/11\/how-not-to-do-migration-assistant\/","title":{"rendered":"How Not to do Migration Assistant"},"content":{"rendered":"

\"MigrationWhen I got the 2016 Touch Bar 15″ MacBook Pro, it was only about a month after I’d done an involuntary nuke and pave on my 2013 MacBook Pro. For those unfamiliar with the term nuke and pave, that’s when you erase everything, including the operating system, and then install everything from scratch. You can drag your documents over from a backup or another Mac, but you don’t bring over network settings or license files or any customizations you’ve made.<\/p>\n

I have lauded the benefits of a nuke and pave over the years on the podcast and I’m a huge believer in doing it around once a year. It’s painful and time consuming (think days before everything is back to “just so”) but the advantages of speed and freed up disk space are enormous. Your Mac will feel like it did when it was new.<\/p>\n

Anyway, since I’d just had the joy of doing that a month ago, I was uninterested in doing that all again on the new Mac. Two weeks ago I told you the story of how I’d tried to use Migration Assistant for the first time to accomplish the task. I explained that I hooked the 2013 and 2016 Macs up to a gigabit switch hooked to my router and yet the migration was taking forever. Forever is defined as 125GB of data transferred in 4.5 hours.<\/p>\n

I want to dig a bit further into exactly what I originally did, give you a problem to be solved, and then walk you through what actually worked in the end to give me a successful migration from the 2013 to 2016 MacBook Pro. I’m hopeful this will help some of you in the future.<\/p>\n

So back to our 125GB transferred in 4.5 hours. How long it should<\/em> it have taken? We’ll have to do the math, starting with converting bytes to bits. There are 8 bits in a byte, so we have to multiply by the 125GB by 8 to get the number of gigabits that were transferred. 125GB x 8 = 1000gigabits to transfer. If I’m transferring over gigabit Ethernet, that means I’m transferring at 1 gigabit per second, so I should be able to move 1000 gigabits in 1000 seconds. Dividing by 60, we get that the 125GB should have transferred in 17 minutes, not 4.5 hours. Sure your mileage may vary on this kind of thing, but with pretty recent SSDs on both machines which I personally have measured at 850MB\/sec read\/write on the slower machine, those numbers just don’t make sense.<\/p>\n

As my data was simply crawling from one machine to the next, Steve and I studied things to make sure I wasn’t misleading myself on what I had actually set up. We looked at the Ethernet cables I’d chosen and verified that they said CAT 6 on them (Cat 5 is only 100 megabits\/sec). Steve studied the switch itself which said<\/em> it was gigabit. He looked on the back for the blinky lights. My particular switch is from Netgear, and it has a light on ether side of each port. One says 10, the other says 100. A graphic on the switch says that if both are blinking you’re getting 1000Mbits\/sec. Both were blinking on all three involved ports.<\/p>\n

So why was my transfer going at about 1\/16th the speed it should be going? The only thing I could figure was that maybe it was ignoring the cables and using WiFi. I went back to the iperf tests that Steve and I conducted on the Netgear Nighthawk X8<\/a> and the WiFi speeds were 524megabits\/sec when we tested right next to the Netgear. 524megabits\/sec \u00f7 8 = 65megabytes\/sec but I’m only getting 6.<\/p>\n

While WiFi should have been 10X as fast, I decided to try and kill it off anyway. I quit the process of Migration Assistant and on both machines, turned off WiFi and started over, but still it was transferring at 6MB\/sec. I looked at the connection window and for some unknown reason it showed that I was still using WiFi.<\/p>\n

I was baffled, but I had fooled around with this long enough. I abandoned that whole path and selected only Apps for Migration Assistant, which toodled over quite quickly. Then simply dragged my data over by hand, which only took about 20 minutes just like it should have. I have no clue why Migration Assistant failed me but I was glad to be rid of it.<\/p>\n

At this point you’re thinking, “Hey Al, this is nice to get more geeky detail but why are you repeating the substance of the story from two weeks ago?” I haven’t yet told you the problem to be solved. While my new Mac was basically working (after reauthenticating EVERY app from the Mac App Store and entering license codes for EVERY app outside of the Mac App Store), there was one big problem. I was unable to start up iCloud Photo Library.<\/p>\n

In the past I’ve complained bitterly about how iCloud Photo Library tries to reupload all of my photos every time I touch iCloud, but this problem was even worse. I would click the little check box to turn on iCloud Photo Library and after about 5-10 minutes it would turn itself off.<\/p>\n

After several days of fighting with this I called AppleCare. My little friend Mary and I worked through several ideas, none of which worked. She asked me to run a diagnostic tool that would generate some log files that I could then ship back to Apple, and she would in turn send the files to engineering. I have learned through past experience that “send to engineering” means wait several weeks or more and get back the answer, “we can’t figure it out” if you get any answer at all. Maybe my problems are just harder than other peoples’ but so far they’re batting 0 for 3.<\/p>\n

I spent some time noodling the log files myself, and discovered something very odd. System Integrity Protection, aka SIP was turned off. To quote Apple:<\/p>\n

System Integrity Protection is a security technology in OS X El Capitan and later that’s designed to help prevent potentially malicious software from modifying protected files and folders on your Mac. System Integrity protection restricts the root user account and limits the actions that the root user can perform on protected parts of the Mac operating system.<\/p><\/blockquote>\n

This is a feature you definitely want on by default. I tweeted out asking if anyone else had noticed that it was off on their new MacBook Pros, and discovered that this was a wide-spread issue.<\/p>\n

@mlaundrie, @mike_wuerthele, @donmcallister, and @dvidsouthard all pointed me to articles like this one at iMore<\/a> reporting the issue. The good news is that it’s pretty easy to turn on. The bad news is that it’s super geeky. You have to boot into Recovery Mode (using \u2318R), launch Terminal and type in csrutil enable<\/code>, then reboot. Easy enough for us since we’ve tamed the Terminal and all, but can you imagine trying to get your uncle to do that?<\/p>\n

Ok, let’s keep going with the story because that was a complete side lobe that has nothing to do with my iCloud Photo Library problem. I was proud of my little self for finding it all by myself though!<\/p>\n

I should mention that I tried Googling “turn on iCloud Photo Library” and other combinations like ” iCloud Photo Library keeps turning itself off” but every hit would be either how to turn it off (or on). I found a couple of people in the Apple discussion forums with the problem and I tried all of the solutions suggested there, including fixing permissions but nothing fixed the problem for me.<\/p>\n

While I was waiting what would surely be an interminable length of time for the engineers at Apple to get back to me, I posted my iCloud Photo Library turning itself off problem in our Google Plus group, our Facebook group, and the Mac Geek Gab Facebook group. Gary Hays and Greg InLa from the Mac Geek Gab both jumped in with ideas.<\/p>\n

They had me turn off iCloud (which Pat Dengler had suggested too) and turn it back on, we disabled Keychain (because we found some errors about Keychain in the logs I sent to Apple) and turn it back on, we dragged my Keychain files out of the Library and back, we deleted plists, but nothing fixed the problem.<\/p>\n

By then I was whining to Steve Goetz on Telegram (as I am wont to do when things go awry), and he reminded me that I had aborted Migration Assistant and maybe that’s why I was having a problem. I realized that after aborting it, I didn’t wipe the system clean in any way, I just kept going forward. We started noodling whether maybe I’ve got a completely borked system at that point. It was time for drastic measures. It was time for yet another nuke and pave.<\/p>\n

\"BlackBefore I started down the path that finally worked, I first tried to use my SuperDuper! Backup from my old Mac to the new. I verified that I could boot from it from the old Mac, and then tried to boot from it on the new Mac. Instead of booting up, I got a black screen with a white circle on it.<\/p>\n

I searched throughout the SuperDuper! Site and found not clues to how to fix this and wrote to the very responsive developer, Dave Nanian over at shirt-pocket.com<\/a>. I also tweeted out the question. Stephen Hackett of relay.fm answered, as did Dave Nanian, that new Macs come with a slightly<\/em> different build of the operating system which means that usually you can’t boot from the backup drive when you’ve got a brand new machine. Aggravating answer, but at least I understood why it was failing. Dave went on to explain that I COULD use Migration Assistant with my backup and choose “another Mac” and it would be able to see the drive, even though it couldn’t boot from it.<\/p>\n

As I thought about that, I realized that while my backup drive is a snazzy new USB 3 drive, it’s only 7200RPM and so I’d really suffer on transfer speed. I really wanted to take advantage of the SSDs in the two Macs. Here’s the path I chose that finally actually worked, and worked well:<\/p>\n