Mac OS X on VmWare – Upgrading from 10.6.4 to 10.6.8

In my previous articles (this and this) I have shown you how to setup a working Mac OS X 10.6.4 system running on your PC using VmWare Workstation. For some time, the setup has been working perfectly fine for me, mostly for iOS development, since I don’t own a Mac.

However, recently I needed to upgrade my xCode to version 4.2 in order to support the latest iOS SDK, and to my surprise, Xcode 4.2 requires at least 10.6.7 for installation.

The easy way: modifying SystemVersion.plist

Well, if you don’t want to read the rest of this post, there is an easier way. It should be noted that most of xCode and iOS SDK will work just fine without the extra features in 10.6.7 – the minimum version requirement is just Apple’s lazy way to reduce development and support efforts by forcing users to upgrade to their latest release.  Following this trick, I opened my SystemVersion.plist located at System/Library/CoreServices, and changed the version number to 10.6.7 or higher:

After a reboot, the new version was shown in About This Mac and xCode installed and worked just fine! Notice that this would fail (xCode installs but behaves erratically) if your current system is too old, e.g. 10.5.x. You’ll need at least 10.6.4 for the trick to work.

Updating to 10.6.8 the proper way

However, with some free time at hand, I still decided to go ahead and properly update my system to 10.6.8 using the built-in Software Update. The updated system rebooted just fine, showing 10.6.8 correctly in About This Mac. For complete functionality, I installed the following 2 patches and rebooted the system again:

1. IOUSBFamily-378.pkg: allow the virtual OS to recognize USB devices. You would first need to disconnect it from the host and connect to the Mac via VMWare’s Removable Devices menu.
2. EnsoniqAudioPCI_v1.0.3_Common_Installer.pkg: allow audio to work. 

In my case, I also needed to disable the screensaver and various power management settings. For some reasons, it causes random kernel panic.

Expanding the virtual hard disk

Next, I realized that there was not enough disk space to install the latest iOS SDK. Expanding the hard disk is not an easy task, as common methods fail with a “MediaKit reports partition map too small” error message. In my previous tutorial, I have shown a workaround which took a long time and did not always work. The proper method is to manually modify the partition table to reflect the new hard disk size. Run gpt tool from terminal as described in this post (see also this), destroy the existing partition table and recreate a new one with the correct partition size.

Take note that for gpt to work, you need to have the disk unmounted which is not easy as it’s a system disk. You would need to boot from the install DVD and use Terminal from there. If a boot disk is not available, make a copy of the working virtual machine, insert the original hard disk as another drive, boot from the copied virtual machine and use it to work with the original hard disk. If you choose the second method, take note that the copied hard disk and the original hard disk will have the same UUID, which will cause problems with Disk Utility and VmWare will also warn you upon startup. The correct way to fix this is to use a hex editor that can accept large file such as Hex Editor Neo to edit the VMDK file and change the UUID. Look for ddb.uuid:

With the expanded hard disk, I installed the latest xCode, iOS SDK and various other apps just fine. Since the default Preview app does not work properly for graphics file due to the lack of QE/CI support, I replaced it with JustLooking, a freeware mac preview app that does not require QE/CI. Taking screenshots is done via VmWare’s Capture Screen menu, or via Ctrl-Alt-PrintScreen.

However, everything was working great and I was developing my iOS app on the simulator when I encountered a kernel panic on the virtual Mac, causing VmWare to shut it down:

It took a while for me to realize that it wasn’t the Mac that crashed first – it was the iOS app crashing on the simulator and taking the entire system down with it. Yes, any kind of crash, even one as simple as calling an unrecognized selector on an object:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
    [self dummyMethod];
    return YES;
}

If you are unlucky enough and the system is writing to the disk when the crash happens, the disk image will be corrupted and the Mac won’t reboot to the desktop successfully. It will also be a tough task to recover any data from the corrupted disk image. Sort of funny but true. I was unable to determine the root cause and can only assume that it’s due to hardware virtualization. The iPhone simulator architecture is actually x86, which suggests it is sharing the same CPU as the Mac, and any exception caused by the simulator will be escalated to the Mac if not handled properly.

Adding exception breakpoint in xCode

To work around this, I put all my projects in a VmWare shared folder that is linked to a folder the host’s hard drive so that the projects are still intact even if the Mac drive is corrupted. I also save working snapshots of the system that I can revert to in case something goes wrong. Most importantly, I add an exception breakpoint so that xCode will stop before an exception occurs, instead of letting it happen and crash the system:

My 10.6.8 upgrade is now completed and my next attempt is to upgrade to Mac OS X Lion (10.7.0), which will be another article. Meanwhile, I can now happily develop iOS apps on my laptop without purchasing a Mac.