Steps to reproduce problem:
1) place RedHat 70 install files to FAT16 partition on a Compaq Array
2) start installation from that same FAT16 partition on the hard drive
3) installation doesn't begin because the installer can't access the
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
Possibly the problem is in loader on boot.img.
We will have a look.
Assigning to a developer.
fixed in CVS - will be included in the next version.
*** Bug 24387 has been marked as a duplicate of this bug. ***
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 ...
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
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
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(), step)
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
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 755, in
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1199, in
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>
windowCreator: <method InstallInterface.progressWindow of InstallInterface
instance at 825bbb8>
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 ...
This must be a bug in the driver.
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.
Reports that the cpqarray is fixed kernel side, moving back to anacodna
*** Bug 29567 has been marked as a duplicate of this bug. ***
Matt make sure we get this verified before 3/6 please.
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.
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.
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.
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
--- 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://"):
fix checked into CVS.