Re: mediacheck failing ...

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

 



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

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux