Actually RedHat has in the past suggested the "padding" options as a solution to this. I actually had thought it fixed as I used to have this problem so had used the "padding" options and it went away. I had a case were I had forgot the "padding" options and there was no issue so had thought that the problem was really fixing. In reality the problem is with different readers/burner combinations. I do NOT think that padding will harm anything. All it is doing is adding some "blank" space at the end of the burn. -Connie Sieh On Tue, 2 Aug 2005, hilare wrote: > Hello Daniel, > > English is not my mother-tongue, and i guess i was not > clear. > > The answer is in the first source of documentation: > the man page(*), which stated for the cdrecord padding > factor: ""Use this option if your CD-drive is not able > to read the last sectors of a track or if you want to > be able to read the CD on a Linux system with the > ISO-9660 filesystem read ahead bug"" > > This warning combined with IBM link ( the IBM howto > does not tell a word about padding factore, and when > IBM doesn't speak about a feature, they are very few > reasons: a) IBM doesn't know anything about it - you > can rate this near to null; b) IBM perfectly knows the > feature, but it is not compatible with its > hardware/software. Very bad mouthing :-) ; c) the > feature is at best useless, and at worst dangerous ) > lead me to say ""the advise on specifying padsize for > writing a CD may required some attention before being > used"". > > In fact forcing dao ( disk at once ) is the _standard_ > solution ( except for specific bad hardwares, as > stated by the man page ) to avoid CDrom reading > problems. > > (*) links for the man page: > > http://node1.yo-linux.com/cgi-bin/man2html?cgi_command=cdrecord&cgi_section=&cgi_keyword=m > > > That being said, i will try this padding factor for > writing 'on the fly' DVD ( not CD, because they gives > me no problem excepting the SL ones ;-) ), which > always gives me a lot IO errors at reading time, > opposite to first generating an iso DVD image which > always leads to 'no problem' at reading time. > > > I hope i am clear now ? > > > > --- Daniel Widyono <[log in to unmask]> wrote: > > > Forgive me if I'm just being clueless, but your > > posting was more confusing > > than the original, as your links had no information > > regarding padsize or its > > effects. > > > > Your message came off sounding like you're warning > > against using padsize; do > > you have links to such warnings against using > > padsize with data cdroms? Or > > was your intent simply to provide more sources for > > generic CD burning > > information for the release notes? > > > > Regards, > > Dan W. > > > > > > > > On Tue, Aug 02, 2005 at 09:56:46AM -0700, hilare > > wrote: > > > The link provided by Shannon is undoubtly usefull, > > > thank you Shannon, especially for its CD raw > > reading > > > section. > > > > > > But the advise on specifying padsize for writing a > > CD > > > may required some attention before being used, > > > moreover for a data cdrom. You might be interested > > by > > > some other links, and other advises: > > > > > > > > > http://www-128.ibm.com/developerworks/linux/library/l-cdburn.html > > > > > > > > > http://www.uk.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-cds.html > > > > > > http://www.cdrfaq.org/ > > > > > > > > > http://applications.linux.com/applications/04/11/16/1555246.shtml?tid=13&tid=47 > > > > > > > > > > > > > > > > > > --- Connie Sieh <[log in to unmask]> wrote: > > > > > > > Shannon, > > > > > > > > I will add this to the release notes. > > > > > > > > Thanks > > > > > > > > -Connie Sieh > > > > On Tue, 2 Aug 2005, Shannon V. > > > > Davidson wrote: > > > > > > > > > I used to have trouble burning CDs until I > > > > discovered the instructions > > > > > at > > > > > > > > > > http://www.troubleshooters.com/linux/coasterless.htm. > > > > Your mileage > > > > > may vary, but now I always use the following > > > > command and don't have any > > > > > problems: > > > > > > > > > > cdrecord dev=0,0,0 speed=16 padsize=63s > > -pad > > > > -v -eject -data > > > > > /tmp/name.iso > > > > > > > > > > Note: to figure out the device, use > > cdrecord > > > > -s -scanbus > > > > > Note: use a slower speed, if you have a > > > > slower CD writer > > > > > > > > > > Shannon > > > > > > > > > > > > > > > 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 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 > > > === message truncated === > > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > >