mediacheck failing ...

Bill Davidsen davidsen at
Mon Nov 26 18:35:43 UTC 2007

Gene Heskett wrote:
> On Friday 23 November 2007, Andre Robatino wrote:
>> Gene Heskett wrote:
>>> On Friday 23 November 2007, Andre Robatino wrote:
>>>> David Timms wrote:
>>>>> Andre Robatino wrote:
>>>>>> Andre Robatino wrote:
>>>>>>>  I'm pretty sure that it was fixed, or at least less likely to
>>>>>>> manifest.  I was using the same computer, with the same DVD drive,
>>>>>>> when F7 came out, and found by going through a pile of old Fedora
>>>>>>> CDs that I burned without padding that all of them passed mediacheck
>>>>>>> anyway, though many of them failed earlier.  Testing now with F8, I
>>>>>>> find that 3 out of 3 of them fail (I was convinced at that point and
>>>>>>> stopped checking).
>>>>>>  Just to clarify, the mediacheck I'm talking about is checkisomd5
>>>>>> from the anaconda-runtime package, which is the equivalent of the
>>>>>> regular mediacheck, but done while booted up in a currently installed
>>>>>> Fedora.  So my mediacheck was using the kernel in the distro being
>>>>>> used at the time (F7/F8), not the kernel on the old install discs
>>>>>> themselves, as would have been the case if I booted from them.
>>>>> find mediacheck
>>>>> This suggests certain hdparm parameters get applied when you boot the
>>>>> dvd and start linux mediacheck, this wouldn't happen if you are
>>>>> running from a live f7/8.
>>>>> Also there is suggestion to try:
>>>>> ide=nodma mediacheck
>>>>> in
>>>>> Does either make any difference ?
>>>>  I thought that using the word "mediacheck" only caused the installer
>>>> to go to the mediacheck immediately, instead of asking first, so we only
>>>> tried the "ide=nodma" option, which didn't help.  The latter, at least,
>>>> is definitely not a reliable workaround, but applying the proper
>>>> zero-padding seems to be.  Even if the ide=nodma works, one has to
>>>> remember to use it during the actual install, not just the mediacheck,
>>>> then to remove it from grub.conf later, since any options used during
>>>> install end up there.
>>> As has been stated here before, the only reliable way to do the mediacheck
>>> once the disk is burnt, is to call up something like kcalc, enter the size
>>> of the iso image as it sits on your hard drive, and divide by 2048, the
>>> size of a 'sector' on a cd/dvd.  Then use the answer as the count= in a
>>> command line to dd that looks something like this:
>>> dd if=/dev/dvd0 bs=2048, count=answer-above|sha1sum
>>> Then a readahead bug doesn't have a chance because you are only reading
>>> exactly the size of the .iso image.
>>  I always use the rawread script from
>> which does all this automatically.  The readahead bug prevents the last
>> tiny little bit of the ISO at the end from actually being read, so
>> knowing how big the ISO is supposed to be doesn't help since the part
>> that's readable is smaller than that.
> I was under the impression that is backwards, and that the readahead was 
> finding the end of the iso ok, but was handing the trailing garbage from the 
> previous read buffer to the summer, so it was getting an extra few hundred 
> bytes instead of a valid EOF at where ever the good data ended in the buffer. 
> This would be caused by an incorrect EOF checking sequence.
> Also, please note that when dd is given the exact number of blocks of size 
> 2048 to read, dd reports no EOF error, and the checksum is correct, so it 
> makes no sense to me that the actual is smaller than the iso.  That is not to 
> say that the iso doesn't have some trailing zero padding applied in order to 
> make it an even *2048 in size, but that is not and never has been an error.  
> The sha1sum (or md5sum) isn't effected by zero fill padding AFAIK.
> All that said, if that script works folks, use it.  Or shut readahead off in 
> your kernel builds.
That's a bit drastic! You can set it to zero with "blockdev --setra 0" 
instead, just when you want to verify something.

Bill Davidsen <davidsen at>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

More information about the fedora-list mailing list