Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
The obvious question would be: why (since they're your CD's), you can't just re-run the dd with the proper device?
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
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?
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
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?
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?
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.
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
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.
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.
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.
@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. :/
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.
Since dd does a byte level copy it shouldn't be representing an iso file anyways.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.