mediacheck failing ...
gene.heskett at verizon.net
Fri Nov 23 19:56:03 UTC 2007
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 https://bugzilla.redhat.com/show_bug.cgi?id=177526
>>>> 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.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
And in the heartbreak years that lie ahead,
Be true to yourself and the Grateful Dead.
-- Joan Baez
More information about the fedora-list