 | Creating an ISO file from a CD -- Via The Command Line. |  |
 Posted: Mon Mar 08, 2025 12:47 am |
 |
|
|
|
| Posted: Mon Mar 08, 2025 7:26 am |
|
|
| mmmna |
| . . . . . . . |
 |
| Status: Offline |
 |
| Joined: 21 Apr 2025 |
| Posts: 4979 |
|
| Location: Central New Hampster |
|
|
|
|
 |
|
Why not use mksiofs?
mkisofs might be better suited, when dealing with non ISO9660 CDROMs.
Curious - do the md5sums match, from after you d'l an iso, and again after you recreate the iso (per above) from a CDROM that you burned? |
|
_________________
SuSe 9.1 Pro for now |
|
|
|
| Posted: Mon Mar 08, 2025 11:49 am |
|
|
| jbsnake |
| Moderator |
 |
| Status: Offline |
|
| Joined: 02 Dec 2025 |
| Posts: 1474 |
|
| Location: Georgia |
|
|
|
|
|
|
i would also add a line to the end of that dd command
| Code: |
dd if=/dev/cdrom of=your.iso bs=32k
|
i believe it speeds up the process just a touch  |
|
|
|
|
| Posted: Mon Mar 08, 2025 12:38 pm |
|
|
| Stuka |
| Advanced Member |
|
| Status: Offline |
|
| Joined: 15 Oct 2025 |
| Posts: 958 |
|
| Location: Houston, TX |
|
|
|
|
|
|
| mmmna: since a .iso file is disk image, dd is a perfectly acceptable way to handle it. The process is analogous to the method for creating boot floppies from .img files (don't know if you've ever done this, as it's not necessary on newer hardware, but I've done it for some older boxes, and in the older days of Linux). |
|
|
|
|
| Posted: Mon Mar 08, 2025 2:51 pm |
|
|
| crouse |
| Site Admin |
 |
| Status: Offline |
|
| Joined: 16 Apr 2025 |
| Posts: 8558 |
|
| Location: Iowa |
|
|
|
|
|
|
| jbsnake wrote: | i would also add a line to the end of that dd command
| Code: |
dd if=/dev/cdrom of=your.iso bs=32k
|
i believe it speeds up the process just a touch |
ok, at the probably obvious risk of being laughed at (yet again ), what does the bs=32k DO ?? |
|
|
|
|
| Posted: Mon Mar 08, 2025 2:54 pm |
|
|
| crouse |
| Site Admin |
|
| Status: Offline |
|
| Joined: 16 Apr 2025 |
| Posts: 8558 |
|
| Location: Iowa |
|
|
|
|
|
|
| mmmna wrote: | Why not use mksiofs?
mkisofs might be better suited, when dealing with non ISO9660 CDROMs.
|
Don't you just love the way Linux gives you MANY ways to do the same thing  |
|
|
|
|
| | |
| Posted: Mon Mar 08, 2025 5:58 pm |
|
|
| mmmna |
| . . . . . . . |
|
| Status: Offline |
|
| Joined: 21 Apr 2025 |
| Posts: 4979 |
|
| Location: Central New Hampster |
|
|
|
|
|
|
| Stuka wrote: | | mmmna: since a .iso file is disk image, dd is a perfectly acceptable way to handle it. The process is analogous to the method for creating boot floppies from .img files (don't know if you've ever done this, as it's not necessary on newer hardware, but I've done it for some older boxes, and in the older days of Linux). |
I'm with you on making diskette images and whatnot.
My point is that when you use dd, it has no content checking functions... ISO9660 standards want only limited directory depths, file name string length limits, illegal characters, etc. The mkisofs program will alert you of anyconflicts to ISO9660, where dd will not tell you that 648 directories is too deep for an ISO9660 image, or filenames contain illegal characters, and all that. dd just makes a file, much like I can make a tar.gz file by renaming readme.txt into readme.tar.gz.
In some instances, dd is fine for the job as per whenever you are going to read back the CD on the same filesystem at a later date. However, if you are passing something off as an ISO image, lets assume to a Macintosh System 7 user (hypothetically assume that OS7 might have issues), the OS7 user might not be able to read the CD which they burn from the pseudo ISO file that you gave them, because of not adhereing to ISO9660 limitations when you use dd.  |
|
|
|
|
| | |
| Posted: Thu Mar 11, 2025 5:46 pm |
|
|
| jbsnake |
| Moderator |
|
| Status: Offline |
|
| Joined: 02 Dec 2025 |
| Posts: 1474 |
|
| Location: Georgia |
|
|
|
|
|
|
i'm not exactly sure what bs stands for...it's either Byte Speed...or Byte Size
(i'm putting my money on Byte Size) |
|
|
|
|
| Posted: Thu Mar 11, 2025 7:25 pm |
|
|
| Germ |
| Keeper of the BIG STICK |
 |
| Status: Offline |
|
| Joined: 30 Apr 2025 |
| Posts: 9047 |
|
| Location: Planet Earth |
|
|
|
|
|
|
yup, read and write byte size. I believe if you don't specify the byte size it defaults to 4.
You can specify input bytes size with ibs= and output byte size with obs=. bs= sets them both. |
|
_________________
Mandriva 2025 kernel-2.6.16.11
Slackware 10.2
Kubuntu 6.06 LTS Beta
OpenSuSE 10.0 |
|
|
|
| Posted: Wed Jun 02, 2025 9:18 am |
|
|
| nukes |
| Linux Guru |
 |
| Status: Offline |
|
| Joined: 29 Aug 2025 |
| Posts: 3821 |
|
| Location: St Andrews Uni, Scotland |
|
|
|
|
|
|
| Any idea how to make this work with copy-protected discs, eg safedisc/securom etc? |
|
_________________
Gentoo; 2.6.9, 2.6.12, 2.6.13-rc7-ck1
Debian Woody: 2.4.30 |
|
|
|
| Posted: Wed Jun 02, 2025 10:38 pm |
|
|
| jbsnake |
| Moderator |
|
| Status: Offline |
|
| Joined: 02 Dec 2025 |
| Posts: 1474 |
|
| Location: Georgia |
|
|
|
|
|
|
| it doesn't work for them? |
|
|
|
|
| Posted: Wed Jun 02, 2025 11:05 pm |
|
|
| gentooian |
| Member |
 |
| Status: Offline |
|
| Joined: 24 May 2025 |
| Posts: 192 |
|
| Location: Exit 9, New Jersey |
|
|
|
|
|
|
| since dd is just copying the raw data, in theory it should make an exact copy of the disc even if it is copy protected. |
|
|
|
|
| | |
| Posted: Thu Jun 03, 2025 5:58 am |
|
|
| nukes |
| Linux Guru |
|
| Status: Offline |
|
| Joined: 29 Aug 2025 |
| Posts: 3821 |
|
| Location: St Andrews Uni, Scotland |
|
|
|
|
|
|
Yes, but stuff like safedisk and securom work kind of like the "bad sector" protections we saw on floppy-based programs years back. Even if you did a 1:1 copy in nero or something it wouldn't work - It's a fancy copy protection that I can't really be bothered explaining about. Simply, the data is encoded onto the disc, but when it's read back it's different, so if you wrote it back on it it would be different again and not work.
That's how they (afaik) never got working CD cracks for games like RA2 (all your stuff would just blow up 10 mins into the game) - quite clever really, but annoying. |
|
_________________
Gentoo; 2.6.9, 2.6.12, 2.6.13-rc7-ck1
Debian Woody: 2.4.30 |
|
|
|
| | |
| Posted: Thu Jun 03, 2025 9:09 am |
|
|
| Stuka |
| Advanced Member |
|
| Status: Offline |
|
| Joined: 15 Oct 2025 |
| Posts: 958 |
|
| Location: Houston, TX |
|
|
|
|
|
|
Is the problem in the ISO creation, or is it in the 'checksumming' and what have you in the burning code (or perhaps CD-ROM/CD-RW firmware)? From what I've seen, most of these protection schemes need hardware and/or software vendors complicit in the schemes.
<edit>
Google is my friend. Apparently, a 100%, bit for bit copy SHOULD work with SafeDisc, as it relies on a 'digital signature' on the disc. Now, how that signature is implemented is probably a major trade secret, BUT if you did literally copy EVERY SINGLE BIT on the source disc to the ISO, and then transferred EVERY SINGLE BIT back out to a new disc, it SHOULD work.
</edit> |
|
|
|
|
| | |
| Posted: Thu Jun 03, 2025 11:51 am |
|
|
| nukes |
| Linux Guru |
|
| Status: Offline |
|
| Joined: 29 Aug 2025 |
| Posts: 3821 |
|
| Location: St Andrews Uni, Scotland |
|
|
|
|
|
|
Yes, but dd and cat just dump out with an error when they get, say, 200mb into it. The only things I've heard working (besides cracking it) are some philips/panasonic drives (which had a design fault and broke down after a bit) or sometimes software like Alcohol 120% and CDRWin on windows, which are no use to me..
It's the same as when you try and read a copy-protected floppy. If I could find a way to make it keep retrying (say 10 times) before giving up, I could probably get it. I'll try it with the "noerr" thing. :/ |
|
_________________
Gentoo; 2.6.9, 2.6.12, 2.6.13-rc7-ck1
Debian Woody: 2.4.30 |
|
|
|
|
