Folks,
As much as I hate to, I feel I need to post my long story and ask help.
Shortly after the release announcement, I kicked off rtorrent and downloaded the CD and DVD images. Since my cable provider does my "throttling", I disabled throttling and shared for several days, "returning" several GBs at no objectionable loss I could discern.
While that was going on, I used cdrecord (don't jump to conclusions here, read on) via CLI to burn the CDs. This on a fully-up-to-date CentOS... well here
uname -a Linux centos01.homegroannetworking 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686 athlon i386 GNU/Linux
$ lsb_release -a LSB Version: :core-3.0-ia32:core-3.0-noarch:graphics-3.0- ia32:graphics-3.0-noarch Distributor ID: CentOS Description: CentOS release 4.4 (Final) Release: 4.4 Codename: Final
CD writer is a generic 52x24x52x that I have used to burn many CDs before w/o problems. On this unit and the other I'll mention, the writer is master on IDE channel 2. Neither has an HD on that channel currently. The other unit has SATA drives and the writer is again on IDE 2 by itself.
Disc 1 passes media check and 2 - 6 fail consistently. Checks OK:
...CentOS-5.0-Old]$ md5sum -c md5sum.txt CentOS-5.0-i386-bin-1of6.iso: OK CentOS-5.0-i386-bin-2of6.iso: OK CentOS-5.0-i386-bin-3of6.iso: OK CentOS-5.0-i386-bin-4of6.iso: OK CentOS-5.0-i386-bin-5of6.iso: OK CentOS-5.0-i386-bin-6of6.iso: OK CentOS-5.0-i386-bin-DVD.iso: OK
IIRC, I also used the sha1 check (can't recall the command ATM) and it also passed.
"NP" says I! I'll copy 'em over to my LFS machine and burn on the Lite- on DVD/CD* burner.
Same results.
Hmph. OK. Rtorrent unreliable (don't giggle - there's a difference in the images as evidenced by "cmp" below)? Download all but the DVD directly from the UofGA mirror. Save them in ...CentOS-New. Do similar things.
...CentOS-5.0-New]$ md5sum -c md5sum.txt CentOS-5.0-i386-bin-1of6.iso: OK CentOS-5.0-i386-bin-2of6.iso: OK CentOS-5.0-i386-bin-3of6.iso: OK CentOS-5.0-i386-bin-4of6.iso: OK CentOS-5.0-i386-bin-5of6.iso: OK CentOS-5.0-i386-bin-6of6.iso: OK md5sum: CentOS-5.0-i386-bin-DVD.iso: No such file or directory CentOS-5.0-i386-bin-DVD.iso: FAILED open or read md5sum: WARNING: 1 of 7 listed files could not be read
Burned the CDs again. Media checks same as before - 1st passes and all others fail. Did again on the LFS machine, same results.
All media as RW, some <=12x, some <=4x speeds. Was rewriting over media previously used for CentOS 4.0 install (keeping 4.3 CDs available) and other miscellaneous previously used RW CDs.
Well... maybe they are bad now? All the ones I tried?! Unlikely. But be the type to avoid assumptions, burned disc 2 again on new media. It still fails.
Jorge, in his long-running condemnation of Linux kernel SCSI implementations, again mentions his usual in the docs he provides and specifically states that kernel >=2.5 has problems (at least the rants about the wort-ever SCSI implementations have abated). So I figure I'll use something that does not involve CLI.
BTW, by now I've learned that there are differences between the rtorrent created and downloaded-from-mirror images.
So I go to my trusty CentOS desktop, get nautilus going, right the disc 2 image and write to CD.
No improvement.
Last data point. Right after I downloaded from the UofGA mirror, I did a cmp. All the rtorrent vs direct download images showed a byte difference at offset 32768 of "line 1". My rtorrent was still running (IIRC) serving others. OMG! Am I delivering corrupted images to many other users!
I immediately shut down rtorrent.
When I do the cmp *now*, now differences are noted.
I checked cable seating on the "target" machine. OK. I tried reading the CDs on the same unit(s) that created them.
I'm now suspecting "wetware" problems. ATM, I probably can't see the forest for the trees.
Any thoughts, wisecracks, suggestions are welcome.
TIA -- Bill
On Sun, 2007-04-22 at 15:07 -0400, William L. Maltby wrote:
Folks,
<snip>
All media as RW, some <=12x, some <=4x speeds. Was rewriting over media previously used for CentOS 4.0 install (keeping 4.3 CDs available) and other miscellaneous previously used RW CDs.
Clarification: each set consisted of the same-speed media.
<snip>
So I go to my trusty CentOS desktop, get nautilus going, right the disc
^ click
2 image and write to CD.
No improvement.
Last data point. Right after I downloaded from the UofGA mirror, I did a cmp. All the rtorrent vs direct download images showed a byte difference at offset 32768 of "line 1". My rtorrent was still running (IIRC) serving others. OMG! Am I delivering corrupted images to many other users!
I immediately shut down rtorrent.
When I do the cmp *now*, now differences are noted.
s/now d/no d/
<snip>
-- Bill
William L. Maltby wrote:
Folks,
As much as I hate to, I feel I need to post my long story and ask help.
Shortly after the release announcement, I kicked off rtorrent and downloaded the CD and DVD images. Since my cable provider does my "throttling", I disabled throttling and shared for several days, "returning" several GBs at no objectionable loss I could discern.
While that was going on, I used cdrecord (don't jump to conclusions here, read on) via CLI to burn the CDs. This on a fully-up-to-date CentOS... well here
uname -a Linux centos01.homegroannetworking 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686 athlon i386 GNU/Linux $ lsb_release -a LSB Version: :core-3.0-ia32:core-3.0-noarch:graphics-3.0- ia32:graphics-3.0-noarch Distributor ID: CentOS Description: CentOS release 4.4 (Final) Release: 4.4 Codename: Final
CD writer is a generic 52x24x52x that I have used to burn many CDs before w/o problems. On this unit and the other I'll mention, the writer is master on IDE channel 2. Neither has an HD on that channel currently. The other unit has SATA drives and the writer is again on IDE 2 by itself.
Disc 1 passes media check and 2 - 6 fail consistently. Checks OK:
...CentOS-5.0-Old]$ md5sum -c md5sum.txt CentOS-5.0-i386-bin-1of6.iso: OK CentOS-5.0-i386-bin-2of6.iso: OK CentOS-5.0-i386-bin-3of6.iso: OK CentOS-5.0-i386-bin-4of6.iso: OK CentOS-5.0-i386-bin-5of6.iso: OK CentOS-5.0-i386-bin-6of6.iso: OK CentOS-5.0-i386-bin-DVD.iso: OK
IIRC, I also used the sha1 check (can't recall the command ATM) and it also passed.
At one time I got media check errors on a particular DVD in a new drive sometimes but not others.
My solution? Don't do the media check, that way it can't fail:-) If the install works, who cares what media check says?
Why not burn boot.iso and do an NFS install? You don't need to burn the rest at all.
John Summerfield wrote:
William L. Maltby wrote:
Folks,
As much as I hate to, I feel I need to post my long story and ask help.
Shortly after the release announcement, I kicked off rtorrent and downloaded the CD and DVD images. Since my cable provider does my "throttling", I disabled throttling and shared for several days, "returning" several GBs at no objectionable loss I could discern.
While that was going on, I used cdrecord (don't jump to conclusions here, read on) via CLI to burn the CDs. This on a fully-up-to-date CentOS... well here
uname -a Linux centos01.homegroannetworking 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686 athlon i386 GNU/Linux $ lsb_release -a LSB Version: :core-3.0-ia32:core-3.0-noarch:graphics-3.0- ia32:graphics-3.0-noarch Distributor ID: CentOS Description: CentOS release 4.4 (Final) Release: 4.4 Codename: Final
CD writer is a generic 52x24x52x that I have used to burn many CDs before w/o problems. On this unit and the other I'll mention, the writer is master on IDE channel 2. Neither has an HD on that channel currently. The other unit has SATA drives and the writer is again on IDE 2 by itself.
Disc 1 passes media check and 2 - 6 fail consistently. Checks OK:
...CentOS-5.0-Old]$ md5sum -c md5sum.txt CentOS-5.0-i386-bin-1of6.iso: OK CentOS-5.0-i386-bin-2of6.iso: OK CentOS-5.0-i386-bin-3of6.iso: OK CentOS-5.0-i386-bin-4of6.iso: OK CentOS-5.0-i386-bin-5of6.iso: OK CentOS-5.0-i386-bin-6of6.iso: OK CentOS-5.0-i386-bin-DVD.iso: OK
IIRC, I also used the sha1 check (can't recall the command ATM) and it also passed.
At one time I got media check errors on a particular DVD in a new drive sometimes but not others.
My solution? Don't do the media check, that way it can't fail:-) If the install works, who cares what media check says?
Why not burn boot.iso and do an NFS install? You don't need to burn the rest at all.
My 2c ; Ditto (or similar?) - Memorex DVD writer with the CentOS5 dvd - md5sum says the iso is fine, but even burning at the lowest speed it would not pass the Nero "verify", however the install was flawless. Maybe i had 3 bad dvds in a row, but unlikely. Maybe it didnt write well, but the damaged data was in packages i did not install? Fairly likely. Bottom line is that the md5 passed (good iso image) and the DVD install worked.
MrKiwi.
My suggestions:
verify the md5sum's / sha1sum's of the burned CD/DVD's. (Since you already have the apparently correct iso downloaded to disk). How?
like this:
dd if=/dev/dvd bs=xxx count=yyy | md5sum
(/dev/dvd is your dvd/cd whatever device, might be /dev/cdrecorder, /dev/cdrw, /dev/dvd, /dev/dvdrw, /dev/hda, /dev/hdb, /dev/hdc, /dev/hdd, etc... you should know ;-) )
Where xxx and yyy satisfy the constraint xxx * yyy = size of iso image in bytes. Preferably you want xxx as large as possible. Since iso's are written in 2KB sectors, you can always use 2048 for xxx, but bigger is better (better = faster).
If I've lost you, then just do:
ISOSIZE=... dd if=/dev/dvd bs=2048 count=$[$ISOSIZE/2048] | md5sum
Where you would replace the three dots with the size of the iso image that should have been burned to that cd/dvd.
This will allow you to do a mediacheck by hand. I'd venture to guess they'll fail... if so, then burn on good media at minimum speed (ie. like 1x, or 2x, or something) - although I know you've tried this... I'll just add my 2c - I burnt the DVDs with no problem at 4x, and the above mentioned verification passes.
Cheers, Maciej.
On Mon, 2007-04-23 at 05:00 +0200, Maciej Zenczykowski wrote:
My suggestions:
verify the md5sum's / sha1sum's of the burned CD/DVD's. (Since you already have the apparently correct iso downloaded to disk). How?
like this:
dd if=/dev/dvd bs=xxx count=yyy | md5sum
(/dev/dvd is your dvd/cd whatever device, might be /dev/cdrecorder, /dev/cdrw, /dev/dvd, /dev/dvdrw, /dev/hda, /dev/hdb, /dev/hdc, /dev/hdd, etc... you should know ;-) )
Where xxx and yyy satisfy the constraint xxx * yyy = size of iso image in bytes. Preferably you want xxx as large as possible. Since iso's are written in 2KB sectors, you can always use 2048 for xxx, but bigger is better (better = faster).
If I've lost you, then just do:
Nope, not lost! Been doing lots of *IX things for more decades than I wish to confess publicly! :-)
I had considered that and discarded it due to the statements by Joerg in his docs about the problems with kernels >=2.5. BTW, I've since looked at the logs and confirmed that kernel buffer errors (I think) occur and get the kernel complaining about I/O errors on /dev/hdc (the drive I was going to checksum the CDs on on CentOS). I'll give the dd a try with a blksize of some multiple of 2K and see if that gives me a decent checksum.
<snip>
This will allow you to do a mediacheck by hand. I'd venture to guess they'll fail... if so, then burn on good media at minimum speed (ie. like 1x, or 2x, or something) - although I know you've tried this... I'll just add my 2c - I burnt the DVDs with no problem at 4x, and the above mentioned verification passes.
Let's start an office pool! I'm betting they'll pass because the media are not that old and and have been successfully used previously. I'm betting on the Linux kernel problems mentioned Joerg as being guilty when a high-speed sequential pass is made to do the checksum.
And you are right, I did burn at lower speed. *sigh* didn't help. I think I've got an old 2.4* kernel laying around on one of my HDs that I'm waiting to (re)install and use again. If I burn it there, I'll probably get good results.
Cheers, Maciej.
<snip sig stuff>
Thanks for the feed back and thoughts.
For John Summerfield, thx to you to. I had been considering doing the network install, but I'm always meandering around and tearing down/(re)building my home eqpt. There is a certain sense of security that comes with having known good media available in case the current torn-down unit is my server (I know, I've got enough old junk around, why don't I have multiples yet? Time, incentive, trying to get my skills updated to current levels vis-a-vis admin and user things).
I had also thought of "don't do the media check, but decided to first prevail upon the wisdom, and potential humor, of the list.
Mr. Kiwi, also thanks for taking the time. Combined with John's thought, I will feel giving the "install regardless" attempt a shot will be worthwhile.
Thanks to all. I'll post a "SOLVED" to end this thread if any/all of these things work. maybe the next "victim" achieves "nirvana" is significantly less time, with less angst, that way.
Probably take a day or two to take a shot at it. I quit working professionally with this junk a long time ago and now have to actually *work*, rather than play, for a living.
Thanks to all, -- Bill
William L. Maltby wrote:
On Mon, 2007-04-23 at 05:00 +0200, Maciej Zenczykowski wrote:
I had considered that and discarded it due to the statements by Joerg in his docs about the problems with kernels >=2.5. BTW, I've since looked at the logs and confirmed that kernel buffer errors (I think) occur and get the kernel complaining about I/O errors on /dev/hdc (the drive I was going to checksum the CDs on on CentOS). I'll give the dd a try with a blksize of some multiple of 2K and see if that gives me a decent checksum.
JS makes so many ridiculous statements that I find it hard to take him seriously. Recently, he's upset Debian enough (he changed the licence on cdr-tools) that Debian's forked cdrecord, SUSE is distributing another version (Debian's I suspect).
I may be mistaken, but I think the Linux Kernel Hackers know more about the Linux kernel than JS does.
On Sunday 22 April 2007, William L. Maltby wrote:
Folks,
As much as I hate to, I feel I need to post my long story and ask help.
[snip info about failed mediachecks]
Please see the thread starting at http://lists.centos.org/pipermail/centos/2005-March/003347.html
Short form answer: cdrecord needs to -pad to get good mediachecks consistently.
On Mon, 2007-04-23 at 22:03 -0400, Lamar Owen wrote:
On Sunday 22 April 2007, William L. Maltby wrote:
Folks,
As much as I hate to, I feel I need to post my long story and ask help.
[snip info about failed mediachecks]
Please see the thread starting at http://lists.centos.org/pipermail/centos/2005-March/003347.html
Short form answer: cdrecord needs to -pad to get good mediachecks consistently.
Right ... it seems on some hardware (and versions of cdrecord) that is true.
Try this on your images (make a backup) before you burn it:
dd if=/dev/zero bs=2048 count=150 >> filename.iso
(of course, substitute your ISO filename for filename.iso)
Then burn it and run the media checks.