Red Hat Bugzilla – Bug 23365
7.0 install consistently fails on dell optiplex gx101
Last modified: 2005-10-31 17:00:50 EST
I bought 7.0 to instal on a Dell Optiplex GX101 (500 MHz P3, 128 Mb Ram,
Rage pro/8Mb video, 30 GB Ibm ide drive, added Adaptec 2940U (narrow) scsi
adapter w/2 quauntum drives, but standard everything else on that machine
as from Dell). However, the installation repeatedly fails in the same
place whether I am doing the text install or the x-based install, and it
fails there if I put the original 8GB ide drive back in the machine (the
ibm was an upgrade). I can make one slight variation - in where it occurs,
and that is described below.
I am doing (as I have done on every other machine i have) the custom
install -- selecting various additional packages normally from the server
install & adding them to the normal workstation items. (Adding in support
for web server and nfs server primarily, and adding tripwire and some
However, after going through the setup to that point, the disk partitions
are formatted and the an installer error message occurs, terminating the
installation. (I did the save to disk bit, and the message is attached at
the end of this report). If I do *not* list the /dev/hda1 disk partition
(which will be a vfat fs with mount-point "/dos") as one of the slices in
disk druid, then I also get the "transferring installation .... to hard
disk" message and *then* the message occurs. Otherwise, I only get as far
as formatting the partitions. (I tried this after reading the problems
about the updates version, which also failed on this machine... [no matter
what I did, the install told me that one of the drives on the system had
not been properly unmounted and that I would have to reboot and run fsck --
but this was not the case as rebooting and running a forced mode fsck on
ALL of the partiions on all 3 drives showed] too late to repeat that now as
the file systems have been re-formatted :-( ).
I tried both borrowing another RH 7.0 cdrom set from someone else *and*
downloading the image and burning a cdrom myself -- the same error occurs
in the same place.
The text of file "anacdump.txt" follows below:
Traceback (innermost last):
File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/iw/progress_gui.py", line
20, in run
rc = self.todo.doInstall ()
File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1543, in
File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1298, in
self.rpmFD = os.open(fn, os.O_RDONLY)
OSError: [Errno 2] No such file or directory:
Local variables in innermost frame:
self: <todo.ToDo instance at 84998c8>
h: <header object at 8a449e8>
intf: <progress_gui.InstallProgressWindow instance at 850b200>
END OF TEXT FROM FILE.
7.0 installed perfectly with the same software configuration on my othe
workstation (but different MB, 900 MHz P3, more memory, different video,
etc.), but due to the hardware differences I am unable to say for certain
that it is not a case that all 3 different CD's I tried to do the install
(have been through the procedure on this machine > 14 times so far & all
failed) contain the same bug.
Have read the installation documentation and searched through the bugs
without finding this one and really need help -- have now wasted 9 days
trying to do a simple installation on one system (but on the bright sie of
things, the others are working nicely, so I'm not totally out of luck.)
In a word, HELP!
One mistake in my post: the system is a Dell OptiPlex GX1 -- not "101" (chalk
it up to a long day...)
This afternoon I finally found a workaround -- I had previously tried removing
the external tape drive and scanner and internal disks from the scsi card... but
with no change in the result. Today I fainally pulled the board out of the
system, and the install went normally. This is not a board problem, however,
because both a completely different 2940U/W (the board I removed was a 2940U) or
a different 2940U put into the system causes exactly the same problem.
After the installation finishd, I re-installed the scsi board and ran kudzu.
Kudzu never found the board (potential bug in kudu, perhaps?). Nor did it find
the 2940U/W which I also tried in the system. I finally added a line in
/etc/rc.d/rc.sysinit to load the aic7xxx module just before adding swap (or
checking for local drives) -- otherwise the boot sequence would fail since the
scsi drives could not be found for an fsck... endless loop.
I suspect that this system cannot take an install if both id and scsi drives are
present. :-( But at least it finally worked :-) [17h time is the charm, they
This error can only occurs if there is a problem with the CD you burned, or with
the CDROM device. Perhaps moving hardware around somehow fixed the read problems
from the CDROM device (seems unlikely, but this is not a anaconda algorithmic
bug). We want to improve the error handling in the future to report these types
of problems more nicely.