Bug 197112
Summary: | FEAT:Need SCSI generic module loaded for tape firmware update to work. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Sandeep K. Shandilya <sandeep_k_shandilya> |
Component: | module-init-tools | Assignee: | Jon Masters <jcm> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 4.5 | CC: | coughlan, jfeeney, notting, wwlinuxengineering |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2007-0265 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-05-01 22:51:11 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: | 190484, 225073 |
Description
Sandeep K. Shandilya
2006-06-28 16:50:56 UTC
Have they tried using SG_IO on the actual device node? Assigning to udev; this is probably best handled there. For example, in current Fedora releases we have: ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg" (In reply to comment #2) > Assigning to udev; this is probably best handled there. For example, in current > Fedora releases we have: > ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg" The application is just calling the open("/dev/sg0",....). I dont think that udev should be responsible to load a module at this time? (In reply to comment #2) > Assigning to udev; this is probably best handled there. For example, in current > Fedora releases we have: > ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg" I tried the same on fc5 and the module get autoloaded. I will try the same on RHEL 4 by adding the line you have mentioned above. Can this fix make it to RHEL4 update4? If there is patch that you want me to check out I could help. I am setting up a test to make changes to udev.rules to try this out. While I'm not the udev maintainer, it is very late in the update cycle for U4; we've well passed the content definition process. This request is too late for RHEL4 Update4 -- it's closed and due out by the end of the month. RHEL4.5 is also closed for feature requests. If this is critical, we can escalate it for late consideration. I will need a business case and Dell's agreement to escalate. In the meantime, I've put it on the RHEL4.6 list for consideration. Though there's no schedule yet, GA will likely be in the summer of '07. (In reply to comment #7) > This request is too late for RHEL4 Update4 -- it's closed and due out by the end > of the month. > > RHEL4.5 is also closed for feature requests. If this is critical, we can > escalate it for late consideration. I will need a business case and Dell's > agreement to escalate. In the meantime, I've put it on the RHEL4.6 list for > consideration. Though there's no schedule yet, GA will likely be in the summer > of '07. Yes this is critical because the DAT72 is a low end SCSI tape drive. These are used in the small and medium Buisness and are sold in large quantities. Moreover none of the other tape management commands (eject, forward, rewind etc...)work because all of them require the /dev/sg? nodes to be present. In all the above cases manual intervention to load sg is required. Customers are very likely to call Dell support if they observe that thier drive is not working as expected and they are not aware about the sg module. Red Hat assumes Dell will test this during RHEL4.5 beta. Yes, Dell will test this during 4.5 Beta. This event sent from IssueTracker by ltroan issue 97824 please let dell test http://people.redhat.com/harald/downloads/udev/udev-039-10.16.EL4/ ping? (In reply to comment #18) > ping? No the module does not autoload with this rule. I could attach some logs to the defect, what will you need. I can think starting udevd with log level set to LOG_DEBUG? Best solution: add to /etc/modprobe.conf.dist: install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg (In reply to comment #20) > Best solution: > add to /etc/modprobe.conf.dist: > install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg > It works okay now. (In reply to comment #20) > Best solution: > add to /etc/modprobe.conf.dist: > install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg > (In reply to comment #24) > (In reply to comment #20) > > Best solution: > > add to /etc/modprobe.conf.dist: > > install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg > > > > It works okay now. > I presume that it will be available in the next update of RHEL4.[56]'s module-init-tools package. 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-2007-0265.html |