From Bugzilla Helper: User-Agent: Mozilla/4.51 [en] (X11; I; Linux 2.2.5-15 i686) Dell Optiplex GX1p - 450MHz PII - Adaptec AHA-2940x Ultra SCSI. Same problem as reported for RH6.2 install/upgrade Please see Bugzilla #19558 Reproducible: Always Steps to Reproduce: 1. Optiplex with Adaptec 2940 Ultra SCSI Adapter - Seagate 39102W Drive - existing and working RH 6.0 Distribution 2. Disable IDE in CMOS (anaconda will *always* only specify IDE drives ignoring the SCSI if the IDE Drive is present). 3. Boot with either RH 7.0 boot.img or RH 7.0 bootnet.img file and attempt install. Actual Results: ananconda finds the FTP or NFS vfat /RedHat distribution on networked machine. Correctly identifies the ethernet controllers and the Adaptec SCSI controller - downloads to the adapter and populates the ram /proc entries. No devices on the SDSI adapter are detected even thought the drive is at i.d. 0 Expected Results: Installation should proceed on the SCSI drive partitions. This same problem is well-documented in Bugzilla Report #19558 which is the identical problem but with the RH 6.2 distribution.
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 2001-02-08 17:25:36 ------- Created an attachment (id=9479) RH 7.0 Install's /proc/scsi/scsi file ------- Additional comments from ARE 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 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 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 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 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 Component: anaconda Status: CLOSED Priority: normal Resolution: RAWHIDE Severity: Assigned To: bfox Cc: ARE QA Contact: borgan 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).