How to recover Bootcamp NTFS Partition? - Page 6

srs5694 · Dec 9, 2012, 10:14 AM

I'm Rod Smith, the author of gdisk. Chris Murphy e-mailed me about this thread, so I'm replying.

The easy (but expensive) solution is to do as Chris suggests: Send the drive off to a specialist data-recovery firm. Unfortunately, I don't have any recommendations, since I've never dealt with such firms myself.

If you can't afford that or if you want to try to do more yourself, I have an idea of what you could do:

Do a low-level backup of the disk. You'll need a spare disk that's at least as large as the one you've got. In OS X, the command "sudo dd if=/dev/disk0 of=/dev/disk1" will do the trick -- but be sure to specify the correct disk devices! Your disk is currently /dev/disk0, but its number could change when you attach another disk, depending on how you do it. If you get the if= (input) and of= (output) options wrong, your backup attempt will destroy all your data, beyond any hope of recovery. Thus, this step is very dangerous -- but it's also an important means of recovery should things go badly wrong in subsequent steps.
Make a hardcopy printout of the gdisk output you've posted to this thread. This will help you recover should you accidentally trash your partitions.
Launch gdisk on your disk.
Delete the two clearly bogus partitions 61 and 62 by using the "d" command.
Type "r" to enter the recovery & transformation menu.
Type "h" to create a new hybrid MBR. Tell it to enter only partition #4, to place the 0xEE partition first, to give it a type code of 07 (which should be the default), to set the bootable flag, and to not create an additional protective partition.
Type "w" to save your changes.

If you're very lucky, Windows will become bootable again, or at the very least, you'll be able to use Windows recovery tools on a bootable CD or USB drive to view the contents of the partition, back up your critical data, and repair the installation.

I do have another idea for more radical data recovery methods, but the procedure is very risky and involves enough decision points that trying to describe it in a Web forum is not practical. Basically, it involves using TestDisk on a Linux emergency disc to recover your lost partition, even if it's been moved or resized.

I'll also say this: I don't know what caused the problem, but I suspect one of two things:

There may have been multiple problems over time that led up to the catastrophic failure. I say this because you've got damage to both the start of the disk and to the end of the disk. Very few simple errors would cause such a pattern, and most of those that would are bugs in GPT partitioning tools, which you didn't mention using. Many tools and OSes ignore problems to the backup GPT data, so that problem could have sat there for a long time without your noticing it.
One of the few things that might write to the start and end of the disk that is not a GPT tool is various types of low-level software for BIOS computers, such as boot loaders, disk encryption software, and viruses. These programs may try to install themselves in the MBR and the area immediately after it (where the primary GPT data resides), and perhaps in unpartitioned space at the end of the disk (where the GPT backup data resides). (Note that these areas are "unpartitioned" in the MBR scheme, but they are allocated in GPT. Windows only uses the MBR side of a hybrid MBR disk, though, so such programs would ignore the GPT allocations.) Thus, if you were installing such a program -- even unknowingly, as would be the case for a virus -- that might explain the problem. It could also explain the crash, if the installer did something wrong. If this explanation is correct, it's important that you identify the offending software as soon as you recover your system. Removing it, if it's permanently installed itself, could be tricky, since such a removal might just damage your partition table again. If it was in the process of installing itself and it didn't complete the job, then deleting the installer and whatever files it installed should be adequate protection.

Good luck with your recovery!

murphychris · Dec 9, 2012, 11:20 AM

Quote:

Originally Posted by Hubriz70

One last question...any idea why no CDs are being read by the unit?

No idea. That shouldn't be related to what's going on.

Quote:

There is some good partition recovery software I would like to try.

If it doesn't *explicitly* support "hybrid MBRs" in particular the unique kind of MBR and GPT Apple is using, it will dig you into a deeper hole. The only tool I ever trust for these scenarios is GPT fdisk (gdisk).

murphychris · Dec 9, 2012, 11:35 AM

I agree with everything in Rod's post. But I have a couple additions to make to the dd command: you ought to be booted from another disk for dd to correctly sector copy a whole disk. If any volume on the source disk is mounted, as the sectors are being copied at the start of the volume, the live OS is making changes to the file system. So you get a copy of a file system that's out of sync with itself. Every single time I've done this, HFS+ gets pretty irritated. Since the Windows volume isn't going to be mounted, it wouldn't negatively affect the Windows data.

Also, dd can sector copy a disk to a disk, or a disk to a file. e.g.
dd if=/dev/rdisk0 of=/Volumes/CrazyHD/DifficultHD.bin

The destination file system doesn't matter.

Disk Utility can be made to do a block copy if you boot from a different disk than the source, but it's been so long since I've done it, I'd have to defer to someone else on specifics.

Once you've done this backup, you can get more aggressive with your self-recovery attempts. But until then, you're continuing to court disaster.

ub1quitous · 02:59 PM

Christopher,

I just stumbled across this thread after countless months of trying to figure out WHAT exactly happened to my laptop. Similar situation as everyone else; I was playing a game on my Windows 7 partition when out of nowhere I received a blue error message proceeded by a hard shut down. Once I turn my laptop back on, there is no further boot option for Windows and under DiskUtil, my partition is greyed out and renamed like the OP. My code appears similar but I am copying it anyways since I have absolutely zero idea what any of it means. If you would be willing to help me, I would be more than happy to PayPal you a donation! Here are the results:

Code:

gpt show: disk0: mediasize=750156374016; sectorsize=512; blocks=1465149168
gpt show: disk0: Suspicious MBR at sector 0
gpt show: disk0: Bad CRC in GPT table at sector 2
       start        size  index  contents
           0           1         MBR
           1      409639         
      409640  1062499968      3  MBR part 175
  1062909608     1269536      4  MBR part 171
  1064179144   400970024

These are the results for

Code:

 sudo fdisk /dev/disk0

Code:

Disk: /dev/disk0	geometry: 91201/255/63 [1465149168 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
 2: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 3: AF 1023 254  63 - 1023 254  63 [    409640 - 1062499968] HFS+        
 4: AB 1023 254  63 - 1023 254  63 [1062909608 -    1269536] Darwin Boot

And

Code:

 "sudo gdisk -l /dev/disk0"

Code:

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer:

I also used TestDisk to analyze the sectors and I can see my Windows directories when exploring the 4th section. I am terribly sorry that my skills are limited in regards to this, but I just don't really know what to do after this. If I choose option 2 and try to repair (r), it tells me that the size is too large and needs to be resized. How are things looking on my end and what should be the next step?

Thank you very much and I hope to hear a reply back!

EDIT: I also wanted to include that my main priority is having Windows boot-up again and not necessarily data recovery. My important data are on the OSX side of the drive and the Windows partition is used for applications. If I am able to restore Windows enough to boot into it, it would be godsend. I am not tech savvy enough to even attempt to wipe the drive/partitions completely and start over. It took nearly 2 weeks to sadly figure out how to install Win7 from Lion and Boot Camp. This is a nightmare!

ub1quitous · Dec 9, 2012, 02:58 PM

If I select "2" for GPT in the recovery process, this is the error I receive:

Code:

 Warning! Secondary partition table overlaps the last partition by
9002440836584669493 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/disk0: 1465149168 sectors, 698.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5221CE1A-61FF-4E52-A41E-DA75B72704F6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1465149134
Partitions will be aligned on 8-sector boundaries
Total free space is 2317 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640      1062909607   506.6 GiB   AF00  Customer
   3      1062909608      1064179143   619.9 MiB   AB00  Recovery HD
   4      1064179712      1465147391   191.2 GiB   0700  BOOTCAMP
  57  16177792531902366089  9002440838049818627   4.9 ZiB     FFFF  ⶾ᎛糟鮏0狑餀䑱ﾀ歬섾Ｆ塇븀弖ꓧૐ墯픆
  58  9024114456867150270  4785357088958439475   6.2 ZiB     FFFF  墉晸Ή곑惿拇䷫璈馆菌숏¯靟촓ӝ垬꧹✬

murphychris · Dec 9, 2012, 05:33 PM

Quote:

Originally Posted by ub1quitous

If I select "2" for GPT in the recovery process, this is the error I receive:

You should only proceed if you have backups. In any case, you need to delete partitions 57 and 58, they are bogus. Then create a new hybrid MBR, adding partitions 2 3 4, flagging 4 as bootable.

srs5694 · Dec 9, 2012, 05:42 PM

Hubriz70 and ub1quitous,

The odd similarities between your two cases make me think that there's a common cause and that it's not just some random corruption or series of smaller errors aggregating into a catastrophic failure. Key (and peculiar) similarities include the blanking out of the 1st partition slot in the MBR while moving the 0xEE partition to the second slot and the appearance of two clearly-bogus new GPT partitions about mid-way through the main partition table. If it were random data errors, I wouldn't expect to see just two bogus partitions in roughly the same place on two disks; I'd expect random corruption, possibly including trashing the real partition data or something that completely fills the partition table (similar to the backup partition table that Hubriz70 posted).

Some possibilities of things that might cause this that spring to mind include the following:

A virus (perhaps a new one) that's infected both of your systems and that happens to be trashing the GPT data when it tries to write part of itself to an "unallocated" (from a Windows/MBR view) part of the disk.
A legitimate utility that's doing the same thing. Some boot loaders, disk-compression software, and similar low-level disk utilities do this. Even an upgrade to software that used to work might be a cause.
A tool for pirating Windows might do something similar, although I'm not very familiar with the details of such tools. Windows 8 happens to be pretty cheap right now, so it's a good time to go legit if you're using pirated software.

I recommend the two of you compare notes to try to find a commonality in what sorts of Windows software you're running. I'd say that a virus scan is in order, too, but of course you won't be able to do that until you recover your installations, at least to the point where you can use a Windows emergency system to access the filesystem.

ub1quitous · Dec 9, 2012, 06:05 PM

Thank you guys for the reply and caring enough to respond to a newbie like me. Unfortunately, I just don't think I have the skills to recreate the partitions and make a hybrid MBR. I went ahead to back up my data and tried to boot into recovery mode to do a factory reset but now that's even not working. I am receiving this error when trying to erase the greyed out windows partition:

"volume erase failed couldn't modify partition map"

I also tried to erase both partitions and make 1 and its still locked. Should I take my laptop to the Apple store at this point? I have been googling around but not having any luck. I really can't afford to let Apple take it away for a few weeks to figure out the GPT and MBR are completely messed up! Thanks again.

murphychris · Dec 9, 2012, 06:14 PM

Quote:

Originally Posted by srs5694

Hubriz70 and ub1quitous,

The odd similarities between your two cases make me think that there's a common cause and that it's not just some random corruption

Are you noticing that the GPT partition name for the AF00 (OS X JHFS+) partition in both cases is "Customer" ? What are the odds of this?

murphychris · Dec 9, 2012, 06:24 PM

Quote:

Originally Posted by ub1quitous

I also tried to erase both partitions and make 1 and its still locked. Should I take my laptop to the Apple store at this point?

I really wish Apple included smartmontools by default with OS X. Bad form that they don't. And I also wish there were maintained binaries for OS X, unfortunately it has to be done through Macports and compiled which is a total PITA.

If you're prepared to totally obliterate the partitions on your drive, and thus lose all access to the data on the drive, you can try this:

Code:

sudo dd if=/dev/zero of=/dev/rdisk0 count=40

That will zero the MBR and the main GPT on any disk. While the typical GPT and MBR are just the first 4 sectors, the count of 40 nukes all sectors Apple reserves for the main GPT and MBR.

To delete the backup GPT is disk specific. On your disk it's

Code:

sudo dd if=/dev/zero of=/dev/rdisk0 seek=1465149134

I'm getting this value from gdisk's info on the disk: "last usable sector is 1465149134". While this zeros 34 sectors, more than necessary, it's fast, and easy since it doesn't require doing any math to actually zero only the backup GPT sectors.

ub1quitous · Dec 9, 2012, 07:12 PM

Chris, I've never encountered someone so helpful on the Internet. Thanks, a lot. I called Apple Care before reading what you wrote and they had absolutely no clue what to do. If I type these two prompts, will I be able to go into recovery mode with command + r and reinstall lion? Or will this allow me to repartition the drive into a single partition? Again, I can't thank you enough for all of your help. I've learned more about partition structures in a day than I ever wanted to know for a life time ;P

murphychris · Dec 9, 2012, 08:53 PM

Quote:

Originally Posted by ub1quitous

If I type these two prompts, will I be able to go into recovery mode with command + r and reinstall lion?

No. As I said it will obliterate the partition information on the drive, which is needed to find the Recovery partition. If you have a relatively new Mac, you can use the boot menu at startup to connect to a network and download Lion and install it from scratch that way. Otherwise you need to create a Lion recovery USB stick.

http://support.apple.com/kb/HT4848
http://support.apple.com/kb/DL1433

-lupo- · Jan 26, 2013, 06:00 PM

Hello,

I have a problem on my unibody MBP and the best entry I found in google was this thread here. I am quite impressed by the help given by murphychris. So here I am...

I had installed Windows 7 on a 32 or 64GB partition (I can't rememeber) back in 2009. At the end of 2011, this was not enough anymore, so I tried to resize the Bootcamp partition in OS X. This did not work, so I took the WinClone route and copied my Windows install, made a fresh install of OS X, then using Bootcamp I creted a 150GB partition and deflated my WinClone file there. This worked flawlessy until I upgraded to 10.8, 2 weeks ago. Since then I cannot boot under windows anymore.

I see the bootcamp partition in my finder and I can see Windows in the startup options, but after selecting windows I get the infamous BSoD with the message Unmountable_Boot_Volume.

Windows Startup Repair cannot find the Partition though, and now I'm stuck.

Here is some info:

results for

Code:

sudo fdisk /dev/disk0

Code:

Disk: /dev/disk0	geometry: 60801/255/63 [976773168 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 -  680634544] HFS+        
 3: AB 1023 254  63 - 1023 254  63 [ 681044184 -    1269544] Darwin Boot 
*4: 07 1023 254  63 - 1023 254  63 [ 682313728 -  135141376] HPFS/QNX/AUX

Results for

Code:

sudo gpt -r -vv show disk0

Code:

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  680634544      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  681044184    1269544      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  682313728  135141376      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  817455104  159318031         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header

and finally the results for

Code:

sudo gdisk -l /dev/disk0

Code:

GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.
Disk /dev/disk0: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DDE5ADF6-056B-453A-BA7D-DAB6B528AA80
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 159318037 sectors (76.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       681044183   324.6 GiB   AF00  Macintosh HD
   3       681044184       682313727   619.9 MiB   AB00  Recovery HD
   4       682313728       817455103   64.4 GiB    0700  BOOTCAMP

If I'm interpreting this the right way the GPT and the MBR seem to be both all right; but I'm still a noob and maybe I don't understand everything I'm seeing.
I think there's something off in the last line in the output of gdisk; it shows only 64GB, I'm quite sure it should show more. Under finder the bootcamp partition seems to have 150GB, and I remember doing so in Bootcamp.

murphychris · Jan 26, 2013, 06:46 PM

@-lupo-

OK so I think this is not too bad actually. But it definitely needs to be fixed. I would not boot Windows off the BOOTCAMP drive any further, to avoid causing more problems, until this is fixed.

The BSOD means this is not a boot loader problem, like everyone else was experiencing. In your case, you're getting all the way to the kernel, and then it's panicking for some reason. From what you say, it sounds like the NTFS volume is reporting that it's 150GB in size, but very clearly both the MBR and GPT are reporting the Windows partition is 64GB. This is likely the problem for the kernel, is that the file system is saying "data is over here" but the partition is saying "that space is for something else". So the kernel doesn't want to risk possibly damaging some other file system, based on what the partition table says, but also can't proceed farther if it doesn't access the space outside this small partition, so it panics because it's stuck with a contradiction.

Possibly Test Disk can get you out of this, but I've never used it, so I can't help you with that part. And also, I don't explicitly see that it understands hybrid MBRs. Yet there's an OS X version, which would imply it must know about hybrid MBRs.

What I would do, in order, is backup your Windows stuff from OS X using either Finder copies or Winclone. Possibly Finder copies are more reliable since it sees this volume as being 150GB. It would hopefully find all of your stuff and let it be backed up.

Next, make the Windows/Bootcamp partition bigger. As big as possible. As long as the partition is bigger than the NTFS volume, the NTFS volume can probably be resized/fixed as needed. It's unworkable to have a volume that's larger than a partition (at least, not without RAID or a logical volume manager, which aren't applicable here).

So I'm going to have you use gdisk to change the BOOTCAMP partition size. All of these changes happen in memory, not live. So don't get too freaked out over the first step which is going to be to delete the BOOTCAMP partition entry. The most important thing is to note the the starting sector value for BOOTCAMP, which is 682313728 on your disk.

Launch gdisk in interactive mode targeted at your disk: sudo gdisk /dev/disk0

Delete the 4th partition, with d <enter> 4 <enter>

Create a new partition with n <enter>, and by default it should be partition 4, accept that. And then it asks for a start sector value, and it proposes a default. That default might be 682313728, and if so, just accept it. If not, enter in 682313728. For the end sector value, it will propose a default - we have no way of knowing what the correct end sector value is; again someone with more experience with ntfsprogs might know how to get this information. But hopefully the default will be big enough (it's the entire remaining space on the disk afterall). It's fine if the partition is BIGGER than the NTFS volume, it'll just get resized later. It's not good if the partition is smaller than the NTFS volume.

So accept that change, and change the default partition type hexcode AF00 to 0700 for Windows.

Next you have to go to the Recovery/Transformation menu with r <enter>. And create a new hybrid MBR with h <enter>. Enter 2 3 4 for the first question; yes to the 2nd question. Accept all default MBR hex codes for all three partitions. Do not make partitions #2 or #3 bootable, but do make #4 bootable.

If you want, type o <enter> p <enter> and then post the results of those two which are the new hybrid MBR and the new GPT, before you write them to disk. You can just leave gdisk hanging out (hide Terminal if you want), all of these changes are in memory, they haven't been committed to disk, so they aren't going anywhere and won't negatively affect anything.

Once you're ready, you'll use w <enter> to write out the change.

If you mess up at any point, you can just control-c and it will quit gdisk and you can start over with no consequences.

After you write out the new partition, you probably shouldn't boot Windows. I think it's better to boot off the DVD, go and get to a command prompt, and manually run chkdsk on the c: volume and see what it says. If that comes up OK. Then I'd run chkdsk /f which does a more invasive check on the file system, and see what that says.

Even if there's bad news, in any case, the partition had to be fixed to proceed further. And the next step is Test Disk, which there is an OS X binary for. So that might be more helpful than what I'm more used to which is ntfsprogs from a Linux LiveCD. But even after Test Disk has fixed everything, I would be sure to look at the MBR and GPT again, and make sure every partition start and end values are the same in both MBR and GPT to avoid problems down the road.

-lupo- · Jan 27, 2013, 10:52 AM

Hi,

thanks a LOT for your help. So I used finder to copy all the important data to an external HDD and now I used gdisk with the options you told me. As for the end sector of the Bootcamp partition, it looks to have taken the available space left, so it should be good, right?

Here is what gdisk gave as output after performing the changes:

Code:

Recovery/transformation command (? for help): p
Disk /dev/disk0: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DDE5ADF6-056B-453A-BA7D-DAB6B528AA80
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 6 sectors (3.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       681044183   324.6 GiB   AF00  Macintosh HD
   3       681044184       682313727   619.9 MiB   AB00  Recovery HD
   4       682313728       976773134   140.4 GiB   0700  Microsoft basic data

If that's okay I'll write the canges to the HDD.

murphychris · Jan 27, 2013, 10:55 AM

Quote:

Originally Posted by -lupo-

If that's okay I'll write the canges to the HDD.

That's fine, but it's just the GPT. Type o <enter> and report those results also, which is the contents of the MBR.

-lupo- · Jan 27, 2013, 11:12 AM

Ehm yes, sorry... here it is

Code:

Recovery/transformation command (? for help): o

Disk size is 976773168 sectors (465.8 GiB)
MBR disk identifier: 0x00004A5B
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1       409639   primary     0xEE
   2                409640    681044183   primary     0xAF
   3             681044184    682313727   primary     0xAB
   4      *      682313728    976773134   primary     0x07

Recovery/transformation command (? for help): p
Disk /dev/disk0: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DDE5ADF6-056B-453A-BA7D-DAB6B528AA80
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 6 sectors (3.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       681044183   324.6 GiB   AF00  Macintosh HD
   3       681044184       682313727   619.9 MiB   AB00  Recovery HD
   4       682313728       976773134   140.4 GiB   0700  Microsoft basic data

Recovery/transformation command (? for help):

What is the * for in front of partition 4?

murphychris · Jan 27, 2013, 11:20 AM

Yeah that's good, write it out now.

Quote:

Originally Posted by -lupo-

What is the * for in front of partition 4?

That's the active flag (boot flag). The way BIOS boot loading works is it locates the first sector of the boot drive, loads it, executes the code in the first 440 bytes, which tells the CPU to look at which partition has an active flag and jump to that start sector and load the next stage boot loader there, and then the next stage boot loader, and so on until the kernel is loaded and running.

-lupo- · Jan 27, 2013, 11:43 AM

Quote:

Originally Posted by murphychris

Yeah that's good, write it out now.

That's the active flag (boot flag). The way BIOS boot loading works is it locates the first sector of the boot drive, loads it, executes the code in the first 440 bytes, which tells the CPU to look at which partition has an active flag and jump to that start sector and load the next stage boot loader there, and then the next stage boot loader, and so on until the kernel is loaded and running.

Ok, gotcha.

I just rebooted with the Win7 DVD and it wanted to repair the Windows Boot Manager by adding the Windows Recovery Environment option and it wouldn't let me go to a command prompt.

Then I booted in mac os and now I get an error message from NTFS-3G, telling me that the Volume /dev/rdisk0s4 has not been unmounted properly. I now can Force a mounting or I can abort. Should I uninstall NTFS-3G and use something different? I will not force the mounting as I seem to recall that I did exactly that after upgrading to os x 10.8.

murphychris · 12:45 PM

Quote:

Originally Posted by -lupo-

I just rebooted with the Win7 DVD and it wanted to repair the Windows Boot Manager by adding the Windows Recovery Environment option and it wouldn't let me go to a command prompt.

OK then what? Does it try to make any repairs?

Quote:

Should I uninstall NTFS-3G and use something different? I will not force the mounting as I seem to recall that I did exactly that after upgrading to os x 10.8.

You don't need to uninstall it, but I wouldn't force mount either. It either needs to be repaired, or it needs to be resized and repaired. Do you have any ntfs commands in Terminal? If you type ntfs<tab><tab> you should get a list of all files on the computer that begin with ntfs. I'd try:

Code:

ntfsinfo -m
ntfsfix -n
ntfsresize -c
ntfsresize -i

All four are read only commands and make no changes to the disk, which at this stage is important.

murphychris · Jan 27, 2013, 12:53 PM

OK and each one of those commands needs to be followed by /dev/disk0s4, so actually it's just these three:

Code:

ntfsinfo -m /dev/disk0s4
ntfsfix -n /dev/disk0s4
ntfsresize -i /dev/disk0s4

-lupo- · Jan 27, 2013, 03:07 PM

Quote:

Originally Posted by murphychris

OK and each one of those commands needs to be followed by /dev/disk0s4, so actually it's just these three:

Code:

ntfsinfo -m /dev/disk0s4
ntfsfix -n /dev/disk0s4
ntfsresize -i /dev/disk0s4

Ok, here it is (had to do a sudo on ntfsinfo)

Code:

ntfsinfo -m /dev/disk0s4

Code:

Volume Information 
	Name of device: /dev/disk0s4
	Device state: 11
	Volume Name: BOOTCAMP
	Volume State: 1
	Volume Version: 3.1
	Sector Size: 512
	Cluster Size: 4096
	Volume Size in Clusters: 36806911
MFT Information 
	MFT Record Size: 1024
	MFT Zone Multiplier: 1
	MFT Data Position: 24
	MFT Zone Start: 786432
	MFT Zone End: 5387295
	MFT Zone Position: 786432
	Current Position in First Data Zone: 5387295
	Current Position in Second Data Zone: 0
	LCN of Data Attribute for FILE_MFT: 786432
	FILE_MFTMirr Size: 4
	LCN of Data Attribute for File_MFTMirr: 2
	Size of Attribute Definition Table: 2560
FILE_Bitmap Information 
	FILE_Bitmap MFT Record Number: 6
	State of FILE_Bitmap Inode: 0
	Length of Attribute List: 0
	Attribute List: (null)
	Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
	Decompressed Runlist: not done yet
	Base Inode: 6
	Attribute Types: not done yet
	Attribute Name Length: 0
	Attribute State: 3
	Attribute Allocated Size: 4603904
	Attribute Data Size: 4600864
	Attribute Initialized Size: 4600864
	Attribute Compressed Size: 0
	Compression Block Size: 0
	Compression Block Size Bits: 0
	Compression Block Clusters: 0

Code:

ntfsfix -n /dev/disk0s4

Code:

ntfsfix: invalid option -- n
ntfsfix v1.13.1 (libntfs 9:0:0)

Usage: ntfsfix [options] device
    Attempt to fix an NTFS partition.

    -h, --help             Display this help
    -V, --version          Display version information

For example: ntfsfix /dev/hda6

Developers' email address: linux-ntfs-dev@lists.sf.net
Linux NTFS homepage: http://www.linux-ntfs.org

Should I try this without the -n option?

ntfsresize isn't on my system.

About my previous post: yes, windows tried a repair then and it didn't give me any error messages. I still haven't tried to boot windows though.

murphychris · Jan 27, 2013, 03:16 PM

No, do not run ntfsfix without -n yet.

-lupo- · Jan 27, 2013, 03:31 PM

Quote:

Originally Posted by murphychris

No, do not run ntfsfix without -n yet.

Ok. I forgot: I ran chkdsk fron the Win Install DVD and it seemed fine, I got no errors or whatsoever; only in the last line a notice that something couldn't be saved, but I thought that was b/c chkdsk was running from the DVD. I didn't try chkdsk /F though. Is it necessary?

murphychris · Jan 27, 2013, 03:44 PM

OK so the partition is about 4111 sectors bigger than the NTFS volume is claiming. So preferably you need ntfsresize to make this adjustment.

Otherwise it's a gamble to change the partition to match the size of the volume. I think the pad for the partition is +7. So that would make partition 4 end at sector 976769023. If you do it this way, you go back to gdisk, delete partition 4, make a new one, make the start sector 682313728, the end sector 976769023, and the partition type 07, and then make a new hybrid MBR same as before: add 2 3 4, make only 4 bootable, then write out the partitions.

That *should* work, but I'm guessing at the padding based on an 80GB virtual disk formatted as NTFS. I still think it's better to do this with ntfsresize.

That tool comes with most Linux LiveCDs, I know it does with Fedora 18 x86_64 LiveCD because I just checked.

Another way to proceed is support from Winclone if you purchased Winclone 3.7, since that's what did the original resize. And I'm pretty sure it's using ntfs-3g, the same stuff that Tuxera builds for OS X NTFS support, and the open source version is what's on the Fedora 18 x86_64 Live CD. That version is quite new, v2012.1.15

----------

Quote:

Originally Posted by -lupo-

Ok. I forgot: I ran chkdsk fron the Win Install DVD and it seemed fine, I got no errors or whatsoever; only in the last line a notice that something couldn't be saved, but I thought that was b/c chkdsk was running from the DVD. I didn't try chkdsk /F though. Is it necessary?

chkdsk /f is different and eventually it will be necessary, but I think it's better to run ntfsresize which will make the volume fit the partition correctly, and it will set a flag on the volume so that chkdsk runs correctly the next time you boot Windows (off the hard drive, not DVD). After using ntfsresize, it's best to reboot twice, Windows may even do this for you, I forget.

Dec 9, 2012, 10:14 AM	#126
srs5694 macrumors newbie Join Date: Mar 2012	I'm Rod Smith, the author of gdisk. Chris Murphy e-mailed me about this thread, so I'm replying. The easy (but expensive) solution is to do as Chris suggests: Send the drive off to a specialist data-recovery firm. Unfortunately, I don't have any recommendations, since I've never dealt with such firms myself. If you can't afford that or if you want to try to do more yourself, I have an idea of what you could do: Do a low-level backup of the disk. You'll need a spare disk that's at least as large as the one you've got. In OS X, the command "sudo dd if=/dev/disk0 of=/dev/disk1" will do the trick -- but be sure to specify the correct disk devices! Your disk is currently /dev/disk0, but its number could change when you attach another disk, depending on how you do it. If you get the if= (input) and of= (output) options wrong, your backup attempt will destroy all your data, beyond any hope of recovery. Thus, this step is very dangerous -- but it's also an important means of recovery should things go badly wrong in subsequent steps. Make a hardcopy printout of the gdisk output you've posted to this thread. This will help you recover should you accidentally trash your partitions. Launch gdisk on your disk. Delete the two clearly bogus partitions 61 and 62 by using the "d" command. Type "r" to enter the recovery & transformation menu. Type "h" to create a new hybrid MBR. Tell it to enter only partition #4, to place the 0xEE partition first, to give it a type code of 07 (which should be the default), to set the bootable flag, and to not create an additional protective partition. Type "w" to save your changes. If you're very lucky, Windows will become bootable again, or at the very least, you'll be able to use Windows recovery tools on a bootable CD or USB drive to view the contents of the partition, back up your critical data, and repair the installation. I do have another idea for more radical data recovery methods, but the procedure is very risky and involves enough decision points that trying to describe it in a Web forum is not practical. Basically, it involves using TestDisk on a Linux emergency disc to recover your lost partition, even if it's been moved or resized. I'll also say this: I don't know what caused the problem, but I suspect one of two things: There may have been multiple problems over time that led up to the catastrophic failure. I say this because you've got damage to both the start of the disk and to the end of the disk. Very few simple errors would cause such a pattern, and most of those that would are bugs in GPT partitioning tools, which you didn't mention using. Many tools and OSes ignore problems to the backup GPT data, so that problem could have sat there for a long time without your noticing it. One of the few things that might write to the start and end of the disk that is not a GPT tool is various types of low-level software for BIOS computers, such as boot loaders, disk encryption software, and viruses. These programs may try to install themselves in the MBR and the area immediately after it (where the primary GPT data resides), and perhaps in unpartitioned space at the end of the disk (where the GPT backup data resides). (Note that these areas are "unpartitioned" in the MBR scheme, but they are allocated in GPT. Windows only uses the MBR side of a hybrid MBR disk, though, so such programs would ignore the GPT allocations.) Thus, if you were installing such a program -- even unknowingly, as would be the case for a virus -- that might explain the problem. It could also explain the crash, if the installer did something wrong. If this explanation is correct, it's important that you identify the offending software as soon as you recover your system. Removing it, if it's permanently installed itself, could be tricky, since such a removal might just damage your partition table again. If it was in the process of installing itself and it didn't complete the job, then deleting the installer and whatever files it installed should be adequate protection. Good luck with your recovery!
	0

Dec 9, 2012, 11:51 AM	#129
ub1quitous macrumors newbie Join Date: Dec 2012	Christopher, I just stumbled across this thread after countless months of trying to figure out WHAT exactly happened to my laptop. Similar situation as everyone else; I was playing a game on my Windows 7 partition when out of nowhere I received a blue error message proceeded by a hard shut down. Once I turn my laptop back on, there is no further boot option for Windows and under DiskUtil, my partition is greyed out and renamed like the OP. My code appears similar but I am copying it anyways since I have absolutely zero idea what any of it means. If you would be willing to help me, I would be more than happy to PayPal you a donation! Here are the results: Code: gpt show: disk0: mediasize=750156374016; sectorsize=512; blocks=1465149168 gpt show: disk0: Suspicious MBR at sector 0 gpt show: disk0: Bad CRC in GPT table at sector 2 start size index contents 0 1 MBR 1 409639 409640 1062499968 3 MBR part 175 1062909608 1269536 4 MBR part 171 1064179144 400970024 These are the results for Code: sudo fdisk /dev/disk0 Code: Disk: /dev/disk0 geometry: 91201/255/63 [1465149168 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] ------------------------------------------------------------------------ 1: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 2: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] <Unknown ID> 3: AF 1023 254 63 - 1023 254 63 [ 409640 - 1062499968] HFS+ 4: AB 1023 254 63 - 1023 254 63 [1062909608 - 1269536] Darwin Boot And Code: "sudo gdisk -l /dev/disk0" Code: Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Caution! After loading partitions, the CRC doesn't check out! Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables. Warning! One or more CRCs don't match. You should repair the disk! Partition table scan: MBR: hybrid BSD: not present APM: not present GPT: damaged Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.) 1 - MBR 2 - GPT 3 - Create blank GPT Your answer: I also used TestDisk to analyze the sectors and I can see my Windows directories when exploring the 4th section. I am terribly sorry that my skills are limited in regards to this, but I just don't really know what to do after this. If I choose option 2 and try to repair (r), it tells me that the size is too large and needs to be resized. How are things looking on my end and what should be the next step? Thank you very much and I hope to hear a reply back! EDIT: I also wanted to include that my main priority is having Windows boot-up again and not necessarily data recovery. My important data are on the OSX side of the drive and the Windows partition is used for applications. If I am able to restore Windows enough to boot into it, it would be godsend. I am not tech savvy enough to even attempt to wipe the drive/partitions completely and start over. It took nearly 2 weeks to sadly figure out how to install Win7 from Lion and Boot Camp. This is a nightmare! Last edited by ub1quitous; Dec 9, 2012 at 02:59 PM.
	0

Dec 9, 2012, 05:42 PM	#132
srs5694 macrumors newbie Join Date: Mar 2012	Hubriz70 and ub1quitous, The odd similarities between your two cases make me think that there's a common cause and that it's not just some random corruption or series of smaller errors aggregating into a catastrophic failure. Key (and peculiar) similarities include the blanking out of the 1st partition slot in the MBR while moving the 0xEE partition to the second slot and the appearance of two clearly-bogus new GPT partitions about mid-way through the main partition table. If it were random data errors, I wouldn't expect to see just two bogus partitions in roughly the same place on two disks; I'd expect random corruption, possibly including trashing the real partition data or something that completely fills the partition table (similar to the backup partition table that Hubriz70 posted). Some possibilities of things that might cause this that spring to mind include the following: A virus (perhaps a new one) that's infected both of your systems and that happens to be trashing the GPT data when it tries to write part of itself to an "unallocated" (from a Windows/MBR view) part of the disk. A legitimate utility that's doing the same thing. Some boot loaders, disk-compression software, and similar low-level disk utilities do this. Even an upgrade to software that used to work might be a cause. A tool for pirating Windows might do something similar, although I'm not very familiar with the details of such tools. Windows 8 happens to be pretty cheap right now, so it's a good time to go legit if you're using pirated software. I recommend the two of you compare notes to try to find a commonality in what sorts of Windows software you're running. I'd say that a virus scan is in order, too, but of course you won't be able to do that until you recover your installations, at least to the point where you can use a Windows emergency system to access the filesystem.
	0

Jan 27, 2013, 12:53 PM	#146
murphychris macrumors 6502a Join Date: Mar 2012	OK and each one of those commands needs to be followed by /dev/disk0s4, so actually it's just these three: Code: ntfsinfo -m /dev/disk0s4 ntfsfix -n /dev/disk0s4 ntfsresize -i /dev/disk0s4
	0

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Dec 9, 2012, 11:35 AM	#128
murphychris macrumors 6502a Join Date: Mar 2012	I agree with everything in Rod's post. But I have a couple additions to make to the dd command: you ought to be booted from another disk for dd to correctly sector copy a whole disk. If any volume on the source disk is mounted, as the sectors are being copied at the start of the volume, the live OS is making changes to the file system. So you get a copy of a file system that's out of sync with itself. Every single time I've done this, HFS+ gets pretty irritated. Since the Windows volume isn't going to be mounted, it wouldn't negatively affect the Windows data. Also, dd can sector copy a disk to a disk, or a disk to a file. e.g. dd if=/dev/rdisk0 of=/Volumes/CrazyHD/DifficultHD.bin The destination file system doesn't matter. Disk Utility can be made to do a block copy if you boot from a different disk than the source, but it's been so long since I've done it, I'd have to defer to someone else on specifics. Once you've done this backup, you can get more aggressive with your self-recovery attempts. But until then, you're continuing to court disaster.
	0

Dec 9, 2012, 06:05 PM	#133
ub1quitous macrumors newbie Join Date: Dec 2012	Thank you guys for the reply and caring enough to respond to a newbie like me. Unfortunately, I just don't think I have the skills to recreate the partitions and make a hybrid MBR. I went ahead to back up my data and tried to boot into recovery mode to do a factory reset but now that's even not working. I am receiving this error when trying to erase the greyed out windows partition: "volume erase failed couldn't modify partition map" I also tried to erase both partitions and make 1 and its still locked. Should I take my laptop to the Apple store at this point? I have been googling around but not having any luck. I really can't afford to let Apple take it away for a few weeks to figure out the GPT and MBR are completely messed up! Thanks again.
	0

Dec 9, 2012, 07:12 PM	#136
ub1quitous macrumors newbie Join Date: Dec 2012	Chris, I've never encountered someone so helpful on the Internet. Thanks, a lot. I called Apple Care before reading what you wrote and they had absolutely no clue what to do. If I type these two prompts, will I be able to go into recovery mode with command + r and reinstall lion? Or will this allow me to repartition the drive into a single partition? Again, I can't thank you enough for all of your help. I've learned more about partition structures in a day than I ever wanted to know for a life time ;P
	0

Jan 26, 2013, 06:46 PM	#139
murphychris macrumors 6502a Join Date: Mar 2012	@-lupo- OK so I think this is not too bad actually. But it definitely needs to be fixed. I would not boot Windows off the BOOTCAMP drive any further, to avoid causing more problems, until this is fixed. The BSOD means this is not a boot loader problem, like everyone else was experiencing. In your case, you're getting all the way to the kernel, and then it's panicking for some reason. From what you say, it sounds like the NTFS volume is reporting that it's 150GB in size, but very clearly both the MBR and GPT are reporting the Windows partition is 64GB. This is likely the problem for the kernel, is that the file system is saying "data is over here" but the partition is saying "that space is for something else". So the kernel doesn't want to risk possibly damaging some other file system, based on what the partition table says, but also can't proceed farther if it doesn't access the space outside this small partition, so it panics because it's stuck with a contradiction. Possibly Test Disk can get you out of this, but I've never used it, so I can't help you with that part. And also, I don't explicitly see that it understands hybrid MBRs. Yet there's an OS X version, which would imply it must know about hybrid MBRs. What I would do, in order, is backup your Windows stuff from OS X using either Finder copies or Winclone. Possibly Finder copies are more reliable since it sees this volume as being 150GB. It would hopefully find all of your stuff and let it be backed up. Next, make the Windows/Bootcamp partition bigger. As big as possible. As long as the partition is bigger than the NTFS volume, the NTFS volume can probably be resized/fixed as needed. It's unworkable to have a volume that's larger than a partition (at least, not without RAID or a logical volume manager, which aren't applicable here). So I'm going to have you use gdisk to change the BOOTCAMP partition size. All of these changes happen in memory, not live. So don't get too freaked out over the first step which is going to be to delete the BOOTCAMP partition entry. The most important thing is to note the the starting sector value for BOOTCAMP, which is 682313728 on your disk. Launch gdisk in interactive mode targeted at your disk: sudo gdisk /dev/disk0 Delete the 4th partition, with d <enter> 4 <enter> Create a new partition with n <enter>, and by default it should be partition 4, accept that. And then it asks for a start sector value, and it proposes a default. That default might be 682313728, and if so, just accept it. If not, enter in 682313728. For the end sector value, it will propose a default - we have no way of knowing what the correct end sector value is; again someone with more experience with ntfsprogs might know how to get this information. But hopefully the default will be big enough (it's the entire remaining space on the disk afterall). It's fine if the partition is BIGGER than the NTFS volume, it'll just get resized later. It's not good if the partition is smaller than the NTFS volume. So accept that change, and change the default partition type hexcode AF00 to 0700 for Windows. Next you have to go to the Recovery/Transformation menu with r <enter>. And create a new hybrid MBR with h <enter>. Enter 2 3 4 for the first question; yes to the 2nd question. Accept all default MBR hex codes for all three partitions. Do not make partitions #2 or #3 bootable, but do make #4 bootable. If you want, type o <enter> p <enter> and then post the results of those two which are the new hybrid MBR and the new GPT, before you write them to disk. You can just leave gdisk hanging out (hide Terminal if you want), all of these changes are in memory, they haven't been committed to disk, so they aren't going anywhere and won't negatively affect anything. Once you're ready, you'll use w <enter> to write out the change. If you mess up at any point, you can just control-c and it will quit gdisk and you can start over with no consequences. After you write out the new partition, you probably shouldn't boot Windows. I think it's better to boot off the DVD, go and get to a command prompt, and manually run chkdsk on the c: volume and see what it says. If that comes up OK. Then I'd run chkdsk /f which does a more invasive check on the file system, and see what that says. Even if there's bad news, in any case, the partition had to be fixed to proceed further. And the next step is Test Disk, which there is an OS X binary for. So that might be more helpful than what I'm more used to which is ntfsprogs from a Linux LiveCD. But even after Test Disk has fixed everything, I would be sure to look at the MBR and GPT again, and make sure every partition start and end values are the same in both MBR and GPT to avoid problems down the road.
	0

Jan 27, 2013, 03:16 PM	#148
murphychris macrumors 6502a Join Date: Mar 2012	No, do not run ntfsfix without -n yet.
	0