Fedora Core 3 Test 3 Discs Not Working
maze at cela.pl
Thu Oct 14 12:55:52 UTC 2004
I think the proper solution would be for not only the MD5SUM to be
embedded on disk but also the data length of the data to checksum. Or is
this already done and the problem are read errors near the end of the CD
if there is insufficient padding - if so, isn't this a kernel error?
On Thu, 14 Oct 2004, Jim Cornette wrote:
> Harald Hoyer wrote:
> >> The issue is related to the 2.6 kernel and such. If you pad the discs
> >> with at least 150 kb, the discs should checksum alright. As why disc 1
> >> passed, it was just a "lucky lotto winner".
> > just burn them with the cdrecord "-dao" parameter
> Not using cdrecord directly, except for early examples that were relayed
> from others during early 2.5 kernels. How can it be determined if
> front-ends to cdrecord, like nautilus-cd-burner are using -dao or -tao?
> It would seem to me that this would be disc at once, by default. If the
> one and only choice is for nautilus-cd-burner to burn using track at
> once vs. -dao, why is there not a selection to choose this option from
> the interface?
> k3b bombed with this attempt and using xcdroast w/ -dao was not
> something that I thought about using. Right clicking, then writing to CD
> is s tempting, since it is so easily selected.
> Which direction are we supposed to follow? CLI and long strings of
> options to the program? Or GUI and working defaults for
> simplified/feature reduced interfaces?
> Anyway, I'll become more familiar with cdrecord w/o the front-ends and
> add padding, options to become more familiar with the actual program
> that records the CDs.
More information about the test