Re: mediacheck failing ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 26 November 2007, Bill Davidsen wrote:
>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.
>>>>>>
>>>>>> http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Installer.html
>>>>>> 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
>>>
>>> http://www.troubleshooters.com/linux/coasterless.htm
>>>
>>> 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.

I wasn't aware it might be that simple.  Thanks.

Does that indeed fix the problem, Bill?  Just Curious(TM). :)

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



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
He jests at scars who never felt a wound.
		-- Shakespeare, "Romeo and Juliet, II. 2"


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux