md5sum of cd-image

[Nifty Hat Mitch]

On Sat, Nov 13, 2004 at 03:42:06PM +0100, Dennis Bjorklund wrote:
> On Sat, 13 Nov 2004, Paul Howarth wrote:
> 
> > >   dd if=/dev/cdrom bs=2k | md5sum
> > > 
> > > to check the md5sum after you have burned the cd. I've tried to burn the
> > > cd's in different ways using cdrecord (different pad-size) but no matter
> > > what, I get a I/O-error in the end and a sum that is correct.
> > 
> > That's OK; you get the I/O error when dd attempts to read past the end
> > of the data on the CD. The md5sum is good, so the CD is too.
> 
> Except that the md5sum is not good.
> 
> The iso I downloaded have the correct checksum, but the above command does
> not give the correct checksum on my burned cds.

This md5sum error almost makes sense for a CDROM burned with a pad.
  (Someone with problem drive and padded media could check this...)

I am not sure how a filesystem size is determined in the ISO case but
a filesystem that is smaller (or larger) than the physical media is
possible.  In the smaller than media case the pad blocks could screw up
the check sum done with a dd because of the extra blocks.

One possible way to check the burn process is to limit the block count
so that it matches the image and does not include the pad blocks.
i.e.
 # ls -l /iso/RH/FC3/FC3-i386-disc4.iso
 .... 404764672 Nov  9 12:03 /iso/RH/FC3/FC3-i386-disc4.iso
 $ bc
 404764672/512
 790556
 $ dd if=/iso/RH/FC3/FC3-i386-disc4.iso of=/dev/null
 790556+0 records in
 790556+0 records out

Now the above dd command becomes:

   dd if=/dev/cdrom count=790556 | md5sum

Sticking with a 2K block as per above...
   $ dd if=/iso/RH/FC3/FC3-i386-disc4.iso bs=2k of=/dev/null
   197639+0 records in
   197639+0 records out

   dd if=/dev/cdrom bs=2k count=197639  | md5sum

Summary: 

If the size does not match then the check sum cannot be expected to
match.  Check the size of the source and dd results (records in/out)
when checking.  Pad blocks are possible (dd; conv=sync etc...).


Speculation: The iso images could have been padded with some 'extra'
blocks of nulls and the published md5sum include the pad.  As long as
the resultant size was still smaller than a physical CDROM all would
be cool.  The pad could have 'hidden' the troubling interaction with
read ahead that nodma seems to fix.

Clever security folks might see the 'extra blocks' and want to check
that they are packed with null bits.  ;-)


-- 
	T o m  M i t c h e l l 
	spam unwanted email.
	SPAM, good eats, and a trademark of  Hormel Foods.