Created attachment 35283 [details]
crashdump file for failed 7.2 installation

Looks like you have a bad cd to me.  This section of your debug information
concerns me:
<4>end_request: I/O error, dev 16:00 (hdc), sector 89192
<4>hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
<4>hdc: drive not ready for command
<4>hdc: status timeout: status=0xd8 { Busy }
<4>hdc: drive not ready for command
<4>hdc: ATAPI reset complete
<4>VFS: busy inodes on changed media.

The kernel can't talk to the cdrom drive.  Did you download the ISO images or
did you buy the retail box set?  If you downloaded the images, did you check the
md5sum of the ISOs before burning them?

By the way, this looks very similar to bug #55245.

Retail box set purchased from BestBuy.
Thanks for assistance!
Mike S.

Is there any way to tell from the outside of the box whether I am getting a 
new retail box set that is from the same or a different production run?  In 
other words, is it likely that any new CD I purchase from the same store 
(BestBuy) will be defective as well?
Thanks again.

I don't know of any way to tell if a box is of a different production run or
not.  I've notified Product Management of your problem too.  We should have more
information for you soon.

FYI: exchanged RHL 7.2 for new boxed retail set: same problem.  ON a graphical 
upgrade installation I got as far as the grub password screen (I declined) 
before the unhandled exception appeared.  ON a second try with a text based 
clean custom install the crash occurred while disk formatting was underway.
Crash dump for the second crash attached.
Thanks,
Mike Sebastian

crashdump #2 not saved for some reason.

MDS

Hmm...it would be nice to have that second crash dump.  Can you give it another try?

tried it again. Clean graphical install.  this time it gave me the eth0 config 
screen which it did not on the other two attempts with the second retail CD 
package either clean or upgrade.  Got as far as the "authentication 
configuration" screen; I accepted the defaults, clicked "next" and badabing--
crash.

Dump attached.

I don't see the second attachement.

Traceback (innermost last):
  File "/usr/bin/anaconda", line 620, in ?
    intf.run(id, dispatch, configFileData)
  File "/usr/lib/anaconda/gui.py", line 350, in run
    self.icw.run (self.runres, configFileData)
  File "/usr/lib/anaconda/gui.py", line 778, in run
    mainloop ()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2608, in mainloop
    _gtk.gtk_main()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__
    ret = apply(self.func, a)
  File "/usr/lib/anaconda/gui.py", line 399, in nextClicked
    self.dispatch.gotoNext()
  File "/usr/lib/anaconda/dispatch.py", line 143, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/dispatch.py", line 208, in moveStep
    rc = apply(func, self.bindArgs(args))
  File "/usr/lib/anaconda/packages.py", line 106, in readPackages
    id.comps = method.readComps(id.hdList)
  File "/usr/lib/anaconda/image.py", line 17, in readComps
    return ComponentSet(self.tree + '/RedHat/base/comps', hdlist)
  File "/usr/lib/anaconda/comps.py", line 795, in __init__
    self.readCompsFile(file, self.packages)
  File "/usr/lib/anaconda/comps.py", line 558, in readCompsFile
    self.expressions[packages[l]] = None  
File "/usr/lib/anaconda/comps.py", line 152, in __getitem__
    return self.packages[item]
KeyError: MAKEDEV


Local variables in innermost frame:
self: <comps.HeaderListFromFile instance at 8699318>
item: MAKEDEV


Individual package selection status:
4Suite: 0, Canna: 0, Canna-libs: 0, a2ps: 0, abiword: 0, alchemist: 0, ami:
0, ami-gnome: 0, anacron: 0, anonftp: 0, apache: 0, apacheconf: 0, apmd: 0,
arts: 0, ash: 0, asp2php: 0, asp2php-gtk: 0, aspell: 0, aspell-de: 0,
aspell-es: 0, aspell-fr: 0, aspell-it: 0, at: 0, audiofile: 0, aumix: 0,
authconfig: 0, autofs: 0, autorun: 0, awesfx: 0, balsa: 0, basesystem: 0,
bash: 0, bcm5820: 0, bdflush: 0, bind: 0, bind-utils: 0, bindconf: 0,
bonobo: 0, bug-buddy: 0, bzip2: 0, bzip2-libs: 0, caching-nameserver: 0,
cdda2wav: 0, cdlabelgen: 0, cdp: 0, cdparanoia: 0, cdrecord: 0, chkconfig:
0, chkfontpath: 0, cipe: 0, cleanfeed: 0, compat-libstdc++: 0,
console-tools: 0, control-center: 0, cpio: 0, cpp: 0, cracklib: 0,
cracklib-dicts: 0, crontabs: 0, curl: 0, cyrus-sasl: 0, cyrus-sasl-md5: 0,
cyrus-sasl-plain: 0, dateconfig: 0, db1: 0, db2: 0, db3: 0,
desktop-backgrounds: 0, dev: 0, dhcpcd: 0, dia: 0, dialog: 0, diffutils: 0,
docbook-dtd30-sgml: 0, docbook-dtd31-sgml: 0, docbook-dtd40-sgml: 0,
docbook-dtd41-sgml: 0, docbook-style-dsssl: 0, docbook-utils: 0, dosfstools:
0, e2fsprogs: 0, ed: 0, ee: 0, eel: 0, efax: 0, eject: 0, esound: 0, exmh:
0, expat: 0, extace: 0, fam: 0, fetchmail: 0, filesystem: 0, fileutils: 0,

<7>eth0:  Identified 8139 chip type 'RTL-8139C'
<6>md: raid0 personality registered as nr 2
<6>md: raid1 personality registered as nr 3
<6>raid5: measuring checksumming speed
<4>   8regs     :  1837.200 MB/sec
<4>   32regs    :  1193.600 MB/sec
<4>   pII_mmx   :  2816.400 MB/sec
<4>   p5_mmx    :  3593.600 MB/sec
<4>raid5: using function: p5_mmx (3593.600 MB/sec)
<6>md: raid5 personality registered as nr 4
<6>Journalled Block Device driver loaded
<4>hdc: cdrom_read_intr: Bad transfer size 65534
<4>  Trying to limit transfer sizes
<4>end_request: I/O error, dev 16:00 (hdc), sector 89192
<4>hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
<4>hdc: drive not ready for command
<4>hdc: status timeout: status=0xd8 { Busy }
<4>hdc: drive not ready for command
<4>hdc: ATAPI reset complete
<4>hdc: command error: status=0x51 { DriveReady SeekComplete Error }
<4>hdc: command error: error=0x50
<4>end_request: I/O error, dev 16:00 (hdc), sector 89196
<4>VFS: busy inodes on changed media.

Michael, do you have a second cdrom drive that you could try out?  I find it a
little hard to believe that you've gotten two bad retail cd's.  Not that it's
impossible, but it seems unlikely.  I'm wondering if there isn't something wrong
with either the cdrom drive or the IDE controller on the motherboard.  It really
seems like we're seeing hardware troubles at this point.

Or, do you have another machine that you could try the install on?

I can work something out, maybe install a CDROM drive in the machine and see 
what happens.  Might take a day or two.

Ok.

New CDRW drive,flawless 7.2 clean graphical install.
Thanks for your help.  Alles klar Herr Komissar.

Hmm...wonder if you have a bad cdrom drive or if something went wrong with the
software.  I wouldn't think that the kernel's cdrom code has changed, though.  

Arjan, can you think of any reason why some cdrom drives would behave in this
way?  I have seen a couple of these kinds of reports.

I'm closing this report since things seem to be working now.  Thanks for your
report.

*** Bug 58089 has been marked as a duplicate of this bug. ***