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