Bug 650107 - /dev/changer symlink not created
/dev/changer symlink not created
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
16
All Linux
low Severity high
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-05 04:42 EDT by Wolfgang Denk
Modified: 2013-02-13 19:51 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 19:51:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed udev rule to add /dev/changer* symlinks (198 bytes, text/plain)
2011-02-09 03:32 EST, Wolfgang Denk
no flags Details

  None (edit)
Description Wolfgang Denk 2010-11-05 04:42:08 EDT
Description of problem:

I have several systems with SCSI Medium Changers (auto-loaders, tape libraries)
attached. Up to and including Fedora 13 udev would create a "/dev/changer"
symbolic link pointing to the specific /dev/sg* device.  After updating these
systems to Fedora 14, these links are missing on all systems. 

Version-Release number of selected component (if applicable):

udev-161-4.fc14.x86_64


How reproducible:

always

Steps to Reproduce:
1. Boot a system with a SCSI Medium Changer attached
2. Check that the console log contains output similar to this:
...
ch0: type #1 (mt): 0x0+1 [medium transport]
ch0: type #2 (st): 0x1+7 [storage]
ch0: type #3 (ie): 0x0+0 [import/export]
ch0: type #4 (dt): 0xf0+1 [data transfer]
ch0: dt 0xf0: READ ELEMENT STATUS failed
ch0: INITIALIZE ELEMENT STATUS, may take some time ...
ch0: ... finished
ch 10:0:4:0: Attached scsi changer ch0
ch 10:0:4:0: Attached scsi generic sg6 type 8
...

3.  Check if the /dev/changer link is there:
# ls -l /dev/chang*
ls: cannot access /dev/chang*: No such file or directory
  
Actual results:

Link is missing.

Expected results:

Normally, /lib/udev/rules.d/40-redhat.rules would detect that a SCSI changer device is there and create symlinks (in the example above, "/dev/changer" and
"/dev/changer-sg6").

However, /lib/udev/rules.d/40-redhat.rules does not exist any more.

Additional info:

I had the very same problem when updating to Fedora 13; doen't anybody test this?

See Bug 600983 - /dev/changer symlink not created
Comment 1 Wolfgang Denk 2011-02-09 03:32:45 EST
Created attachment 477765 [details]
Proposed udev rule to add /dev/changer* symlinks

The attached udev rule appears to work fine for me.
Comment 2 Harald Hoyer 2011-02-09 06:08:11 EST
(In reply to comment #0)
> ch 10:0:4:0: Attached scsi changer ch0
> ch 10:0:4:0: Attached scsi generic sg6 type 8

hmm... is there a /dev/ch0 which could be used instead?
Comment 3 Harald Hoyer 2011-02-09 06:21:29 EST
And you should really use the symbolic link in /dev/disk/*/* which is more precise.
Comment 4 Wolfgang Denk 2011-02-09 06:32:34 EST
I can see the

...
ch 3:0:8:0: Attached scsi changer ch0
...
ch 3:0:10:0: Attached scsi changer ch1
...

messages in my syslog, but I cannot see any /dev/ch? on my systems:

# ls -ld /dev/ch*
drwxr-xr-x 2 root root 3520 Nov  9 13:15 /dev/char
# 

Which symbolic link in /dev/disk/*/* should I use? It appears there are only disk drives (as the name suggests), but not any tape drives or media changers.
Comment 5 Harald Hoyer 2011-02-09 06:53:41 EST
(In reply to comment #4)
> I can see the
> 
> ...
> ch 3:0:8:0: Attached scsi changer ch0
> ...
> ch 3:0:10:0: Attached scsi changer ch1
> ...
> 

ok.. reading the kernel driver, the devices are:

/dev/sch[0-9]

what is the output of:

# scsi_id --export --whitelisted /dev/sch0
Comment 6 Wolfgang Denk 2011-02-09 07:39:50 EST
There is no output from scsi_id, but the sch* devices do exist:

# scsi_id --export --whitelisted /dev/sch0
# ls -l /dev/sch*
crw-rw---- 1 root disk 86, 0 Nov  9 12:26 /dev/sch0
crw-rw---- 1 root disk 86, 1 Nov  9 12:26 /dev/sch1
#
Comment 7 Wolfgang Denk 2011-04-01 17:09:49 EDT
Note that the /dev/sch* devices are NOT what can be used for example with "mtx":

# ls -l /dev/sch0 /dev/sg10
crw-rw---- 1 root disk 86,  0 Apr  1 22:58 /dev/sch0
crw-rw---- 1 root tape 21, 10 Apr  1 22:58 /dev/sg9
# mtx -f /dev/sch0 status
/dev/sch0 is not an sg device, or old sg driver
# mtx -f /dev/sg10 status
  Storage Changer /dev/sg10:1 Drives, 7 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full 
      Storage Element 2:Empty
      Storage Element 3:Empty
      Storage Element 4:Empty
      Storage Element 5:Empty
      Storage Element 6:Empty
      Storage Element 7:Empty
Comment 8 JM 2011-04-04 09:49:08 EDT
Same problem here, no devices with

/dev/disk/*/*

but I can find the devices with

/dev/tape/*/*

/dev/tape/by-id/scsi-3500110a001407f36 -> ../../st0
/dev/tape/by-id/scsi-3500110a001407f36-nst -> ../../nst0
/dev/tape/by-id/scsi-3500e09efff0ede6f -> ../../sg4


But 

/dev/changer*

does not exist, I added the rule from comment 1 and this way it works.
Comment 9 Wolfgang Denk 2011-04-04 10:29:57 EDT
Yes, it works, but it is still suboptimal, because standard tools like "mtx"
expect "/dev/changer0" as first (or only) device and thus default, not some
/dev/changer-sgXXX
Comment 10 Harald Hoyer 2011-06-17 05:49:49 EDT
maybe "mtx" should be rewritten to use /dev/sch[0-9]*
Comment 11 Wolfgang Denk 2011-06-17 06:32:14 EDT
> maybe "mtx" should be rewritten to use /dev/sch[0-9]*

Well, and all other tools that refer to self-explaining device names like /dev/dvd, /dev/dvdrw, /dev/cdrom, /dev/floppy, /dev/tape, ...
should be changed as well?

This doesn't sound like a good idea to me.  Of course, it would solve the problem for you but just by defining it as a SEP (somebody else's problem).
Comment 12 Harald Hoyer 2011-06-17 09:00:50 EDT
In general it is a bad idea to address a device by it's kernel name, because you cannot be sure, that the numbering stays the same across reboots.

Because of this, we created the /dev/disk/* and /dev/tape/* symlinks.

/lib/udev/rules.d/60-persistent-storage-tape.rules:

# type 8 devices are "Medium Changers"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8", IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $tempnode", SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}"


maybe we should add to the last rule:

 , SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-changer"
Comment 13 Wolfgang Denk 2011-06-17 10:47:35 EDT
I understand your reasoning, and agree with it for the general case.  But please also consider Joe Average User - they will have only one floppy drive, only one CDROM or DVD drive, only one tape drive at their systems, so numbering will actually be always the same.

Guess if these majority of users like referring to their tapes as
"/dev/tape/by-id/scsi-STANDBERGSLR100_SN100002993-nst" or "/dev/tape/by-path/01.0-scsi-0" when they used to use plain simple names?

And if such changes get implemented and forced on the users, then all tools that refer to the old names and use these as defaults MUST be fixed as well, or you will really frustrate users.

And if you add changes to the tape/by-id/ dir, then please also to tape/by-path/ as well to make it at least consistent.

Thanks.
Comment 14 Wolfgang Denk 2011-06-18 06:33:23 EDT
And another argument: Please keep in mind that Linux is not everything.  The "mtx" tool for example supports "32-bit MS Windows (NT/2000/XP), All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSD/UNIX-like OSes), FreeBSD, Linux, Win2K, Microsoft Windows Server 2003, WinXP, Solaris" so it seems inappropriate to demand changes of the defaults just because Linux decides to rename things.
Comment 15 Harald Hoyer 2011-06-20 04:47:08 EDT
(In reply to comment #14)
> And another argument: Please keep in mind that Linux is not everything.  The
> "mtx" tool for example supports "32-bit MS Windows (NT/2000/XP), All BSD
> Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX
> (Linux/BSD/UNIX-like OSes), FreeBSD, Linux, Win2K, Microsoft Windows Server
> 2003, WinXP, Solaris" so it seems inappropriate to demand changes of the
> defaults just because Linux decides to rename things.

Neither of them have a simple /dev/changer* device.
Comment 16 Fedora Admin XMLRPC Client 2011-10-20 12:09:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Fedora Admin XMLRPC Client 2011-10-20 12:11:36 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 18 Fedora Admin XMLRPC Client 2011-10-20 12:13:23 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora Admin XMLRPC Client 2011-10-20 12:17:50 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 20 Fedora End Of Life 2013-01-16 17:16:32 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Fedora End Of Life 2013-02-13 19:51:30 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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