Fixing boot camp after a possible dd error

[ranmakun]

Hi all, hope this is an appropriate forum for this question.

 

The situation:

 

boot computer

hold option

choose the OS (mac) (windows)

booting in to osx is fine, booting in to windows isnt.

 

 

The problem is, it has been a while (say, 4 months) since I have booted in to windows(vista). I have been using it in VMWare, so I'm not 100% sure what has caused the issue. Of course, I dont know when it went bad, since VMWare seems to not mind whatever happened and boots windows fine. The behavior is as follows.

 

1st problem) boot in to windows, brief flashing _, then screen full of (see pic)

 

Not able to find anything on this, I booted to the windows dvd and tried the recovery bit. It didnt see the windows install, and the app to fix the mbr and boot were failing due to not being able to mess with the file system.

 

The last thing I had done is use fdisk -u /dev/rdisk0, which leaves me at

 

 

2nd problem) I now boot in to windows, and get:

 

boot0: done

boot1: error

 

All the solutions for this have seemed to require reformatting or otherwise leaving me unable to boot windows.

 

 

 

I think that this all might have happened with a bad DD command, though. I was attempting to make a HD to install OSX from, and was following(mostly) the following method. Lifehacker

 

The command was

 

sudo dd if=boot1h of=/dev/rdisk2s2 (obviously replacing it with my drive)

 

I think I might have targeted my windows partition at this point by mistake.(dont do this {censored} when you are dead tired, is the lesson here)

 

Is there a way to recover from the situation I am now in? I feel I might be in a worse position now having the error codes then I was before.

 

 

 

I also wonder if this command could have fudged things: sudo fdisk -f boot0 -u -y /dev/rdisk2

[srs5694]

A couple of preliminary questions: Is this on a real Apple Mac? (I assume yes because you mention Boot Camp.) Does your VMWare installation use the same boot partition you're trying (and failing) to use directly? (I assume no.) The answer to the first question doesn't greatly affect the below, but if VMWare and your direct boot are using the same partition, it seems unlikely that filesystem errors are the cause of the problem.

 

You need diagnostic information. I suggest you start with both the MBR partition table. You can view this with the fdisk command in a command prompt window:

 

speaker:~ rodsmith$ sudo fdisk /dev/disk2
Disk: /dev/disk2		geometry: 987/64/63 [3981312 sectors]
Signature: 0xAA55
	 Starting	   Ending
#: id  cyl  hd sec -  cyl  hd sec [	 start -	   size]
------------------------------------------------------------------------
1: EE	0   0   1 - 1023 255  63 [		 1 -	3981311] GPT
2: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused
3: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused
4: 00	0   0   0 -	0   0   0 [		 0 -		  0] unused

 

This example shows a valid protective MBR for a GPT-only disk (a USB flash drive), /dev/disk2; you'll probably use /dev/disk0. Your configuration probably requires a hybrid MBR, which will have a GPT partition, as above, along with at least one other entry for your Windows partition. If this isn't the case, then you need to re-create your hybrid MBR setup. There may be an option in Boot Camp to do this (I don't know for sure, since I've never used it); or you can use my GPT fdisk program.

 

If your MBR looks OK, then my suspicion falls on the validity of the low-level NTFS structures. For this, you'll need to look to Windows-specific emergency disk tools. If the Windows install disc can't recover the partition, then you may need to resort to third-party tools, but I'm not familiar enough with such tools to make a specific recommendation.

[ranmakun]

Disk: /dev/disk0	geometry: 38913/255/63 [625142448 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 216  45 [    409640 -  536608768] HFS+        
3: 07 1023  42  47 - 1023  80  23 [ 537280552 -   87861856] HPFS/QNX/AUX
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused  

/dev/disk0
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *320.1 GB   disk0
  1:                        EFI                         209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            274.7 GB   disk0s2
  3:       Microsoft Basic Data Vista32                 45.0 GB    disk0s3

First off, thanks for the reply and the suggestions. Above are the results of the fdisk and $diskutil list.

 

I have run the windows disk checker from the vista boot, and it found some minor stuff and repaired it - is there a tool thatg goes deeper that you might recommend? I would have no issues with going in with vista/win7 PE and trying it.

 

 

I have potential recovery recourse in WinClone, but I am worried that the bad parts will just be copied over. I also have up to date time machine backups. So it is not entirely devastating (though time consuming) to try just about anything sensible. Honestly, I'd rather gouge my eyes out then reinstall windows, all the updates, and windows dev tools... again

 

Im also intensely curious to learn more of the inner workings of the boot system, so slogging out a direct fix is really what Id like to try.

[srs5694]

Your MBR looks OK, although I note that the Mac OS partition is flagged as active, assuming that's what the asterisk next to the partition number means. (I'm not familiar enough with Mac OS's fdisk to be sure of that.) This could be an artifact of the working of your boot loader, but it's conceivable it's the source of your problem. If the latter, setting the active MBR partition to the Windows partition should fix the problem; however, it's also conceivable that doing this would render Mac OS unbootable. Thus, if you try to change this, be sure you know how to undo your change using an emergency disk of one sort or another.

 

As I said, I'm not familiar enough with Windows filesystem utilities to recommend one to use to recover a corrupted NTFS partition, if that's the source of the problem.

[ranmakun]

I think the hardest problem im having is determining if the issue is on the windows partition or the first partition which is showing up as

 

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

 

 

if anyone can help point to a definitive answer, would surely be closer to cracking this problem.

[srs5694]

The "first partition" you've identified is the EFI GPT protective partition. It's basically a "dummy" partition. It exists to signal to GPT-aware OSes that the disk is a GPT disk, not an MBR disk. You should not mess with that partition! Trust me; I've mucked with these partitions a lot in developing GPT fdisk, and OSes tend to behave strangely if you delete it, change its size, etc.

 

That said, you're using a hybrid MBR/GPT configuration, and those are flaky. See my page on hybrid MBRs for all the gory details. That's why I suggested you might need to recreate your hybrid MBR; if it's been disrupted in any way, it could cause problems. At first glance, yours appears to be OK, but I can't be positive of that.