Resized partition and now Windows wont boot

sudo gpt -rv show disk0

Shrinking the OS X volume itself doesn't actually cause a problem; as far as I know it correctly alters the GPT and MBR. It's adding another partition in that free space that gets people into data loss territory.

In your case, the use of Disk Utility didn't directly cause a problem, but it meant you weren't going to use a resize utility that can do the job correctly. The tools that do this right, resize HFSJ/X and NTFS, and understand MBR and GPT partition schemes.

The major complaint I have here though is less with users, and more on Apple's Disk Utlity. The tool should refuse to manipulate a Boot Camp Assistant modified disk; and only allow an option (when booted from another drive) to blow away all data. This is the behavior prescribed in their very own Technote on the subject of the protective MBR. It includes a warning of data loss: "Failure to comply with this recommendation may result in the loss of user data." And low and behold if you use Disk Utility on a Boot Camp disk, you have at a minimum, a 30% chance of ending up with data loss (efffectively - it is easily repaired with free open source command line tools, just not with any tools Apple provides).

That's a good short summary. I haven't used any of them. It'd be nice to see a comprehensive review of the three published. I have heard of problems with old versions of winclone; and likewise old (positively ancient) versions of ntfs-3g for OS X from like 5 years ago, still floating on the internet.

All of those utilities are designed to resize volumes on a drive that's in working condtion. They aren't explicitly designed to repair problems.

Christopher Murphy wrote:

That's a good short summary. I haven't used any of them. It'd be nice to see a comprehensive review of the three published. I have heard of problems with old versions of winclone; and likewise old (positively ancient) versions of ntfs-3g for OS X from like 5 years ago, still floating on the internet.

Yup, they are both still floating around and neither work safely.

iPartition will allow you to resize the Boot Camp partition, but it won't be bootable after you do.

When I have to deal with Windows on a Mac I always backup using CopyCat (Block Copy) slow but reliable.

Yeah, so whatever was the last utility to touch the disk, has made the MBR and GPT identical. So the true start and end position of the Windows volume is unknown, and not easily determined; maybe Test Disk could do that. But even if determined, the fixing of the GPT occurred after NTFS was resized, which means there's a better than even chance that the GPT rewrite stepped on the tail of NTFS and corrupted it.

So the simplest thing to do is start over. I have no way of knowing if the Winclone (what version of Winclone??) backup is good or based on a corrupt copy. And I think it's not worth the time to figure that out.

3.7 is current, but the viability of the clone is hard to determine without restoring it, which will take as long as just restoring it would. 😐

You can bust through that block copy a lot faster using dd and changing the block size, and using the raw device instead of the character device.

dd if=/dev/rdisk0s4 of=/Volumes/Backup/<nameoffile>.img bs=1m

This turns a partition into a file, with a block size of 1 MB. That's a lot faster than the default of 4KB block size. This block size only affects the rate of copy, not the resulting image. If it's named .img you can even double click on it, and it'll mount as a read only disk image. And it works for NTFS. You can also write it back to a partition so long as it's the exact same size (identical number of sectors). Useful for moving Recovery HD around, as for some reason sometimes diskutil resizevolume won't.

Christopher Murphy wrote:

You can bust through that block copy a lot faster using dd and changing the block size, and using the raw device instead of the character device.

dd if=/dev/rdisk0s4 of=/Volumes/Backup/<nameoffile>.img bs=1m

This turns a partition into a file, with a block size of 1 MB. That's a lot faster than the default of 4KB block size. This block size only affects the rate of copy, not the resulting image. If it's named .img you can even double click on it, and it'll mount as a read only disk image. And it works for NTFS. You can also write it back to a partition so long as it's the exact same size (identical number of sectors). Useful for moving Recovery HD around, as for some reason sometimes diskutil resizevolume won't.

Thanks, that is an excellent idea.

In practice if I am resorting to this it is because I have a client with data that is so important that they couldn't be bothered to back it up. Under those cirumstances (and their dime) I take as long as I need in order to convince them to back up before there is a next time.

That's the fatal flaw in this case. That Windows utility isn't MBR and GPT aware. Using it damaged the GPT, and modified only the MBR. Then the next utility comes in and corrects the GPT, possibly incorrectly, but in any case it will damage the Windows NTFS volume. And then another utlity comes in and syncs the MBR and GPT, almost certainly from GPT to MBR. If the GPT was wrong, the MBR will be wrong, but they'll be the same, look correct, but you'll get the behavior you're experiencing where Windows won't boot.

And the other thing is that Windows is extremely fussy about being moved around. NTFS is designed to be resized from the back, not the front. When moving the start point, all of the boot loader stages are rendered useless as is the BCD. So all of that stuff has to be fixed in sequence.

Hello Christopher,

I really like your suggestion using the 'dd' command for making a block copy .img file. Like Csound1, I use CopyCatX (www.subrosasoft.com) to copy a BootCamp'ed Mac OS X install (Mac OS X 10.8.4 + Windows 7 Pro SP1 x64).

I have a few quick questions for you if you don't mind.

1) If I wanted to copy the entire hard drive image (OS X + bootcamp Win7) and have a fully bootable restore, would copying the entire rdisk0 be the way to do it? e.g. dd if=/dev/rdisk0 of=/Volumes/Backup/<filename>.img bs=1m

1a) I assume [keyword here] I would need to boot from an external firewire or USB drive to do this (I have one with 10.8.4 installed with utilities) as well as the target .img file also external (could do on same drive?)

1b) I am not sure of the rdisk0 parameter -- would I need to do rdisk0s1, rdisk0s2, etc?

1b) Could the of=<...> be a network share on my NAS? I mount nfs shares in OS X via NFS (e.g. nfs://xxx.xxx.xxx.xxx/SomeShare)

I also assume that using the raw device vs. the character device is the way to capture the GPT and MBR information correctly.

Thank you (in advance)

John