Am i using md5sum correctly?
 

Hello fellow linux people. I am having some issues verifying burnt dvd iso's with k3b at present. Every verification has been a failure. I have read forum postings and found that others have also had issues. Anyway my last burn at 4x failed to verify, but I used md5sum manually like this which looks ok:

myname@ubuntu-desktop:~/Extraction$ cat mydisc.iso | md5sum
7a82aae5d938b33d5908619e7ea0c7c3 -
myname@ubuntu-desktop:~/Extraction$ nice -20 dd if=/dev/hda bs=2048 count=892781 | md5sum
7a82aae5d938b33d5908619e7ea0c7c3 -
892781+0 records in
892781+0 records out
1828415488 bytes (1.8 GB) copied, 313.313 seconds, 5.8 MB/s

Being a slightly paranoid sort of person I'd be grateful if someone who burns lots of discs in linux could tell me whether md5sum is right and that its verified or k3b is right and its a bad disk.

thanks guys

Possible useful info:
Kubuntu6.10
-----------------------
K3b Version: 1.0rc4

KDE Version: 3.5.5
QT Version: 3.3.6
Kernel: 2.6.17-10-generic
Devices
-----------------------
SONY DVD RW DRU-710A BYX5 (/dev/hda, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+R DL] [DVD-ROM, DVD-R Sequential, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite]

Used versions
-----------------------
growisofs: 7.0.1

Did you burn the disk from an image you downloaded, which included an md5 checksum file (like a linux dvd download).

You can verify the image with "md5sum -f md5sumfile"

If what you are trying to do is verify if a burnt disk matches your original image, then the command you used to verify indicates that the disk matches the file provided that your parameters included the entire image.

Does "stat -f /dev/hda" give the same number of blocks as you used in the dd | md5sum command?
I wonder if there are few null bytes after the image being read by k3b and that is the cause of the failure.

You might try mounting the image and looking at the block size and number of blocks using stat.
If the two checksums match then you can be assured that the dvd was burnt correctly.

Even if you have two different checksums, you might try getting the checksums of the files contained in the image and in the dvd and compare them. Maybe the difference isn't in a place that is important.

Thank you for your reply. The iso i'm trying to burn is actually a home brew iso I created using mkisofs. I did as you suggested and here is the outcome:

myname@ubuntu-desktop:~$ stat -f /dev/hda
File: "/dev/hda"
ID: 0 Namelen: 255 Type: tmpfs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 2560 Free: 2522 Available: 2522
Inodes: Total: 64453 Free: 63623

myname@ubuntu-desktop:~/Extraction$ stat -f mydisc.iso
File: "mydisc.iso"
ID: 0 Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 24970173 Free: 18644894 Available: 17376462
Inodes: Total: 12697600 Free: 12677609

erm.. shouldn't the block size be 2048 have I misused mkisofs?

If the checksums are different how do I know whether or not the difference is in an important place or not?

That I don't know. I used an image of the openSuSE 10.2 which is only 3GB. Maybe a double layer dvd uses a larger blocksize or even one that is full does as well.
I'll pop in a DL disk and see what it says.

I popped in an old SuSE 8.2 Professional. It turned out that it is 4.7GB, but the block size is 4096.

I might be wrong about the output of stat however. Some commands like ls will give a block size, but it simply is what the command regards as the block size (1024). The block size of the image file will be the block size of the file system it is on of course. I just didn't want an arbitrary block size causing a difference between blocksize*count and the number of bytes in the image file or disk.

You might play around with something like this:Also, for the iso file, look at "stat mydisk.iso" instead of "stat -f mydisk.iso"
example:For this example, try bs=9142935 for both the dvd image and /dev/hda. I still have a feeling that you are dealing with a filesystem image that has null bytes filling out the end of the last block. If the md5sums are the same, use count=1 with offset=9142935 to compare the last block. Or even subtract 4096 from the byte size of the disk and use that as the skip value, with a blocksize of 1. I don't know if when the image is created to the disk, the filesystems's blocksize causes the last block to be padded or contain random characters. KDE3 might be only counting upto the real end of the iso9660 filesystem and ignores the rest.

---

You could also calculate the md5sums of the contents of every file on the dvd. Do the same with the files in the mounted image. Then see if any of the files differ. You could also use the "cmp" command to compare the files:

I did it this way so that it would be possible to strip of the last field and use diff to find any differences. The number will allow you to look up what the file is.