Bug 231986
Summary: | [Emulex 4.7 bug] udev does not provide persistent names for tape devices | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Jamie Wellnitz <jamie.wellnitz> |
Component: | udev | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED ERRATA | QA Contact: | Jan HutaĆ <jhutar> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 4.6 | CC: | aliceboltofficial, andriusb, berthiaume_wayne, coughlan, cward, emcnabb, hicks_verdell, laurie.barry, lemons_terry, pknirsch, revers |
Target Milestone: | rc | Keywords: | OtherQA, Regression, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2008-0740 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-07-24 19:59:42 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: | 231990 | ||
Bug Blocks: | 246627, 286451, 367631 |
Description
Jamie Wellnitz
2007-03-13 13:52:41 UTC
nothing in /dev/disk* ?? But yes, I will add the upstream rules. Yes - nothing in /dev/disk*. The /dev/disk names are sd devices - those udev rules don't match st devices. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. The kernel from rhel-4.6 and udev do not support the easy way of getting the ids. scsi_id would have to be called to query the id, but scsi_id may hang on firewire devices, so firewire devices could not get a persistent name. I am sorry. added some tape rules anyway.. Jamie @ Emulex - Can you please test and provide feedback ASAP? Thanks! A fix for this issue should have been included in the packages contained in the RHEL4.6 Beta released on RHN (also available at partners.redhat.com). Requested action: Please verify that your issue is fixed to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should have been included in the packages contained in the RHEL4.6-Snapshot1 on partners.redhat.com. Requested action: Please verify that your issue is fixed to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. Ping. QE Here. 231986: Requested partner feed back from Jamie @ Emulex, but not yet PartnerVerified. I've manually Verified that the new rules have been added to udev 51-by-id.rules in new pkgs. Any updates? Please let me know ASAP. A fix for this issue should be included in RHEL4.6-Snapshot2--available soon on partners.redhat.com. Please verify that your issue is fixed to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should have been included in the packages contained in the RHEL4.6-Snapshot3 on partners.redhat.com. Please verify that your issue is fixed to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should be included in the packages contained in RHEL4.6-Snapshot4--available now on partners.redhat.com. Please verify that your issue is fixed ASAP to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should be included in the packages contained in RHEL4.6-Snapshot5--available now on partners.redhat.com. Please verify that your issue is fixed ASAP to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should be included in the packages contained in RHEL4.6-Snapshot6--available now on partners.redhat.com. Please verify that your issue is fixed ASAP to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. A fix for this issue should be included in the packages contained in RHEL4.6-Snapshot7--available now on partners.redhat.com. IMPORTANT: This is the last opportunity to confirm that your issue is fixed in the RHEL4.6 update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message about your test results to Issue Tracker. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. Unfortunately, the udev tape support in RHEL 4.6 doesn't quite work. The rules are there, but they don't work out of the box. We realize this fix is too late for RHEL 4.6, which is Emulex's error because we didn't verify this much earlier which we had ample time to do. Here are the steps for a user to fix it: 1. In /etc/udev/rules.d/50-udev.rules, remove/comment out this line: KERNEL="nst[0-9]*", SYMLINK="tape%e" (removes the rule that creates a softlink named /dev/tape which in turn obscures the /dev/tape directory that the other rules use) 2. In /etc/scsi_id.config, comment out this line: options=-b and change this line: ## options=-g to: options=-g -u (tells the scsi_id utility to whitelist all devices (-b removed and -g added) and replace spaces with underscores (-u)) 3. Add this line (as a single line) to /etc/udev/rules.d/51-by-id.rules : KERNEL="sg*", SYSFS{type}="8", PROGRM="/sbin/scsi_id", SYMLINK="tape/by-id/scsi-%c-changer" (to support persistent names for Medium Changers) Jamie, let's just create new bugs to track this for 4.7 and 5.2... I'll take care of the cloning of bugs... it far too late to add anything for 4.6. and 5.1. Thanks, Andrius. Jamie, I've just been informed by Quality Engineering that they don't see this bug as resolved, so we'll use this for 4.7. Harald, please use Comment #22 as a guide for a better fix for 4.7. An EMC engineer provides these comments: I found a bug in the new 50-udev.rules. If you have tape devices with double digit 'numbers' the patched rules don't make persistent names for them. I fixed it by adding a * after the nst[0-9] lines: [root@marmot rules.d]# diff 50-udev.rules 50-udev.rules.pre_edc 262,265c262,265 < KERNEL=="nst[0-9]*", IMPORT{parent}=="ID_*" < KERNEL=="nst[0-9]*", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="", IMPORT {program}="scsi_id -g -x -s %p -d $tempnode" < KERNEL=="nst[0-9]*", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="", IMPORT {program}="scsi_id -g -x -a -s %p -d $tempnode" < KERNEL=="nst[0-9]*", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="?*", SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-nst" --- > KERNEL=="nst[0-9]", IMPORT{parent}=="ID_*" > KERNEL=="nst[0-9]", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="", IMPORT {program}="scsi_id -g -x -s %p -d $tempnode" > KERNEL=="nst[0-9]", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="", IMPORT {program}="scsi_id -g -x -a -s %p -d $tempnode" > KERNEL=="nst[0-9]", SUBSYSTEM=="scsi_tape", ENV{ID_SERIAL}=="?*", SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-nst" Seems to work on my system. edc ~~~~~~~~~~~~~~ ~ Attention: ~ Feedback requested regarding this **High Priority** bug. ~~~~~~~~~~~~~~ A fix for this issue should be included in the latest packages contained in RHEL4.7-Snapshot1--available now on partners.redhat.com. After you (Red Hat Partner) have verified that this issue has been addressed, submit a comment describing the passing results of your test in appropriate detail, along with which snapshot and package version tested. The bugzilla will be updated by Red Hat Quality Engineering for you when this information has been received. If you believe this issue has not properly fixed or you are unable to verify the issue for any reason, please add a comment describing the most recent issues you are experiencing, along with which snapshot and package version tested. If you believe the bug has not been fixed, change the status of the bug to ASSIGNED. If you are receiving this message in Issue Tracker, please reply with a message to Issue Tracker about your results and bugzilla will be updated for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager. Thank you Red Hat QE Partner Management The RHEL4.7-Snapshot1 udev RPM (udev-039-10.21.el4) creates persistent tape names correctly in my environment, however the rule for changers has a typo: KERNEL="sg*", SYSFS{type}="8", PROGRM="/sbin/scsi_id", SYMLINK="tape/by-id/scsi-%c-changer" The word "PROGRAM" is missing its 'A' (in /etc/udev/rules.d/51-by-id.rules). So this works for tape devices themselves (with a properly configured /etc/scsi_id.config), but not for changers/robots. ~ Attention ~ Testing Feedback Deadlines are approaching! This bug should fixed in Partner Snapshot 4, which is now available on partners.redhat.com, ready for testing. We are approaching the end of RHEL 4.7 testing cycle. It is important to let us know of your testing results *as soon as possible*. If any issues are found once the testing phase deadline has passed, you might lose your opportunity to include the fix in this RHEL update. If you have verified that this bug has been properly fixed or have discovered any issues, please provide detailed feedback of your testing results, including the package version and snapshot tested. The bug status will be updated for you, based on testing results. Contact your Partner Manager with any additional questions. Tested snapshot: RHEL 4.7-snapshot4 package: udev-039-10.22.el4 The rules in this package work for changers now (as well as for tape drives themselves). 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 therefore 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-2008-0740.html Partners, I would like to thank you all for your participation in assuring the quality of this RHEL 4.7 Update Release. My hat's off to you all. Thanks. Hi I'd like to re-open this bug, because I believe the fix is not yet in RHEL 4. This same feature works GREAT right out of the box in RHEL 5.3. When a RHEL 4.7 system is created, the persistenly-named symbolic links that should appear in /dev/[disk|tape]/by-id are not created. I corresponded with Jamie Wellnitz at Emulex, the father of this bug. He told me that, in order for the persistenly-named symbolic links to be created, /etc/scsi_id.conf MUST be modified thusly: options=-g -u Commenting on this solution, Jamie wrote: "Well ... I can see the problem with turning -g on by default - apparently there are SCSI devices that don't respond well to inquiry commands. -u seems harmless, though. I am unaware of any side effect that some users wouldn't like. One partial solution might be to add a comment to /etc/scsi_id.config to explain the need for options=-g -u for persistent names for SCSI devices. But I'm not sure how someone in this situation would find the comment. I agree this isn't as good a customer experience as one would want." The problem I have is that we still haven't created a documented working solution for our customers. Not only does RHEL 4.7 not work out-of-the-box, the supporting documentation created as part of solving this problem does not articulate a working solution, either. What about the idea of modifying http://rhn.redhat.com/errata/RHBA-2008-0740.html to include the need to implement "options=-g -u" in /etc/scsi_id.conf, in order to get a working solution? If there are 'cons' to doing this, put them in there, too, so our customers can make an informed decision on whether to implement this or not. I checked the RHEL V4.8 beta 1, and it has the same issue. What next? Thanks! Terry Lemons BPG Engineering EMC A new bugzilla is required, since Emulex signed off already on the fix that went into RHEL 4.7. Please do not re-open this bug. That being said, we are already well past RHEL 4.8 Beta development, and ramping down RHEL 4 development in general. Thanks for the reply. Given that RHEL 4 development is ramping down, perhaps the right thing to do is to go with a documentation-only fix, as I suggested in comment #50. Thoughts? Thanks tl Please note also that with the erratum RHBA-2009:8195-03 for RHEL4.8 the directory name has changed to /dev/tape-id because of https://bugzilla.redhat.com/show_bug.cgi?id=461480 . Terry - it looks like the most effective means of documentation (that will persist after RHEL 4 is in maintenance mode) is via a kbase entry. Evan McNabb can propose a kbase entry, but it would be really helpful if you could do a quick draft in the form of a single Q&A regarding this issue. Thanks! Okay, here's my swag: Q: How can RHEL 4.7 automatically create persistent names for SCSI devices? A: udev rules supplied with RHEL 4.7 will create persistent device names for SCSI devices. These names are actually persistenly-named symbolic links that appear in /dev/disk/by-id (for disk devices) and /dev/tape/by-id (for tape and media changer devices). These symbolic links, which use persistent device attributes (like serial numbers), do not change when devices are added or removed from the system (which causes reordering if the /dev/nst* devices, for example). Use of these persistenly-named symbolic links is highly desirable in, for instance, the configuration of backup software (which is commonly a static definition that binds a backup software device name to an operating system-level device file name). By default, a RHEL 4.7 system will not create these persistenly-named symbolic links in /dev/[disk|tape]/by-id. In order for the persistenly-named symbolic links to be created, /etc/scsi_id.conf MUST be modified thusly: options=-g -u Following this modification, the system should be rebooted to enable creationof the persistenly-named symbolic links. Note that these persistenly-named symbolic links are created in addition to the default device file names in /dev (ex., /dev/nst0). A caution: use of these options will send SCSI inquiry commands to all SCSI devices connected to the system. Some SCSI devices don't respond well to inquiry commands. If problems caused by this feature appear, disable use of the 'options=-g -u' parameter in /etc/scsi_id.conf. Hi Terry, Thanks for the write-up. We already have a few kbases related to this topic: http://kbase.redhat.com/faq/docs/DOC-4233 http://kbase.redhat.com/faq/docs/DOC-4202 What are your thoughts? Are these sufficient or should some of your notes above be integrated in? Hi Evan Thanks for the reply, and for this additional information. Alas, these two documents are not sufficient/correct, because: - they do not explain the need to use the -u option as well as -g, and - the documents espouse the creation of additional udev rules, instead of using the default, standard, automatically-exeucted ones I believe that our customers do not want to write udev rules unless they absolutely have to, and we don't want them to, as we must provide support for this activity. We don't want to go there, if we can help it. So I do think the words I suggested are unique, and not covered in anything else that I've seen. What say you? Thanks! tl Let's discuss this further via email and we can post the final result here. I decided to include pressing the control panels . While my left pinky pressed on the ON button, my other left fingers just randomly and continuously pressed the Home, Back, Select button. And at the same time, my rights fingers also did the similar, randomly and continuously pressed on the other control buttons, the Up, Down, and OK. https://www.hpsupport365.com/blog/5-easy-steps-to-fix-hp-printer-error-code-0x83c0000a/ |