Bug 137217

Summary:	Posted cd iso images fail media check
Product:	[Fedora] Fedora	Reporter:	G.S. Link <gslink>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	barryn, riclund, sub1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-02-02 03:02:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
checksum.

Steps to Reproduce:
1.Boot 2.92 disc1
2.Check discs 3,src1,src2 and recovery
3.
  
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

FC3-i386-disc2.iso
FC3-i386-disc3.iso

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 
FC3-i386-disc1.iso
FC3-i386-disc2.iso

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.