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
>
