Bug 23942 - Install from hard drive failes on Compaq Array Controller
Install from hard drive failes on Compaq Array Controller
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Matt Wilson
Aaron Brown
:
: 24387 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-12 20:20 EST by Richard Black
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-05 16:34:24 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 Richard Black 2001-01-12 20:20:09 EST
Steps to reproduce problem:
1) place RedHat 70 install files to FAT16 partition on a Compaq Array 
Controller
2) start installation from that same FAT16 partition on the hard drive
3) installation doesn't begin because the installer can't access the 
source files.

Notes:
The device name pointing to the Compaq Array Controller is mangled.  It 
currently reads ida/c0d01 instead of ida/c0d0p1.  Notice the missing "p".

As long as the installation source is not the same hard drive, the 
installer will install to a Compaq Array Controller.  When the source 
files reside on the array controller is when this issue shows up.

This install from hard drive works on SCSI and IDE, fails on Compaq Array 
Controller.

Possibly the problem is in loader on boot.img.
Comment 1 Michael Fulbright 2001-01-15 19:25:19 EST
We will have a look.
Comment 2 Michael Fulbright 2001-01-17 13:04:53 EST
Assigning to a developer.
Comment 3 Matt Wilson 2001-01-19 03:13:45 EST
fixed in CVS - will be included in the next version.
Comment 4 Matt Wilson 2001-01-19 18:01:52 EST
*** Bug 24387 has been marked as a duplicate of this bug. ***
Comment 5 Brock Organ 2001-01-23 10:35:46 EST
testing using the qa0123.0 test tree, the cpqarray module is loaded by anaconda,
but is listed by lsmod as being unused; additionally, cat /proc/scsi/scsi lists:
No devices attached ...
Comment 6 Matt Wilson 2001-01-23 10:45:46 EST
cpqarray doesn't use the scsi midlayer.  Look in /proc/driver/ida and 
/proc/driver/cciss.  I hope those locations are not moving around from 2.2 to
2.4.

Matt
Comment 7 Brock Organ 2001-01-24 13:43:35 EST
testing with qa0124.0 test tree shows some progress (device is recognized!) but
there are three issues:

1) GUI install:  hangs during installation of the first package glibc-common @
95% of the way through
2) TUI install (non-serial): kernel oops at random places in the first few
packages
3) TUI install (serial console): traceback (see below):

Traceback (innermost last):
  File "/usr/bin/anaconda", line 503, in ?
    intf.run(todo, test = test)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 1201, in run
    rc = apply (step[1](), step[2])
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/text.py", line 628, in __call__
    if todo.doInstall ():
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1588, in
doInstall
    self.fstab.makeFilesystems ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 755, in
makeFilesystems
    mntpoint)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1199, in
ext2FormatFilesystem   
    fd = os.open(messageFile, os.O_RDWR)
OSError: [Errno 2] No such file or directory: '/tmp/mke2fs.log'

Local variables in innermost frame:
argList: ['/usr/sbin/mke2fs', '/tmp/ida/c0d0p6', '-L', '/']
w: <text.ProgressWindow instance at 9231070>
mntpoint: /
windowCreator: <method InstallInterface.progressWindow of InstallInterface
instance at 825bbb8>
messageFile: /tmp/mke2fs.log

Comment 8 Brock Organ 2001-01-24 15:21:52 EST
oot supplied an update disk with qa0124.0 test tree, that avoids the traceback
above, but now the TUI and GUI installer both hang on the installation of the
first package, glibc-common ...
Comment 9 Matt Wilson 2001-01-24 18:15:52 EST
This must be a bug in the driver.
Comment 10 Arjan van de Ven 2001-01-25 09:03:23 EST
The Compaq Smart Array driver has a known bug in 2.4 kernels upto and including
2.4.0-ac11. A (potential) fix has become available in 2.4.1pre10, however the
fix clashes with the ac11 patch (which is 2.4.1pre9 based). Either ac12 (due out
today) or our own fix will happen soon, having a way to test to verify that the
bug fixed is actually the problem seen here would be nice.
Comment 11 Matt Wilson 2001-02-28 10:25:43 EST
Reports that the cpqarray is fixed kernel side, moving back to anacodna
Comment 12 Matt Wilson 2001-02-28 10:26:44 EST
*** Bug 29567 has been marked as a duplicate of this bug. ***
Comment 13 Michael Fulbright 2001-03-01 14:26:23 EST
Matt make sure we get this verified before 3/6 please.
Comment 14 Michael Fulbright 2001-03-05 12:52:47 EST
Assigning to a developer.
Comment 15 Brent Fox 2001-03-05 13:05:04 EST
It's not clear whether we are taking about the Smart Array 5300, which uses the
cciss driver, or the other Smart Arrays, which use the cpqarray.
Comment 16 John Cagle 2001-03-05 13:14:39 EST
Initially this problem was found with the 'cpqarray' driver which uses the 
device nodes in the /dev/ida directory.  The 'cciss' driver uses similarly 
named device nodes in the /dev/cciss directory.

The original problem was caused by the installer using mal-formed device names 
(/dev/ida/c0d01 instead of /dev/ida/c0d0p1).  The "p" partition specifier was 
missing from the device name.

Since the install code for cciss devices was probably copied from the install 
code for cpqarray devices, this problem may exist with *both* cpqarray and 
cciss when trying to install from a hard drive.
Comment 17 Brent Fox 2001-03-05 13:19:10 EST
I have done installs of both Wolverine and RC2 on DL380s with the Smart Array
Controller...but not the 5300.  I have tried cdrom and nfs installs...but not
hard drive.  I will test this today.
Comment 18 Matt Wilson 2001-03-05 16:34:18 EST
ok, now that we've gotten all the other bugs out of the way, I've found a
parsing bug in the code that sets up the second stage anaconda parts.  I've
fixed this.

--- anaconda	2001/02/27 18:13:34	1.147
+++ anaconda	2001/03/05 21:34:10
@@ -429,14 +429,15 @@
         method = UrlInstallMethod(method)
     elif (method[0:5] == "hd://"):
         method = method[5:]
-        i = string.index(method, '/')
-        dir = method[i:]
-        driveAndType = method[0:i]
+
+        i = string.index(method, ":")
+        drive = method[0:i]
+        method = method[i+1:]
         
-        i = string.index(driveAndType, ":")
-        drive = driveAndType[0:i]
-        type = driveAndType[i + 1:]
-        
+        i = string.index(method, "/")
+        type = method[0:i]
+        dir = method[i+1:]
+
         from harddrive import HardDriveInstallMethod
         method = HardDriveInstallMethod(drive, type, dir, intf.messageWindow)
     elif (method[0:8] == "oldhd://"):
Comment 19 Matt Wilson 2001-03-05 16:37:17 EST
fix checked into CVS.

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