Bug 141591

Summary: PowerVault backplane results in "N/A" in STORAGE definition
Product: [Retired] Red Hat Ready Certification Tests Reporter: Jay Turner <jturner>
Component: otherAssignee: Rob Landry <rlandry>
Status: CLOSED ERRATA QA Contact: Rob Landry <rlandry>
Severity: medium Docs Contact:
Priority: medium    
Version: betaCC: bjohnson, daniel.ottey, hcp-admin, richardl, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-01 15:20:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 143442    
Attachments:
Description Flags
Output from hardware.py none

Description Jay Turner 2004-12-02 11:42:24 UTC
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 18:13:46 UTC
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 12:57:21 UTC
Created attachment 108036 [details]
Output from hardware.py

Comment 3 Rob Landry 2004-12-07 14:55:30 UTC
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 14:58:58 UTC
should be fixed in CVS

Comment 5 Daniel W. Ottey 2005-01-19 16:31:13 UTC
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 16:35:32 UTC
> 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 16:47:48 UTC
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 17:31:57 UTC
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 21:27:47 UTC
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 21:51:41 UTC
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 15:20:06 UTC
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