I've got a triple boot system on my Early 2013 Mac Book Pro: OS X, Windows 7 and Ubuntu. I'm using rEFInd as my boot manager. My Windows install boots using legacy BIOS boot, and OS X and Ubuntu boot with native EFI boot.
Everything has been working until I updated to OS X Yosemite. That broke my Windows:
"No bootable device — insert boot disk and press any key"
I guess I should've backed the boot sector up before updating, but it's too late now! Since the Windows boots in BIOS mode, it reads the hybrid MBR and indeed, the Windows partition was not flagged as bootable. After I flagged it bootable with fdisk, the message changed to:
"Missing operating system"
I have checked the MBR with fdisk, and GPT with gdisk that and are indeed compatible and in sync. After hours of googling and trying everything, I finally realised what the problem was:
I had some weeks earlier resized the Windows partition, by shrinking the OS X partition in OS X, and then, using a certain Windows software, growing the Windows partition to accommodate the new free space that now lied before the Windows partition. It now seems that that program updated ONLY MBR: from GPT viewpoint there is some unpartitioned space before the Windows partition, and from MBR viewpoint that space is used by Windows.
However, when installing Yosemite, it synced the hybrid MBR to comply with the GPT, marking the upper section of the Windows partition as free space. That "free space", of course contains the Windows bootloader and a bunch of data!
My question is, is there any way to scan the seemingly unpartitioned portion of the disk, and determine the first sector of the Windows partition? I guess that is possible, but I need the right tools for that.
For information, here is my GPT data:
Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 731723959 348.7 GiB AF05 Macintosh HD
3 731723960 732993495 619.9 MiB AB00 Recovery HD
4 799528960 906948607 51.2 GiB 0700 WINDOWS 1
5 906948608 977104895 33.5 GiB 0700 UBUNTU
and the data from protective/hybrid MBR:
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] <Unknown ID>
2: AC 1023 254 63 - 1023 254 63 [ 409640 - 731314320] <Unknown ID>
3: AB 1023 254 63 - 1023 254 63 [ 731723960 - 1269536] Darwin Boot
*4: 0C 1023 254 63 - 1023 254 63 [ 732993496 - 173955112] Win95 FAT32L
Note that there is a 66535465 sector, 31.7 GiB gap before the 51.2 GiB Windows partition. When Windows worked, it saw its partition as roughly 80 GiB partition. So, the "real" start of that Windows partition lies somewhere inisde that gap. How to scan it out?
Best Answer
I'll post this as an answer, even though it didn't fix my problem – this was a lost case in the end. Aftermath: I dd'ed a backup of the Windows partition to my OS X partition:
Now I had a 80 gig hex dump which I could examine safely. I used a hex editor to search for all kinds of metadata:
... and so on. But without success. I was able to find all kinds of data from the dump, but all the metadata, including the boot record (the first sector of the volume), the $Boot file (the first 15 sectors after the boot record), the $MFT file which keeps record of all the files on the file system, were gone.
The thing that baffles me that I couldn't even find $MFTMirr file, which is the backup file of the metadata files and stored halfway of the volume.
I was able to find a backup of the boot sector from its standard location, the last sector of the volume. However, the data was old, from the era before resizing the volume. The boot sector has stored the offset of the $MFT file metadata file, but inspecting the references was moot, there was nothing of value there.
In the end, I concluded that the volume was totally borked. The moral of the story? Hybrid Master Boot Record is evil. Also, it seems that the program that resized the volume did a subpar job, failing to update some of the metadata.