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