Bug 570490 - /dev/cdrom not created after optical drive replaced
/dev/cdrom not created after optical drive replaced
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
14
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 570561
  Show dependency treegraph
 
Reported: 2010-03-04 09:26 EST by Steve Tyler
Modified: 2012-08-16 18:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 18:22:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
70-persistent-cd.rules with three optical drive records; from F12 system (1.84 KB, text/plain)
2010-03-05 07:56 EST, Steve Tyler
no flags Details
70-persistent-cd.rules with five optical drive records; from F12 (2.91 KB, text/plain)
2010-03-05 08:36 EST, Steve Tyler
no flags Details
screenshot of xine when /dev/dvd is missing; the dvd is mounted though (285.64 KB, image/png)
2010-03-05 12:36 EST, Steve Tyler
no flags Details
70-persistent-cd.rules generated with "write_cd_rules by-id" (810 bytes, text/plain)
2010-03-16 07:10 EDT, Steve Tyler
no flags Details
udev rules to generate default device links for optical devices (1.91 KB, text/plain)
2010-03-17 16:11 EDT, Steve Tyler
no flags Details
70-default-cd.rules -- udev rules to generate default device links for optical devices (1.18 KB, text/plain)
2010-03-19 08:34 EDT, Steve Tyler
no flags Details

  None (edit)
Description Steve Tyler 2010-03-04 09:26:07 EST
Description of problem:
I replaced my optical drive and, after rebooting, /dev/cdrom was not created. /dev/cdrom2 was created instead. The system has one optical drive (before and after the replacement).

This could be reproduced on F11, F12, F13, and Ubuntu 9.10 (all booting on the same hardware and fully updated).

Not sure if this is related:
If a CD is inserted, it is mounted, and an icon appears on the desktop.
If I eject the CD (from desktop or command line), it is ejected,
but it is immediately loaded again.

Will report further on F13 once I get it reinstalled.

Version-Release number of selected component (if applicable):
udev-145-15.fc12.x86_64

How reproducible:
Replaced the drive only once,
however the /dev links are always created as listed below.

Steps to Reproduce:
1. Replace optical drive.
2. Reboot.
  
Actual results:
/dev/cdrom is not created.

Expected results:
/dev/cdrom is created.

Additional info:
The old optical drive is PATA/IDE.
The new optical drive is SATA.

[stephent@walnut ~]$ ls -ld /dev/* | grep 'sr[0-9]'
lrwxrwxrwx  1 root root           3 2010-03-04 05:47 /dev/cdrom2 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-04 05:47 /dev/cdrw2 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-04 05:47 /dev/dvd2 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-04 05:47 /dev/dvdrw2 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-04 05:46 /dev/scd0 -> sr0
brw-rw----+ 1 root cdrom    11,   0 2010-03-04 05:46 /dev/sr0
Comment 1 Steve Tyler 2010-03-04 09:31:06 EST
This seems to be a work-around for the spontaneous reloading problem:
$ eject /dev/sr0; sleep 1; eject /dev/sr0
Comment 2 Harald Hoyer 2010-03-04 09:48:20 EST
(In reply to comment #1)
> This seems to be a work-around for the spontaneous reloading problem:
> $ eject /dev/sr0; sleep 1; eject /dev/sr0    

https://bugzilla.redhat.com/show_bug.cgi?id=453095#c127

sysctl -w dev.cdrom.autoclose=0
Comment 3 Harald Hoyer 2010-03-04 09:49:30 EST
(In reply to comment #0)
> Description of problem:
> I replaced my optical drive and, after rebooting, /dev/cdrom was not created.
> /dev/cdrom2 was created instead. The system has one optical drive (before and
> after the replacement).
> 
> This could be reproduced on F11, F12, F13, and Ubuntu 9.10 (all booting on the
> same hardware and fully updated).

cdrom2 is by purpose... edit: 

/etc/udev/rules.d/70-persistent-cd.rules
Comment 4 Steve Tyler 2010-03-04 10:16:28 EST
Thanks for your tip re autoclose.

And thanks for your suggestion that I edit a config file after replacing an optical drive. I edit config files all the time, but this is not one I should even have to know about. I should not have to edit anything after replacing one optical drive with another optical drive. There is only one drive in the system before and there is only one after. That implies that it should be /dev/cdrom.

NB: This bug breaks the "eject" command. In Ubuntu 9.10 the "eject" command works despite this bug.
Comment 5 Harald Hoyer 2010-03-04 10:34:08 EST
ah, well, I will not fix this "bug", because it's intentionally designed that way, so if you connect e.g. USB cdroms, they will get the same name, regardless of the ordering you plug them in..
Comment 6 Steve Tyler 2010-03-04 10:41:43 EST
(In reply to comment #5)
> ah, well, I will not fix this "bug", because it's intentionally designed that
> way, so if you connect e.g. USB cdroms, they will get the same name, regardless
> of the ordering you plug them in..    

Yeah, I understand that. But my optical drives are not "removable" -- it takes a screwdriver and lot of hard cable plugging and unplugging. :-)

(In reply to comment #4)

> NB: This bug breaks the "eject" command. In Ubuntu 9.10 the "eject" command
> works despite this bug.    

I forgot to mention that this bug also breaks "xine" which uses /dev/dvd by default.

Maybe a better way would be to file bugs against "eject" and "xine" -- but I
don't know the buzz-words -- gvfs? hal? -- that would be needed to say:
"eject" and "xine" do not use such-and-such a feature, but instead rely on
udev-generated links that may change or disappear.

There may be one more case though:
I have a back-up script that uses wodim. The script passes /dev/cdrom to wodim.
Recently, I tried running wodim without an explicit device name and wodim found
/dev/sr0. That is good enough for me.
Comment 7 Steve Tyler 2010-03-04 10:51:34 EST
(In reply to comment #6)
> Recently, I tried running wodim without an explicit device name and wodim found
> /dev/sr0. That is good enough for me.    

Also, totem, rhythmbox and brasero work without those /dev links.
What is their trick?
Comment 8 Harald Hoyer 2010-03-04 10:53:05 EST
(In reply to comment #7)
> (In reply to comment #6)
> > Recently, I tried running wodim without an explicit device name and wodim found
> > /dev/sr0. That is good enough for me.    
> 
> Also, totem, rhythmbox and brasero work without those /dev links.
> What is their trick?    

maybe they look after /dev/sr* or /dev/cdrom*
Comment 9 Harald Hoyer 2010-03-04 10:53:50 EST
or even /proc/sys/dev/cdrom/info :-)
Comment 10 Kamil Dudka 2010-03-04 18:13:05 EST
(In reply to comment #5)
> ah, well, I will not fix this "bug", because it's intentionally designed that
> way, so if you connect e.g. USB cdroms, they will get the same name, regardless
> of the ordering you plug them in..    

I am new to udev.  Is that intention anywhere documented?  In particular, I need some info about how the assignment of /dev/cdrom* and the corresponding mount points is designed.  Thanks in advance!
Comment 11 Steve Tyler 2010-03-05 07:56:05 EST
Created attachment 398047 [details]
70-persistent-cd.rules with three optical drive records; from F12 system

/etc/udev/rules.d/70-persistent-cd.rules from my F12 system.

There are three optical drive records in this file. The first two records are for exactly the same drive. I am guessing that is because I replaced my motherboard but did not reinstall F12. With the first MB, the drive was the only device on its IDE bus. With the second MB, the drive is a slave on the IDE bus shared with a hard drive master. The third record is for a SATA optical drive with the new MB. I also had a different IDE optical drive in the system with the second MB while investigating CD I/O errors, but it is not recorded at all.

In all cases, there was only one optical drive in the system at any time.

# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0)
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0)
Comment 12 Steve Tyler 2010-03-05 08:36:06 EST
Created attachment 398053 [details]
70-persistent-cd.rules with five optical drive records; from F12

/etc/udev/rules.d/70-persistent-cd.rules from my F12 system.

As an experiment, I shut down my system, moved the SATA plug to the optical drive over to the next SATA connector on the motherboard, restarted. Did that again.

Now I have five optical drives in 70-persistent-cd.rules:

# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0)
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-2:0:0:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0)

[stephent@walnut ~]$ ls -ld /dev/* | grep 'sr[0-9]'
lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/cdrom4 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/cdrw4 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/dvd4 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/dvdrw4 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-05 05:17 /dev/scd0 -> sr0
brw-rw----+ 1 root cdrom    11,   0 2010-03-05 05:17 /dev/sr0
[stephent@walnut ~]$
Comment 13 Steve Tyler 2010-03-05 10:20:42 EST
I forgot to move the SATA plug back to where it was before the experiment in Comment 12. After I booted into my fresh F13 install, /dev/cdrom did not exist.

Here is a simple work-around for this problem -- tested with F13:

$ su -c 'rm /etc/udev/rules.d/70-persistent-cd.rules'
$ reboot

udev regenerates 70-persistent-cd.rules with a single drive entry:

# iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0)

/dev/cdrom exists and "eject" works as expected.


[stephent@spruce ~]$ rpm -q udev
udev-151-3.fc13.x86_64
Comment 14 Steve Tyler 2010-03-05 12:11:10 EST
(In reply to comment #13)
> Here is a simple work-around for this problem -- tested with F13:
> $ su -c 'rm /etc/udev/rules.d/70-persistent-cd.rules'
> $ reboot

Works with F12 too ...

[stephent@walnut ~]$ rpm -q udev
udev-145-15.fc12.x86_64
Comment 15 Steve Tyler 2010-03-05 12:36:00 EST
Created attachment 398086 [details]
screenshot of xine when /dev/dvd is missing; the dvd is mounted though

xine is also affected by this problem. If /dev/dvd does not exist, xine displays the two errors shown in this screenshot.

This is with F12.
Comment 16 Susi Lehtola 2010-03-05 13:09:16 EST
(In reply to comment #15)
> Created an attachment (id=398086) [details]
> screenshot of xine when /dev/dvd is missing; the dvd is mounted though
> 
> xine is also affected by this problem. If /dev/dvd does not exist, xine
> displays the two errors shown in this screenshot.
> 
> This is with F12.    

Surprise surprise - any software using a device that does not work will fail. I don't understand why you added me to the cc list.

PS. You can change the dvd device from xine configuration options.
Comment 17 Steve Tyler 2010-03-05 13:50:07 EST
(In reply to comment #16)
> (In reply to comment #15)
> > Created an attachment (id=398086) [details] [details]
> > screenshot of xine when /dev/dvd is missing; the dvd is mounted though
> > 
> > xine is also affected by this problem. If /dev/dvd does not exist, xine
> > displays the two errors shown in this screenshot.
> > 
> > This is with F12.    
> 
> Surprise surprise - any software using a device that does not work will fail. I
> don't understand why you added me to the cc list.

Because xine should "just work" with the default settings.

> PS. You can change the dvd device from xine configuration options.    

Yes, I know ...

If you prefer, I can open a bug against xine like the one against "eject". :-)
Bug 570561 - "eject" fails after optical drive replaced

And you don't need to get sarcastic.
Comment 18 Harald Hoyer 2010-03-16 05:17:24 EDT
(In reply to comment #12)
> Created an attachment (id=398053) [details]
> 70-persistent-cd.rules with five optical drive records; from F12
> 
> /etc/udev/rules.d/70-persistent-cd.rules from my F12 system.
> 
> As an experiment, I shut down my system, moved the SATA plug to the optical
> drive over to the next SATA connector on the motherboard, restarted. Did that
> again.
> 
> Now I have five optical drives in 70-persistent-cd.rules:
> 
> # DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0)
> # DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0)
> # iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0)
> # iHAS424_Y (pci-0000:00:11.0-scsi-2:0:0:0)
> # iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0)
> 
> [stephent@walnut ~]$ ls -ld /dev/* | grep 'sr[0-9]'
> lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/cdrom4 -> sr0
> lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/cdrw4 -> sr0
> lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/dvd4 -> sr0
> lrwxrwxrwx  1 root root           3 2010-03-05 05:18 /dev/dvdrw4 -> sr0
> lrwxrwxrwx  1 root root           3 2010-03-05 05:17 /dev/scd0 -> sr0
> brw-rw----+ 1 root cdrom    11,   0 2010-03-05 05:17 /dev/sr0
> [stephent@walnut ~]$    

works as intended
Comment 19 Steve Tyler 2010-03-16 06:36:54 EDT
(In reply to comment #18)
,,,
> works as intended    

Well, it breaks xine and eject. They could be called legacy apps., but as you can read in comment 16, that is not going to change. Modern apps. search for the device or offer a GUI asking what device to use (e.g. brasero).

My current workaround is to remove 70-persistent-cd.rules, disable its regeneration in /lib/udev/rules.d/75-cd-aliases-generator.rules, explicitly pass "eject" the device name, and not use xine (totem works fine without any of those device links -- I am still studying how it finds the device without them).

Indeed, I wonder why those udev-generated links are needed at all? From 75-cd-aliases-generator.rules, it looks like the "usb|ieee1394" case is handled separately.

BTW, /dev/scd0 is still being generated -- maybe "eject" could search for that.

[stephent@walnut rules.d]$ cat /lib/udev/rules.d/75-cd-aliases-generator.rules 
# these rules generate rules for the /dev/{cdrom,dvd,...} symlinks

# the "path" of usb/ieee1394 devices changes frequently, use "id"
ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", \
  PROGRAM="write_cd_rules by-id", SYMLINK+="%c", GOTO="persistent_cd_end"

#ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules", SYMLINK+="%c"

LABEL="persistent_cd_end"
Comment 20 Steve Tyler 2010-03-16 07:10:16 EDT
Created attachment 400437 [details]
70-persistent-cd.rules generated with "write_cd_rules by-id"

I have a simple fix for the case in comment 12.

Use "write_cd_rules by-id" instead of "write_cd_rules" in /lib/udev/rules.d/75-cd-aliases-generator.rules.

With this change, I can move my single optical drive from one SATA port on the motherboard to another and still get /dev/cdrom.

How can this be further fixed so that if there is only one optical drive in the system, it always gets /dev/cdrom? That would fix this bug.

[stephent@walnut rules.d]$ cat /lib/udev/rules.d/75-cd-aliases-generator.rules 
# these rules generate rules for the /dev/{cdrom,dvd,...} symlinks

# the "path" of usb/ieee1394 devices changes frequently, use "id"
ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", \
  PROGRAM="write_cd_rules by-id", SYMLINK+="%c", GOTO="persistent_cd_end"

#ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules", SYMLINK+="%c"
ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules by-id", SYMLINK+="%c"

LABEL="persistent_cd_end"
Comment 21 Steve Tyler 2010-03-16 08:14:15 EDT
Here's an even better solution, IIUC:

# 70-persistent-cd.rules
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"

This was hand edited -- something I swore I was not going to do. :-)

If write_cd_rules could generate these rules when there is only one optical drive in the system, I believe that would fix this bug and the case in
comment 12. (I'm assuming ID_CDROM is always "1" when there is only one optical drive in the system -- is that valid?)

The solution in comment 20 doesn't entirely work, because two identical optical drives would match this part:
ENV{ID_MODEL}=="iHAS424_Y", ENV{ID_REVISION}=="ZL1U"

The fundamental problem is that optical drives may not have serial numbers or UUIDs. Compare:
$ udevadm info --query=all --name=sr0
$ udevadm info --query=all --name=sda1

I'm still trying to figure out what to do when there is more than one optical drive -- which one should "eject" work on?

Bug 190037 - "eject" command opens different drive in FC5
Comment 22 Steve Tyler 2010-03-16 10:04:51 EDT
"ID_CDROM" seems to be a boolean ...

SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw",  ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd",   ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"

Writing udev rules
CD/DVD drives
http://www.reactivated.net/writing_udev_rules.html#example-cdrom
Comment 23 Steve Tyler 2010-03-16 16:39:32 EDT
This does almost everything right with two optical devices. What it lacks is a way to remap in one line which device gets /dev/cdrom. ATM, "sr0" would have to be changed in five places. An arbitrary mapping would be more general, but overkill for the problem at hand (and I don't know how to implement one anyway :-) ). If /dev/cdrom0 is acceptable in addition to /dev/cdrom, the GOTO could be eliminated.

NB: For testing, I have disabled write_cd_rules as in comment 19 and have put these in 70-persistent-cd.rules. This is probably not the right file ...


SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw",  ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd",   ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end"

SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom%n", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw%n",  ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd%n",   ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw%n", ENV{GENERATED}="1"

LABEL="cd_rules_end"


[stephent@walnut dev]$ ls -l /dev | grep 'sr[0-9]'
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 cdrom -> sr0
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 cdrom1 -> sr1
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 cdrw -> sr0
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 dvd -> sr0
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 dvd1 -> sr1
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 dvdrw -> sr0
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 scd0 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-16 13:20 scd1 -> sr1
brw-rw----+ 1 root cdrom    11,   0 2010-03-16 13:20 sr0
brw-rw----+ 1 root cdrom    11,   1 2010-03-16 13:20 sr1
[stephent@walnut dev]$
Comment 24 Steve Tyler 2010-03-16 17:48:48 EDT
(In reply to comment #23)
> If /dev/cdrom0 is acceptable in addition to /dev/cdrom, the GOTO could
> be eliminated.

If there were three optical devices, and the "middle" one (sr1) were the default, the rules in comment 23 would produce:

cdrom0 -> sr0
cdrom  -> sr1
cdrom2 -> sr2

IOW, there would be a "hole" in the sequence.

NB: I am a udev rules noob ...
Comment 25 Steve Tyler 2010-03-17 13:19:29 EDT
This bug also affects abcde (Bug 527123, Comment 3), which searches for a cdrom in these places (abcde is a shell script):

# If the CDROM has not been set yet, find a suitable one.
# If this is a devfs system, default to /dev/cdroms/cdrom0
# instead of /dev/cdrom
if [ "$CDROM" = "" ] ; then
        if [ -e /dev/cdroms/cdrom0 ]; then
                CDROM=/dev/cdroms/cdrom0
        elif [ -e /dev/cdrom ]; then
                CDROM=/dev/cdrom
        elif [ -e /dev/cd0c ]; then
                CDROM=/dev/cd0c
        elif [ -e /dev/acd0c ]; then
                CDROM=/dev/acd0c
        elif [ -e /dev/disk1 ]; then
                CDROM=/dev/disk1
        fi
fi

The -d option allows a device to be specified:
[stephent@walnut ~]$ abcde -h
This is abcde v2.3.99.8.
...
-d <device>
       Specify CDROM device to grab (flac uses a single-track flac file)

abcde uses the eject command:
EJECT=eject
Comment 26 Steve Tyler 2010-03-17 15:55:29 EDT
This version adds a fallback handler in case the chosen default device does not exist (e.g. it was removed). Added comments to guide the user in changing the default device.

Tested with one and two devices and with sr0, sr1, and sr9 as the default device. Verify generated links with:
$ ls -l /dev | grep 'sr[0-9]'

# change the default device by changing sr0 to srN in this section
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw",  ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd",   ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end"
# end of default device rules

# if the default device does not exist, fall back to sr0
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw",  ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd",   ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end"

SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM}=="1",        SYMLINK+="cdrom%n", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_CD_RW}=="1",  SYMLINK+="cdrw%n",  ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD}=="1",    SYMLINK+="dvd%n",   ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw%n", ENV{GENERATED}="1"

LABEL="cd_rules_end"
Comment 27 Steve Tyler 2010-03-17 16:11:01 EDT
Created attachment 400876 [details]
udev rules to generate default device links for optical devices

/etc/udev/rules.d/70-dynamic-cd.rules

I have been calling this file 70-dynamic-cd.rules because it is a supplement to, not a replacement for, /etc/udev/rules.d/70-persistent-cd.rules
Comment 28 Harald Hoyer 2010-03-18 07:35:30 EDT
?? why don't you simply change 70-persistent-cd.rules instead of introducing a new file, which has to be changed?
Comment 29 Harald Hoyer 2010-03-18 07:36:55 EDT
maybe changing the rule generator with link_priority=1 and adding the fallback would be a solution
Comment 30 Steve Tyler 2010-03-18 13:30:48 EDT
(In reply to comment #28)
> ?? why don't you simply change 70-persistent-cd.rules instead of introducing a
> new file, which has to be changed?    

Thanks for your comments.

The short answer is that, for testing, I didn't want write_cd_rules possibly mangling my rules file.

The long answer is that I don't know how to integrate the two (write_cd_rules and 70-dynamic-cd.rules) -- they are both creating cdrom[0-9]* links ...

It isn't clear how to get the rules in 70-dynamic-cd.rules into 70-persistent-cd.rules initially. One way would be to not, but instead to add them to /lib/udev/rules.d/75-cd-aliases-generator.rules.

Also, 70-dynamic-cd.rules doesn't exactly create "persistent" device links.
Comment 31 Steve Tyler 2010-03-18 13:41:32 EDT
(In reply to comment #29)
> maybe changing the rule generator with link_priority=1 and adding the fallback
> would be a solution    

OK. How would it work to put the first two blocks into 75-cd-aliases-generator.rules, drop the last block, and drop the second write_cd_rules rule in 75-cd-aliases-generator.rules (the one that causes all the trouble :-))?

I am fuzzy on some of the requirements:
Is it a requirement that a persistent rule be able to generate "cdrom"?
When there is more than one optical device, is it a requirement that "cdromN" links be created for them?
Is it OK for "cdrom" to link to one device and "dvd" to link to another device?
(AKA, mix-and-match :-))
Comment 32 Steve Tyler 2010-03-19 08:34:21 EDT
Created attachment 401232 [details]
70-default-cd.rules -- udev rules to generate default device links for optical devices

/etc/udev/rules.d/70-default-cd.rules

Rules to generate optical device links "cdrom", "cdrw", "dvd", "dvdrw".
These links are used by some applications as default devices (e.g. eject, xine, abcde).

This file is intended to be user-configurable.

The following patch ensures that write_cd_rules does not generate rules that create links with the same names.

/lib/udev/write_cd_rules

[stephent@walnut udev]$ rcsdiff -u write_cd_rules
===================================================================
RCS file: RCS/write_cd_rules,v
retrieving revision 1.1
diff -u -r1.1 write_cd_rules
--- write_cd_rules	2010/03/19 11:15:51	1.1
+++ write_cd_rules	2010/03/19 12:07:11
@@ -97,6 +97,11 @@
 
 link_num=$(find_next_available 'cdrom[0-9]*')
 
+# Ensure that "cdrom0" is generated instead of "cdrom".
+# find_next_available may return an empty string instead of "0".
+# This hack restores the "0".
+link_num=${link_num:-"0"}
+
 match="SUBSYSTEM==\"block\", ENV{ID_CDROM}==\"?*\", $RULE"
 
 comment="$ID_MODEL ($ID_PATH)"
Comment 33 Steve Tyler 2010-03-19 08:40:53 EDT
In the single-device case, the rules and patch in comment 32 produce redundant links. Is that a problem?

[stephent@walnut dev]$ ls -l /dev | grep 'sr[0-9]*'
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 cdrom -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 cdrom0 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 cdrw -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 cdrw0 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 dvd -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 dvd0 -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 dvdrw -> sr0
lrwxrwxrwx  1 root root           3 2010-03-19 05:08 dvdrw0 -> sr0
srw-rw-rw-  1 root root           0 2010-03-19 05:08 log
lrwxrwxrwx  1 root root           3 2010-03-19 05:07 scd0 -> sr0
brw-rw----+ 1 root cdrom    11,   0 2010-03-19 05:07 sr0
Comment 34 Steve Tyler 2010-03-19 08:59:42 EDT
(In reply to comment #28)
> ?? why don't you simply change 70-persistent-cd.rules instead of introducing a
> new file, which has to be changed?    

A user should be able to remove 70-persistent-cd.rules and restart to regenerate a fresh 70-persistent-cd.rules. If a user has customized the file, this simple procedure could result in data loss.

Machine-generated files and user-configurable files should be kept separate --
hence 70-default-cd.rules.

This opinion is based on having had my customized /etc/fstab trashed many times in the past by updates. I never did figure out who was doing the trashing ...
Comment 35 Harald Hoyer 2010-03-19 09:13:55 EDT
fstab never gets trashed on my system...  
70-persistent-cd.rules is designed for user modifications
Comment 36 Steve Tyler 2010-03-19 14:20:04 EDT
(In reply to comment #35)
> fstab never gets trashed on my system...  

Last time, I couldn't figure out happened to my swap space ...
Another time, my nfs mount disappeared ...

> 70-persistent-cd.rules is designed for user modifications    

Yes. And it achieves that by requiring the user to put
ENV{GENERATED}="1"
on every line.
udev is already hard enough to understand without this additional complexity.

Also, "GENERATED" is a misleading and confusing name. If the rules generated by write_cd_rules were the only ones with it, that would makes sense. A user editing 70-persistent-cd.rules is not generating rules, yet has to lie by saying the additional rules were also "generated".

I much prefer this advice from /etc/sysconfig/iptables :

# Manual customization of this file is not recommended.

BTW, I sometimes ignore that advice. :-)
Comment 37 Bug Zapper 2010-11-03 16:49:18 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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 38 Bug Zapper 2010-12-03 17:03:19 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.
Comment 39 Steve Tyler 2010-12-04 13:10:55 EST
Reopening against F14.
udev-161-8.fc14.x86_64

Reproduce by moving SATA cable to a different port.
Comment 40 Fedora Admin XMLRPC Client 2011-10-20 12:10:42 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 41 Fedora Admin XMLRPC Client 2011-10-20 12:12:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 42 Fedora Admin XMLRPC Client 2011-10-20 12:15:08 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 43 Fedora End Of Life 2012-08-16 18:22:23 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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" (top right of this page) 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

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