Additional Information:  

On same machine (Optiplex GX1p) and with same configuration, I was able to
install RH 7.0 Standard Edition from Boxed Set ordered from RedHat.

The original problem remains - i.e. not able to install from TCP/IP or from disk
partition using boot floppy.
The difference is that the CD ROM from which the new installation was made is on
the Adaptec SCSI Adaptor and when  booting the RedHat Install CD from that
drive, anaconda now associates itself with the drives on the SCSI adaptor
instead of presuming the primary drive is on the IDE - nonetheless, even with
the IDE disabled, it is still not possible to install from the floppy using a
RedHat partition either locally or via NFS even though those partitions are
found;  only the CD installation is possible.

When you boot the system using the boot floppy that is failing to detect the
SCSI drives, once the system gets to the stage of detecting and partitioning
disks, can you switch to VT2 (Alt-F2 in text installs or CTRL-ALT-F2 in GUI
installs) and tell me what the contents of /proc/scsi/scsi show (just use cat
/proc/scsi/scsi from the command prompt)?  If it shows your SCSI drives, then
the kernel isn't the problem here and we need to switch components.  If it
doesn't show your drives, then try typing "modprobe sd_mod.o" and see if that
makes your SCSI drives become available.  If that works, then this is, again,
not a kernel issue but an installer issue.

The information you requested was already documented under Bug #19558 which is
the analogous Bug Report for RH 6.2 and which has now been closed for lack of
reproducability at RH but is repeatable locally.  The kernel does indeed support
the SCSI controller and drive provided that RH is installed as follows:

1) The IDE Interface and associated drive is disabled in FW rendering it
invisible to anaconda.
2) The RH 7.0 CD, which is on the same SCSI Controller as the install drive, is
booted. The install then proceeds normally.

The kernel cannot be the problem here, it most emphatically is the Install
Script which is at fault - I don't know how many 1000's of complaints must be
reported at Bugzilla before somebody at Red Hat realizes that the competent
individuals reporting the bugs do not all download in ASCI or are unable to
follow instructions - but that is how the majority of these type problems have
been 'resolved'.

I believe that it is imperative that RH take a *very* serious look at the
Ananconda install scripts, scrap them, completely rewrite them to at least
generate relavent and comprehensive documenation of failure modes to aid in
debugging.  Virtually all of the information requested for all these bug reports
is information which could be automated in the script itself - the customer
should *not* have to dig through /proc entries and the like to get this
information which is available to the install process itself.

Rewriting the install scripts from scratch, given the known pitfalls, will
benefit not only potential RH Customers, many of whom are novices to Linux/Unix,
but RH as well.  You will greatly reduce the number of customers who opt for
competitors' products because of an inability to install RH properly - no matter
how good the underlying product is. You will fare much better in the Linux News
Groups.  You will also reduce the considerable waste of RH intellectual
resources trying to patch defective software when the patches will most likely
create even more unanticipated problems.

The problem only arises if the install attempt is made from a RH boot floppy
even if the SCSI drive is the only one in the system and the IDE is disabled.

Specifically, the /proc/scsi link is populated as follows (in the floppy install):

1) The /proc/scsi/aic7xxx directory was populated (like RH6) with the '0' file.
This file is identical to the RH 6.0 file of the same name except
there are no statistics.
2) The /proc/scsi/scsi file had a single line: No Drives Found despite the fact
that the aic7xxx driver (or whatever) downloads to the controller card.

Please review th3 attachments for Bug #19558 for exhaustive diagnostic info.

Thanks for not blowing this Bug Report off as user incompetence as so many
others have.

-jim stadelmann

A partial copy of that Bug Report follows:

_______________________________________________________________________________

New Attempt with different configuration:  (Bug #19558)

1) Disabled the IDE Drive in Optiplex CMOS
2) Disabled the IDE Controllers in CMOS
3) Set boot preferences in CMOS as follows:
   2940U2W:00 Seagate ST3940
   System BIOS Boot Devices

Thus the system boots directly from the SCSI drive with no IDE References.

I used the RH 7.0 bootnet.img file on floppy to install via FTP from a
RH 7.0 Workstation with the distribution on a vfat partition (the same one
used to install the Workstation).

Expert mode fails to find anything and the drivers.img file contains no
reference to the proper Ethernet adapters (2) or to the SCSI Controller (1).

Attempting to install using the 'graphics' mode causes the probe to find all
devices including the Adaptec Controller Adaptor and appears to load drivers for
them all.  The install script finds the distribution on the Workstation and
loads both stages from it.

It then reports "No Drives Found"

I used the shell window to look at the /proc entries for the scsi.

1) The /proc/scsi/aic7xxx directory was populated (like RH6) with the '0' file.
   This file is identical to the RH 6.0 file of the same name except
   there are no statistics.
2) The /proc/scsi/scsi file had a single line: No Drives Found.

Everything else seemed normal including the download to the Adaptec Adapter
and it's report as documented in the aix7xxx file.

I will attach the following:

From the fully-configured and working (this) RH 6.0 configuration:
	proc_aic7_6 (the /proc/scsi/aic7xxx/0 copy)
        proc_scsi_6 (the /proc/scsi/scsi copy)

From the RH 7.0 installation attempt:
	proc_aic7_7 (the install's /proc/scsi/aic7xxx/0 copy)
        proc_scsi_7 (the install's /proc/scsi/scsi copy)


------- Additional comments from ARE@xnet.com 2001-02-08 17:25:36 -------


Created an attachment (id=9479) RH 7.0 Install's /proc/scsi/scsi file

------- Additional comments from ARE@xnet.com 2001-02-08 17:27:25 -------


Created an attachment (id=9480) RH 7.0 Install's /proc/scsi/aic7xxx/0 file

------- Additional comments from ARE@xnet.com 2001-02-08 17:28:29 -------


Created an attachment (id=9481) RH 6.0's /proc/scsi/scsi file - same configuration

------- Additional comments from ARE@xnet.com 2001-02-08 17:29:30 -------


Created an attachment (id=9482) RH 6.0's /proc/scsi/aic7xxx/0 file - same
configuration

------- Additional comments from bfox@redhat.com 2001-02-20 12:56:54 -------


I can't explain why /proc/scsi/scsi says 'No Drives Found'.  I tried upgrading
from 6.0 to a recent internal tree and got a traceback.  In short, I am unable
to reproduce the original bug.

Traceback (innermost last):
  File "/usr/bin/anaconda", line 509, in ?
    intf.run(todo, test = test)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 376, in run
    self.icw.run ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 851, in run
    mainloop ()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop
    _gtk.gtk_main()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__
    ret = apply(self.func, a)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 478, in nextClicked
    self.setScreen (self.currentScreen, self.nextClicked)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 587, in setScreen
    new_screen = screen.getScreen ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/examine_gui.py", line 31, in
getScreen
    self.parts = self.todo.upgradeFindRoot ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1090, in
upgradeFindRoot
    return upgrade.findExistingRoots(self.intf, self.fstab)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/upgrade.py", line 55, in
findExistingRoots
    isys.umount('/mnt/sysimage')
  File
"/mnt/redhat/test/qa0217.1/i386/RedHat/instimage/usr/lib/anaconda/isys.py", line
117, in umount
    raise ValueError, "isys.umount() can only umount by mount point"
ValueError: isys.umount() can only umount by mount point

------- Additional comments from bfox@redhat.com 2001-03-02 15:39:05 -------


I have tried again with the latest internal tree as of March 2, 2001, and things
seem to be fine.  I did an upgrade from a 6.0 scsi system to the latest tree and
things went fine.  I can't really explain what has changed except that perhaps
there was some driver weirdness that has been worked out.  Resolving as rawhide.
 Please reopen if the bug reappears in the future.  If you're interested, try
the Wolverine public beta (released on Feb. 19, 2001) and see how that works for
you.  It is available at ftp.redhat.com/redhat/beta/wolverine/en/iso



Additional Information
Bug#: 19558 Product: Red Hat Linux Version: 6.2
Platform: i686 Reporter: ARE@xnet.com Component: anaconda
Status: CLOSED Priority: normal
Resolution: RAWHIDE Severity:
Assigned To: bfox@redhat.com

Cc: ARE@xnet.com
QA Contact: borgan@redhat.com
URL:
Summary: Attempt to upgrade existing RH6.0 on SCSI fails in ananconda
Status Whiteboard:
Attachments:
2000-11-08 10:04:38 graphmod.txt Dmesg, syslog, and Directory Tree for aborted
RH6.2 Update
2000-11-08 10:06:13 exprtmod.txt Dmesg, syslog, Directory Tree for aborted RH6.2
expert mode update attempt
2001-01-16 05:23:36 fstab fstab containing all mountable partitions on both drives
2001-01-16 05:24:28 partitions Partitions
2001-02-08 05:25:36 proc_scsi_7 RH 7.0 Install's /proc/scsi/scsi file
2001-02-08 05:27:25 proc_aic7_7 RH 7.0 Install's /proc/scsi/aic7xxx/0 file
2001-02-08 05:28:29 proc_scsi_6 RH 6.0's /proc/scsi/scsi file - same configuration
2001-02-08 05:29:30 proc_aic7_6 RH 6.0's /proc/scsi/aic7xxx/0 file - same
configuration
Create a new attachment (proposed patch, testcase

OK, I looked through the files from the previous bug, and I tend to agree that I
don't think this is a kernel bug.  But, I can't confirm what the actual bug is
just yet.  Personally, I *think* it is the problem I mentioned in my last
update.  Specifically, I think that in the presence of an existing IDE
subsystem, the installer is not automatically loading the sd_mod.o module.  That
would mean that even if the aic7xxx driver found some hard drives, they wouldn't
get attached as disks.  You can see if the sd_mod module is loaded by typing
lsmod on vt2.  Also, I wanted to point out that the number of interrupts from
the aic7xxx controller when it doesn't find any devices according to your last
bug report looks too high, like it really did find the devices but they aren't
there for some reason.  Booting the system into expert noprobe mode would allow
you to manually load the aic7xxx driver and you could pass the option
aic7xxx=verbose:0xffff to the aic7xxx module to get far more information about
what devices it might or might not find (which would fairly definitively isolate
the aic7xxx out of the equation if it finds the devices).