Inconsistent Upgrade Behavior on Software-Mirrored RAID Volumes

August 8th, 2013 by Allister Banks

It came up again recently, so this post is to warn folks treading the same path in the near future. First a little ‘brass tacks’ background: As you probably know, as of 10.7 Lion’s Mac App Store-only distribution, you can choose the option to extract the InstallESD.dmg from the Install Mac OS X (insert big cat name here) application, and avoid duplicitous downloads and manual Apple ID logins. One could even automate the process on a network that supports NetInstall with a redundantly named NetInstall set to essentially ‘virtualize’ or serve up the installer app on the network.

We’ve found recently that more than a few environments are just getting around to upgrading after taking a ‘wait and see’ approach to Lion, and jumping straight to 10.8 Mountain Lion. Getting to the meat after all this preamble… it was also, at one time, considered best practice to use RAID to mirror the boot disk, even without a hardware card to remove the CPU overhead. (It hadn’t been considered a factor then, but even modern storage virtualization *cough*Drobo*cough* can perform… poorly. I personally recommend what I call a ‘lazy mirror’, having CCC clone the volume and putting less writes on the disk over time, and getting the redundancy of CCC reporting SMART status of the source and destination.)

When upgrading a software-mirror’d boot drives OS, you get a message about features been unavailable, namely FileVault2 and the Recovery Partition it relies upon. If it detects the machine being upgraded is running (a relic of a bygone era, a separate OS called quaintly) ‘Mac OS X Server,’ it additionally warns that the server functionality will be suspended until Server.app 2.x can be installed via… the Mac App Store. We’ve found it can do an upgrade of those paused services(at least those that are still provided by the 2.2.1 version of the Server application) and pick up where it left off without incident after being installed and launched.

If, however, you use a Mac App Store-downloaded application to perform the process, we’ve seen higher success rates of a stable upgrade. If instead you tried to save time with either the InstallESD.dmg or NetInstall set methods mentioned earlier, a failure symptom occurred that, post-update, the disk would never complete its first boot(verbose boot was not conclusive as to reasons, either.) Moving the application bundle to another machine(volume license codes have, of course, been applied to the appropriate AppleID on the machines designated for upgrades,) hasn’t been as successful, although the recommended repackaging of the Install app, as Apple has referred to in certain documentation, wasn’t attempted this particular time. In some cases even breaking the software mirror didn’t allow the disk to complete an upgrade successfully. Another symptom before we could tell it was going to fail is the drop-down sheet warning of the loss of server functionality would immediately cause the entire window to lose focus while about to initiate the update. A radar has not been filed due to the fact that a supported(albeit semi time-intensive) method exists and as been more consistently successful.

Tags: , , , , , , , , ,

Comments are closed.