On Sunday 08 May 2005 16:13, Tom wrote: > Hi, Tom. > I posted here the day the torrents were available, 1 -> > checked, but the CD6 iso failed. So I got the separate torrent for > CD5-6, and that CD6 iso checked.
I took the Silver 5-6 torrent, and it's that one that is failing. Is the one you got different? > IIRC, shortly after Warly posted > (on cooker) that the mini CD and CD6 (0f 1-6) would fail md5sum, but > still be usable. I believe the problem was a fairly obscure md raid > (win-fake-raid) module that was missing from the torrents. CD6 isn't > all that important anyhow. > Fair enough. I could probably ignore it, then. > As to 'md5sum /dev/hdd'. Well you already know my disdain for > GUI frontends to cdrecord (particularly k3b), but I an others have > posted many times that -dao _must_ be used, -pad or -data should > _never_ be used for iso's. Somehow I have not managed to catch that in the past, but point taken, and I'll remember it. > An that best results will probly come > from 1/3 speed. Speed being the lessor of your burners rating, or > the media used. So for the best drives and Cdr's, that means no > faster than 16x. > I am burning at 1/3 speed - 8x on a 24x drive. > If 'md5sum /dev/hdd' results in an I/O error, it usually means > the drive being used to read, can't read the CDr correctly. Just as > often a hardware or media problem than an improperly burned iso. Is > hdd your burner?, or a CDrom? hdd is the burner. > The burner used to make the CD should > be able to read it better than a cdrom drive can. 'Course if you're > makin CD's to be used on other systems, they will need to be able to > be read by CDrom drives. CD-RW's use a "tighter" an brighter laser > than CD (CDrom or DVDrom) drives do. > > So it's better to use a CDrom drive to check the md5sum. If the > first try returns I/O error, try several more times. It might help > to close the console being used, remove an re-insert the Cdr, an > then try again with a new console. If many tries fail, you can > always try 'dd'ing the CDr to a file on your hardrive an then md5sum > that. But IME, if you can't check the CDr, then the dd'd iso probly > won't check either. > > One last note; if you happen to be usin a LE2005 system (or > older Mandrake with a recent kernel) to make the CD's, burning > should be done as root. cdrecord as user is denied access (recent > kernel security changes) to: > > cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler > cdrecord: Permission denied. WARNING: Cannot set priority using > setpriority(). > cdrecord: WARNING: This causes a high risk for buffer underruns. > > While burning as user is still possible (the above are just > warnings, not errors) the resulting CD's can be harder to read. > Specially at the very outer edges. CDr's record from the inside > near the spindle to the outer rim. While the md5sum may fail, it > could be that only the last file recorded is corrupt. The CD should > most likely still be usable. > > If you still have problems, I'd be interested in the hardware > you're using, uname -r, uname -r 2.6.8.1-24W4L > the result of an -atip on the media being > used, I don't understand that one, Tom. I presume -atip is a switch - on which command? > and if a simple 'cdrecord -v -eject speed=4 dev=ATA:X,Y,Z -dao > xxxxxx.iso', still produces an uncheckable md5sum CDr. OK - I'll try that one last test, but don't I somewhere have to tell it the device name? Anne -- Registered Linux User No.293302 (http://counter.li.org/) Have you visited http://twiki.mdklinuxfaq.org yet? Mandrake at all levels
pgpW5vmJUUJ5o.pgp
Description: PGP signature
