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.
