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
>
>
|
