Bug 137217 - Posted cd iso images fail media check
Summary: Posted cd iso images fail media check
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-26 19:00 UTC by G.S. Link
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-02 03:02:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description G.S. Link 2004-10-26 19:00:55 UTC
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
Discs of the 2.9.2 images fail when checked at boot time by disc 1. 
The failing images are 3,src1,src2, and recovery.  We could find
nothing wrong with the contents of the discs and suspect a defective

Steps to Reproduce:
1.Boot 2.92 disc1
2.Check discs 3,src1,src2 and recovery
Actual results: fail

Expected results:pass

Additional info: We checked the media and downloaded the images again
from another source.  They continue to fail but our checks show the
disc contents to be good. We suspect the checksum on the disc images
is bad and that this is not a bug.

Comment 1 Harald Hoyer 2004-10-27 08:33:40 UTC
You have to burn them with the -dao (disk at once) or -sao (session at
once) mode.

Comment 2 Harald Hoyer 2004-10-27 08:35:31 UTC
Reassigning bug to the anaconda media check. Besides the checksum, the
length should be on the disk, because of possible padding by burning
apps or the burner itsselves.

Comment 3 G.S. Link 2004-10-27 13:30:36 UTC
Neither DAO nor SAO makes any difference.  Each download was compared
with the previous character by character.  There was no difference. 
This was tried with one of the other disc images that did not fail. 
The result was a good disc.  I do not recommend something that
requires DAO as a good many burners do not support that mode.  All
this burning was done from mirrors it may be a copy problem.  We
installed everything and could find NOTHING wrong with any of the
resulting systems that this could cause.  We suspect the checksum or
the burning software in RH9 which may have added padding.  We tried
both programs in RH9 and got the same result.  We do not think these
images are bad.

Comment 4 Jeremy Katz 2004-10-27 16:01:57 UTC
Do they work if you boot with 'ide=nodma'?

Comment 5 G.S. Link 2004-10-29 13:51:20 UTC
That doesn't make any difference.  I downloaded FC3-RC2 and those cds
are ok.

Comment 6 Normand Robert 2004-11-14 03:47:59 UTC
I get media check failures using FC3 for these disks burned in
"uptodate" RH9


MD5SUM's for all 5 discs (1-4 + rescue) agree with values posted on
mirror site.

Reburned discs 2 and 3 at slower speed with better media in RH9

cdrecord  -v speed=12 dev=1,0,0 ~robert/FC3-i386-disc2.iso

and obtained errors at the very end of the media check process as
indicated by the progress bar. My system burns CD extremely reliably
(~1 coaster/80) and never fails "silently" so I will ignore failures
and install anyways.

Comment 7 Rick Lundgren 2004-12-08 20:15:49 UTC
I get media check failures using FC3 for 

MD5SUMs agree with values posted.

Attempted install anyway and got "An unhandled exception has 
occurred. This is most likely a bug..."

Don't know if this is result of media check or should be reported as 
new bug.

Comment 8 G.S. Link 2004-12-09 14:06:35 UTC
The reported CDs are the only ones that we can find that show this
problem.  We did not get the problem with the FC3 release discs.  The
problem was probably confined to the indicated RC discs.

Note You need to log in before you can comment on or make changes to this bug.