Bug 149608 - CDs burnt from ISO images fail test (but seem ok)
CDs burnt from ISO images fail test (but seem ok)
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-24 08:31 EST by David Tonhofer
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-24 15:47:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Tonhofer 2005-02-24 08:31:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

Description of problem:
The CDs burnt from the ISO images downloaded from RedHat fail the 'media check' that should be done prior to installation. However, the CD seems fine.

The MD5 checksum of the ISO image has been verified after download.

The CD has been burnt on a W2K machine using Nero 5.5.10.56 with the 
options "finalize CD" OFF and the write method equal to "track-at-once".

I have re-read the ISO image off the CD, which gives a file that nearly 
matches the original ISO image in size, but there is a 2KByte difference:

182151168 RHEL4-x86_64-ES-disc1.iso
182149120 Track.iso

A hexdump and diff of these files reveals that the files differ at the end,
the re-read iso image is missing 2KByte of 0s:

$ tail RHEL4-x86_64-ES-disc1.iso.hex

ad6a930 0000 0000 0000 0000 0000 0000 0000 0000
*
ad6b000 2046 4f43 504d 5f53 4534 522e 4d50 313b
ad6b010 2020 2020 2020 2020 2020 2020 2020 2020
*
ad6b0d0 2020 6309 6d6f 7370 342d 5345 302d 322e
ad6b0e0 3030 3035 3031 2e37 7273 2e63 7072 0a6d
ad6b0f0 0000 0000 0000 0000 0000 0000 0000 0000
*
adb6800

$ tail track.iso.hex

ad6a930 0000 0000 0000 0000 0000 0000 0000 0000
*
ad6b000 2046 4f43 504d 5f53 4534 522e 4d50 313b
ad6b010 2020 2020 2020 2020 2020 2020 2020 2020
*
ad6b0d0 2020 6309 6d6f 7370 342d 5345 302d 322e
ad6b0e0 3030 3035 3031 2e37 7273 2e63 7072 0a6d
ad6b0f0 0000 0000 0000 0000 0000 0000 0000 0000
*
adb6000

So it seems that the media check is not lenient enough.



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


How reproducible:
Always

Steps to Reproduce:
See above


Actual Results:  See above

Expected Results:  See above

Additional info:
Comment 1 Jeremy Katz 2005-02-24 15:47:25 EST
Nero has been reported to actually misburn ISOs.  I would recommend trying to
find a port of cdrecord to do your burning with.
Comment 2 David Tonhofer 2005-03-31 05:54:07 EST
I have heard and tested that if you start linux with 'ide=nodma', the CDs
actually pass. Which is nice. This seems to be a common problem btw.

Should one not suggest to the user to start mediacheck with the dma disabled
instead of just saying 'FAIL'?

Here's an additional note I found, I did not test this btw:

> I had the same problem until I made sure that I was burning "Disc At Once"
> instead of "Track At Once" in Nero.
> The default is "Track at Once," so be sure to change it to "Disc At Once"
> every time you burn a new ISO. Now all 4 of my discs pass mediacheck, but I
> haven't used them to install yet.
Comment 3 Peter Jones 2005-03-31 14:20:02 EST
David, how are you reading the data off of the CD?  You need to use "isosize" to
find out how many bytes to read.  If it really fails to read that number of
bytes off of the CD, then nero is burning the CD incorrectly, and that is not a
mediacheck bug.

Unfortunately, the utility of "ide=nodma" almost varies according to what CD
drive and IDE or SCSI controller you're using, and about as many drives will
fail with ide=nodma as do without it.
Comment 4 Jos Vos 2005-08-20 16:12:36 EDT
Note that I have seem similar problems using cdrecord.  This was due to a
missing padding or an padsize that was too small.  When using the -pad, the
media check failed due to I/O errors at the end of the ISO image (fully
reproducable with multiple CD's).  When using a larger padsize, everything was
ok.  The failed CD's were fine for installing, b.t.w., but the mediacheck failed.

One way to solve this problem is to add (enough) padding to the distributed ISO
images after implanting the md5 checksum.  This would save a lot of trouble for
all people using bad CD burning programs and/or use too few padding space.

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