How to prevent a FAT32 partition from mounting at boot?

[PositronicBrain]

I'm using VMWare Fusion 3.1 in a MacBook Pro with the following partitions:

* a HFS partition for Mac OS X 10.6

* a FAT32 partition

* a NTFS partition for Windows XP Profesional SP3

The idea of the FAT32 partition was to have it as a common drive among operating systems. Both XP and OSX, when booting, recognize and mount the FAT32 partition.

However, when I boot the bootcamp partition using Fusion, Windows XP mounts the FAT32 partition and OSX loses it. I understand this is working as intended, since it is a physical partition and only one OS can mount it at a time. However, I'd rather have OSX mount the partition itself and share it with windows using Fusion's shared folders.

So, I ask, is there a way to keep the XP partition or Fusion from mounting the FAT32 partition? Failing that, is there a way to unmount the FAT32 partition in XP so I can remount it in OSX? (removing it from Computer Management/Storage doesn't work - I removed the letter from the partition and then tried to mount it back again using OSX and it was still in use)

The ideal behavior would be to keep XP from mounting the FAT32 partition when booting with Fusion so OSX could use it, but have XP automount the partition when booting using Bootcamp. I wonder if this is possible...

Thanks!

[WoodyZ]

To help figure out what is what the best way to provide comprehensive diagnostic information is to use the "Collect Support Information" command from the VMware Fusion (menu bar) > Help > Collect Support Information and then attach the .tgz file it created on your Desktop.

[PJL73]

Bump.

[WoodyZ]

Since your appear not to be the OP then why are you bumping this year and a half old thread and not including any information?  If you want help then you need to provide enough information that can be analyzed!   While the OP had some information there wasn't enough to properly determine how everything was configured in order to provide a solution based on the actual facts that were not included and why the suggestion of providing the support bundle.

[PJL73]

Hi,

I bumped it simply because the OP was asking the exact question I'm trying to find the answer to, and they didn't seem to have got an answer.  The age of the thread is irrelevant.  The information provided by the OP was clear enough to me - it seemed more a question of preference regarding which OS takes control of the 3rd partition, rather than a problem that needs 'diagnosing', but I've now attached the support bundle as suggested.

Many thanks.

[WoodyZ]

He didn't get an answer because he didn't provide the support bundle nor did he include the more relevant information necessary to provide a solution without having to ask a bunch of questions, that most users couldn't easily answer to begin with, and not waste my time otherwise.  If there was only one possible configuration option and only one way of partitioning/formatting a hard drive and only one type of Host and Guest OS and no possibility of more then one physical hard disk then some definitive information could have been provided with just what the OP included however that is not the case!

Without wasting my time detailing all the relevant points why and to keep it simple nonetheless, the age of a thread is always relevant because things change over time and can or do have an affect in todays context!

Anyway I'll review the info in the support bundle and either make a recommendation, or if necessary ask a question or so, shortly.

[WoodyZ]

Okay, obviously without the support bundle from the OP I can't detail all of the differences between his situation and yours other then the mounting issue, however on the surface he's using Windows XP and a FAT32 data volume and you're using Windows 7 and a ExFAT data volume.  It's easier to resolve this issue with Windows XP then with Windows 7 however that's moot since Windows 7 is what you're using under Boot Camp.   BTW Just an FYI in case you didn't know, ExFAT only uses one MBR as opposed to two MBR's with FAT32 and this makes ExFAT less resilient and more prone to catastrophic data loss the FAT32 however if you need to store files >4GB then that may be why you chose ExFAT over FAT32.  Personally I wouldn't use ExFAT, nor do I like using FAT32 for a Data Volume however for some users they don't have a better alternative they're comfortable with.

Anyway it looks like when VMware Fusion prepared the Boot Camp partition to be used as a Virtual Machine it automatically took both /dev/disk0s3 and /dev/disk0s4 and created the Boot Camp.vmdk meta-data virtual hard disk using both partitions.  While I do use Boot Camp I do not let VMware Fusion even touch it anymore and have disable what's necessary for VMware Fusion to even begin to touch it so I cannot do any experimentation at this point in time although in the past I used to run my Boot Camp partition as a Virtual Machine and did have multiple primary partitions with it and did experimentation back then.

So since I'm not presently in a position to physically replicate a specific given configuration I can only say what I'd try to get the results I wanted in theory where the configuration was the same as your's and the OP's.

I see two options involving the meta-data virtual hard disk used by the Boot Camp Virtual Machine...

One would be to manually edit the Disk DescriptorFile of the virtual hard disk (Boot Camp.vmdk) to remove /dev/disk0s3 and relevant ddb.geometry entries, although this doesn't modify the binary portion (Boot Camp-pt.vmdk) and without testing I can't say if there would be any issues.

The other would be to use vmware-rawdiskCreator to manually create a new meta-data virtual hard disk only for /dev/disk0s4 and then manually swap out the Boot Camp.vmdk and Boot Camp-pt.vmdk files.  This being done with the understanding that the following two conditions might occur, one being the BCD may need to be repaired in order to boot from the Virtual Machine and the other may be Windows having to be reactivated because of changes in the virtual disk.

Other considerations would be doing nothing until proper backups are made and be in a position to easily restore the system in the event something goes awry.  To me this means a Time Machine backup of the OS X Host (this does not include normal file based Virtual Machines as that is not the proper* way to back those up) and Data Volume and a WinClone backup of the Boot Camp partition.  Additionally I always maintain separate User Data Backups so as to have appropriate redundancy and the ability to approach any system and have direct access to User Data in of and by itself as/if/when necessary.

I know you are only using Boot Camp however * is included to cover all bases.

==========

* It is a known fact that Time Machine is not 100% reliable backing up/restoring Virtual Machines under all circumstances/conditions.  Also backing up Virtual Machines via Time Machine is disk/time intensive and wastes a tremendous amount of space for something that may be corrupt and worthless come time to restore it.  At a minimum I would exclude Virtual Machines from Time Machine and with the Virtual Machines shutdown, not suspended, and VMware Fusion closed then manually copy the Virtual Machines Package(s) to an alternate location, preferably on to a different physical hard disk.  Then keep the User Data that is stored within the Virtual Machine backed up off of the Virtual Machine on a regular basis so as to always have a current User Data Backup.  If you have to restore a properly backed up Virtual Machine that is not as current at least you'll have a working Virtual Machine and current User Data to go forward with when you find out your Time Machine Backup of the Virtual Machine fails.

[PJL73]

Wow. Thank you for such an in-depth response!

So it sounds like the short answer is "not very easily".  And by some of your other comments, it also sounds like what I am trying to do might be a Bad Idea anyway.

1. I can probably cope with the 4GB size restriction in FAT32, I was just making a lazy assumption that this was the only difference between it and ExFAT - thanks for the warning.

2. You mention that you wouldn't let Fusion touch the Boot Camp partition, which presumably you have good reason for.  While I realise this is a vmware forum, do you know if this would be equally risky using Parallels?

Basically, I just really liked the idea of having OSX on one partition, Windows on another bootable partition, but with the option to run it in a VM occasionally (without the need to have another installation of Windows taking up more space), and with a separate data partition with read/write access from both OSes. Maybe this is unachievable after all (or at least quite risky), but if you know of a better way to do it, any suggestions would be welcome.

Again, many thanks for taking the time to respond.

[WoodyZ]

So it sounds like the short answer is "not very easily".  And by some of your other comments, it also sounds like what I am trying to do might be a Bad Idea anyway.

Actually for me it would be extremely easy because I'm quite comfortable using Terminal and running programs from the command line however I don't think it all that difficult generally speaking.  Also if I conveyed that I thought it was a bad idea that certainly was not the intention and I wouldn't hesitate to do it if I needed that uses case scenario now.

2. You mention that you wouldn't let Fusion touch the Boot Camp partition, which presumably you have good reason for.  While I realise this is a vmware forum, do you know if this would be equally risky using Parallels?

Without getting to to all the reasons, some of which are no longer relevant since VMware fixed the major issue, let me just say that with VMware Fusion 3 and later it's not the issue it was in the prior versions and today I do not think the way Parallels or VMware handles it is better or worse then the other.  While I personally do not use my Boot Camp partition as a Virtual Machine I do however have VM's that use Raw Disks, just like the Boot Camp Virtual Machine does, so I really do not have a issue the concept, or application of the technology however outside of letting VMware Fusion do its thing with Boot Camp then using Raw Disks manually is for advanced users as there are inherent risks one needs to be aware of and understand how to deal with them.  Regardless though this is why one needs to always be properly backed up and in a position to easily restore the system in the event something goes awry.

Basically, I just really liked the idea of having OSX on one partition, Windows on another bootable partition, but with the option to run it in a VM occasionally (without the need to have another installation of Windows taking up more space), and with a separate data partition with read/write access from both OSes. Maybe this is unachievable after all (or at least quite risky), but if you know of a better way to do it, any suggestions would be welcome.

A better way would probably be considered subjective so let me just say that if I had one computer, a Mac, and wanted to dual boot OS X and Windows and share a Data volume between them and also boot Windows under Boot Camp as a Virtual Machine I wouldn't hesitate to do it.  The issue for you is that since VMware Fusion included both /dev/disk0s3 and /dev/disk0s4 and created the Boot Camp.vmdk meta-data virtual hard disk using both partitions and that is not the exact use case scenario you prefer then the best option I see at the moment in this context it to manually create a new meta-data virtual hard disk just for /dev/disk0s4 and then swap out the virtual hard disks.  As long as you're properly backed up I just don't see an issue with at least trying.  I've done the same thing in the past with Raw Disks outside of Boot Camp and to me it's just not a big deal.   If you need some help with resolving this issue, there are others here beside myself that can help you where you might need some help.  I too will of course provide what assistance I can along the way.