A more reliable command for finding mounts is either 'df' or 'mount'.
For a Windows partition at disk0s5 the command to copy it to a file is something like:
sudo dd if=/dev/rdisk0s5 of=/Volumes/externaldiskname/somefolder/Windows_backup.bin bs=256k
You can use .bin or .img, both are common, and .iso will work but it's not strictly correct (I think that's for CD/DVD's based on ISO 9660); but funny enough if you give it a .iso and double click on it in OS X, Disk Utility will open and mount it as a read only "DMG" like file. So you can read the contents.
So in the above command it's important to use sudo so the command has root privilage; that you use rdisk (with r) so you're using the raw block device; that you're pointing to an external disk with enough space; and the bs=256k means a block size of 256k at a time which will make this go way faster. You get no command prompt (it seems like it's hung) for the duration of the process, at the end there's a summary that's kinda important to make sure the records in and out are the same values.
Yes. If you go back to your gpt -v -rr show output for this disk, it reports the Windows partition is 89004032 sectors, which is 45570064384 bytes. But dd was interrupted and only copied 25744375808 bytes, or 56%. The resulting file is next to useless. And it raises the question what this IO error is about. Down the rabbit hole... This is usually the result of a disk read error which means it encountered a bad sector.
In terminal, type
and report the results. It might be long. You might also open Console and see if the system.log reports anything suspicious at the time this error was received.
Worth trying the command again. Try a bs=128k this time. If it's a persistent read error it'll happen again at the same point and it means you've got bigger issues going on. If it works, great. You should end up with a file that's the same size as this partition. You can delete the one that was interrupted halfway through.
Thansk for your reply! As I am a bit unsure what terminal commands I have to use to make a new hybrid MBR, copy 2 3 4 to it and make 4 bootable, I would like to ask you to list the commands step by step for me.
I hope it's not to much trouble for you and thanks in advance for your time and help! Cheers
myuser$ sudo dd if=/dev/rdisk0s5 of=/Volumes/external/directoryname/POCTOBAM.iso bs=128k
dd: /dev/rdisk0s5: Input/output error
196415+0 records in
196415+0 records out
25744506880 bytes transferred in 612.548041 secs (42028551 bytes/sec)
The target disk has given me I/O errors in other settings. The source disk has never given any I/O errors. I will choose a different target.
Oh my. This just came in:
SMARTReporter has detected an 'I/O Error' on the disk named
MtnLion1,SnoLeopard (/dev/disk0)! This is not a S.M.A.R.T. error, but repeated errors still can indicate a failing disk - please consult SMARTReporter's FAQ for recommendations how to proceed.
Full message from 'kernel.log':
Jan 25 06:58:54 Figaro71 kernel: disk0s5: I/O error.
The output of
myser$ sudo dmesg
is a bit long. Here it is. I can post it directly if you prefer. The USB power notifications are new and unprecedented. TCFigHit1 is a remote backup volume targeted by Time Machine.
The source drive is a 2.5 inch, and it is 4 years old. It might have suddenly begun to fail. Sigh
disk0s5 is is what it's complaining about and is the source; so while the USB power notifications are a problem too I'm not sure it's related. Is the only USB device the drive? I'd disconnect the hub and everything else you can and directly plug the drive into the computer. Also, I see spurious behavior like this with USB bus powered drives all the time, which is why I don't use them anymore. I only use USB enclosures with a separate power supply. Firewire has more power available so that's workable for bus powered.
Nope sorry. I've done that one a bunch of times already in this thread, the UI is interactive and very straightforward. And gdisk is well documented. If you post the result from the o and p commands from the recovery and transformation menu, I'll look at those before you commit the write, just leave gdisk running after you issue the o and p commands, post the result and leave gdisk to hang out while you wait back for a response.