CentOS - Mar 2005 - Getting burned ISO''s to pass mediacheck.

Long long ago, in a mailing list far far away, a Red Hat Knight once uttered:
"*PLEASE MAKE SURE* that you are using the following command to
burn your CDs:

cdrecord -dev=x,x,x -v -dao -pad padsize=150s beta3-i386-discX.iso

I have seen mediacheck fail on CDs that were written without
the "-pad padsize=150s" option.  I do not recommend burning the
images under Win32, unless you are using cdrecord for win32,
which I have verified as working correctly."

Don''t ask where or by whom that was uttered.  I can''t tell
you.  I will say
that the person who said that above knows exactly what he''s talking
about,
and that it was uttered in 2002.

Under CentOS 4 itself, assuming an ATAPI CD burner, use something like (which
is the actual command I''m using):
cdrecord -dev=ATAPI:1,0,0 -v -dao -pad padsize=150s -eject
CentOS-4.0-i386-bin1of4.iso

k3b burnt discs can and do fail mediacheck; plus, it''s faster from the
command
line.... This is after, of course, you verify the MD5SUMs.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

hrmm.  I have burned several sets of CentOS 3 and 4 cd''s and
DVD''s without issue under win2k sp4 using nero 5.x. with a nec
burner single layer 4x dvd burner flashed to an 8x dual layer dvd
burner.

Lamar Owen wrote:
> Long long ago, in a mailing list far far away, a Red Hat Knight once
uttered:
> "*PLEASE MAKE SURE* that you are using the following command to
> burn your CDs:
>
> cdrecord -dev=x,x,x -v -dao -pad padsize=150s beta3-i386-discX.iso
>
> I have seen mediacheck fail on CDs that were written without
> the "-pad padsize=150s" option.  I do not recommend burning the
> images under Win32, unless you are using cdrecord for win32,
> which I have verified as working correctly."
>
> Don''t ask where or by whom that was uttered.  I can''t
tell you.  I will say
> that the person who said that above knows exactly what he''s
talking about,
> and that it was uttered in 2002.
>
> Under CentOS 4 itself, assuming an ATAPI CD burner, use something like
(which
> is the actual command I''m using):
> cdrecord -dev=ATAPI:1,0,0 -v -dao -pad padsize=150s -eject
> CentOS-4.0-i386-bin1of4.iso
>
> k3b burnt discs can and do fail mediacheck; plus, it''s faster from
the command
> line.... This is after, of course, you verify the MD5SUMs.
--
My "Foundation" verse:
Isa 54:17  No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/

On Thursday 03 March 2005 10:53, William Warren wrote:
> hrmm.  I have burned several sets of CentOS 3 and 4 cd''s and
> DVD''s without issue under win2k sp4 using nero 5.x. with a nec
> burner single layer 4x dvd burner flashed to an 8x dual layer dvd
> burner.
You got lucky, I believe.  But, again, remember that the advice was given in
2002, and that there have been several messages in the past couple of days
about discs failing mediacheck.  Given the list traffic, I dug into my
archives of messages on that list and found the advice (which I have been
using for some time myself, but I wanted to quote an expert on it.  Said
expert was and is well-known in Red Hat, and was at one time responsible for
getting good ISO''s to the CD pressing company Red Hat used.).  The
statement
about Win32 was uttered by him, not by me.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

the problem can be solved by appending 300kB worth of zeroes (dd
if=/dev/zero bs=2048 count=150 >> file.iso) to the iso before burning (it
just simulates padding) - if iso''s with this padding were distributed,
we''d get rid of the problem for good.

Cheers,
MaZe.

On Thu, 3 Mar 2005, Lamar Owen wrote:
> On Thursday 03 March 2005 10:53, William Warren wrote:
> > hrmm.  I have burned several sets of CentOS 3 and 4 cd''s and
> > DVD''s without issue under win2k sp4 using nero 5.x. with a
nec
> > burner single layer 4x dvd burner flashed to an 8x dual layer dvd
> > burner.
>
> You got lucky, I believe.  But, again, remember that the advice was given
in
> 2002, and that there have been several messages in the past couple of days
> about discs failing mediacheck.  Given the list traffic, I dug into my
> archives of messages on that list and found the advice (which I have been
> using for some time myself, but I wanted to quote an expert on it.  Said
> expert was and is well-known in Red Hat, and was at one time responsible
for
> getting good ISO''s to the CD pressing company Red Hat used.).  The
statement
> about Win32 was uttered by him, not by me.
>

On Thursday 03 March 2005 11:29, Maciej ?enczykowski
wrote:
> the problem can be solved by appending 300kB worth of zeroes (dd
> if=/dev/zero bs=2048 count=150 >> file.iso) to the iso before burning
(it
> just simulates padding) - if iso''s with this padding were
distributed,
> we''d get rid of the problem for good.
No, it wouldn''t, I believe.  The reason being is that zero pad changes
the MD5
sum of the ISO file.  As this shows:
[lowen@ditto iso]$ cp ubcd24.iso ubcd24-padded.iso
[lowen@ditto iso]$ dd if=/dev/zero bs=2048 count=150 >>ubcd24-padded.iso
150+0 records in
150+0 records out
[lowen@ditto iso]$ md5sum -b ubcd24.iso
10db8f4df5f44caa0af3ed8c83bad682 *ubcd24.iso
[lowen@ditto iso]$ md5sum -b ubcd24-padded.iso
e6dd60ac3623f2e489f3d3ab3cbf184c *ubcd24-padded.iso
[lowen@ditto iso]$

Now, that doesn''t sound bad until you remember that anaconda embeds the
MD5
inside the ISO during ISO filesystem creation.  This MD5 sum is what
mediacheck checks against, IIRC.

I could easily be wrong, but someone would just have to check and see.  I know
that the zero-padded ISO you would download would fail MD5 sum if you use the
automatically generated ISO MD5 sum made by anaconda (which is the only good
sum, in reality, because it is also inside the ISO itself).  To pass both sum
checks using the same sum for both checks requires the padding to be done at
burn time.  Otherwise Red Hat would have already done it that way; this is
far from the first time this question has come up.  It came up in 2002 on
another list of which I am a member, that much I know for sure.

Padding on a CD will not be read by accurate raw reading of the CD.  Yes, you
heard me right.  Simple dd of a CD is not accurate reading of that CD; you
need the right block count and blocksize to get an accurate ISO from the CD.
Anaconda does the read correctly, and does not see the padding for the
purposes of mediacheck.  So, your hand padded ISO will fail both checks.
But, try it and see if you get accurate results.  Burn a CentOS disc 1 with a
hand-padded ISO and see if it passes mediacheck.

The padding exists to work around bugs in some CD readers and some IDE
chipsets under Linux, which can cause a ''read-ahead'' bug to be
triggered.

More information at:
http://www.troubleshooters.com/linux/coasterless.htm
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

would be!

why?

cause anaconda doesn''t embed the md5 of the entire file in the file
(after
all how would one do that? you calc the md5 sum of the file and then you
change the file and the md5sum is no longer valid since you just change
the file and thus the md5sum...) - anaconda is smarter about it...
appending zeroes does change the md5sum of the file, but it doesn''t
affect
anaconda which doesn''t actually checksum the entire file anyway (just
the
area with the data).  And the -pad option to cdrecord does exactly this -
it appends 150sectors (2Kb each) so total 300KB worth of zeroes at the end
and burns the iso with this 300KB appended data to the disk.  If you use
cdrecord pad, then md5sum /dev/cdrom never returns the same value as
md5sum file.iso - since wc -c < /dev/cdrom is larger (the padding).

On Thu, 3 Mar 2005, Lamar Owen wrote:
> On Thursday 03 March 2005 11:29, Maciej ?enczykowski wrote:
> > the problem can be solved by appending 300kB worth of zeroes (dd
> > if=/dev/zero bs=2048 count=150 >> file.iso) to the iso before
burning (it
> > just simulates padding) - if iso''s with this padding were
distributed,
> > we''d get rid of the problem for good.
>
> No, it wouldn''t, I believe.  The reason being is that zero pad
changes the MD5
> sum of the ISO file.  As this shows:
> [lowen@ditto iso]$ cp ubcd24.iso ubcd24-padded.iso
> [lowen@ditto iso]$ dd if=/dev/zero bs=2048 count=150
>>ubcd24-padded.iso
> 150+0 records in
> 150+0 records out
> [lowen@ditto iso]$ md5sum -b ubcd24.iso
> 10db8f4df5f44caa0af3ed8c83bad682 *ubcd24.iso
> [lowen@ditto iso]$ md5sum -b ubcd24-padded.iso
> e6dd60ac3623f2e489f3d3ab3cbf184c *ubcd24-padded.iso
> [lowen@ditto iso]$
>
> Now, that doesn''t sound bad until you remember that anaconda
embeds the MD5
> inside the ISO during ISO filesystem creation.  This MD5 sum is what
> mediacheck checks against, IIRC.
>
> I could easily be wrong, but someone would just have to check and see.  I
know
> that the zero-padded ISO you would download would fail MD5 sum if you use
the
> automatically generated ISO MD5 sum made by anaconda (which is the only
good
> sum, in reality, because it is also inside the ISO itself).  To pass both
sum
> checks using the same sum for both checks requires the padding to be done
at
> burn time.  Otherwise Red Hat would have already done it that way; this is
> far from the first time this question has come up.  It came up in 2002 on
> another list of which I am a member, that much I know for sure.
>
> Padding on a CD will not be read by accurate raw reading of the CD.  Yes,
you
> heard me right.  Simple dd of a CD is not accurate reading of that CD; you
> need the right block count and blocksize to get an accurate ISO from the
CD.
> Anaconda does the read correctly, and does not see the padding for the
> purposes of mediacheck.  So, your hand padded ISO will fail both checks.
> But, try it and see if you get accurate results.  Burn a CentOS disc 1 with
a
> hand-padded ISO and see if it passes mediacheck.
>
> The padding exists to work around bugs in some CD readers and some IDE
> chipsets under Linux, which can cause a ''read-ahead'' bug
to be triggered.
>
> More information at:
> http://www.troubleshooters.com/linux/coasterless.htm
>

and even if you''re right, then anaconda should be patched...

On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
> would be!
>
> why?
>
> cause anaconda doesn''t embed the md5 of the entire file in the
file (after
> all how would one do that? you calc the md5 sum of the file and then you
> change the file and the md5sum is no longer valid since you just change
> the file and thus the md5sum...) - anaconda is smarter about it...
> appending zeroes does change the md5sum of the file, but it
doesn''t affect
> anaconda which doesn''t actually checksum the entire file anyway
(just the
> area with the data).  And the -pad option to cdrecord does exactly this -
> it appends 150sectors (2Kb each) so total 300KB worth of zeroes at the end
> and burns the iso with this 300KB appended data to the disk.  If you use
> cdrecord pad, then md5sum /dev/cdrom never returns the same value as
> md5sum file.iso - since wc -c < /dev/cdrom is larger (the padding).
>
> On Thu, 3 Mar 2005, Lamar Owen wrote:
>
> > On Thursday 03 March 2005 11:29, Maciej ?enczykowski wrote:
> > > the problem can be solved by appending 300kB worth of zeroes (dd
> > > if=/dev/zero bs=2048 count=150 >> file.iso) to the iso
before burning (it
> > > just simulates padding) - if iso''s with this padding
were distributed,
> > > we''d get rid of the problem for good.
> >
> > No, it wouldn''t, I believe.  The reason being is that zero
pad changes the MD5
> > sum of the ISO file.  As this shows:
> > [lowen@ditto iso]$ cp ubcd24.iso ubcd24-padded.iso
> > [lowen@ditto iso]$ dd if=/dev/zero bs=2048 count=150
>>ubcd24-padded.iso
> > 150+0 records in
> > 150+0 records out
> > [lowen@ditto iso]$ md5sum -b ubcd24.iso
> > 10db8f4df5f44caa0af3ed8c83bad682 *ubcd24.iso
> > [lowen@ditto iso]$ md5sum -b ubcd24-padded.iso
> > e6dd60ac3623f2e489f3d3ab3cbf184c *ubcd24-padded.iso
> > [lowen@ditto iso]$
> >
> > Now, that doesn''t sound bad until you remember that anaconda
embeds the MD5
> > inside the ISO during ISO filesystem creation.  This MD5 sum is what
> > mediacheck checks against, IIRC.
> >
> > I could easily be wrong, but someone would just have to check and see.
I know
> > that the zero-padded ISO you would download would fail MD5 sum if you
use the
> > automatically generated ISO MD5 sum made by anaconda (which is the
only good
> > sum, in reality, because it is also inside the ISO itself).  To pass
both sum
> > checks using the same sum for both checks requires the padding to be
done at
> > burn time.  Otherwise Red Hat would have already done it that way;
this is
> > far from the first time this question has come up.  It came up in 2002
on
> > another list of which I am a member, that much I know for sure.
> >
> > Padding on a CD will not be read by accurate raw reading of the CD. 
Yes, you
> > heard me right.  Simple dd of a CD is not accurate reading of that CD;
you
> > need the right block count and blocksize to get an accurate ISO from
the CD.
> > Anaconda does the read correctly, and does not see the padding for the
> > purposes of mediacheck.  So, your hand padded ISO will fail both
checks.
> > But, try it and see if you get accurate results.  Burn a CentOS disc 1
with a
> > hand-padded ISO and see if it passes mediacheck.
> >
> > The padding exists to work around bugs in some CD readers and some IDE
> > chipsets under Linux, which can cause a ''read-ahead''
bug to be triggered.
> >
> > More information at:
> > http://www.troubleshooters.com/linux/coasterless.htm
> >
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>

On Thu, 3 Mar 2005 11:22:40 -0500, Lamar Owen <lowen@pari.edu>
wrote:
> On Thursday 03 March 2005 10:53, William Warren wrote:
> > hrmm.  I have burned several sets of CentOS 3 and 4 cd''s and
> > DVD''s without issue under win2k sp4 using nero 5.x. with a
nec
> > burner single layer 4x dvd burner flashed to an 8x dual layer dvd
> > burner.
>
> You got lucky, I believe.
I find all of this moderately ridiculous.

I''ve burned ISO''s for 6-8 years on a variety of computers,
linux, and
windows systems at various recording speeds without using the -pad
value recommended here, and I''ve never yet burned an ISO that turned
out to be unusable with the possible exception of bad media.

As someone reported later in this thread, this probably has more to do
with certain flaky CD hardware and IDE chips than with any real
requirement. I would love to read a discussion of this problem by CD
writing gurus.

If someone is having a problem with CentOS ISO''s, perhaps this is
worth a try, but to state this as a universal truth seems to be beyond
the mark.

--
 Collins

> I find all of this moderately ridiculous.
>
> I''ve burned ISO''s for 6-8 years on a variety of
computers, linux, and
> windows systems at various recording speeds without using the -pad
> value recommended here, and I''ve never yet burned an ISO that
turned
> out to be unusable with the possible exception of bad media.
>
> As someone reported later in this thread, this probably has more to do
> with certain flaky CD hardware and IDE chips than with any real
> requirement. I would love to read a discussion of this problem by CD
> writing gurus.
>
> If someone is having a problem with CentOS ISO''s, perhaps this is
> worth a try, but to state this as a universal truth seems to be beyond
> the mark.
ok, liteon cd/dvd burner 832S (8xR-/R+ with dual layer support), rather
new fails to burn any CD image with size not % 32KB, so it needs 15
sectors (2KB) worth of padding to work - screwed up on CentOS4 CD1 and got
a bad cd (didn''t actually try media check, but cmp -l /dev/cdrom
centos4-i386-cd1.iso ended with /dev/cdrom: IO Error)

I don''t think my lite-on 48248S has this problem, so yes, it is burner
related - but - it is common.

Cheers,
MaZe.

I just installed CentOS-4 on my gaming server using the same
system to burn the iso I noted previously.  Everything went off
without a hitch..:)

Lamar Owen wrote:
> On Thursday 03 March 2005 10:53, William Warren wrote:
>
>>hrmm.  I have burned several sets of CentOS 3 and 4 cd''s and
>>DVD''s without issue under win2k sp4 using nero 5.x. with a nec
>>burner single layer 4x dvd burner flashed to an 8x dual layer dvd
>>burner.
>
>
> You got lucky, I believe.  But, again, remember that the advice was given
in
> 2002, and that there have been several messages in the past couple of days
> about discs failing mediacheck.  Given the list traffic, I dug into my
> archives of messages on that list and found the advice (which I have been
> using for some time myself, but I wanted to quote an expert on it.  Said
> expert was and is well-known in Red Hat, and was at one time responsible
for
> getting good ISO''s to the CD pressing company Red Hat used.).  The
statement
> about Win32 was uttered by him, not by me.
--
My "Foundation" verse:
Isa 54:17  No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/

On Thursday 03 March 2005 13:40, Collins Richey wrote:
> On Thu, 3 Mar 2005 11:22:40 -0500, Lamar Owen <lowen@pari.edu> wrote:
> > On Thursday 03 March 2005 10:53, William Warren wrote:
> > > hrmm.  I have burned several sets of CentOS 3 and 4 cd''s
and
> > > DVD''s without issue under win2k sp4 using nero 5.x. with
a nec
> > > burner single layer 4x dvd burner flashed to an 8x dual layer dvd
> > > burner.
> > You got lucky, I believe.
> I find all of this moderately ridiculous.
I find the whole deal ridiculous in that when a simple piece of advice is
given to try to help make more reliable installs people attempt to disect it.
That is what is ridiculous.
> I''ve burned ISO''s for 6-8 years on a variety of
computers, linux, and
> windows systems at various recording speeds without using the -pad
> value recommended here, and I''ve never yet burned an ISO that
turned
> out to be unusable with the possible exception of bad media.
Are you sure it was bad media?  Why not google for the situation;
http://www.troubleshooters.com/linux/coasterless.htm is a good primer on the
subject.

The point was and is that CD''s can fail mediacheck (I myself saw this
with
CentOS 4 Beta where four out of five CD''s failed mediacheck) but then
INSTALL
FINE.  I saw this, again, in an actual install on modern hardware using the
very CD drive that burned the name-brand media; that is, mediacheck failed
all but one of the install discs, but all of the install discs installed
FINE.  I have burned over a thousand discs over a period of several years as
well, and have had the experience of having media fail mediacheck on a fairly
high percentage, until I began using the padding, and at that point no more
failures.
> As someone reported later in this thread, this probably has more to do
> with certain flaky CD hardware and IDE chips than with any real
> requirement.
I would be that person, as well as the original poster of the thread.
> I would love to read a discussion of this problem by CD
> writing gurus.
Ok, the person in question was Aaron Brown at Red Hat.  Google for him
(abrown@redhat.com); he worked in QA at Red Hat for a long time.  Also see
the following links for ''discussions'' of this:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=137217
http://www.troubleshooters.com/linux/coasterless.htm
http://www.fedoraforum.org/forum/archive/index.php/t-2099.html
http://ubuntuforums.org/archive/index.php/t-12161.html
http://www.keithl.com/knoppixdisks.html

There is a lot of misinformation out there, that is for sure.

The fact of the matter is that real-world hardware possessed by a large number
of people need padding.  The solution is to pad.  Pad properly and the
problem goes away.  Nothing complex at all about it, and Red Hat for one has
been following that mantra for at least 4 years now.
> If someone is having a problem with CentOS ISO''s, perhaps this is
> worth a try, but to state this as a universal truth seems to be beyond
> the mark.
The post said ''recommended'' and the recomendation was by
someone who had found
through trial and error (lots of trial and error, being that he was in Red
Hat''s QA department!) that padding fixed the problems when nothing else
(including ide=nodma) would not.  Recommended!=universal truth.

Another recommendation was made to pre-pad the ISO''s.  This appears
that it
might work; I''m not going to take the time to check with media if it
does or
doesn''t work; using the anaconda checkiosmd5 tool on a prepadded ISO
does
return and exit code of 0, so it seems a prepadded ISO would pass mediacheck
IF it is actually read correctly off the CD (I did the test on my hard drive,
which is not the same as doing it off of CD, obviously).

This is my last post on the subject since people seem to be more interested in
splitting hairs than in helping people get a good burn on their hardware.
And whether their hardware is broken or not is irrelevant; there is a
recommendation that works for the vast majority of people that have the
problem, and I simply looked through my archives to try to help people get a
good burn.  If I had known that people were going to nitpick my post I would
not have bothered looking through my archives, nor would I have posted it.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu> wrote:
> This is my last post on the subject since people seem to be more interested
in
> splitting hairs than in helping people get a good burn on their hardware.
> And whether their hardware is broken or not is irrelevant; there is a
> recommendation that works for the vast majority of people that have the
> problem, and I simply looked through my archives to try to help people get
a
> good burn.  If I had known that people were going to nitpick my post I
> would not have bothered looking through my archives, nor would I have
> posted it.
> --
Please don''t consider my questions on the subject
"nitpicking." I''m
just enterested in learning "the rest of the story," most especially
since it runs counter to several years of my own experience.

Thank you for replying at length. Helping people to understand "why"
is somethimes just as important as understanding "how" or
"what."

--
 Collins

I''m pretty sure we should just prepad the ISO''s with 300KB
worth of zeroes
before calcing their md5sums and distributing them, I''ll check whether
this works (what''s a CD worth? 30cents?) in a moment and report back.
If this only passes mediacheck (all reports are it should) then this will
eliminate _all_ non-badburner and bad-media related burn errors (some 95%
I''d say) and save a lot of trouble for a lot of people (ie I wasted a
CD
and 10 minutes burning the 4 centos4 cd''s).

Cheers,
MaZe.

On Thu, 3 Mar 2005, Collins Richey wrote:
> On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu> wrote:
>
> > This is my last post on the subject since people seem to be more
interested in
> > splitting hairs than in helping people get a good burn on their
hardware.
> > And whether their hardware is broken or not is irrelevant; there is a
> > recommendation that works for the vast majority of people that have
the
> > problem, and I simply looked through my archives to try to help people
get a
> > good burn.  If I had known that people were going to nitpick my post I
> > would not have bothered looking through my archives, nor would I have
> > posted it.
> > --
>
> Please don''t consider my questions on the subject
"nitpicking." I''m
> just enterested in learning "the rest of the story," most
especially
> since it runs counter to several years of my own experience.
>
> Thank you for replying at length. Helping people to understand
"why"
> is somethimes just as important as understanding "how" or
"what."
>
>

mkisofs -pad ?
This is normally done by default unless you use -nopad

Read http://www.troubleshooters.com/linux/coasterless.htm
it has good info, (except for a dd typo)

John.

Maciej ?enczykowski wrote:
> I''m pretty sure we should just prepad the ISO''s with
300KB worth of zeroes
> before calcing their md5sums and distributing them, I''ll check
whether
> this works (what''s a CD worth? 30cents?) in a moment and report
back.
> If this only passes mediacheck (all reports are it should) then this will
> eliminate _all_ non-badburner and bad-media related burn errors (some 95%
> I''d say) and save a lot of trouble for a lot of people (ie I
wasted a CD
> and 10 minutes burning the 4 centos4 cd''s).
>
> Cheers,
> MaZe.
>
> On Thu, 3 Mar 2005, Collins Richey wrote:
>
>
>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu>
wrote:
>>
>>
>>>This is my last post on the subject since people seem to be more
interested in
>>>splitting hairs than in helping people get a good burn on their
hardware.
>>>And whether their hardware is broken or not is irrelevant; there is
a
>>>recommendation that works for the vast majority of people that have
the
>>>problem, and I simply looked through my archives to try to help
people get a
>>>good burn.  If I had known that people were going to nitpick my post
I
>>>would not have bothered looking through my archives, nor would I
have
>>>posted it.
>>>--
>>
>>Please don''t consider my questions on the subject
"nitpicking." I''m
>>just enterested in learning "the rest of the story," most
especially
>>since it runs counter to several years of my own experience.
>>
>>Thank you for replying at length. Helping people to understand
"why"
>>is somethimes just as important as understanding "how" or
"what."
>>
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>
>
>

--
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin

I just burned 3 CD''s (at speed 16 on a 40x capable burner) of
"CentOS4
i386-bin CD1" (md5sum of image on HDD is OK, after padding it changes but
who cares)
One straight from iso, the other with appended 300KB zeroes, the third
with cdrecord -pad.

CD A: iso
CD B: iso with builtin 300KB pad (150 sectors of 2KB, IMHO 15 is enough)
CD C: iso with cdrecord -pad (15 zeroed sectors of 2KB = 30KB)

cmp -l /dev/cdrom file.iso-unpadded
CD A: IO error (within the last 30KB)
CD B: EOF on file.iso
CD C: EOF on file.iso

cmp -l /dev/cdrom file.iso-prepadded
CD B: OK
[wonder why I''d expect an
IO error (within the last 30KB of the padded image)]

running md5sum on CD A/B gives IO ERRORS, while C works (think this was
just a matter of luck).

My theoretical explanation which isn''t perfect:
Why? Cause the burner can only burn in 32KB blocks (16 sectors) and
anything leftover doesn''t burn (is left of the disk, so it
can''t be read)
(my drive: [LITE-ON ][DVDRW SOHW-832S ][VS0A])

CD A: Mediacheck FAIL
CD B: Mediacheck OK
CD C: Mediacheck OK

This proves pre-padding CD iso images before distribution with a few (30KB
at least, 300KB suggested) KB worth of zeroes fixes burn issues and
retains a working mediacheck - even if the last part of the burned image
is unreadable (since it''ll be in the unimportant padding...)

Thus images should be padded after implanting the md5sum and before
calculating the md5sum for distribution.

ie.
mkisofs > file.iso
impland-md5iso file.iso
dd if=/dev/zero bs=2048 count=150 >> file.iso
md5sum file.iso > MD5SUMS
upload file.iso MD5SUMS

Cheers,
MaZe.

On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
> I''m pretty sure we should just prepad the ISO''s with
300KB worth of zeroes
> before calcing their md5sums and distributing them, I''ll check
whether
> this works (what''s a CD worth? 30cents?) in a moment and report
back.
> If this only passes mediacheck (all reports are it should) then this will
> eliminate _all_ non-badburner and bad-media related burn errors (some 95%
> I''d say) and save a lot of trouble for a lot of people (ie I
wasted a CD
> and 10 minutes burning the 4 centos4 cd''s).
>
> Cheers,
> MaZe.
>
> On Thu, 3 Mar 2005, Collins Richey wrote:
>
> > On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu>
wrote:
> >
> > > This is my last post on the subject since people seem to be more
interested in
> > > splitting hairs than in helping people get a good burn on their
hardware.
> > > And whether their hardware is broken or not is irrelevant; there
is a
> > > recommendation that works for the vast majority of people that
have the
> > > problem, and I simply looked through my archives to try to help
people get a
> > > good burn.  If I had known that people were going to nitpick my
post I
> > > would not have bothered looking through my archives, nor would I
have
> > > posted it.
> > > --
> >
> > Please don''t consider my questions on the subject
"nitpicking." I''m
> > just enterested in learning "the rest of the story," most
especially
> > since it runs counter to several years of my own experience.
> >
> > Thank you for replying at length. Helping people to understand
"why"
> > is somethimes just as important as understanding "how" or
"what."
> >
> >
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>

this seems to be a burner issue with that liteon.  With my NEC i
burned them straight from the isos without issue.  Even using an
old cranky hp 10x burner i did not have any problems with he
isos.  This i think falls under a hardware issue not a .iso issue.

Maciej ?enczykowski wrote:
> I just burned 3 CD''s (at speed 16 on a 40x capable burner) of
"CentOS4
> i386-bin CD1" (md5sum of image on HDD is OK, after padding it changes
but
> who cares)
> One straight from iso, the other with appended 300KB zeroes, the third
> with cdrecord -pad.
>
> CD A: iso
> CD B: iso with builtin 300KB pad (150 sectors of 2KB, IMHO 15 is enough)
> CD C: iso with cdrecord -pad (15 zeroed sectors of 2KB = 30KB)
>
> cmp -l /dev/cdrom file.iso-unpadded
> CD A: IO error (within the last 30KB)
> CD B: EOF on file.iso
> CD C: EOF on file.iso
>
> cmp -l /dev/cdrom file.iso-prepadded
> CD B: OK
> [wonder why I''d expect an
> IO error (within the last 30KB of the padded image)]
>
> running md5sum on CD A/B gives IO ERRORS, while C works (think this was
> just a matter of luck).
>
> My theoretical explanation which isn''t perfect:
> Why? Cause the burner can only burn in 32KB blocks (16 sectors) and
> anything leftover doesn''t burn (is left of the disk, so it
can''t be read)
> (my drive: [LITE-ON ][DVDRW SOHW-832S ][VS0A])
>
> CD A: Mediacheck FAIL
> CD B: Mediacheck OK
> CD C: Mediacheck OK
>
> This proves pre-padding CD iso images before distribution with a few (30KB
> at least, 300KB suggested) KB worth of zeroes fixes burn issues and
> retains a working mediacheck - even if the last part of the burned image
> is unreadable (since it''ll be in the unimportant padding...)
>
> Thus images should be padded after implanting the md5sum and before
> calculating the md5sum for distribution.
>
> ie.
> mkisofs > file.iso
> impland-md5iso file.iso
> dd if=/dev/zero bs=2048 count=150 >> file.iso
> md5sum file.iso > MD5SUMS
> upload file.iso MD5SUMS
>
> Cheers,
> MaZe.
>
> On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
>
>
>>I''m pretty sure we should just prepad the ISO''s with
300KB worth of zeroes
>>before calcing their md5sums and distributing them, I''ll check
whether
>>this works (what''s a CD worth? 30cents?) in a moment and report
back.
>>If this only passes mediacheck (all reports are it should) then this
will
>>eliminate _all_ non-badburner and bad-media related burn errors (some
95%
>>I''d say) and save a lot of trouble for a lot of people (ie I
wasted a CD
>>and 10 minutes burning the 4 centos4 cd''s).
>>
>>Cheers,
>>MaZe.
>>
>>On Thu, 3 Mar 2005, Collins Richey wrote:
>>
>>
>>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu>
wrote:
>>>
>>>
>>>>This is my last post on the subject since people seem to be more
interested in
>>>>splitting hairs than in helping people get a good burn on their
hardware.
>>>>And whether their hardware is broken or not is irrelevant; there
is a
>>>>recommendation that works for the vast majority of people that
have the
>>>>problem, and I simply looked through my archives to try to help
people get a
>>>>good burn.  If I had known that people were going to nitpick my
post I
>>>>would not have bothered looking through my archives, nor would I
have
>>>>posted it.
>>>>--
>>>
>>>Please don''t consider my questions on the subject
"nitpicking." I''m
>>>just enterested in learning "the rest of the story," most
especially
>>>since it runs counter to several years of my own experience.
>>>
>>>Thank you for replying at length. Helping people to understand
"why"
>>>is somethimes just as important as understanding "how" or
"what."
>>>
>>>
>>
>>_______________________________________________
>>CentOS mailing list
>>CentOS@caosity.org
>>http://lists.caosity.org/mailman/listinfo/centos
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>
--
My "Foundation" verse:
Isa 54:17  No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/

I burned the cd iso''s at either 10x(hp) or 32x(nec) without
issues using verbatim and maxell cd-r''s.  I burned the dvd''s
with
the nec at 8x on maxell media without issues.

Maciej ?enczykowski wrote:
> I just burned 3 CD''s (at speed 16 on a 40x capable burner) of
"CentOS4
> i386-bin CD1" (md5sum of image on HDD is OK, after padding it changes
but
> who cares)
> One straight from iso, the other with appended 300KB zeroes, the third
> with cdrecord -pad.
>
> CD A: iso
> CD B: iso with builtin 300KB pad (150 sectors of 2KB, IMHO 15 is enough)
> CD C: iso with cdrecord -pad (15 zeroed sectors of 2KB = 30KB)
>
> cmp -l /dev/cdrom file.iso-unpadded
> CD A: IO error (within the last 30KB)
> CD B: EOF on file.iso
> CD C: EOF on file.iso
>
> cmp -l /dev/cdrom file.iso-prepadded
> CD B: OK
> [wonder why I''d expect an
> IO error (within the last 30KB of the padded image)]
>
> running md5sum on CD A/B gives IO ERRORS, while C works (think this was
> just a matter of luck).
>
> My theoretical explanation which isn''t perfect:
> Why? Cause the burner can only burn in 32KB blocks (16 sectors) and
> anything leftover doesn''t burn (is left of the disk, so it
can''t be read)
> (my drive: [LITE-ON ][DVDRW SOHW-832S ][VS0A])
>
> CD A: Mediacheck FAIL
> CD B: Mediacheck OK
> CD C: Mediacheck OK
>
> This proves pre-padding CD iso images before distribution with a few (30KB
> at least, 300KB suggested) KB worth of zeroes fixes burn issues and
> retains a working mediacheck - even if the last part of the burned image
> is unreadable (since it''ll be in the unimportant padding...)
>
> Thus images should be padded after implanting the md5sum and before
> calculating the md5sum for distribution.
>
> ie.
> mkisofs > file.iso
> impland-md5iso file.iso
> dd if=/dev/zero bs=2048 count=150 >> file.iso
> md5sum file.iso > MD5SUMS
> upload file.iso MD5SUMS
>
> Cheers,
> MaZe.
>
> On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
>
>
>>I''m pretty sure we should just prepad the ISO''s with
300KB worth of zeroes
>>before calcing their md5sums and distributing them, I''ll check
whether
>>this works (what''s a CD worth? 30cents?) in a moment and report
back.
>>If this only passes mediacheck (all reports are it should) then this
will
>>eliminate _all_ non-badburner and bad-media related burn errors (some
95%
>>I''d say) and save a lot of trouble for a lot of people (ie I
wasted a CD
>>and 10 minutes burning the 4 centos4 cd''s).
>>
>>Cheers,
>>MaZe.
>>
>>On Thu, 3 Mar 2005, Collins Richey wrote:
>>
>>
>>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen <lowen@pari.edu>
wrote:
>>>
>>>
>>>>This is my last post on the subject since people seem to be more
interested in
>>>>splitting hairs than in helping people get a good burn on their
hardware.
>>>>And whether their hardware is broken or not is irrelevant; there
is a
>>>>recommendation that works for the vast majority of people that
have the
>>>>problem, and I simply looked through my archives to try to help
people get a
>>>>good burn.  If I had known that people were going to nitpick my
post I
>>>>would not have bothered looking through my archives, nor would I
have
>>>>posted it.
>>>>--
>>>
>>>Please don''t consider my questions on the subject
"nitpicking." I''m
>>>just enterested in learning "the rest of the story," most
especially
>>>since it runs counter to several years of my own experience.
>>>
>>>Thank you for replying at length. Helping people to understand
"why"
>>>is somethimes just as important as understanding "how" or
"what."
>>>
>>>
>>
>>_______________________________________________
>>CentOS mailing list
>>CentOS@caosity.org
>>http://lists.caosity.org/mailman/listinfo/centos
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>
--
My "Foundation" verse:
Isa 54:17  No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/

Hello William,

I would confirm that. I''m using an old USB Backpack CDreWriter at 4x,
and it''s flawless.  It never seems to fail, where my faster burners
often seem to skip a beat.  I''ve managed to get all the iso''s
burnt
without problem and have successfully installed from them.

--
Best regards,
 Mickael
 mailto:mike@kamloopsbc.com


Friday, March 4, 2005, 7:26:26 AM, you wrote:

WW> I burned the cd iso''s at either 10x(hp) or 32x(nec) without
WW> issues using verbatim and maxell cd-r''s.  I burned the
dvd''s with
WW> the nec at 8x on maxell media without issues.

WW> Maciej ?enczykowski wrote:
>> I just burned 3 CD''s (at speed 16 on a 40x capable burner) of
"CentOS4
>> i386-bin CD1" (md5sum of image on HDD is OK, after padding it
changes but
>> who cares)
>> One straight from iso, the other with appended 300KB zeroes, the third
>> with cdrecord -pad.
>>
>> CD A: iso
>> CD B: iso with builtin 300KB pad (150 sectors of 2KB, IMHO 15 is
enough)
>> CD C: iso with cdrecord -pad (15 zeroed sectors of 2KB = 30KB)
>>
>> cmp -l /dev/cdrom file.iso-unpadded
>> CD A: IO error (within the last 30KB)
>> CD B: EOF on file.iso
>> CD C: EOF on file.iso
>>
>> cmp -l /dev/cdrom file.iso-prepadded
>> CD B: OK
>> [wonder why I''d expect an
>> IO error (within the last 30KB of the padded image)]
>>
>> running md5sum on CD A/B gives IO ERRORS, while C works (think this was
>> just a matter of luck).
>>
>> My theoretical explanation which isn''t perfect:
>> Why? Cause the burner can only burn in 32KB blocks (16 sectors) and
>> anything leftover doesn''t burn (is left of the disk, so it
can''t be read)
>> (my drive: [LITE-ON ][DVDRW SOHW-832S ][VS0A])
>>
>> CD A: Mediacheck FAIL
>> CD B: Mediacheck OK
>> CD C: Mediacheck OK
>>
>> This proves pre-padding CD iso images before distribution with a few
(30KB
>> at least, 300KB suggested) KB worth of zeroes fixes burn issues and
>> retains a working mediacheck - even if the last part of the burned
image
>> is unreadable (since it''ll be in the unimportant padding...)
>>
>> Thus images should be padded after implanting the md5sum and before
>> calculating the md5sum for distribution.
>>
>> ie.
>> mkisofs > file.iso
>> impland-md5iso file.iso
>> dd if=/dev/zero bs=2048 count=150 >> file.iso
>> md5sum file.iso > MD5SUMS
>> upload file.iso MD5SUMS
>>
>> Cheers,
>> MaZe.
>>
>> On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
>>
>>
>>>I''m pretty sure we should just prepad the ISO''s
with 300KB worth of zeroes
>>>before calcing their md5sums and distributing them, I''ll
check whether
>>>this works (what''s a CD worth? 30cents?) in a moment and
report back.
>>>If this only passes mediacheck (all reports are it should) then this
will
>>>eliminate _all_ non-badburner and bad-media related burn errors
(some 95%
>>>I''d say) and save a lot of trouble for a lot of people (ie
I wasted a CD
>>>and 10 minutes burning the 4 centos4 cd''s).
>>>
>>>Cheers,
>>>MaZe.
>>>
>>>On Thu, 3 Mar 2005, Collins Richey wrote:
>>>
>>>
>>>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen
<lowen@pari.edu> wrote:
>>>>
>>>>
>>>>>This is my last post on the subject since people seem to be
more interested in
>>>>>splitting hairs than in helping people get a good burn on
their hardware.
>>>>>And whether their hardware is broken or not is irrelevant;
there is a
>>>>>recommendation that works for the vast majority of people
that have the
>>>>>problem, and I simply looked through my archives to try to
help people get a
>>>>>good burn.  If I had known that people were going to nitpick
my post I
>>>>>would not have bothered looking through my archives, nor
would I have
>>>>>posted it.
>>>>>--
>>>>
>>>>Please don''t consider my questions on the subject
"nitpicking." I''m
>>>>just enterested in learning "the rest of the story,"
most especially
>>>>since it runs counter to several years of my own experience.
>>>>
>>>>Thank you for replying at length. Helping people to understand
"why"
>>>>is somethimes just as important as understanding "how"
or "what."
>>>>
>>>>
>>>
>>>_______________________________________________
>>>CentOS mailing list
>>>CentOS@caosity.org
>>>http://lists.caosity.org/mailman/listinfo/centos
>>>
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@caosity.org
>> http://lists.caosity.org/mailman/listinfo/centos
>>

It may be a hardware issue, but it isn''t restricted to Lite-On.

I have had this problem with Fedora Core 3 and CentOS ISO''s. I had
never
had this problem before.

I have three burners, two DVD+/-R and one CD+R. All three have the same
problem.

HP      '' ''DVD Writer 200j '' ''1.06''
Removable CD-ROM
SONY    '' ''DVD RW DRU-710A '' ''BY02''
Removable CD-ROM
SAMSUNG '' ''CDRW/DVD SN-324F'' ''U203''
Removable CD-ROM

I just tried the -pad option on the Sony and got a good Fedora Core 3
disk 1.

Dave

William Warren wrote:
> this seems to be a burner issue with that liteon.  With my NEC i
> burned them straight from the isos without issue.  Even using an old
> cranky hp 10x burner i did not have any problems with he isos.  This i
> think falls under a hardware issue not a .iso issue.
>

no it''s an iso issue - because it can be fixed in the iso, and a _lot_,
_lot_ of different brand burners have this problem (like hundreds of
different models from different manufacturers) - it''s classic case
where
fixing it in software is worth it... especially DVD burners have this
problem as many can''t record 2KB sectors and can only do 32KB...

On Fri, 4 Mar 2005, William Warren wrote:
> this seems to be a burner issue with that liteon.  With my NEC i
> burned them straight from the isos without issue.  Even using an
> old cranky hp 10x burner i did not have any problems with he
> isos.  This i think falls under a hardware issue not a .iso issue.
>
> Maciej ?enczykowski wrote:
> > I just burned 3 CD''s (at speed 16 on a 40x capable burner) of
"CentOS4
> > i386-bin CD1" (md5sum of image on HDD is OK, after padding it
changes but
> > who cares)
> > One straight from iso, the other with appended 300KB zeroes, the third
> > with cdrecord -pad.
> >
> > CD A: iso
> > CD B: iso with builtin 300KB pad (150 sectors of 2KB, IMHO 15 is
enough)
> > CD C: iso with cdrecord -pad (15 zeroed sectors of 2KB = 30KB)
> >
> > cmp -l /dev/cdrom file.iso-unpadded
> > CD A: IO error (within the last 30KB)
> > CD B: EOF on file.iso
> > CD C: EOF on file.iso
> >
> > cmp -l /dev/cdrom file.iso-prepadded
> > CD B: OK
> > [wonder why I''d expect an
> > IO error (within the last 30KB of the padded image)]
> >
> > running md5sum on CD A/B gives IO ERRORS, while C works (think this
was
> > just a matter of luck).
> >
> > My theoretical explanation which isn''t perfect:
> > Why? Cause the burner can only burn in 32KB blocks (16 sectors) and
> > anything leftover doesn''t burn (is left of the disk, so it
can''t be read)
> > (my drive: [LITE-ON ][DVDRW SOHW-832S ][VS0A])
> >
> > CD A: Mediacheck FAIL
> > CD B: Mediacheck OK
> > CD C: Mediacheck OK
> >
> > This proves pre-padding CD iso images before distribution with a few
(30KB
> > at least, 300KB suggested) KB worth of zeroes fixes burn issues and
> > retains a working mediacheck - even if the last part of the burned
image
> > is unreadable (since it''ll be in the unimportant padding...)
> >
> > Thus images should be padded after implanting the md5sum and before
> > calculating the md5sum for distribution.
> >
> > ie.
> > mkisofs > file.iso
> > impland-md5iso file.iso
> > dd if=/dev/zero bs=2048 count=150 >> file.iso
> > md5sum file.iso > MD5SUMS
> > upload file.iso MD5SUMS
> >
> > Cheers,
> > MaZe.
> >
> > On Thu, 3 Mar 2005, Maciej ?enczykowski wrote:
> >
> >
> >>I''m pretty sure we should just prepad the ISO''s
with 300KB worth of zeroes
> >>before calcing their md5sums and distributing them, I''ll
check whether
> >>this works (what''s a CD worth? 30cents?) in a moment and
report back.
> >>If this only passes mediacheck (all reports are it should) then
this will
> >>eliminate _all_ non-badburner and bad-media related burn errors
(some 95%
> >>I''d say) and save a lot of trouble for a lot of people (ie
I wasted a CD
> >>and 10 minutes burning the 4 centos4 cd''s).
> >>
> >>Cheers,
> >>MaZe.
> >>
> >>On Thu, 3 Mar 2005, Collins Richey wrote:
> >>
> >>
> >>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen
<lowen@pari.edu> wrote:
> >>>
> >>>
> >>>>This is my last post on the subject since people seem to be
more interested in
> >>>>splitting hairs than in helping people get a good burn on
their hardware.
> >>>>And whether their hardware is broken or not is irrelevant;
there is a
> >>>>recommendation that works for the vast majority of people
that have the
> >>>>problem, and I simply looked through my archives to try to
help people get a
> >>>>good burn.  If I had known that people were going to
nitpick my post I
> >>>>would not have bothered looking through my archives, nor
would I have
> >>>>posted it.
> >>>>--
> >>>
> >>>Please don''t consider my questions on the subject
"nitpicking." I''m
> >>>just enterested in learning "the rest of the story,"
most especially
> >>>since it runs counter to several years of my own experience.
> >>>
> >>>Thank you for replying at length. Helping people to understand
"why"
> >>>is somethimes just as important as understanding
"how" or "what."
> >>>
> >>>
> >>
> >>_______________________________________________
> >>CentOS mailing list
> >>CentOS@caosity.org
> >>http://lists.caosity.org/mailman/listinfo/centos
> >>
> >
> > _______________________________________________
> > CentOS mailing list
> > CentOS@caosity.org
> > http://lists.caosity.org/mailman/listinfo/centos
> >
>
>

there''s nothing to confirm - I know and stated this was a burner issue
-
but there''s millions of these burners out and about (hundreds of models
from dozens of manufacturers, with thousands of each type sold to
consumers) - it''s not a matter of something failing on Samsung CDZ678,
it
fails on Samasung CDZ687 CD^T&* CD%T^*& CD^*&CD %^*&CD
*%&CD%* C% *D%*CD
and Toshiba CD&*( CC^D(& CD^(&* C^D*&( CD^(& C^D(, and
LiteOn CD^*& CD^&(*
CD^*& CD^&* C^D*&, etc... (those were model numbers, just did some
quick
typing :) )

On Fri, 4 Mar 2005, Mickael Maddison wrote:
> Hello William,
>
> I would confirm that. I''m using an old USB Backpack CDreWriter at
4x,
> and it''s flawless.  It never seems to fail, where my faster
burners
> often seem to skip a beat.  I''ve managed to get all the
iso''s burnt
> without problem and have successfully installed from them.
>
>

I beg to differ:

man cdrecord (FC2):
      -nopad Do not pad the following tracks - the default.


On Fri, 4 Mar 2005, John Newbigin wrote:
> mkisofs -pad ?
> This is normally done by default unless you use -nopad
>
> Read http://www.troubleshooters.com/linux/coasterless.htm
> it has good info, (except for a dd typo)
>
> John.
>
> Maciej ?enczykowski wrote:
>
> > I''m pretty sure we should just prepad the ISO''s with
300KB worth of zeroes
> > before calcing their md5sums and distributing them, I''ll
check whether
> > this works (what''s a CD worth? 30cents?) in a moment and
report back.
> > If this only passes mediacheck (all reports are it should) then this
will
> > eliminate _all_ non-badburner and bad-media related burn errors (some
95%
> > I''d say) and save a lot of trouble for a lot of people (ie I
wasted a CD
> > and 10 minutes burning the 4 centos4 cd''s).
> >
> > Cheers,
> > MaZe.
> >
> > On Thu, 3 Mar 2005, Collins Richey wrote:
> >
> >
> >>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen
<lowen@pari.edu> wrote:
> >>
> >>
> >>>This is my last post on the subject since people seem to be
more interested in
> >>>splitting hairs than in helping people get a good burn on their
hardware.
> >>>And whether their hardware is broken or not is irrelevant;
there is a
> >>>recommendation that works for the vast majority of people that
have the
> >>>problem, and I simply looked through my archives to try to help
people get a
> >>>good burn.  If I had known that people were going to nitpick my
post I
> >>>would not have bothered looking through my archives, nor would
I have
> >>>posted it.
> >>>--
> >>
> >>Please don''t consider my questions on the subject
"nitpicking." I''m
> >>just enterested in learning "the rest of the story," most
especially
> >>since it runs counter to several years of my own experience.
> >>
> >>Thank you for replying at length. Helping people to understand
"why"
> >>is somethimes just as important as understanding "how" or
"what."
> >>
> >>
> >
> > _______________________________________________
> > CentOS mailing list
> > CentOS@caosity.org
> > http://lists.caosity.org/mailman/listinfo/centos
> >
> >
> >
>
>
>

we will agree to disagree..this is a hardware issue..you just
said so..there are many more millions of drives that work fine.
The number of drives with a problem are in the minority..not
majority.

Maciej ?enczykowski wrote:
> there''s nothing to confirm - I know and stated this was a burner
issue -
> but there''s millions of these burners out and about (hundreds of
models
> from dozens of manufacturers, with thousands of each type sold to
> consumers) - it''s not a matter of something failing on Samsung
CDZ678, it
> fails on Samasung CDZ687 CD^T&* CD%T^*& CD^*&CD %^*&CD
*%&CD%* C% *D%*CD
> and Toshiba CD&*( CC^D(& CD^(&* C^D*&( CD^(& C^D(, and
LiteOn CD^*& CD^&(*
> CD^*& CD^&* C^D*&, etc... (those were model numbers, just did
some quick
> typing :) )
>
> On Fri, 4 Mar 2005, Mickael Maddison wrote:
>
>
>>Hello William,
>>
>>I would confirm that. I''m using an old USB Backpack CDreWriter
at 4x,
>>and it''s flawless.  It never seems to fail, where my faster
burners
>>often seem to skip a beat.  I''ve managed to get all the
iso''s burnt
>>without problem and have successfully installed from them.
>>
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>
--
My "Foundation" verse:
Isa 54:17  No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.

-- carpe ductum -- "Grab the tape"
CDTT (Certified Duct Tape Technician)

Linux user #322099
Machines:
206822
256638
276825
http://counter.li.org/

mkisofs-2.0-11.AS21.1 (CentOS-2) &
mkisofs-2.01.0.a32-0.EL3.1 (CentOS-3) both have:
               To avoid problems with I/O error on the  last  file
               on  the  filesystem,  the -pad option has been made
               the default.


Perhaps this change is why the ISO problem has only become a major issue
now.

Were the CentOS-4 ISOs created with -pad?  If not, would it be worth
reissuing them?  (with some missing packages added too?).

John.



Maciej ?enczykowski wrote:
> I beg to differ:
>
> man cdrecord (FC2):
>       -nopad Do not pad the following tracks - the default.
>
>
> On Fri, 4 Mar 2005, John Newbigin wrote:
>
>
>>mkisofs -pad ?
>>This is normally done by default unless you use -nopad
>>
>>Read http://www.troubleshooters.com/linux/coasterless.htm
>>it has good info, (except for a dd typo)
>>
>>John.
>>
>>Maciej ?enczykowski wrote:
>>
>>
>>>I''m pretty sure we should just prepad the ISO''s
with 300KB worth of zeroes
>>>before calcing their md5sums and distributing them, I''ll
check whether
>>>this works (what''s a CD worth? 30cents?) in a moment and
report back.
>>>If this only passes mediacheck (all reports are it should) then this
will
>>>eliminate _all_ non-badburner and bad-media related burn errors
(some 95%
>>>I''d say) and save a lot of trouble for a lot of people (ie
I wasted a CD
>>>and 10 minutes burning the 4 centos4 cd''s).
>>>
>>>Cheers,
>>>MaZe.
>>>
>>>On Thu, 3 Mar 2005, Collins Richey wrote:
>>>
>>>
>>>
>>>>On Thu, 3 Mar 2005 14:27:02 -0500, Lamar Owen
<lowen@pari.edu> wrote:
>>>>
>>>>
>>>>
>>>>>This is my last post on the subject since people seem to be
more interested in
>>>>>splitting hairs than in helping people get a good burn on
their hardware.
>>>>>And whether their hardware is broken or not is irrelevant;
there is a
>>>>>recommendation that works for the vast majority of people
that have the
>>>>>problem, and I simply looked through my archives to try to
help people get a
>>>>>good burn.  If I had known that people were going to nitpick
my post I
>>>>>would not have bothered looking through my archives, nor
would I have
>>>>>posted it.
>>>>>--
>>>>
>>>>Please don''t consider my questions on the subject
"nitpicking." I''m
>>>>just enterested in learning "the rest of the story,"
most especially
>>>>since it runs counter to several years of my own experience.
>>>>
>>>>Thank you for replying at length. Helping people to understand
"why"
>>>>is somethimes just as important as understanding "how"
or "what."
>>>>
>>>>
>>>
>>>_______________________________________________
>>>CentOS mailing list
>>>CentOS@caosity.org
>>>http://lists.caosity.org/mailman/listinfo/centos
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> CentOS mailing list
> CentOS@caosity.org
> http://lists.caosity.org/mailman/listinfo/centos
>
>
>

--
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin