Bug 819500 - sos devicemapper plugin passes wrong arguments to systool for scsi bus info
sos devicemapper plugin passes wrong arguments to systool for scsi bus info
Product: Fedora
Classification: Fedora
Component: sos (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Bryn M. Reeves
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks: 868719 1036799
  Show dependency treegraph
Reported: 2012-05-07 08:36 EDT by Mark Goodwin
Modified: 2014-04-14 18:47 EDT (History)
4 users (show)

See Also:
Fixed In Version: sos-3.0-23.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 868719 (view as bug list)
Last Closed: 2014-04-14 18:47:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
correct arguemnts to systool to capture scsi bus info (617 bytes, patch)
2012-05-07 08:36 EDT, Mark Goodwin
no flags Details | Diff

  None (edit)
Description Mark Goodwin 2012-05-07 08:36:32 EDT
Created attachment 582644 [details]
correct arguemnts to systool to capture scsi bus info

Description of problem:
The devicemapper.py plugin in the sos tool invokes systool with incorrect
arguments for capturing scsi bus info. The patch from BZ #444838 and
it's various z-stream clones appears to be wrong. The correct usage
for scsi bus info is "systool -v -b scsi" or for scsi_host info is
"systool -v -c scsi_host". 

Version-Release number of selected component (if applicable):
All versions of sos in all versions of RHEL and Fedora, and also upstream
in the master branch at: https://github.com/sosreport/sosreport.git

How reproducible:

Steps to Reproduce:
1. run sosreport on a system with scsi devices
2. In the resulting sos tarball:
   # cat sos_commands/devicemapper/systool_-v_-c_-b_scsi
   Error opening class -b
Actual results:
   literally: "Error opening class -b" in all captured sos reports.

Expected results:
   scsi bus information (here omitted for brevity)

Additional info:
   the systool arguments are wrong, see attached patch against the
   current upstream master branch
Comment 1 Mark Goodwin 2012-05-07 09:03:09 EDT
Capturing the output of the following command would be even more useful,
but that's really an RFE rather than a bug fix :

systool -v -b scsi -c scsi_device -c scsi_disk -c scsi_generic -c scsi_host -m fc_host -m fc_remote_ports -m fc_transport -m fc_vports -m scsi_transport_fc -m scsi_tgt -m fcoe

See also BZ #444839 for capturing FC state. It would be useful to capture
some of the fc transport statistics (error_frames, crc_errors, etc), since
these are important for diagnosing flaky FC cables/connections.
Comment 7 Fedora End Of Life 2013-04-03 14:08:06 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
Comment 8 Fedora Update System 2014-03-31 12:22:56 EDT
sos-3.0-23.fc19 has been submitted as an update for Fedora 19.
Comment 9 Fedora Update System 2014-04-02 05:23:57 EDT
Package sos-3.0-23.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sos-3.0-23.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2014-04-14 18:47:12 EDT
sos-3.0-23.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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