This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 141591 - PowerVault backplane results in "N/A" in STORAGE definition
PowerVault backplane results in "N/A" in STORAGE definition
Status: CLOSED ERRATA
Product: Red Hat Ready Certification Tests
Classification: Retired
Component: other (Show other bugs)
beta
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rob Landry
Rob Landry
:
Depends On:
Blocks: 143442
  Show dependency treegraph
 
Reported: 2004-12-02 06:42 EST by Jay Turner
Modified: 2015-01-07 19:09 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-01 10:20:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output from hardware.py (10.74 KB, application/octet-stream)
2004-12-07 07:57 EST, Jay Turner
no flags Details

  None (edit)
Description Jay Turner 2004-12-02 06:42:24 EST
Description of problem:
This is pretty minor, but we might want to clean it up at some point in time.  I
have a Dell PE2800, and with rhr2-rhel4-0.9-14.9e.dummyrun, I end up with
"STORAGE sda N/A" in hardware.conf.  The "N/A" is coming from this:

        'generic' : 'sg0'
        'bus' : 'SCSI'
        'driver' : 'ignore'
        'id' : '6'
        'host' : '0'
        'lun' : '0'
        'device' : 'sg0'
        'detached' : '0'
        'class' : 'OTHER'
        'channel' : '0'
        'desc' : '"Pe/pv 1x8 SCSI BP"'

Appears to be completely harmless, as the test completes successfully, but it
does throw lots of errors into the output.log (which I'm surprised don't lead to
a failure, but nonetheless.)  Stuff like:

++ awk -v awkdev=N/A ' {                if($4==awkdev){                 print
$3;                }               } ' /proc/partitions + local size= ++ expr /
3 expr: syntax error + local second= ++ expr / 3 '*' 2 expr: syntax error +
local third= + badblocks -c 16384 -s /dev/N/A 0 + badblocks -c 16384 -s /dev/N/A
+ badblocks -c 16384 -s /dev/N/A + wait badblocks: bad blocks range: 0-0^M
badblocks: No such file or directory while trying to determine device size^M
badblocks: No such file or directory while trying to determine device size^M 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Rob Landry 2004-12-06 13:13:46 EST
Being class of "Other" should mean it get's ignored so there's
something else causing it most likely.  Can I get a copy of the output
from /usr/share/rhn/up2date_client/hardware.py.  Also I believe the
latter part to be a different bug (hopefully sorted already) though we
do need to track it.
Comment 2 Jay Turner 2004-12-07 07:57:21 EST
Created attachment 108036 [details]
Output from hardware.py
Comment 3 Rob Landry 2004-12-07 09:55:30 EST
I believe it's this...

'pcibus' : '2'
'vendorId' : '1028'
'subDeviceId' : '016e'
'bus' : 'PCI'
'driver' : 'megaraid_mbox'
'pciType' : '1'
'pcidom' : '0'
'deviceId' : '0013'
'pcifn' : '0'
'detached' : '0'
'pcidev' : 'e'
'subVendorId' : '1028'
'class' : 'RAID'
'desc' : '"Dell PowerEdge Expandable RAID controller 4"'

...that causes the problem, I thought this was already worked out though, let me
take a look as if this is it then it should be a regression and I'll need to fix
that.
Comment 4 Rob Landry 2004-12-07 09:58:58 EST
should be fixed in CVS
Comment 5 Daniel W. Ottey 2005-01-19 11:31:13 EST
We have seen this also in our running, also with "megaraid_mbox."  But it
actually seems to cause our STORAGE test to fail.  We were able to work-around
it by modifying the scripts.

Is the CVS repository publically available?  I see many fixes are being placed
into CVS, and we would like to have those fixes in order to run our test.

What is the process for us to run official hardware certification if the cert
test is failing because of this bug?
Comment 6 Richard Li 2005-01-19 11:35:32 EST
> We have seen this also in our running, also with "megaraid_mbox."  But it
> actually seems to cause our STORAGE test to fail.  We were able to work-around
> it by modifying the scripts.

What version are you running?

> Is the CVS repository publically available?  I see many fixes are being placed
> into CVS, and we would like to have those fixes in order to run our test.

No, the CVS repository is not publically available at this time. The fix for
this should have gone out in the RC (and gold) releases.

> What is the process for us to run official hardware certification if the cert
> test is failing because of this bug?

Open an Issue Tracker, please.
Comment 7 Daniel W. Ottey 2005-01-19 11:47:48 EST
We are running the release version, ispec-1.0-2

I've seen in the code where if the driver is "megaraid" the device is ignored. 
My work-around added a check for a driver named "megaraid_mbox".
Comment 8 Rob Landry 2005-01-19 12:31:57 EST
we'll need to change the literal ="megaraid" to anything containing "megaraid"
since that's a moving target (eg. megaraid vs. megaraid_mbox vs. megaraid_mm vs
megaraid_2002 etc.) or code a couple more cases.  Untill we release an errata to
correct this the N/A will need to be removed from the hardware.conf; if using
the rhr-wrapper then a hardware.append will need to be created containing the
correct STORAGE line and that should work around this.
Comment 9 Daniel W. Ottey 2005-01-19 16:27:47 EST
Is this an official certification route (modifying the hardware.conf file)?

Also, should we still raise an Issue Tracker item?
Comment 10 Rob Landry 2005-01-19 16:51:41 EST
This needs to be addressed in an errata; however we don't want to block certs
based on this so using hardware.append is the work around to use for any
official certs until such an errata is released.
Comment 11 David Lawrence 2005-02-01 10:20:06 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-051.html

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