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@xxxxxxxxxxx
> http://lists.caosity.org/mailman/listinfo/centos
>
