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:
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.
Created attachment 108036 [details] Output from hardware.py
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.
should be fixed in CVS
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?
> 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.
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".
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.
Is this an official certification route (modifying the hardware.conf file)? Also, should we still raise an Issue Tracker item?
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.
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