"Boot Camp is not installed" a.k.a. Mommy Knows Best

I have -- well, I had -- a nice setup on my Mac Mini: the internal disk uses rEFIt to select between booting Mac OS X, NetBSD, and FreeBSD (I use NetBSD and FreeBSD for development work at my job), and an external firewire drive, disk1, has several partitions including data partitions for NetBSD and FreeBSD which I share between my Parallels VMs under MacOS and my direct-booted NetBSD and FreeBSD installations.

This all worked fine, with the partitioning on the external disk created by Apple's diskutil (to get GPT and MBR tables in sync) and adjusted slightly (partition type and active flag only) by the NetBSD and FreeBSD installers. I could mount the NetBSD and FreeBSD data partitions under Parallels or when directly booted to those OSes from the external disk.

Suddenly, after another slight MBR change to disk1 only (still leaving valid, and in-sync per diskutil and Apple command-line fdisk, MBR and GPT tables) on disk1, I get, on Parallels invocation (Desktop 3.0, build 4560):

"Virtual machine cannot be started because of the following problem:

The Hard Disk 2 is set to use the Boot Camp while Boot Camp is not installed on this computer!"

I don't know what this even is supposed to mean, since "Boot Camp" is a package of device drivers for Windows and Parallels happily used the same partitions before, they *are* MBR partitions (a.k.a. "Boot Camp partitions") and they are accessible by MBR-based OSes *and* by OS X. I tried simply erasing the GPT partition table on disk1, so Parallels couldn't possibly think it was out of sync with the MBR table (10.4.7 is fine with HFS+ partitions on MBR-only external drives) and Parallels still throws the same error.

The partition name in question, disk1s3, is still a perfectly valid Mac OS X partition and is accessible by Disk Utility or, for example, od or hexdump. I can conclude only that Parallels is doing some kind of "Mommy knows best" sanity checking on raw partitions before deigning to permit users to configure them -- even if those users have to edit the configuration file by hand to use them at all. And Mommy doesn't know best, and it's insanity checking, since it's clearly buggy.

This is crazy. Please, tell me there's some way to "persuade" Parallels to stop pretending it's protecting me from myself, and to start attaching my data disks to my virtual machines once more; no adjustment I can make to the MBR or GPT tables seems to make it do so.

 

It sounds like you need to setup a custom Boot Camp configuration.

 

Obviously I already have such a configuration, or I could not even extract that error message from Parallels Desktop. And as I pointed out in my post (did you even read it?) it was working fine, until Parallels arbitrarily decided to make it not work.

Sigh.

The point is, my configuration file for the VM in question already contains everything needed to use two "Boot Camp" (a.k.a. raw) partitions as the second and third disks (disk1 and disk2) respectively. But Parallels Desktop evidently now objects to something about the partition table (or partition contents) on the OS drive "disk1" which contains the partition "disk1s3" and emits the aforementioned useless error message instead of telling me what it thinks is wrong, or simply attaching the partition in question.

Ain't life grand?

 

What's does it say in your ~/Library/Logs/Parallels/Bootcamp.log and ~/Library/Logs/Parallels/BootcampOSP.log files?

 

There is no BootcampOSP.log file, unfortunately.

The Bootcamp.log file contains:

[18.07.2007]-[17:37:14.671]: Open: connected partition disk1s3
[18.07.2007]-[17:37:14.695]: Open: connected partition disk0s3
[18.07.2007]-[17:57:59.294]: Open: connected partition disk1s3
[18.07.2007]-[17:57:59.324]: Open: connected partition disk0s3
[18.07.2007]-[20:09:51.309]: Open: connected partition disk1s3
[18.07.2007]-[20:09:51.375]: Open: connected partition disk0s3

That's once per invocation of the VM since the problem ensued -- but no diagnostics. disk1s3 is the "Hard Disk 2" the error dialog is complaining about.

Thanks for the pointer to the log file. Shame Parallels doesn't actually emit an error message into it!