Red Hat Bugzilla – Bug 183288
udev symlinks for multiple CDROMs broken (%e enumerate)
Last modified: 2007-11-30 17:11:25 EST
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.)
Steps to Reproduce:
1. Install multiple CD-ROM devices
Only one set of /dev/cdrom, /dev/cdwriter, /dev/dvd (etc) devices, pointing to
one of /dev/hdc or /dev/hdd (etc.)
/dev/cdrom and /dev/cdrom1 point to the different devices
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
[root@localhost dev]# udevinfo -q all -n /dev/hdd
[root@localhost dev]# udevinfo -q all -n /dev/cdrom
good catch! Thanks!
Please test ftp://people/harald/udev/084-10/
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.
The "ultimate" solution is to use /dev/disk/by-id/ or for the app to use HAL.
Fair enough. I'll close the bug, since fixing pam_console was the important thing.
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
so, if you have to unique cdroms with a serial id, nobody could say which one is
which.... other than by-path...
s/with a serial id/without a serial id/