8

I just tried burning both a Debian CD and a Debian DVD from their .iso files and I've got a weird behavior: the checksum of the CD is correct but the one of the DVD ain't.

Here's what working:

  • downloaded the two .iso files
  • verified the checksum of the two .iso files
  • burn the CD debian-7.1.0-amd64-CD-1.iso to a CD

  • verify that the CD is correct by issuing:

    dd if=/dev/sr0 | md5sum (or sha-1 or sha-256)

And this works fine: the checksum(s) I get from the CD by using dd and piping into md5, sha-1 or sha-256 do match the official checksums.

Now what I don't get is that I did burn a DVD from the DVD .iso --and I know that the file has been correctly downloaded seen that the .iso file checksum is correct.

However if I put the DVD in the drive and issue the same:

dd if=/dev/sr0 | md5sum   (or sha-1 or sha-256)

then I get a bogus checksum.

The DVD still looks correct in that the files all seem to be there.

So here's my question: can I verify that a DVD has been correctly burned by using dd and piping its output into md5sum (or sha-1 or sha-256) or is there something "special" that would make dd work for verifying burned CDs but not burned DVDs?

*(note that I used Disk Utility on OS X to burn both the CD and the DVD)*

Improve this question
1
  • dd probably has nothing to do with the problem. It's not doing anything that cat /dev/sr0 | md5sum or md5sum /dev/sr0 wouldn't do, except maybe use a different buffer size, and that won't change the hash. As long as you still have the image file around, you can also run cmp /dev/sr0 foo.iso to get some more information on whether they are really different. If it reports EOF on the image file, then the burned disc just has some padding on the end.
    – user41515
    Jul 26, 2013 at 0:17

2 Answers 2

Reset to default
9

In addition to Gilles answer,

If you still have the ISO image, you could use cmp instead of checksums. It would tell you at which byte the difference happens. It would also make the check faster as if there is an error early on, it would tell you right away, whereas the checksum always has to read the entire media.

$ cmp /dev/cdrom /path/to/cdrom.iso

In case of error it should print something like this

/dev/cdrom /path/to/cdrom.iso differ, byte 123456789, line 42

In case it's correct it should print nothing, or this:

cmp: EOF on /path/to/cdrom.iso

Which means there is more data on /dev/cdrom than in the ISO, most likely zero-padding.

Even before starting any comparisons, you could check the size.

$ blockdev --getsize64 /dev/cdrom
123456999
$ stat -c %s /path/to/cdrom.iso
123456789

If it's identical, the checksum should match also. If /dev/cdrom is larger, it should be zero padded at the end. You could check that with hexdump. Use the ISO size for the -s parameter.

$ hexdump -s 15931539256 -C /dev/cdrom
3b597ff38  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
3b597fff8  00 00 00 00 00 00 00 00                           |........|

hexdump is also useful for having a look at difference at any other position in a file, in case a damage was caused deliberately by something.

Improve this answer
1
  • thanks a lot, using cmp I've been able to compare the .iso and the DVD and, indeed, it ends "correctly" with an EOF. Now I understand better what's going on : )
    – Cedric Martin
    Jul 26, 2013 at 11:02
8

As far as I know, both CDs and DVDs consist of a certain number of fixed-size blocks. The image that you're burning may not be a multiple of the block size, in which case the last block will contain some trailing garbage. So when you run dd if=/dev/sr0 (which is an obfuscated way of writing md5sum </dev/sr0), the trailing garbage is included in the hash.

You need to keep track of the size of the image. Then apply the hash utility on the number of bytes of the payload (i.e. the ISO file).

</dev/sr0 head -c "$size" | md5sum
Improve this answer
2
  • +1... oh gotcha and thanks a lot. So I may be taking into account trailing zero bytes or garbage. I'll see if I can use cmp instead. (now to be honest I don't know what's more obfuscated between using the pipe symbol and </dev/sr0 ) ; )
    – Cedric Martin
    Jul 26, 2013 at 0:19
  • 4
    CD sectors are 2,408 bytes long, but AFAIR DVD-ROMs write data in multiples of 16-sector blocks (so 32,768 bytes). growisofs produces an ISO image that's a multiple of 2,048 bytes, but maybe not a multiple of 32,768 bytes. That might explain why the CD checksums correctly and the DVD doesn't.
    – Alexios
    Jul 26, 2013 at 8:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .