Bug 231986 - [Emulex 4.7 bug] udev does not provide persistent names for tape devices
[Emulex 4.7 bug] udev does not provide persistent names for tape devices
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: udev (Show other bugs)
4.6
All Linux
high Severity medium
: rc
: ---
Assigned To: Harald Hoyer
Jan Hutař
: OtherQA, Regression, Reopened
Depends On: 231990
Blocks: 246627 286451 367631
  Show dependency treegraph
 
Reported: 2007-03-13 09:52 EDT by Jamie Wellnitz
Modified: 2009-06-19 11:51 EDT (History)
10 users (show)

See Also:
Fixed In Version: RHBA-2008-0740
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-24 15:59:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jamie Wellnitz 2007-03-13 09:52:41 EDT
Description of problem: udev rules lack persistent tape names.


Version-Release number of selected component (if applicable): udev-039-10.15.EL4


How reproducible: Always


Steps to Reproduce:
1. Plug in tape device (fibre channel-attached in my test case)
2. Look for a persistent name
3.
  
Actual results: No persistent name.


Expected results: Persistent name for the tape device (and for media changers).


Additional info: Tape devices get 8 names each, e.g. st0, st0a, st0l, st0m,
nst0, nst0a, nst0l, nst0m.  The upstream udev tree has these sample rules to
provide a persistent name for the nst name only (in version 106):

KERNEL=="nst[0-9]", SUBSYSTEMS=="scsi", ENV{ID_SERIAL}=="", IMPORT{program}="sc
KERNEL=="nst[0-9]", SUBSYSTEMS=="scsi", ENV{ID_SERIAL}=="", IMPORT{program}="sc
KERNEL=="nst[0-9]", SUBSYSTEMS=="scsi", ENV{ID_SERIAL}=="?*", SYMLINK+="tape/by

# type 8 devices are "Medium Changers"
KERNEL=="sg*", SUBSYSTEMS=="scsi", ATTRS{type}=="8", ENV{ID_SERIAL}=="", IMPORT
KERNEL=="sg*", SUBSYSTEMS=="scsi", ATTRS{type}=="8", ENV{ID_SERIAL}=="", IMPORT
KERNEL=="sg*", SUBSYSTEMS=="scsi", ATTRS{type}=="8", ENV{ID_SERIAL}=="?*", SYML
Comment 1 Harald Hoyer 2007-03-13 10:07:56 EDT
nothing in /dev/disk* ?? But yes, I will add the upstream rules.
Comment 2 Jamie Wellnitz 2007-03-13 10:13:34 EDT
Yes - nothing in /dev/disk*.  The /dev/disk names are sd devices - those udev
rules don't match st devices.
Comment 3 RHEL Product and Program Management 2007-05-09 01:46:02 EDT
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.
Comment 7 Harald Hoyer 2007-07-18 05:26:29 EDT
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.
Comment 8 Harald Hoyer 2007-07-18 06:01:24 EDT
added some tape rules anyway..
Comment 9 Harald Hoyer 2007-08-01 05:29:34 EDT
Please test
http://people.redhat.com/harald/downloads/udev/udev-039-10.19.el4
Comment 11 Andrius Benokraitis 2007-08-01 09:38:42 EDT
Jamie @ Emulex - Can you please test and provide feedback ASAP? Thanks!
Comment 12 John Poelstra 2007-08-29 13:18:15 EDT
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.
Comment 13 John Poelstra 2007-09-05 18:26:30 EDT
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.
Comment 14 Chris Ward 2007-09-10 11:08:32 EDT
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.
Comment 15 John Poelstra 2007-09-11 20:42:05 EDT
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.
Comment 16 John Poelstra 2007-09-20 00:30:33 EDT
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.
Comment 17 John Poelstra 2007-09-26 19:36:00 EDT
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.
Comment 18 John Poelstra 2007-10-04 22:58:02 EDT
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.
Comment 19 John Poelstra 2007-10-10 23:09:37 EDT
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.
Comment 20 John Poelstra 2007-10-18 14:53:48 EDT
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.
Comment 22 Jamie Wellnitz 2007-10-25 16:13:16 EDT
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)
Comment 23 Andrius Benokraitis 2007-10-26 15:26:21 EDT
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.
Comment 24 Jamie Wellnitz 2007-10-26 15:43:26 EDT
Thanks, Andrius.
Comment 25 Andrius Benokraitis 2007-10-30 11:39:50 EDT
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.
Comment 30 Terry Lemons 2007-11-30 15:40:33 EST
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
Comment 31 Harald Hoyer 2008-04-14 11:47:40 EDT
you may test:
http://people.redhat.com/harald/downloads/udev/udev-039-10.20.el4
Comment 34 Chris Ward 2008-06-05 11:55:06 EDT
~~~~~~~~~~~~~~
~ 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
Comment 35 Jamie Wellnitz 2008-06-10 16:14:19 EDT
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.

Comment 45 Chris Ward 2008-06-27 07:37:23 EDT
~ 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.
Comment 46 Jamie Wellnitz 2008-06-27 11:30:19 EDT
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).
Comment 48 errata-xmlrpc 2008-07-24 15:59:42 EDT
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
Comment 49 Chris Ward 2008-07-29 03:30:19 EDT
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.
Comment 50 Terry Lemons 2009-03-18 19:17:08 EDT
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
Comment 51 Andrius Benokraitis 2009-03-18 21:58:07 EDT
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.
Comment 52 Terry Lemons 2009-03-19 09:09:28 EDT
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
Comment 53 Harald Hoyer 2009-03-19 09:45:57 EDT
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 .
Comment 54 Andrius Benokraitis 2009-03-19 13:48:59 EDT
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!
Comment 55 Terry Lemons 2009-03-19 16:00:14 EDT
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.
Comment 56 Evan McNabb 2009-03-25 13:58:05 EDT
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?
Comment 57 Terry Lemons 2009-03-25 15:03:15 EDT
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
Comment 58 Evan McNabb 2009-03-25 15:11:27 EDT
Let's discuss this further via email and we can post the final result here.

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