Thank you, Connie and Troy, for answering so fast. I
am currently downloading the first iso image to solve
my md5sum unfortunate experience.



Regarding the second point ( no problem with CDrom
capabalities up to 800Mo write/read, either with
W2K/Nero or various SL/Xcdroast/K3b. Currently i am
using 700Mo certified - TDK - CDroms ):

1/ i am aware that the autocheck disk is an option (
but a strong one: the only way to skip it is to press
a very well named button ""skip CD verification"",
which is more than 'incentive' regarding laws and
professional responsibility )

2/ i am sure this is a good feature ( i used it since
RH9 from ftp.redhat.com )

3/ but this never had reported OK with SL for me ( RH9
always was OK, not on the same hardware than SL, but i
do not have this hardware anymore, nor i have the RH9
CD ). Do you mean that you, or anybody, had success
with it ?

Anyway, i am ready to provide you any information if
you need them, in order to help you on this topic.

In particular, you guess that i am ready to burn and
install SL305/i386 32bits (from W2K/Nero), and very
soon SL4.1 or 4.rolling (from SL305/K3b), so, if you
want to ask me anything for a testing purpose, feel
free to do so, i will spent the needed time on it. I
don't know if this is related, but i never had
obtained the original md5sum from an iso burned ( and
previously checked md5sum ok ), and then re-extracted
as an image. Maybe is this an other way to say what
Troy stated as ""Not all CD media is created equal""
?, but this is not explaining why RH9 CD verification
was ok and SL never (for me).






--- Connie Sieh <[log in to unmask]> wrote:

> On Tue, 2 Aug 2005, Troy Dawson wrote:
> 
> > Hello,
> > We cannot change the md5sum ... because they are
> correct.
> > Here is the output from ftp.scientificlinux.org
> > 
> > # md5sum SL.305.072605.i386.disc1.iso
> > a031f04f101f5e627cc95350d2d008a1 
> SL.305.072605.i386.disc1.iso
> > #
> > 
> > I'm sorry your having trouble downloading.
> > 
> > The CD check also isn't automatic, it asks you if
> you want to do it, so 
> 
> You have the option of skipping the disk check.
> 
> > I'm not quite sure what you are meaning by this. 
> I think it's a good 
> > thing.
> > Just as some people might get a bit or two mixed
> up in downloading, not 
> > all CD's get all the bits right either.
> > Not all CD media is created equal.  There is alot
> that just plain will 
> > not burn a full 700 Meg cd, no matter what it says
> on the label.
> > Not all CD burners are created equal either.  I've
> had a couple that 
> > gradually died, and it was these checks that
> brought it to my attention.
> > 
> > Troy
> > 
> > hilare wrote:
> > > Hello,
> > > 
> > > checking md5sum on the 072605 ( 26 july 2005 )
> iso for
> > > SL305 / i386, reports :
> > > ""SL.305.072605.i386.disc1.iso: FAILED"", the
> other
> > > iso images are fine.
> > > 
> > > 
> > > I had downloaded twice the
> > > SL.305.072605.i386.disc1.iso, first from
> > > ftp.scientificlinux.org, second from
> > > linuxsoft.cern.ch/scientific (http), the problem
> > > remains, and the md5sum files are the same on
> the two
> > > websites :
> > > 
> > > ""
> > > a031f04f101f5e627cc95350d2d008a1 
> > > SL.305.072605.i386.disc1.iso
> > > daf41b883de342945de968a8731eb033 
> > > SL.305.072605.i386.disc2.iso
> > > 8e655e6f64f241c4ac5c45c591aa21b6 
> > > SL.305.072605.i386.disc3.iso
> > > 58f916a94de7017233234101e9270afa 
> > > SL.305.072605.i386.disc4.iso
> > > ""
> > > 
> > > 
> > > Calculating the checksum via md5sum --binary on
> > > SL.305.072605.i386.disc1.iso (CERN), gives : 
> > > b4712d89a65d5e53174847fd4b5c9b5e
> > > 
> > > 
> > > 1/ could you confirm this last value is the good
> one ?
> > > 
> > > 2/ could you correct the md5sum file for SL305 /
> i386
> > > ?
> > > 
> > > 
> > > 
> > > 
> > > Appart from this problem, SL304 and SL40
> autocheck
> > > feature ( at the start of install from CD )
> always
> > > failed for every disks ( 1 to 4 ). I guess the
> > > checksum remained on the RH disk one. Please
> consider
> > > this is not any comfort request, quite contrary
> a
> > > verification tool not reporting anything 'ok'
> during
> > > an install, is a definitive stopper for every
> 'quality
> > > insurance' driven service contract, and
> potentially a
> > > cause to fire out a system administrator for
> taking
> > > the responsability of installing a system with
> > > 'corrupted' sources. So my request is either :
> > > 
> > > 1/ please disable the autocheck feature
> > > 
> > > 2/ or replace the checksums with the
> corresponding SL
> > > disk checksums.
> > > 
> > > 
> > > 
> > > Thank you
> > > 
> > > 
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > > http://mail.yahoo.com 
> > 
> > 
> > 
> -Connie Sieh
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com