Unable to boot up in bootcamp after installing Mountain Lion

None of them do?

hexdump -C ~/4s_part3.bin

00000000 11 fe fa 24 5f 22 51 ff e0 00 00 f8 e1 04 08 fd |...$_"Q.........|

00000010 f5 2a ae 55 03 6f d1 50 fb 54 67 23 c9 f1 a0 00 |.*.U.o.P.Tg#....|

00000020 00 f8 81 1f 88 89 fa aa bf 54 a3 6f 91 28 8b f7 |.........T.o.(..|

00000030 ca a2 49 f7 20 00 00 f8 61 1c 08 21 ff ea aa 55 |..I. ...a..!...U|

00000040 f3 62 11 7c f8 84 7f a2 01 fa a0 00 00 f8 81 3f |.b.|...........?|

00000050 89 55 fe ea 92 55 fb 64 91 fe fb 44 6a a2 49 f3 |.U...U.d...Dj.I.|

00000060 20 00 00 6f 62 49 1b 58 92 4f ff 5c e8 81 07 f8 | ..obI.X.O.\....|

00000070 20 46 fd 82 20 66 00 00 00 01 c3 f0 11 10 48 82 | F.. f........H.|

00000080 48 7f f8 38 01 a0 14 81 22 31 0c 08 00 00 00 03 |H..8...."1......|

00000090 83 e1 12 08 48 80 00 02 03 ff c1 a0 14 81 22 31 |....H........."1|

000000a0 0c 08 00 00 00 13 e7 11 08 89 54 42 3e 7d 40 8a |..........TB>}@.|

000000b0 0e 48 6a 45 11 09 08 48 20 00 00 0c 43 82 25 10 |.HjE...H ...C.%.|

000000c0 b3 e1 15 7f a8 e5 46 be 55 52 8a a4 54 23 e0 00 |......F.UR..T#..|

000000d0 00 1f f7 2a 8b fd 51 07 3e 7c 40 9f ce 44 6f f5 |...*..Q.>|@..Do.|

000000e0 04 08 f8 41 00 00 00 3f c1 22 0f f0 48 82 44 1f |...A...?."..H.D.|

000000f0 e0 10 00 80 3f c0 20 01 01 ff e0 00 00 01 c3 f0 |....?. .........|

00000100 01 01 ff e2 44 1f e0 91 07 f8 04 01 fe 01 01 ff |....D...........|

00000110 e0 00 00 fb f5 40 be 29 50 8a bf 7c 08 81 84 08 |.....@.)P..|....|

00000120 f8 41 02 0e 11 c1 80 00 00 3f c1 02 0f f0 40 83 |.A.......?....@.|

00000130 fc 7f f8 91 07 f8 24 41 fe 01 01 ff e0 00 00 79 |......$A.......y|

00000140 00 8f bf c8 71 8d 33 3f f9 49 0b f8 52 42 fe 20 |....q.3?.I..RB. |

00000150 81 7f e0 00 00 06 00 48 04 20 40 8d fb 02 00 10 |.......H. @.....|

00000160 0f fc 04 01 22 05 21 ff e0 00 00 30 02 5f a1 24 |....".!....0._.$|

00000170 f1 22 09 10 4b f2 44 12 a9 15 48 8e 85 c8 c0 00 |."..K.D...H.....|

00000180 00 18 11 24 90 a5 f9 21 09 7f 48 42 4a 92 54 90 |...$...!..HBJ.T.|

00000190 84 87 85 e0 e0 00 00 30 02 5f a0 11 f0 82 04 10 |.......0._......|

000001a0 23 e1 04 08 a8 45 42 0c 11 83 80 00 00 30 82 44 |#....EB......0.D|

000001b0 21 21 f7 c2 0a 7c 50 82 95 14 a9 21 09 8e 8d c8 |!!...|P....!....|

000001c0 20 00 00 30 82 44 21 21 f7 e2 09 10 4b e2 44 12 | ..0.D!!....K.D.|

000001d0 a9 15 48 8c 85 88 c0 00 00 10 83 4b 01 80 33 02 |..H........K..3.|

000001e0 04 6f d8 10 1f fe 04 01 22 05 21 ff e0 00 00 30 |.o......".!....0|

000001f0 82 44 20 21 f1 02 3f 10 43 e2 04 10 a8 85 44 0c |.D !..?.C.....D.|

hexdump -C ~/4s_part4.bin

00000000 00 00 00 73 0d 00 00 00 74 00 00 74 01 00 69 02 |...s....t..t..i.|

00000010 00 83 01 00 53 28 01 00 00 00 4e 28 03 00 00 00 |....S(....N(....|

00000020 52 53 01 00 00 52 02 00 00 00 52 7d 00 00 00 28 |RS...R....R}...(|

00000030 00 00 00 00 28 00 00 00 00 28 00 00 00 00 73 3c |....(....(....s<|

00000040 00 00 00 43 3a 5c 50 79 74 68 6f 6e 32 36 5c 4c |...C:\Python26\L|

00000050 69 62 5c 73 69 74 65 2d 70 61 63 6b 61 67 65 73 |ib\site-packages|

00000060 5c 6e 75 6d 70 79 5c 63 6f 72 65 5c 74 65 73 74 |\numpy\core\test|

00000070 73 5c 74 65 73 74 5f 75 6d 61 74 68 2e 70 79 74 |s\test_umath.pyt|

00000080 0e 00 00 00 74 65 73 74 5f 6e 65 78 74 61 66 74 |....test_nextaft|

00000090 65 72 36 04 00 00 73 02 00 00 00 00 01 63 00 00 |er6...s......c..|

000000a0 00 00 00 00 00 00 02 00 00 00 43 00 00 00 73 0d |..........C...s.|

000000b0 00 00 00 74 00 00 74 01 00 69 02 00 83 01 00 53 |...t..t..i.....S|

000000c0 28 01 00 00 00 4e 28 03 00 00 00 52 53 01 00 00 |(....N(....RS...|

000000d0 52 02 00 00 00 52 7c 00 00 00 28 00 00 00 00 28 |R....R|...(....(|

000000e0 00 00 00 00 28 00 00 00 00 73 3c 00 00 00 43 3a |....(....s<...C:|

000000f0 5c 50 79 74 68 6f 6e 32 36 5c 4c 69 62 5c 73 69 |\Python26\Lib\si|

00000100 74 65 2d 70 61 63 6b 61 67 65 73 5c 6e 75 6d 70 |te-packages\nump|

00000110 79 5c 63 6f 72 65 5c 74 65 73 74 73 5c 74 65 73 |y\core\tests\tes|

00000120 74 5f 75 6d 61 74 68 2e 70 79 74 0f 00 00 00 74 |t_umath.pyt....t|

00000130 65 73 74 5f 6e 65 78 74 61 66 74 65 72 66 39 04 |est_nextafterf9.|

00000140 00 00 73 02 00 00 00 00 01 52 86 00 00 00 74 07 |..s......R....t.|

00000150 00 00 00 70 6f 77 65 72 70 63 73 2b 00 00 00 4c |...powerpcs+...L|

00000160 6f 6e 67 20 64 6f 75 62 6c 65 20 73 75 70 70 6f |ong double suppo|

00000170 72 74 20 62 75 67 67 79 20 6f 6e 20 77 69 6e 33 |rt buggy on win3|

00000180 32 20 61 6e 64 20 50 50 43 2e 63 00 00 00 00 00 |2 and PPC.c.....|

00000190 00 00 00 02 00 00 00 43 00 00 00 73 0d 00 00 00 |.......C...s....|

000001a0 74 00 00 74 01 00 69 02 00 83 01 00 53 28 01 00 |t..t..i.....S(..|

000001b0 00 00 4e 28 03 00 00 00 52 53 01 00 00 52 02 00 |..N(....RS...R..|

000001c0 00 00 52 7e 00 00 00 28 00 00 00 00 28 00 00 00 |..R~...(....(...|

000001d0 00 28 00 00 00 00 73 3c 00 00 00 43 3a 5c 50 79 |.(....s<...C:\Py|

000001e0 74 68 6f 6e 32 36 5c 4c 69 62 5c 73 69 74 65 2d |thon26\Lib\site-|

000001f0 70 61 63 6b 61 67 65 73 5c 6e 75 6d 70 79 5c 63 |packages\numpy\c|

Yuck. Well, my next thought is that you can do something like this:

hexdump -C /dev/disk0s4 | grep 'eb 52 90 4e 54 46 53 20'

If that binary exists anywhere on partition 4, it will produce a result with a byte offset from the start sector of that partition, and could be used to define a new (correct?) start sector for this missing-in-action NTFS partition. Windows repair can't do anything because it's not finding either the NTFS header or any superblocks in the expected locations. Not good. And totally bizarre.

Anyway, I'd try that. It might take a while. Like, an hour? Or two? It's a read only command so it's not like it's going to change anything.

If you don't get a hit, we'll deal with that later...

Thanks. That command returned this after a few minutes:

user$ sudo hexdump -C /dev/disk0s4 | grep 'eb 52 90 4e 54 46 53 20'

Password:

3e64c000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

It is still in progress though. I'll post again when it is done.

So on my Core i7 laptop with a WDC black drive in it, I'm only getting 4MB/s for this command. For ~75GB this search is going to take a long time, looks like 5 hours give or take. Also, I had to use sudo in front of hexdump for some silly reason.

control-c to stop it. No sense in waiting!

I stopped it. Is it safe to define a new start sector for the missing NTFS partition?

I will make a clone of the partition with Data Rescue first anyway.

OK so the byte off set is 3e64c000. That's bytes in hex. And the disk0s4 start sector is 3750672384. That's sectors in decimal.

To convert the byte offset to sectors, use 200 hex bytes (512 decimal bytes) per sector.

So 3e64c000 divided by 200 hex bytes per sector = 1F3260 hex sectors or 2044512 decimal sectors.

3750672384 old start + 2044512 offset = 3752716896 new start.

So use gdisk to delete partition 4 (your backups for your partition table are posted to this forum!), then make a new partition. Before you actually do any of this you should check the logic above and the math.

sudo gdisk /dev/disk0

p print partition table

d delete

4 partition 4

n new partition

4

3752716896 new start sector

3909073504 original end sector (no idea if this is right since the beginning one is obviously wrong)

0700 hex code for partition type Windows NTFS/FAT32

w

y

Reboot. See if Mac OS X automatically mounts the NTFS volume now. Now, here are things I don't know because I actually don't use Windows or Boot Camp. I don't know if Mac OS X mounts NTFS volumes read-only automatically by default. I think it does. If so, this is good because we don't want it to. Another thing is if you have a 3rd party software that adds read-write support you need to make sure it's NOT mounting the disk read-write.

Now hopefully this Bootcamp volume mounts and you can suck the data off of it. You could also do something like this to make a "disk image" of your Boot Camp volume.

dd if=/dev/disk0s4 of=/Volumes/diskname/bootcampbackup.bin bs=1m

You should replace diskname with the actual name of the disk. It can be any format, even HFS+. This will copy every sector from disk0s4 (the new partition with NTFS header at the front where it should be) to a file on whatever disk you choose. If you make it a .iso file, Disk Utility will even mount it as a read only disk image and you can suck your files off that. If it works. But you have to have around 75GB free space on the destination disk. You can even do this to you desktop if you wanted to, I think you have a 1.9TB disk with lots of free space for Mac OS X?

dd if=/dev/disk0s4 of=~/Desktop/bootcampbackup.bin bs=1m

If you reboot and the Windows/BOOTCAMP volume doesn't automount, then you can check to see if the logic and math were correct by doing the exact same hexdump command as before:

sudo hexdump -C /dev/disk0s4 | grep 'eb 52 90 4e 54 46 53 20'

This should immediately produce a result:

00000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

Offset of 0 bytes. If it finds it elsewhere, then something in the logic or math was wrong.

I realize there is the possibility that the offset you found is actually the END of the NTFS volume. The last sector of NTFS is the same as the first. So to know which is which you need two full sectors (technically 16 more bytes after either the start or end header). The next 16 bytes after the start header contains bootloader code, the 16 bytes after the end header could be anything: blank space, gibberish, or often a piece of the alternate GPT partition table. To find out:

dd if=/dev/sdb of=~/last1024.bin skip=3750672384 count=2

hexdump -C ~/last1024.bin

What you're looking for if it's the start of NTFS, i.e. I got the earlier gdisk new partition start sector correct.

00000200 07 00 42 00 4f 00 4f 00 54 00 4d 00 47 00 52 00 |..B.O.O.T.M.G.R.|

If you get something else, then it might be the end of the NTFS volume, in which case that's good because we need this information anyway. But then we have to go hunting for the start of the NTFS volume which then has to be somewhere in that free space that's unallocated on your drive.

I ran the command over night and it returned all of these:

user$ sudo hexdump -C /dev/disk0s4 | grep 'eb 52 90 4e 54 46 53 20'

3e64c000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

459f2c000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

524e70000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

56a0ec000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

1174146590 4f 00 00 82 3e 00 55 aa eb 52 90 4e 54 46 53 20 |O...>.U..R.NTFS |

12a3798000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

12a39ffe00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|

How many times has this disk (any partition or partitions) been formatted NTFS?

Hi,

I have just registered to thank Christopher Murphy for all his efforts helping people and for posting such good directions to fix bootcamp problems. Thanks to those directions and a linux live cd I have just been able to boot again from my W7 installation.

My case: I spoiled my installation after decreasing the size of the mac partition with Disk Utility. It missplaced the start sector of my bootcamp installation. I followed your instructions to find the good start sectors and made a preview of its correctness by using a linux live cd to try mounting a filesystem starting at the sectors found. Everyting went quite fine and I could see that all my data were there.

Just one addition, I made my W7 installation by deleting the Bootcamp assistant partition and creating a new one on the W7 installation process. This fact means that there is an additional 100MB partition prior the real W7 system partition. There is where the bootloader is placed and that one is the partition to flag as bootable.

Again, thank you very much Christopher Murphy!!

I made my W7 installation by deleting the Bootcamp assistant partition and creating a new one on the W7 installation process.

I don't understand exactly what you did, and it's potentially hazardous because the Windows installer only modifies the MBR, not the GPT. If you delete a Windows partition from Linux, it would have deleted it from the GPT. So you may very well now have an MBR and GPT that do not at all agree about what is located where on your hard drive. It could take hours or months before this discrepancy turns into a problem.

Please share your GPT and MBR using the following commands:

sudo gpt -r -vv show disk0

sudo fdisk /dev/disk0

I will try to explain it better. Once the W7 installation process reached the point of selecting the target partition, I deleted the one created by the Bootcamp assistant and created a new one. Then the installer created two partitions, the leadinng one with 100MB and holding the boot stuff. I did this on Feb-2010 and everything has been working fine till I used Disk Utility to reduce the size of the Mac partition. As you pointed out, the way I did it probably create a MBR-GPT discrepancy that finally caused all the mess.

The data you requested.

$ sudo gpt -r -vv show disk0

gpt show: disk0: mediasize=500107862016; sectorsize=512; blocks=976773168

gpt show: disk0: Suspicious MBR at sector 0

gpt show: disk0: Pri GPT at sector 1

gpt show: disk0: Sec GPT at sector 976773167

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 738322392 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

738732032 204800 3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

738936832 237834239 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

976771071 2064

976773135 32 Sec GPT table

976773167 1 Sec GPT header

$ sudo fdisk /dev/disk0

Disk: /dev/disk0 geometry: 60801/255/63 [976773168 sectors]

Signature: 0xAA55

Starting Ending

#: id cyl hd sec - cyl hd sec [ start - size]

------------------------------------------------------------------------

1: EE 0 0 2 - 25 127 14 [ 1 - 409639] <Unknown ID>

2: AF 25 127 15 - 1023 254 63 [ 409640 - 738322392] HFS+

*3: 07 1023 254 63 - 1023 254 63 [ 738732032 - 204800] HPFS/QNX/AUX

4: 07 1023 254 63 - 1023 254 63 [ 738936832 - 237834239] HPFS/QNX/AUX

Do you think that this configuration is ok to try resizing the partitions again? Any advice or remarks on doing this? (I have a backup of the W7 partition and 292GB available on the Mac partition)

Let me thank you again your efforts to solve our problems.

The GPT and MBR agree with each other exactly. I see no problem, although I'm unsure how the GPT was updated to reflect the MBR, since the Windows installer would have only added entries to the MBR, not the GPT. In any case, it looks fine right now.

everything has been working fine till I used Disk Utility to reduce the size of the Mac partition

I don't understand what this means: 1.) Why were you reducing the size of the Mac partition? 2.) How are things no longer working?

Do you think that this configuration is ok to try resizing the partitions again? Any advice or remarks on doing this?

Yes, you need to leave things alone. MBR only supports four partitions maximum, and presently you have four partitions. By resizing one of them, you imply you're adding a fifth partition for some purpose. While that fifth partition can exist in the GPT just fine, there's no corresponding place for it in the MBR, in the way Apple's tools create hybrid MBRs. When others have tried adding a fifth partition, the hybrid MBR is blown away in favor of a conventional single entry protective MBR, which in turn renders Windows unbootable.