Mountain Lion Nuked My Boot Camp Partition

[joeblow8579]

I have a 2010 iMac that I had Snow Leopard on. I installed Boot Camp not long after I got it to play Windows games (I installed Windows 7).

Last year I upgraded to Lion and continued to use the Windows partition with no problems.

Recently, I started to run out of space on the very modest partition I had made (~60GB IIRC), so I looked for solutions to expand that Windows partition without destroying data. I ended up shrinking the OS X partition with Disk Utility and expanding the NTFS partition with a Windows program called MiniTool Partition Wizard. I got it from here:

http://download.cnet.com/MiniTool-Partition-Wizard-Home-Edition/3000-2094_4-10962200.html

It worked flawlessly and I continued to use the Boot Camp partition with no problems until I installed Mountain Lion today. Now my Win7 partition will not boot (it does not appear in the Startup Disk panel nor in the menu when I hold option after a reboot). Running Disk Utility shows the old 60GB NTFS partition but without a name (it calls it disk0s4) with ~40GB of free space (the amount I'd increased the partition earlier).

Some googling has led me to several threads, such as these:

https://discussions.apple.com/thread/4151736?start=30&tstart=0
https://forums.macrumors.com/threads/1416174/

Here is the output from these commands:

sudo gpt -r -vv show disk0
sudo fdisk /dev/disk0

gpt show: disk0: mediasize=1000204886016; sectorsize=512; blocks=1953525168
gpt show: disk0: Suspicious MBR at sector 0
gpt show: disk0: Pri GPT at sector 1
gpt show: disk0: Sec GPT at sector 1953525167
       start        size  index  contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  1748359856      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1748769496     1269544      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1750039040    77254144         
  1827293184   126230528      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1953523712        1423         
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
[27iMac:~] joe% sudo fdisk /dev/disk0
Disk: /dev/disk0	geometry: 121601/255/63 [1953525168 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AF 1023 254  63 - 1023 254  63 [    409640 - 1748359856] HFS+        
 3: AB 1023 254  63 - 1023 254  63 [1748769496 -    1269544] Darwin Boot 
 4: 0C 1023 254  63 - 1023 254  63 [1827293184 -  126230528] Win95 FAT32L

Is there any way to restore my partition table without destroying any data on the windows side? I have no way of knowing what is where on that former partition, and I'd be willing to bet there is data in the now "free space" that was formerly taken up by the windows partition before mountain lion nuked it.

 

[joeblow8579]

So I booted from a MiniTools boot CD that I'd made at some point a year or two ago - probably more like two or three, now that I think about it. The program was able to "recover" the Boot Camp partition (I guess by recreating the hybrid partition table), which made that volume readable again - but not bootable. And the kicker was that it made my OS X partition unbootable as well.

I had to boot from an external hard drive. I am in the process of using WinClone to make an image of the Boot Camp partition, since my only backup of that partition is quite old and of dubious utility since I used Disk Utility to make it.

I still need a way to restore the partition table, now for all three bootable partitions on the drive (the OS X, Recovery, and Boot Camp partitions). It would not be the end of the world (assuming this backup is good) for me to lose the Windows partition and restore it later, but I have to make sure my OS X partition does not crap the bed on me here either. I do have a backup of that partition, but it is several weeks old (I know, I know...).

Help!

 

[Blackberryroid]

If the Bootcamp partition is still there (and your files are intact) and just simply won't boot, boot up from the Windows installer and perform an upgrade.

 

[murphychris]

I ended up shrinking the OS X partition with Disk Utility and expanding the NTFS partition with a Windows program called MiniTool Partition Wizard.

You can't use Windows programs to resize dual-boot Boot Camp created disks. It can cause data loss because Windows programs ignore the GPT, and only modify the MBR. The MBR and GPT are thus out of sync, which is a dangerous situation.

It worked flawlessly and I continued to use the Boot Camp partition with no problems until I installed Mountain Lion today.

I'm going to guess that these Mountain Lion problems with Boot Camp might be a failsafe in the installer, that basically disables the Windows bootability in order to prevent Windows from hosing the Mac OS X volume, due to out of sync partition maps, due to using the wrong utilities for resizing volumes. Just a guess.

4: 0C 1023 254 63 - 1023 254 63 [1827293184 - 126230528] Win95 FAT32L

This is the problem, or at least one of the problems. The type code is 0C, which is wrong, it needs to be 07. And the partition's active flag (boot flag) isn't set.

Is there any way to restore my partition table without destroying any data on the windows side?

I don't know.

In the GPT, there is a 36GB free space gap between the 3rd and 4th partitions. I don't know why it's there. Since the MBR and GPT now appear to have the same four partitions with the same starting LBAs, and sizes, I don't know if it's possible the MBR had conflicting (different) information than the GPT. This may be difficult.

dd if=/dev/disk0 of=~/mbrdisk0s4.bin skip=1827293184 bs=512 count=4
hexdump -C ~/mbrdisk0s4.bin

First command will read 4 sectors starting at LBA 1827293184 and write them to binary file "mbrdisk0s4.bin" in the user home director. LBA 1827293184 is the start LBA for the Windows partition as reported in both the GPT and MBR. If correct, we should see the NTFS volume header information in that 4 sector block. Post the results of the hexdump command.

Do it again with the free space area:

dd if=/dev/disk0 of=~/mbrdisk0fs.bin skip=1750039040 bs=512 count=4
hexdump -C ~/mbrdisk0fs.bin

This might help determine what this free space is or was.