dd with wrong source target
 

Hi Everyone,

I used dd the other day to backup some important CD's but I used /dev/sdc1 instead of /dev/cdrom and it seems something was set incorrectly. All of the images refuse to mount correctly citing a bad or unknown format. I have used a non-freeware app to treat it like a broken disk and rescue and it can see inside but will not rescue files until I pay the 100$ fee... I was wondering if the community can help me figure out how to, most likely, convert again to the correct target using linux tools. So far I've tried various combinations of dd to try and treat it as a disk image and not an iso but so far no success.

Thanks in advance!
-JV

The obvious question would be: why (since they're your CD's), you can't just re-run the dd with the proper device?

I don't understand the problem/question. If you backed up /dev/sdc1 instead of /dev/cdrom then you haven't backed up the CD so there's no data to get back, you've just backed up your hard drive partition instead.
What is the exact dd command line you used? What data is it you have lost?

The CD's were misplaced and most likely destroyed.

But from your post if you chose the wrong source then you did not back up your CDs. You can't recover the contents of a CD which you backed up by using dd to copy the contents of one hard drive to the other because that means you did not back up the CD.
What command did you run?

Yes, that's a typo, excuse. It was /dev/scd1 which is a symlink to /dev/cdrom

Even though it's a symlink I believe dd treated it not as a cd source and so it wrote in .img format. Not sure how to convert.

dd does not treat anything as a format, it just copies byte-by-byte form one place to another so it doesn't matter that you specified the "wrong" name you're still moving the same bytes.

I couldn't find any basis for that weirdness either. Ok, I'll change my question. When I copied 13 cd's using /dev/scd1 I got data with a messed up header such that linux won't mount it but yet some windows recovery apps can look inside. When I found this out and switched to /dev/cdrom everything works as you would expect. Now I have 13 messed up .iso files and need to figure out how to make into proper .iso files whether or not it's exactly figured out what went wrong.

Thx. J

dd is an odd choice to use for optical disk backup. My guess is that it could be possible that you only got track 1 of the disk or maybe track 2 only.

Might mount the iso as a loop and see what testdisk can get.

Assuming that sdc is the target of /dev/cdrom, copying sdc1 would not have copied the entire disk, and that is why it is refusing to be processed.

We need to see the actual links between /dev/cdrom and /dev/scd1... The name scd1 implies the first partition on device scd... And that could skip the header of the volume, such that it is not a complete iso - but a dump of only the first partition on the disks.

No, it doesn't. Device names and links for CD-ROM devices aren't set up that way. /dev/scd1 would normally be a link to the second CD-ROM device.

@Verbunk -
What does the file command report when you run it on your saved image files? What are the sizes of those files?

I hope they were not audio CDs. You have to use specialized software to rip tracks from those. dd can't do it.

@rknichols: The output says <name>: data. They were data CD's, mostly installers for legacy equipment which would be nearly impossible to obtain now. Some of them are CD's to boot from so I'm not enthusiastic to do a rescue and rebuild of the boot mechanism. :/

That is not encouraging. I would have expected output like, "<name>: ISO 9660 CD-ROM filesystem data ...".

Try running "dd if=one_filename | hexdump -C | head -50" and post the result. Let's see if any sense can be made from that.

Seems like it won't be of any use.
00000000 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 01 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000810 c5 13 68 2b 00 00 00 00 00 00 00 00 00 f7 00 f5 |..h+............|
00000820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000860 00 00 00 00 00 00 52 35 b8 7d 00 00 00 00 00 00 |......R5.}......|
00000870 00 00 00 f5 00 f4 00 00 00 00 00 00 00 00 00 00 |................|
00000880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000008b0 00 00 00 00 00 00 00 00 00 00 00 00 97 26 d0 56 |.............&.V|
000008c0 00 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00 |.........A......|
000008d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2d 17 |..............-.|
000008e0 2e 1b b1 48 b2 44 00 00 00 00 00 00 00 00 00 00 |...H.D..........|
000008f0 00 00 00 00 00 00 00 65 00 c2 00 e6 00 43 00 00 |.......e.....C..|
00000900 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000910 00 00 45 3c 53 75 33 2b 25 62 00 00 00 00 00 00 |..E<Su3+%b......|


Since dd does a byte level copy it shouldn't be representing an iso file anyways. It would be the raw sectors copied off. I guess I'm looking for a way to copy the copy into a reasonable container. Do you know if there is a combination of dd switches that would correctly copy the data out and wrap in an iso? I've tried to force mount as a disk and it doesn't work but that doesn't mean I had everything setup correctly.

J

Yes, it would. Copying from the raw device, as you said you did, would include all the iso9660 headers and give you an image that looked like an ISO filesystem and which you could mount with "-o loop".

I don't see anything recognizable in the data you posted. You might look a bit further into the hex dump and see if there is anything "interesting" at octal offset 08000. Absent that, I fear that recovering anything at all from those images, if they're all like that, is going to take a lot of very low-level detective work.