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
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 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
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/