On Sun, 2005-05-08 at 13:56 +0100, Anne Wilson wrote:
On Sunday 08 May 2005 11:50, Adolfo Bello wrote:
On Sun, 2005-05-08 at 12:30 +0200, Kaj Haulrich wrote:
Don't be afraid. When burning .iso's with K3B and ticking the "verify written data" my system always reports an error regardless of DAO or TAO. Nevertheless, it's quite OK. Same thing when doing a manual md5sum on the device. Never mind.
Hi Kaj:
In my case the disks were totally useless. I have had no problem verifying with k3b since I started using DAO. I reckon that I burn just a few CD images per year.
I burned disks 1-5 with DAO, and all verified in k3b, but I've now burned disk 6 four times, three of them with DAO, and it's failed to verify every time.
Anne
Anne:
Did you check the MD5 for the downloaded disk # 6 iso image?
Adolfo
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. 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.
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. 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.
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? 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, the result of an -atip on the media being used, and if a simple 'cdrecord -v -eject speed=4 dev=ATA:X,Y,Z -dao xxxxxx.iso', still produces an uncheckable md5sum CDr.
--
Tom Brinkman Corpus Christi, Texas
____________________________________________________ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Join the Club : http://www.mandrakeclub.com ____________________________________________________
