Bug 183288

Summary:	udev symlinks for multiple CDROMs broken (%e enumerate)
Product:	[Fedora] Fedora	Reporter:	John Thacker <johnthacker>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	k.georgiou
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-03-03 06:50:17 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:	150222

Description John Thacker 2006-02-27 22:42:41 UTC

Description of problem:
I know that udev removed mention of %e (the enumeration flag that creates
/dev/cdrom, /dev/cdrom1, etc) from its man page, but I thought that it
still worked.  However, it doesn't appear to be working.  I have a DVD+/-RW and
a CD-RW.  udev is apparently trying to map both of them to just /dev/cdrom,
and only one symlink gets created.   This is particularly annoying since the PAM
magic in /etc/security/console.perms requires the /dev/cdrom* files to
exist for each drive in order for the console permissions to be properly
set upon login.  The user who logs in will only be able to access one of the
devices.  I'm not sure if it makes more sense to change the udev rules or to
change the console.perms file in pam

Version-Release number of selected component (if applicable):
udev-084-6  (This also occurred under a fresh FC5Test3.)

How reproducible:
Every time

Steps to Reproduce:
1. Install multiple CD-ROM devices
2. Reboot
3.
  
Actual results:
Only one set of /dev/cdrom, /dev/cdwriter, /dev/dvd (etc) devices, pointing to
one of /dev/hdc or /dev/hdd (etc.)

Expected results:
/dev/cdrom and /dev/cdrom1 point to the different devices

Additional info:
Output from udevinfo follows.  Note that both block devices have the same
symlinks to cdrom and cdwriter.

[root@localhost dev]# udevinfo -q all -n /dev/hdc
P: /block/hdc
N: hdc
S: cdrom
S: dvd
S: cdwriter
S: dvdwriter
S: disk/by-path/pci-0000:00:09.0-ide-1:0
E: ID_TYPE=cd
E: ID_MODEL=_NEC_DVD_RW_ND-3520A
E: ID_SERIAL=
E: ID_REVISION=1.04
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-1:0

[root@localhost dev]# udevinfo -q all -n /dev/hdd
P: /block/hdd
N: hdd
S: cdrom
S: cdwriter
S: disk/by-path/pci-0000:00:09.0-ide-1:1
E: ID_TYPE=cd
E: ID_MODEL=LITE-ON_LTR-24102B
E: ID_SERIAL=
E: ID_REVISION=5S5A
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-1:1

[root@localhost dev]# udevinfo -q all -n /dev/cdrom
P: /block/hdd
N: hdd
S: cdrom
S: cdwriter
S: disk/by-path/pci-0000:00:09.0-ide-1:1
E: ID_TYPE=cd
E: ID_MODEL=LITE-ON_LTR-24102B
E: ID_SERIAL=
E: ID_REVISION=5S5A
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-1:1

Comment 1 Harald Hoyer 2006-03-01 16:28:57 UTC

good catch! Thanks!

Comment 2 Harald Hoyer 2006-03-02 07:46:52 UTC

Please test ftp://people/harald/udev/084-10/

Comment 3 John Thacker 2006-03-02 19:13:02 UTC

Thanks for moving so quickly on this!  The updated packages definitely solve the
basic problem and get things working.  The solution chosen is basically the same
thing as the hack I did for myself to get it working.  (I didn't have a hyphen.)

While this fixes the buggy behavior, people do have a legitimate complaint that
the new behavior is a slight regression from FC4.  Before, your device names
only changed if the initialization order changed among devices of the same type.
 Now they change if you rearrange the order of anything on the same bus.  It can
be a big deal for USB/Firewire devices that hotplug.

So this fixes the original bug, but it also sounds like some people want a
better fix.  I don't know udev well enough to know if one is possible.  Should
this be closed or left open?  Perhaps left open but switched away from
FC5Blocker to FC5Target or nothing.  I think that the serious behavior that
should block FC5 is fixed, but this may not be the right ultimate solution.  YMMV.

Comment 4 Harald Hoyer 2006-03-03 05:12:48 UTC

The "ultimate" solution is to use /dev/disk/by-id/ or for the app to use HAL.

Comment 5 John Thacker 2006-03-03 06:49:48 UTC

Fair enough.  I'll close the bug, since fixing pam_console was the important thing.

Comment 6 Kostas Georgiou 2006-03-03 11:58:22 UTC

I don't get anything in /dev/disk/by-id/ for my DVDRW the only entry I can find
is in /dev/disk/by-path. I suspect this is because of the empty ID_SERIAL.
So no /dev/disk/by-id/ can not be the "ultimate" solution......

# udevinfo -a -q all -n /dev/hdc
P: /block/hdc
N: hdc
S: dvd
S: dvd-hdc
S: cdwriter
S: cdwriter-hdc
S: cdrw
S: cdrw-hdc
S: dvdwriter
S: dvdwriter-hdc
S: dvdrw
S: dvdrw-hdc
S: disk/by-path/pci-0000:00:0f.1-ide-0:0
E: ID_TYPE=cd
E: ID_MODEL=_NEC_DVD_RW_ND-3550A
E: ID_SERIAL=
E: ID_REVISION=1.05
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:0f.1-ide-0:0

Comment 7 Harald Hoyer 2006-03-03 14:24:08 UTC

so, if you have to unique cdroms with a serial id, nobody could say which one is
which.... other than by-path...

Comment 8 Harald Hoyer 2006-03-03 14:24:42 UTC

s/with a serial id/without a serial id/