Fusion Boot Camp native boot broke?

[wildgeechi]

I had a functioning VMWare fusion 3.1.2 Windows 7 x64 VM, and it broke.  Originally partition structure was

OSX - 130G

BOOTCAMP 130G

LinuxBoot 1G

Ubuntu ~100G

Test ~50G

Test ~50G

Swap ~4G

I deleted Ubuntu, the tests, and the swap and created one partiion in its place (for LVM2).  Booting back to OSX, vmware did not boot windows.  Deleted Bootcamp VM, folder, helper vm... nadda.  Removed VMWare, reinstalled after manually removing any instance of VMware in /library ~/library... nadda.  No matter what I do, the VM only boots to the pxe boot screen and doesn't find the drive.  This worked before and the windows/osx partitions should be untouched by my recent change.  FYI, all three OS's boot without error via rEFIt.

What is wrong here??

[wildgeechi]

Also worth noting, Windows will chainload fine from Grub2 on the linux partition

[continuum]

do you have a vmx and a vmdk for the bootcamp VM ?

[wildgeechi]

Yup.  And they seem in order.  They are entirely created by VMWare... I tried making one to boot linux and editing by hand but that crashed out VMWare... only change in that case was ide0:0 true (or whatever) and pointing it to a vmware-rawdisccreater generated file.

The only thing I can think happened is the partition structure that gparted applied is in some way not agreeable to OSX/VMWare... diskutil in OSX doesn't let me alter anything

[continuum]

can you attach both files so I can check them ?

[wildgeechi]

Here are the files.  Interestingly, I couldn't navigate to the directory.. had to copy them via CLI

Attachment(s)

Boot Camp.vmx.zip   968 B 1 version

Boot Camp.vmdk.zip   703 B 1 version

[continuum]

both look ok to me - can you rule out any permissio n issues ?

[wildgeechi]

And here is some, perhaps, useful info:

*** Report for internal hard disk ***

Current GPT partition table:

#      Start LBA      End LBA  Type

1             40       409639  EFI System (FAT)

2         409640    254315895  Mac OS X HFS+

3      254578688    508483583  Basic Data

4      508483584    509007871  Basic Data

5      509007872    976773119  Linux LVM

Current MBR partition table:

# A    Start LBA      End LBA  Type

1              1       409639  ee  EFI Protective

2         409640    254315895  af  Mac OS X HFS+

3      254578688    508483583  07  NTFS/HPFS

4 *    508483584    509007871  83  Linux

MBR contents:

Boot Code: Unknown, but bootable

Partition at LBA 40:

Boot Code: None (Non-system disk message)

File System: FAT32

Listed in GPT as partition 1, type EFI System (FAT)

Partition at LBA 409640:

Boot Code: None

File System: HFS Extended (HFS+)

Listed in GPT as partition 2, type Mac OS X HFS+

Listed in MBR as partition 2, type af  Mac OS X HFS+

Partition at LBA 254578688:

Boot Code: Windows BOOTMGR (Vista)

File System: NTFS

Listed in GPT as partition 3, type Basic Data

Listed in MBR as partition 3, type 07  NTFS/HPFS

Partition at LBA 508483584:

Boot Code: GRUB

File System: ext4

Listed in GPT as partition 4, type Basic Data

Listed in MBR as partition 4, type 83  Linux, active

Partition at LBA 509007872:

Boot Code: None

File System: Unknown

Listed in GPT as partition 5, type Linux LVM

[continuum]

does a start of the bootcamp VM create a new vmware.log ? - if yes - lets see it

[wildgeechi]

It does, and here it is... at first glance it appears to be atleast trying to open the correct partition.

Attachment(s)

vmware.log.zip   16 KB 1 version

[wildgeechi]

On a side note, how do I make GPT identify disk0s4 as the ext partition that it is and not as MS stuff?

[continuum]

try to add this line to the vmx-file

mainMem.bug178871.disableWorkaround = "TRUE"

[wildgeechi]

No change

[continuum]

SGMAC:  opening 'cdrom0'
SGMAC:  Failed to obtain exclusive access: The media is still mounted. (0xe00002d5)

try without cdrom assigned to the VM

[wildgeechi]

Attempted boot with no usb/network/soundcard/serial/cdrom.  Same result

[wildgeechi]

Was able to get Ubuntu booted from within a VM under OSX.  Involves custom raw disk file assembled from the native GPT sectors so that the VM see's the GPT/EFI and can get to the 5th partition, as well as see what type of partition the 4th was (in my case, as it was only tagged as ext4 in gpt, as I understand it)

http://arstechnica.com/civis/viewtopic.php?f=19&t=64089

[wildgeechi]

Problem has been solved.  At some point during the course of the linux changes the 4th partition was marked as bootable (leaving windows MBR partition not marked as bootable.)  despite having a valid bootloader windows couldn't boot from vmware.  I marked the 3rd (windows) partition as bootable in the MBR, and reverted the linux VM to be GPT aware as outlined above via a hand-crafted linux-pt.vmdk file.  The Linux VM boots at this point.  Recreating the Windows VM so that Fusion re-ripped the MBR off the physical hard disk to place in the Boot Camp-pt.vmdk file now results in a bootable windows VM.  Horray! 

In summary and as I understand it, Windows MUST reside in partitions 2, 3, or 4 (EFI is part 1), as it must boot from MBR unless you have x64 Vista, 7, 2003 or 2008.  Even these will not boot via GPT within VMWare as VMware emulates a BIOS, and they are only GPT capable when EFI booted.  All other VM's can reside where-ever they wish if you do the GPT table trickery described above.

*** VMware enhancement... please make EFI VM's an option?

Thank you continuum for all your assistance!!!