Here's a relevant article I just came across: http://fedora.redhat.com/projects/anaconda-installer/manualtest.html
I think it's just a different way of testing the device. Curtis On Wed, 2004-01-21 at 13:40, Jason Louie wrote: > I believe that these are the same last I tried it. But I assumed that > the burning software I used (Nero on Win2000,) added some identifying > headers, or something on the CD. Thus producing the different MD5. > But that still leaves the question on if the CD is still good or not. > > Jeffrey Clement wrote: > > I do not believe that this is correct. When you take the MD5SUM of the > > cdrom DEVICE (not mounted file system) you are taking the MD5SUM of the > > whole cdrom image which should be the same as the ISO that created it. > > I'm not 100% on this. It may be that the image gets padded or something > > like that. I think what Curtis is talking about is the difference between > > the ISO and the actual mounted CD file system and yes those definately are > > different. So again I think you can simply do: > > > > cdrecord dev=0,0,0 test.iso > > md5sum test.iso > > md5sum /dev/scd0 (or whatever) > > > > I think the output from the two MD5 sums should be the same. Does anyone > > know for sure on this. I'm pretty sure I've done this before and I believe > > it makes sense that this would work. > > > > Jeff > > > > On Wed, Jan 21, 2004 at 12:25:53PM -0700, Curtis Sloan wrote: > > > > > On Wed, 2004-01-21 at 11:43, Jason Louie wrote: > > > > > > > But is this producing the same MD5 checksum directly from the CD as > > > > the ISO? > > > > > > > I'm not sure if I understand what you are asking, so let me rephrase the > > > question and you can correct me if I'm misunderstanding: > > > > > > "Is the MD5 checksum of the CD (i.e. /dev/cdrom) the same as the MD5 > > > checksum of the .iso file (before it was burned)?" > > > > > > If this is the question you are asking, then the answer is no. They > > > will always be different. > > > > > > The answer lies is in the way the MD5 algorithm works. It produces a > > > unique 128-bit checksum for any given arrangement of bytes. > > > > > > In this case, the arrangement of the bytes in an ISO file is distinctly > > > different than that of the exact same bytes laid out in a filesystem > > > (i.e. after burning). The MD5 algorithm doesn't care that they are the > > > same bytes, since (from the algorithm's perspective) the single ISO file > > > is fundamentally different than the collection of files taken as a > > > whole. One MD5 will be a "fingerprint" of an ISO file, the other of an > > > entire filesystem. The difference can seem semantic, but viewed from an > > > algorithm's point of view, it can make sense. > > > > > > This may account for apparent discrepancies in MD5s (if I understood > > > your question correctly). > > > > > > HTH, > > > Curtis > > > > > > > > > > I've seem lots of examples on the web on the process of verifying CDs > > > > burnt from ISOs but I can't seem to reproduce the results. I only > > > > have access to a burner on a Win system and I'm wondering if that is > > > > the reason why the MD5s are different. > > > > > > > > Pete wrote: > > > > > > > > > Linux commandline burning works for me... > > > > > > > > > > http://www.yolinux.com/TUTORIALS/LinuxTutorialCDBurn.html > > > > > > > > > > There are a few examples of commands to copy CDs > > > > > > > > > > Peter > > > > > > > > > > Jason Louie wrote: > > > > > > > > > > > Has anyone been able to verify the *burned* copy of the ISO? Also > > > > > > what programs are you guys using for the burning? I'm using Nero > > > > > > on a Win system. I have lots of distros that I would like to > > > > > > share but I don't feel good about having them available when I'm > > > > > > not sure if they're good. I haven't been able to get matching > > > > > > results with doing an MD5 check on the CD so I was wondering if > > > > > > anyone has been getting better results. _______________________________________________ clug-talk mailing list [EMAIL PROTECTED] http://clug.ca/mailman/listinfo/clug-talk_clug.ca
