Last week, I performed a major upgrade for a corporation in Burlington. A design department was having all of their Macs upgraded to Snow Leopard, CS5, and Office 2011. A few users also had hardware upgrades. One of those users was moving from a first generation Mac mini running 10.5.8 to a brand new 2.4Ghz Quad-Core Mac Pro.
The first step was to transfer the user’s data to the new Mac Pro. I used the built-in Migration Assistant that comes up right in the initial Setup Assistant, as I usually find this is a great and easy way to transfer data. Unfortunately, right at the end of the migration the machine kernel panicked (KP). I shut the Mac Pro down, disconnected the Mac mini, reset PRAM and reboot the Mac Pro. It KP’d once again. My next step was to boot to the install disc, open Disk Utility and repair the volume; no repairs were needed. Then I reinstalled the operating system, which in Snow Leopard is equivalent to the “Archive and Install” option, meaning no data was lost.
After the reinstall, the Mac Pro still kernel panicked. I decided to start from square one by performing and Erase and Install and re-migrating the data. This time, I first created a test account and then used Migration Assistant from /Applications/Utilities. I also chose not to transfer network settings, thinking it could have run into an odd driver issue. As the migration proceeded, I busied myself around the office performing the rest of the installs that needed to be done.
Much to my chagrin, after the migration completed the Mac Pro once again boot to KP. Crap. It was clear that I was going to have to dig deeper. I reboot in single user mode and once again ran an fsck (file system check), which found nothing. I did a little research and found other users were having the same problem due to items in their startup folders. With the Mac Pro in target disk mode, I connected it to my MacBook Pro and deleted the contents of /Library/StartupItems but that had no effect.
I then boot in safe mode (hold down the ‘shift’ key while booting), which worked successfully. I disabled all of the user startup items, but a reboot found the issue was still not resolved. I reboot once again into safe mode. From safe mode I was able to check the Console logs and that’s when the lightbulb turned on; the kernel panics were referencing Parallels drivers. I was already kicking myself that I hadn’t just checked the Console logs hours before. I get a slap on the wrist for that one.
Now that I was able to pin-point the issue to Parallels, I found several other instances of people running into the same specific problem after migration. Using the instructions in this Parallels Kbase article I fully uninstalled Parallels (which does not delete virtual machines) and, sure enough, the machine reboot just fine. This particular user was getting an upgrade to Parallels 6 anyway and after installing that, her virtual machines opened just fine. Problem solved!