Bug 186512

Summary: kernel prevents proper CD checking (mediacheck/install fails)
Product: [Fedora] Fedora Reporter: Andre Robatino <robatino>
Component: kernelAssignee: Peter Martuccelli <peterm>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 16CC: bughunt, davehorn1, don.mies, dsnillo, jforbes, kernel-maint, paul, pmiehe, s.clement, triage, wtogami
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-14 11:36:48 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
The Anaconda dump text none

Description Andre Robatino 2006-03-23 18:37:02 EST
Description of problem:
  Downloaded all 5 FC5 ISOs, verified them against the SHA1SUM file, used gpg
--verify to check the signature on the SHA1SUM file, then burned the CDs.  On
one of my machines, all 5 CDs pass mediacheck, which presumably means the discs
are good.  On another, about half of the CDs fail the mediacheck.  I have 3 CD
or DVD drives and 2 machines, and based on some limited experience swapping the
CD drives, I conjecture that vulnerability to this bug depends only on the CD or
DVD drive, not on which box it's in, and that there are 3 categories of CD or
DVD drive:
1) Those never affected, so mediacheck works properly.
2) Those affected, but for which using "ide=nodma" prevents the problem (though
I have to wonder if a problem which can cause mediacheck to fail can cause data
corruption during normal use).
3) Those affected, and for which "ide=nodma" doesn't help.
I have one drive of each type.  The type 2) drive fails about half the discs
without "ide=nodma".  The type 3) drive fails all the discs.

Version-Release number of selected component (if applicable):
kernel-2.6.15-1.2054_FC5

How reproducible:
always (depending on hardware)

Steps to Reproduce:
1.  Try running mediacheck to verify known good CDs.
  
Actual results:
  Some or all the CDs will fail, depending on whether one uses "ide=nodma", and
on the model of CD/DVD drive.

Expected results:
  Mediacheck should always pass good discs without any special command-line magic.

Additional info:
  In my experience, exactly which discs fail doesn't mean much: something as
simple as plugging or unplugging some peripherals from the PC can change this. 
The only thing that's constant is whether or not the specific hardware is
vulnerable or not, and I think it only depends on the drive itself.  Also, if
one is vulnerable to the mediacheck problem, an install will often fail with a
complaint that a specific package is corrupt.  It should be noted that since
mediacheck only fails about half the discs, if one burns a single install DVD,
it might pass by dumb luck, but still cause the install to fail due to a
complaint about a corrupt package.
  It amazes me that a bug which has existed at least as long as mediacheck
itself (4 years) STILL isn't fixed.  There was some mention of this bug in the
FC4 release notes, but it was faulty - it blamed the problem on mediacheck being
"highly sensitive" (I thought a checksum is SUPPOSED to be sensitive) when it's
simply buggy (though I suppose it might be bad PR to actually use that word). 
Padding shouldn't be needed, that's a workaround.  Apparently some believe that
the problem has been fixed, since it's no longer mentioned in the FC5 Release
Notes.  It's not, and I shudder to think how many thousands of man-hours have
been wasted by all the people burning the same CDs over and over not realizing
that they're good, or having the install fail in the middle.   Someone should
create a FAQ on this so people at least know what's going on.
Comment 1 Don Mies 2006-03-23 23:39:17 EST
Some additional information that might be of use:  I have a system with a type 3
failure described above.  The "ide=nodma" option did not help.  The CD drive was
old so last weekend I bought a brand new drive and installed it with the same
results.  I also replaced the old ide cable.

I tried the system with only the CD and one disk connected to the same ide
channel and I've tried both ide channels with no difference.

I've run a CD drive diagnostic from Windows XP on that same system for hours and
hours and it found no errors of any sort or even marginal behavior.  I ran it on
both the CDs and the DVD with no errors on either.

I have taken the disks to my work system (an IBM system) and all of the disks
passed media check with no problems including the DVD I tried (which also fails
on my home system).

I've wasted days of time trying to make this work with no results whatever and
can't load fedora on my system.  So far I have not found a way to load it and
I'm on the verge of giving up.  I love Linux/Unix but this is frustrating beyond
description.  The only other system I have on this network is a Windows XP
system and so far, no one has been able to tell me how to install from this
system.  Almost all of the "other" installation methods require a Linux/Unix
system to act as the host/server.
Comment 2 Andre Robatino 2006-03-24 00:02:57 EST
  I forgot to mention above - with my type 2) drive, if I do the mediacheck with
"ide=nodma", sometimes instead of PASS, it just hangs, though I can restart the
installer with Ctrl-Alt-Del.  This is okay - I've found that as long as none of
the discs actually FAIL, the install will work properly (not complaining about
some package file being corrupted).
Comment 3 Andre Robatino 2006-03-24 01:58:16 EST
  Here is a fedora-list post from someone who claims that adding padsize=512k to
the cdrecord options will allow mediacheck to work.  I seem to remember from bug
#106685 (which was prematurely closed) that padding was not a reliable
workaround, though for anyone who hasn't been able to get mediacheck to work
it's worth a shot.

http://www.redhat.com/archives/fedora-test-list/2006-March/msg01553.html
Comment 4 Don Mies 2006-03-24 11:21:34 EST
(In reply to comment #3)
>   Here is a fedora-list post from someone who claims that adding padsize=512k to
> the cdrecord options will allow mediacheck to work.  I seem to remember from bug
> #106685 (which was prematurely closed) that padding was not a reliable
> workaround, though for anyone who hasn't been able to get mediacheck to work
> it's worth a shot.
> 
> http://www.redhat.com/archives/fedora-test-list/2006-March/msg01553.html

I don't have access to another Linux system to burn the CDs with the above
parameter.  I used Nero on a Windows XP system to burn my disks.  Do you know if
there is a way to add this padding using Nero?  I'll check the web and see if
anyone has done this as well.

Thanks
Comment 5 Andre Robatino 2006-03-24 17:50:13 EST
  I don't know, but it's probably buried in the UI somewhere.  I think there's
also a version of cdrecord for Windows.  Also, some people claim that forcing a
slower burn, say at 4x, instead of the default speed, can make a difference.
Comment 6 Don Mies 2006-03-25 11:39:02 EST
I searched the Nero GUI and documentation and did not find any references to the
pad setting so I don't think it's an available option.  I'll try the cdrecord
program for Windows.  I found it on the web but the site only talks about being
compatible with 95, 98, and NT... No mention of XP.  I guess I'll just have to
try it and see if it works.  One drawback to this is that the cdrecord program
for Windows run under cygwin so I'll need to install that also.

I did try using a slower burn speed.  My drive is a 16X system but the last set
of  disks I tried I burned at 2x and they still failed.

BTW, the title of this bug may be a bit misleading to developers that are trying
to categorize the bugs... It's not just mediacheck that fails here.  If this
situation occurs, the install will fail as well and that's a lot more serious. 
On most of the software programs that I've worked on, an installation failure
was a high priority bug... There's no better way to lose a customer than for
them to be unable to install the software!
Comment 7 Andre Robatino 2006-03-25 14:29:00 EST
  I renamed this bug "kernel prevents proper CD checking (mediacheck/install
fails)", after bug #106685, since it's the same bug, and since that one hasn't
been reopened, though it should be, and this one should be marked as a
duplicate.  I also changed the severity to "high", though it's unlikely that it
will be fixed, since it's been ignored/tolerated for years.  I realize that it's
an upstream bug, but there ought to be some pressure applied on the current
maintainer of this code, or if they won't respond, some money to hire someone
else to do the work.
  Two things I've wondered about: 1) Can this bug cause data corruption during
normal use? 2) Do other Linux distros have their own mediacheck, and if so, are
they vulnerable to the same bug, and if not, can the Fedora version be modified?
Comment 8 Richard Hollins 2006-03-27 00:46:52 EST
I have tried the 3 drives on my two computers, and all fail, even with ide=nodma.
HP9100 CDRW, LG GCE8525B CDRW, Samsung SC-148 CDROM.
I have also a Creative CD5233E CDROM and an LG CR8521B CDROM (it was already in
my car going to be recycled).  
Before I take any more time testing these drives, has anyone compiled a list of
drives which work consistently?  Do any drives work consistently or does it rely
on the hardware detection order on startup?  This would be consistent with
Andre's report that plugging or unplugging peripherals can change this behaviour.
Comment 9 Andre Robatino 2006-03-27 00:58:19 EST
  Samsung SCR-2432 and SCR-3232 (in 7-year old Emachines boxes) work properly
(category 1), at least in the machines they came in.  NEC ND-2510A CD/DVD burner
is category 2 in two different machines.  MSI MS-8152 is category 3 in two
different machines.  The only thing that changing peripherals seems to do is to
change which particular discs pass mediacheck, or on which package the install
fails with a message that it's missing or corrupt (I suppose with luck, one
might be able to finish an install by trying a lot of combinations to find one
that it doesn't bomb out on).  It doesn't change the category of vulnerability.
Comment 10 Don Mies 2006-03-27 12:31:41 EST
Some additional information:  Andre wondered if the mediacheck from other
distributions has the same problem so I tested it with the mediacheck from
Redhat Enterprise 4.0 Workstation.  It fails the same way as the FC4 mediacheck
does.  I tried it on the 4.0 disk first and it failed there and then I tried it
on the FC4 disks and they also failed.  The program does behave a bit
differently however.  The FC4 version stops with an error message as soon as the
first error is discovered but the RH 4.0 version appears to scan the entire disk
before reporting any errors.  I much prefer the FC4 version.

Since FC5 is now available I decided to try that over the weekend.  I downloaded
the i386 DVD image, verified the sha1 checksum, and burned a DVD (using Nero) at
2X speed with verification.  The DVD verifies correctly but still fails the
mediacheck when I try to use it on the target system.  The FC5 mediacheck
program behaves like the RH 4.0 program in that it appears to scan the entire
disk before reporting an error.

I tried installing from this DVD anyway and the failure mode is different also.
 The FC4 install would report an error of some sort while reading the CD/DVD and
abort the install.  The FC5 install now runs for a while and then just hangs. 
When it hangs, it will not respond to anything including <ctrl>-<alt>-del.  I
had to hard boot the machine to get it back up again.
Comment 11 Nigel Griffiths 2006-03-28 05:57:03 EST
I downloaded FC5 for PowerPC (ppc) CD1.
SHA1SUM for Windows confirmed the .iso image was OK.
Burnt OK on regularly used CDROM-RW - no problems.

On my IBM pSeries p505 the Media Check fails every time.
Burnt a fresh CDROM for different vendor.
Same result.
Comment 12 Andre Robatino 2006-03-28 15:37:21 EST
  There's a fair amount known about the cause of this bug - try the search

"alan cox" mediacheck

on Google.
Comment 13 Philipp 2006-03-28 18:41:56 EST
I downloaded FC5 i386 DVD under Linux. sha1sum is correct. Burnt on DVD - correct.
However, now I am trying to install on Toshiba Satellite M30 Notebook with
DVD/CD-ROM (Pioneer DVD-RW DVR-K12D).

MediaCheck stops at 14% with failure
Burnt another image - MediaCheck stops at 15% with failure

I have read the bug report and tried option ide=nodma - no change. I haven't
tried the padsize=512K option yet. However, is it recommendable trying to
install even without MediaCheck passing? Don't want to mess up my running system
- I was going to install FC5 as second OS but will need the bootmanager...
Comment 14 Andre Robatino 2006-03-28 18:50:36 EST
  It seems to depend on hardware - some people just ignore the mediacheck
failure and are able to install without problems.  Other people, including me,
almost always have install problems coinciding with the mediacheck problem
(though my box responds to ide=nodma, so I can avoid both problems).  Without
prior experience with your own hardware, there's no way to tell.
Comment 15 James G. Sack 2006-04-02 04:32:00 EDT
FYI to all:

Be aware that bad memory may show up as media errors. Just today I found after 
repeated media error reports that memtest86 detected an error in it's test#8. After 
reseating (& swapping dimms), memtest86 passes, and then the media check and install 
proceded normally.

..jim
Comment 16 Andre Robatino 2006-04-10 05:30:53 EDT
  Very informative discussion on the fedora-devel list.  Read the Follow-Ups:

http://www.redhat.com/archives/fedora-devel-list/2006-March/msg01191.html
Comment 17 Don Mies 2006-04-10 12:25:26 EDT
(In reply to comment #15)
> FYI to all:
> 
> Be aware that bad memory may show up as media errors. Just today I found after 
> repeated media error reports that memtest86 detected an error in it's test#8.
After 
> reseating (& swapping dimms), memtest86 passes, and then the media check and
install 
> proceded normally.
> 
> ..jim

Jim - Thank you for this comment!  I created a memtest86 boot CD and ran it on
my problem machine and sure enough, I had an intermittent memory problem.  The
problem never showed up in the boot rom memory check and I had no serious
problems running on this machine but it does have a memory problem.  After
replacing one of the DIMMs the problem was fixed and now the mediacheck works
fine and FC4 and FC5 both install.  I'm up and running!

This does beg the question of why FC is so sensitive to this memory problem when
Windows XP appears to run fine on the same system.  I wondered about this and
thought that it might just be that the bad memory in my case was up at the high
end of the address range and FC might be using that memory more than XP does. 
To test that theory, I swapped the bad DIMM so that it was located down in the
lower area of the address space to see what would happen and the result was the
same behavior.  XP still appears to work fine but FC fails misreably.

Thanks again for solving my problem!
Comment 18 Andre Robatino 2006-04-10 16:53:31 EDT
  FYI, you can run memtest86 from the 1st install CD, or DVD, by booting from it
and typing "memtest86" at the boot: prompt (this is listed if you use F2 to show
options).
Comment 19 Andre Robatino 2006-04-11 01:25:09 EDT
  For anyone trying to burn usable CDs, see this page:

http://www.troubleshooters.com/linux/coasterless.htm

Basically, as a workaround to the read-ahead bug, he recommends using -dao,
-pad, and padsize=63s as options to cdrecord (though he doesn't explain where 63
comes from).  I'd be interested to know whether discs burned this way can pass
mediacheck and/or install on machines that normally require ide=nodma even if it
isn't used, or on machines where ide=nodma didn't work at all.
Comment 20 Andre Robatino 2006-04-11 05:35:36 EDT
  I burned new copies of the 5 FC5 CDs, using the above options, and letting
cdrecord choose the speed automatically.  All 5 CDs now pass mediacheck without
ide=nodma.  In addition, piping the output of the "rawread" script through
sha1sum gave the correct result for each of the CDs, giving an alternative to
mediacheck.  Simply using

cat /dev/cdrom | sha1sum

did NOT work - it didn't show any errors, but the returned sha1sums were wrong.
 This is consistent with the web page, which states that it's necessary to read
the ISO header first to know how far to read.  I'm not going to check whether a
clean install without ide=nodma works, since my FC5 box is working fine.  That
will have to wait until FC6.
Comment 21 Richard Hollins 2006-04-11 19:44:16 EDT
Created attachment 127640 [details]
The Anaconda dump text
Comment 22 Richard Hollins 2006-04-11 19:48:06 EDT
I burned more CD's (I am burning these on a WinXP machine sine I don't have a 
Linux machine connected to the net right now) and got a set which passes 
mediacheck on two computers (one P4 one AMD) but the install failed after the 
first few hardware checks, and yielded the above dump text
Comment 23 Andre Robatino 2006-04-11 21:24:37 EDT
  Did you try installing with the previous CDs, and if so, is this the same
error as before?  The usual install error associated with the mediacheck bug is
that it claims a particular package is missing or corrupt.
Comment 24 Bill Nottingham 2006-05-01 13:38:14 EDT
*** Bug 190303 has been marked as a duplicate of this bug. ***
Comment 25 Andre Robatino 2006-05-03 20:35:34 EDT
  I just bought a Dell Dimension B110 with a Sony CRX310EE CD-RW/DVD-ROM drive.
 Some of the 5 CDs I burned using the above instructions failed mediacheck.  The
failures weren't totally consistent, one disk passed once and failed once. 
Using ide=nodma made no difference.  (So this is a "category 3" drive.) 
However, the actual install worked without incident.  Possibly some drives don't
do enough error checking during mediacheck, but if anaconda has the drive read
an RPM repeatedly during install, it can get it right at least once.  This would
account for the advice some people give to ignore mediacheck and do the install
- their own machines just happen to work like this.
Comment 26 Paul Howarth 2006-05-11 12:03:19 EDT
Here's an alternative way of checking your media if you have a working Linux system:

http://www.city-fan.org/tips/IsoImageFromMedia
Comment 27 Andre Robatino 2006-05-11 12:16:45 EDT
  The "isograb" script does basically the same thing as the "rawread" script.  I
tested the 5 CDs I burned using rawread on my B110 drive, and one disc failed
consistently, with the same wrong sha1sum twice, so it must be failing in only
one specific area.  I know these discs are readable on another drive, so this
drive is probably of low quality.  Maybe forcing a lower burn speed would help -
I'll try that next time.  Also I'm guessing that there's more chance of success
reading the discs on the same drive they're burned on.
Comment 28 none 2006-06-23 14:32:18 EDT
Here is my store, just feel sad that a great product can end up this way, and 
it seems nobody really cares about the fix. Long time ago, I downloaded FC1. It 
worked great until the PC gave up. So I have a new one. Install FC1 without 
problem (use linux allowcddma, a bit problem actually but workable). Then I 
found out it actually has FC5 now. Surly, I download FC5 and burned 5 CDs.  
When I installed, it failed. naturely I ran the test CD, turned out 3 were 
reported bad. I used another brand of CDR, this time one was bad, so reburned 
one, after threw out 4 CD-Rs, it finally reported all CDs are ready for 
install. The rest of story, everyone knows. It keeps reporting some rpm 
corrupted, I tried different burn speed, brand, check the Sha1rsum, differnt 
burning programs, shame on FC5, none worked. I wasted two full days with 
nothing.

Now I try to download FC3 and will give a try. People may ask why not FC4, 
based on this thread, it seems FC4 is no better than FC5. If this FC3 does not 
work, man, I guess I have to use FC1. BTW, anyone can suggest any other Linux 
than Fedora?
Comment 29 Andre Robatino 2006-06-25 01:47:01 EDT
  It's an upstream bug in the kernel.  All distros have it, though the Fedora
installer may be more affected than some.  Try burning the CDs using the URL in
comment #19 to try to work around the bug.
Comment 30 Dave Jones 2006-10-16 20:23:50 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 31 Andre Robatino 2006-10-16 20:49:17 EDT
  Still broken (no surprise).
Comment 33 Andre Robatino 2007-06-04 00:34:34 EDT
  The problem still exists in FC6, but the F7 mediacheck appears not to be
affected.  I'm guessing that the readahead bug still exists, but that mediacheck
has been modified to skip the mkisofs-padded end of the ISO, past where the
actual files are.  This ought to work since mkisofs by default adds enough
padding to the ISO to protect the files in it from the readahead bug.  Can
someone verify this?  If so, then this bug should either be closed or renamed
since its current summary would no longer be accurate.
Comment 34 Andre Robatino 2007-06-05 15:10:27 EDT
  According to Alan Cox, the libata drivers used by F7 don't have the same
problems.  Should this bug be closed then?

http://www.redhat.com/archives/fedora-list/2007-June/msg01013.html
Comment 35 Bug Zapper 2008-04-03 22:13:50 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 36 Andre Robatino 2008-04-03 22:22:22 EDT
Still broken as of F8 (contrary to popular opinion).  See bug #397141.  The
easiest way to trigger this bug, assuming one is using a drive vulnerable to the
bug, seems to be to burn a CD _without_ using either DAO or padding.  Using
wodim in the simplest possible way achieves this, for example when burning a
CD-RW use

wodim dev=/dev/cdrom blank=fast foo.iso

then try to read the ISO off the disc using the rawread script.  It should fail
a few dozen kB from the end.
Comment 37 Bug Zapper 2008-11-26 01:56:45 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 38 Alan Cox 2008-11-28 06:09:52 EST
*** Bug 397141 has been marked as a duplicate of this bug. ***
Comment 39 Andre Robatino 2009-01-02 16:57:36 EST
This has been seen by someone else in bug #448291.
Comment 40 David Tonhofer 2009-01-03 19:15:39 EST
I seem to have hit this bug on Fedora 10. I thought the SCSI/SATA drivers had a
bug until I found this report. Here we go:

With an LG GDRH20N SATA DVD-ROM:

-- Media Check fails 100% (tested DVDs, (live) CDs, several burns...)
-- "Independent Media Check" using another system works (dump the ISO
   image, see below, then check the SHA1 sum against the official sum)
-- Installation fails in a totally weird manner
   (e.g. at the very end, anaconda says "no kernel images installed" or
    arbitrary packages are not found)
-- Starting the same system from a PATA drive found in the attic with
   the same media works nicely (installation not yet tried, will try)
-- Media check passes if "ide=nodma" kernel option is given. Yowza!

Additionally:

-- Booting the system to Fedora 10 Live CD using aforementioned PATA
   drive, then dumping an ISO image (in this case, F10-x86_64-Live.iso)
   off the DVD-ROM if "ide=nodma" has NOT  been set results in a: 

   -- correctly-sized
   -- but slightly corrupted image

   The dump was done with "dd if=/dev/sr0 of=/tmp/corrupted.iso"
   It is probably not of big interest to know the exact differences,
   but a little perl program to cut the dump into 10K blocks and hash
   these, applied tp both original ISO and dumped ISO reveals 61 10K
   blocks with differences, *spread throughout the image* (not only the
   end affected).

Now going to have drink or two.

How to hash 10K blocks:

#!/usr/bin/perl
use Digest::MD5 qw(md5 md5_hex md5_base64);
$file = $ARGV[0];
open(FILE,$file) or die "Could not open $file: $!\n";
binmode FILE;
my $buffer;
my $size = 1024*10;
my $read;
my $pos = 0;
while (($read = read(FILE, $buffer, $size)) > 0) {
   my $digest = md5_hex($buffer);
   my $end    = $pos + $size - 1;
   print "$digest [$pos,$end] $size\n";
   $pos += $size;
}
close(FILE);
Comment 41 Andre Robatino 2009-01-03 19:51:21 EST
The readahead bug should only affect reading the last few dozen KB of the disc image.  You also need to be careful not to use dd to attempt to read off more than the actual size of the ISO.  The rawread script at

http://www.troubleshooters.com/linux/coasterless.htm

reads off the correct amount automatically.  It's very handy; I make it executable and put it in ~/bin so it's always available in my path.

Using "ide=nodma" may or may not work, depending on your hardware (it usually didn't work for me).  Doing the burning as recommended in the link above seems to be the only foolproof way to avoid the readahead bug.
Comment 42 David Tonhofer 2009-01-04 10:18:40 EST
Thanks Andre,

After retesting, any consistent explanation fell apart, and I am now pretty sure that it is just my DVD-ROM drive which does not work or which has some problem with the motherboard. Time burnt on a stupid problem, damn you non-self-checking hardware! Okay, out goes the drive... 

I'm not sure whether "ide=nodma" still has any effect whatsoever in F10, especially with SATA drives? The last time it was mentioned was in the Fedora Core 4 release notes at http://docs.fedoraproject.org/release-notes/fc4/
Comment 44 Bug Zapper 2009-11-18 02:52:17 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 45 Andre Robatino 2009-11-18 08:31:44 EST
Still see this on a clean installed and updated i386 F12 box with a Sony DW-G120A/DRU-120C DVD+RW drive.  Trying to read my old FC4 CDs 1,2,3,4 results in read failures 2048, 110592, 110592, and 57344 bytes from the end, resp.  Using wget -c to complete the files shows the previously read part is correct.
Comment 46 Stephen Clement 2010-04-08 11:25:10 EDT
I can confirm what Andre said, I'm using i386 f12 with a HL-DT-ST DVDRAM GSA-H62N and I see read failures near the end of dual layer DVDs, screwing up hashing. Using the rawread script fixes the issue.
Comment 47 Andre Robatino 2010-04-08 15:02:52 EDT
Stephen: if you are able to read the discs properly with the rawread script, then you're not seeing the same issue.  The read errors I'm talking about happen even when the rawread script is used (which I always do) since they happen before the ISO file has been fully read off.

Personally, the only time I've heard of this problem on DVDs was when my father bought a Fedora 8 DVD online.  The easiest way I know to reproduce it is to burn a CD-RW in the simplest possible way - i.e.,

wodim -v dev=/dev/cdrom blank=fast file.iso

in the default TAO mode (DAO seems to prevent the bug).  Growisofs uses DAO by default which may explain why it's so difficult to reproduce on DVDs.
Comment 48 Stephen Clement 2010-04-08 15:37:26 EDT
Sorry, nevermind, I didn't read all of the comments. Disregard my comment.
Comment 49 Bug Zapper 2010-11-04 08:16:39 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 50 Andre Robatino 2010-11-07 04:01:16 EST
Same behavior on F14 i386 with 2.6.35.6-48.fc14.i686.PAE.
Comment 51 Andre Robatino 2011-05-18 18:04:03 EDT
(In reply to comment #45)
> Still see this on a clean installed and updated i386 F12 box with a Sony
> DW-G120A/DRU-120C DVD+RW drive.  Trying to read my old FC4 CDs 1,2,3,4 results
> in read failures 2048, 110592, 110592, and 57344 bytes from the end, resp. 
> Using wget -c to complete the files shows the previously read part is correct.

Just clean installed F15 i386 (AKA RC3) in this machine, with the same optical drive, running kernel-2.6.38.6-26.rc1.fc15.i686.PAE. Reading the same 4 CDs, CD 1 has a read failure just 2048 bytes from the end. CDs 2, 3, and 4 can be read all the way to the end. The parts that can be read are correct (using wget -c on the first image, and then verifying the sha1sum of all images). I don't know if this is progress or not. Are there any kernel changes that might have reduced the severity of this bug?
Comment 52 Andre Robatino 2011-11-07 17:48:52 EST
Same behavior on F16 (RC5) i386 with kernel-PAE-3.1.0-7.fc16.i686.
Comment 53 Dave Jones 2012-10-23 11:38:41 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 54 Justin M. Forbes 2012-11-14 11:36:48 EST
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.