Bug 23365 - 7.0 install consistently fails on dell optiplex gx101
7.0 install consistently fails on dell optiplex gx101
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-04 19:39 EST by William W. Austin
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-09 16:06: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 William W. Austin 2001-01-04 19:39:07 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
security items).

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
doInstall
    self.instCallback, p)
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1298, in
instCallback
    self.rpmFD = os.open(fn, os.O_RDONLY)
OSError: [Errno 2] No such file or directory:
'/mnt/source/RedHat/RPMS/setup-2.3.4-1.noarch.rpm'

Local variables in innermost frame:
fn: /mnt/source/RedHat/RPMS/setup-2.3.4-1.noarch.rpm
total: 0
self: <todo.ToDo instance at 84998c8>
h: <header object at 8a449e8>
amount: 0
intf: <progress_gui.InstallProgressWindow instance at 850b200>
what: 2

ToDo object:
(itodo
ToDo
p1
(dp2
S'method'
p3
(iimage
CdromInstallMethod
p4
(dp5
S'currentDisc'
p6
I1
sS'tree'
p7
S'/mnt/source'
sS'device'
p8
S'hdc'
sS'progressWindow'
p9

<failed>
--------------
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!
Comment 1 William W. Austin 2001-01-05 20:14:47 EST
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
say]
Comment 2 Michael Fulbright 2001-01-09 16:06:02 EST
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.


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