I was looking through the history of bug #413136, and since I just
worked through these same issues when trying to get raidutils working on
my own machine, I thought I'd post my findings there in case it helps
anyone else.
There are actually two separate problems getting mixed together in
#413136. They both prevent the "raidutil" command from running
successfully, but they have two separate causes.
The problem described in the original post was that running a "raidutil"
command produced the following output:
osdIOrequest : File /dev/dpti17 Could Not Be Opened
Engine connect failed: COMPATIBILITY number
This particular message is generated when "raideng" can't find any valid
device files to open. One can get additional confirmation of this by
running the command "raideng /VERBOSE", which will report
osdOpenEngine : <date> Return = 0 - 0 hbas found
The "0 hbas found" indicates that the program didn't find any
active raid controllers after probing a compiled-in list of device files.
Unfortunately, when raideng finds itself in this situation, it doesn't
give up and exit, but instead just keeps running and waits until a
raidutil process asks it to do something. At that point, raideng then
goes out and tries to open the last device file that it probed during
the earlier phase (even though the probing phase found that there was
not a controller attached to that device file). When this second
attempt to open the device file fails, then raideng (finally) aborts,
printing the "Could Not Be Opened" error message. It happens that
(under Linux, anyway) the last file probed is /dev/dpti17, and thus
that's the file mentioned in the error message.
So, to summarize what various people mentioned as part of the history for
bug #413136: if you get this error message, you most likely just need to
be sure that either /dev/i2octl or /dev/dpti0 exists (depending on
whether you are using the i2o_* modules or the dpt_i2o module).
(/dev/i2octl is created automatically via udev when the i2o_config
module is loaded.) If it still doesn't work, running "strace raideng"
should tell you which device files it's looking for.
(Note that in spite of the message printed, you do NOT actually need to
have a "/dev/dpti17" file [unless you are happen to be using the dpt_i2o
module to run 18 raid cards, anyway].)
However, for many of us who were using the i2o_* modules, getting past
the device-file problem didn't actually allow the "raidutil" command to
work. Instead, the existence of the proper /dev/i2octl caused raideng
to open and access that device file... and then segfault. The symptoms
for this problem are that "raidutil" aborts with the message "Engine
connect failed: Open", and that running "raideng /VERBOSE" doesn't
produce any output at all (other than a "Segmentation fault" message
from the system).
This segfault problem is covered by bug #332229, and I just posted a
patch there which resolves that problem (at least on our machine).
Looking through the history for #413136, I didn't see any issues raised
that weren't either related to missing device files or to the raideng
segfault-after-finding-the-i2octl-device issue. As far as I could see
from the history, all the people who reported a device-file problem were
able to get past it (at least far enough to run into the segfault
problem). So hopefully if the patch does actually resolve #332229, then
bug #413136 can be closed as well....
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
