Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
I have Windows 8 Pro x64 installed through Bootcamp, everything was working fine until I upgraded to Mavericks. After upgrading it didn't show in the Boot menu, Finder and in Disk Utility it was greyed-out.
I formatted and merged the 10.9 Recovery partition with Macintosh HD thinking that there was too many partitions for MBR to handle.
I think this got Windows to show in the Boot menu but every time I boot into it I get "A disk read error has occurred..." or something similar.
Maybe Mavericks' Recovery partition erased some of the Bootloader?

I really need to get the data from this partition so once I get it all I won't be too fussed.

Thanks.


Results from sudo fdisk /dev/rdisk0:

Code:
Disk: /dev/rdisk0	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 - 1269531248] HFS+        
*3: 0C 1023 254  63 - 1023 254  63 [1521211392 -  432312320] Win95 FAT32L
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused


Results from sudo gpt -r -vv show /dev/rdisk0:

Code:
gpt show: /dev/rdisk0: mediasize=1000204886016; sectorsize=512; blocks=1953525168
gpt show: /dev/rdisk0: Suspicious MBR at sector 0
gpt show: /dev/rdisk0: Pri GPT at sector 1
gpt show: /dev/rdisk0: 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  1269531248      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1269940888   251270504         
  1521211392   432312320      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1953523712        1423         
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
This is after I've installed 10.9 but could I still use those command line instructions?

No. The MBR and GPT both have identically incorrect information in them, so there are no magic bullet command line instructions. The problem is the start sector value for Windows was in the MBR, not in the GPT, and upon upgrading, the MBR was overwritten by the OS X installer. So now that starting value is unknown. It's not stored anywhere else.

Your easiest solution is to blow away the drive, reinstall, and restore from backups.

The other option is to use testdisk to search for possible valid NTFS volumes. If one is found, the correct start and end sector values can be plugged into gdisk to correct the GPT. And then also using gdisk, you can create a new hybrid MBR from the now corrected GPT. By doing both things, Windows files will be visible once again in the OS X Finder, as well as being able to boot Windows.
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
Thanks for your help! I might try testdisk later on. I'll report back how it goes.
 
Last edited:

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
This is what I got with test disk:

Code:
Disk /dev/disk0 - 1000 GB / 931 GiB - 1953525168 sectors (RO)
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 P EFI System                    40     409639     409600 [EFI System Partition]
 2 P Mac HFS                   409640 1269940887 1269531248 [Customer]
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
 3 P MS Data               1521211392 1953523711  432312320 [BOOTCAMP] [BOOTCAMP]
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
Code:
 3 P MS Data               1521211392 1953523711  432312320 [BOOTCAMP] [BOOTCAMP]

There's an option P to "list files" - maybe you have to choose quick scan first, I forget. You need to use arrow keys to highlight this option, then click P to list files. If it shows files/folders, then that's the correct entry. If it says the file system is damaged, that's not the correct entry.

You really need to do the scan, or chances are this entry it's showing you is bogus. By default it shows you entries based on the partition map, which we already know is wrong. We need it to scan for NTFS superblock information.

Once you're able to list files, note the start and end sector values. Now you can repair this in gdisk by deleting the current wrong partition 4 entry, creating a new partition 4 entry with the test disk numbers as the first and last sector values in gdisk when prompted; and then also when prompted, you need to use 0700 for the partition type code.

When you write out this partition from gdisk using the w command, reboot. Now it should mount ready only in the OS X Finder. I suggest you do a back up while you still can if you don't have one. Then you'll go back to gdisk and create a new hybrid MBR, adding partitions 2 3 4 to it; put EFI GPT in the 1st MBR entry; use the default hex/type code for each partition my just hitting return; and do not set the bootflag on any partition other than 4.
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
It shows two MS Data:


Code:
Disk /dev/disk0 - 1000 GB / 931 GiB - 1953525168 sectors (RO)
     Partition               Start        End    Size in sectors
 P EFI System                    40     409639     409600 [EFI]
 P Mac HFS                   409640 1269940887 1269531248
 P Mac HFS               1271253171 1910296193  639043023
 P MS Data               1923718516 1923721395       2880 [CDBOOT]
>P MS Data               1924670340 1924673219       2880
 P Mac HFS               1952255592 1953525127    1269536

They both contain files, one more than the other. They look to be like the bootloader?

Code:
   P MS Data               1923718516 1923721395       2880 [CDBOOT]
Directory /

>-rwxr-xr-x     0     0      2048 23-Apr-1999 23:22 JO.SYS
 -rwxr-xr-x     0     0     35330 23-Apr-1999 23:22 ASPI2DOS.SYS
 -rwxr-xr-x     0     0     14386 23-Apr-1999 23:22 ASPI4DOS.SYS
 -rwxr-xr-x     0     0     37564 23-Apr-1999 23:22 ASPI8DOS.SYS
 -rwxr-xr-x     0     0     40792 23-Apr-1999 23:22 ASPI8U2.SYS
 -rwxr-xr-x     0     0     29620 23-Apr-1999 23:22 ASPICD.SYS
 -rwxr-xr-x     0     0       462 23-Apr-1999 23:22 AUTOEXEC.BAT
 -rwxr-xr-x     0     0     21971 23-Apr-1999 23:22 BTCDROM.SYS
 -rwxr-xr-x     0     0     30955 23-Apr-1999 23:22 BTDOSM.SYS
 -rwxr-xr-x     0     0     93890 23-Apr-1999 23:22 COMMAND.COM
 -rwxr-xr-x     0     0       851 23-Apr-1999 23:22 CONFIG.SYS
 -rwxr-xr-x     0     0    272206 23-Apr-1999 23:22 EBD.CAB
 -rwxr-xr-x     0     0     93242 23-Apr-1999 23:22 EXTRACT.EXE
 -rwxr-xr-x     0     0     63916 23-Apr-1999 23:22 FDISK.EXE
                                                   Next

Code:
  P MS Data               1924670340 1924673219       2880
Directory /

>-rwxr-xr-x     0     0       136  3-Apr-1998 14:34 AUTOEXEC.BAT
 -rwxr-xr-x     0     0       521  3-Apr-1998 14:27 CONFIG.SYS
 -rwxr-xr-x     0     0         8  3-Apr-1998 15:44 MSDOS.SYS
[COLOR="Red"] -rwxr-xr-x     0     0         8  3-Apr-1998 15:44 ~0xx.tmp[/COLOR]
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
1269940888 start of "bogus" free space in the GPT
+ 1269535 size of deleted recovery hd
--------------
1271210423 approximate start of the Windows volume

The closest thing to this from your testdisk results listing is:

Mac HFS 1271253171 1910296193 639043023

So it was either erased at some point, and that's why it has HFS superblocks instead of NTFS. Or testdisk is confused. You could try selecting that and "list files" to see what's in there.
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
It just returns: Support for this filesystem hasn't been enable during compilation.
It might be corrupted?
 
Last edited:

murphychris

macrumors 6502a
Mar 19, 2012
661
2
It just returns: Support for this filesystem hasn't been enable during compilation.

So it literally thinks it's HFS+. Recompiling your own copy of testdisk is unlikely to be very revealing because what you want isn't on an HFS+ volume. If the Windows volume has been reformatted, it's toast so no point in going down this path.

You could create a new partition #4 with sector values in between partitions 3 and 4 and look for the NTFS header information manually. This is quite tedious. You're way outside the help of testdisk with this method. If the disk has had more than one NTFS volume created on it since it was last completely zero'd, you will find multiple NTFS headers and you won't know whether it's valid or not without trying it. And by trying it, I mean, you'll have to plug in the start sector value which I think is 2 sectors before the NTFS volume header, and then guess at the end sector. And then you'll need a copy of ntfs-3g on a linux live cd, or built from Macports with XCode, so that it can get you some information on the superblock from which to better estimate the actual end of the NTFS volume.

Tedious. I've done it twice before. It took hours. So again you're better off blowing away this disk, and starting from scratch, restoring from backups. That will take way way way less time.
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
Thanks for your help, I really appreciate it.
I'll decide what do in the morning. I think I might go ahead and create a new partition though. There has only been one NTFS partition on this disk anyway.
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
Thanks for your help, I really appreciate it.
I'll decide what do in the morning. I think I might go ahead and create a new partition though. There has only been one NTFS partition on this disk anyway.

Create the start sector as 1271210423 and end 1521211392, make the type code 0700. I also suggest giving the partition a name with the c command so that it's easier to find in the next step. Something like whoknows. Something obvious. Then use w to write out the new partition table. It may not be necessary but I suggest rebooting to make sure the kernel gets the updated partition map.

Then use:
diskutil list
You need to look for this "whoknows" partition and what node it correlates to, something like disk0s3 or disk0s4.

dd if=/dev/diskXsY | hexdump -C | grep -i ntfs

X= the number of the disk from diskutil list above
Y= the number of the slice/partition from diskutil above

So this command will read in sectors from just this new partition, convert it into hex and ASCI text, and filter it for ntfs.

If the partition starts precisely where the NTFS volume starts, you'd get a first line reply of:

000000000 eb 51 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 | .R.NTFS .....|

But this phony partition probably won't exactly correlate with the start of the NTFS volume. It will be offset by a number of bytes, noted by the first colum which won't actually be zeros. It'll be a byte offset from the start of the partition. So you'll have to take this hex value, get decimal from it, divide it by 512 to get sectors, and then add the sectors to the start value of this partition. That'll be the true start.

Of course, you have a bad partition in your way, which is your current partition 3. I'd deal with this only after you have all the suspect starts by searching the entire phony partition and save this information. Then remove the bogus 3rd partition and the phony new 4th partition before creating the good one.

It's reasonable to fix the last sector of this new Windows partition as the current last sector for the 3rd partition which is 1953523711. I'd leave that alone until there's a reason to change it, which comes after you have success with ntfs-3g. Once you have the new Windows partition (at least a proposed one if you find more than one NTFS instance with the dd hexdump grep command) created, saved from gdisk and rebootd, you'll use the ntfsinfo -m /dev/diskXsY command again - keeping in mind that Y number is probably different than before. So use diskutil list again to make sure you've got the right one, it should be disk0s3 is my guess.

If ntfsinfo -m finds valid mft data, 99% of the work is done. It'll give you cluster size and the volume size in clusters. So from that you can figure out how big the volume actually should be. As long as your partition is as big or bigger than the volume, you're fine. You can use ntfsresize to make it a perfect fit and then have Windows chkdsk fix the rest.
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
Thanks, I must seem very stupid. I don't know what I'd do without you.

No. It's not like anyone else is brave enough to attempt this. And anyway you'd live you'd just reformat the disk and suffer whatever data loss. So make sure you initiate a good backup+restore policy after all of this!
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
No. It's not like anyone else is brave enough to attempt this. And anyway you'd live you'd just reformat the disk and suffer whatever data loss. So make sure you initiate a good backup+restore policy after all of this!

Thanks! The irony is that I was going to copy over most of my data to OS X and onto an external hard drive after upgrading to 10.9 .
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
Create the start sector as 1271210423 and end 1521211392, make the type code 0700.

Sorry for bothering you again, gdisk won't let me create a new partition with those start and end sectors. Should I let it default?
The default start sector is: 1269940888
The default end sector is: 1521211391
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
Sorry for bothering you again, gdisk won't let me create a new partition with those start and end sectors. Should I let it default?
The default start sector is: 1269940888
The default end sector is: 1521211391

No. That will not work. The numbers must be exactly correct. Go to the experts menu and set the sector alignment value to 1 and now it will let you enter those values in.

The thing is, I'm suspicious of this start value you have, because it's not divisible by 2048, therefore it's not 1MB aligned. So where did you find this value?

----------

No. That will not work. The numbers must be exactly correct. Go to the experts menu and set the sector alignment value to 1 and now it will let you enter those values in.

The thing is, I'm suspicious of this start value you have, because it's not divisible by 2048, therefore it's not 1MB aligned. So where did you find this value?

Oh right nevermind. This is the guessing part. So it's obviously the wrong value but we have to start somewhere. With so many messages about this problem I frequently get confused.

So yeah create this partition with alignment value of 1 and then you can run the dd command to search for the NTFS header. When you get a hit, the value on the far left is a hex value and represents the offset from the start sector of the partition you're searching. The start sector is in decimal. So you have to do conversions before you add the offset to the partition start sector value. But once you do that conversion and addition you'll have the correct start value and you can remake this partition with correct values. The correct start value probably will be 2048 divisible, so far that's what I've seen is the case for Windows partitions anyway.
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
I got the values from gdisk. After setting the sector alignment to 1 I still can only enter up to 1521211391.

OH right. Partition 3 is in the way and starts at 1521211392. And we don't need to search anything in partition 3 anyway. New plan.

Create partition 4 with a start of 1269940888, and end at the default which should be 1521211391. And then you'll dd+hexdump+grep that partition which should be disk0s4 but you'll have to check.
 

ihuman:D

macrumors 6502a
Original poster
Jul 11, 2012
925
1
Ireland
This is from the new partition:
Code:
4d3d93a0  00 00 4c 01 4e 74 46 73  43 6f 6e 74 72 6f 6c 46  |..L.NtFsControlF|

Just out of curiosity I ran it on the "real" Bootcamp partition:
Code:
00000000  eb 52 90 4e 54 46 53 20  20 20 20 00 02 08 00 00  |.R.NTFS    .....|
 

murphychris

macrumors 6502a
Mar 19, 2012
661
2
This is from the new partition:
Code:
4d3d93a0  00 00 4c 01 4e 74 46 73  43 6f 6e 74 72 6f 6c 46  |..L.NtFsControlF|

That doesn't look like the correct header. And it's way deep in that partition which also doesn't seem right.

Just out of curiosity I ran it on the "real" Bootcamp partition:
Code:
00000000  eb 52 90 4e 54 46 53 20  20 20 20 00 02 08 00 00  |.R.NTFS    .....|

That's probably expected because I don't think that header is erased. Are you sure the resize grow of the NTFS volume was successful? It was originally what size and was grown to what size?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.