eject: unable to find or open device for: `cdrom' - but my cd is /dev/cdrom1

Bug #795239 reported by Bryce Harrington on 2011-06-09
This bug affects 8 people
Affects Status Importance Assigned to Milestone
eject (Debian)
Fix Released
eject (Ubuntu)
Ankit Sinha

Bug Description

Binary package hint: eject

The eject command does not actually eject my cdrom, unless called as 'eject /dev/cdrom1'

The problem seems to be that the eject command's default device is set to "/dev/cdrom" specifically. Yet, udev will increment the drive name if new cdroms are added or even if you change the cable that the cdrom is connected to. See https://bugzilla.redhat.com/show_bug.cgi?id=570490. udev now assigns permanent names to devices in case they're being hotplugged, which obviously makes sense for servers but a bit sub-optimal for desktops where you generally have no more than one cd...

Anyway, as a workaround, I can set up a /media/cdrom symlink to the proper device and then it works. But that's a brittle solution since if I switched my cable back or changed cdroms, I'd have to manually adjust that link again.

Possibly eject could be modified to determine the default device by looking first for /dev/cdrom, and then if that's missing, look for /dev/cdrom[0-9]. (Make sure /dev/cdroms is not included in that list obviously.) If there's more than one cd device in the system, either bail out or bravely select the lowest numbered one.

The file /proc/sys/dev/cdrom/info could also be read to discover the available devices. This might be preferable to looking for /dev/cdrom*, I'm not sure.

This udev change is a generic problem that affects all utilities that interact with the cdrom. It is possible that this could be solved in a more general purpose way by some sort of little lib shared with xine and other cdrom users. In any case, those other tools may have already solved this problem and could be worth examining for code reuse.

Related branches

Bryce Harrington (bryce) wrote :

The persistent names are stored in /etc/udev/rules.d/70-persistent-cd.rules, so another workaround would be to edit that file and delete out all the extra added bits, so the /dev/cdrom device will be set properly. Again, this is a poor workaround since if I later changed the cdrom at all I'd have to revisit it.

tags: added: bitesize
Raseel (raseel) wrote :

I agree with your suggestion of fixing eject to search for devices /dev/cdrom0 to /dev/cdrom9 .
Have made changes accordingly and submitted the package to be reviewed.

Changed in eject (Ubuntu):
assignee: nobody → Raseel (raseel)
status: New → In Progress
status: In Progress → Fix Committed
eviljoel (eviljoel-t) wrote :
Download full text (5.2 KiB)

I think this is a solid feature request and I've spent a month or so looking into a good solution. While I don't have a patch of my own yet, I disagree with the method Raseel used to solve this issue. Basically there is nothing guaranteeing multiple CD-ROM devices will be named /dev/cdrom1-9. This is simply a convention used by most (if not all) distros. I believe eject's behavior should not make assumptions about the existence of or the configuration of udev.

Most of the following I wrote a before Raseel's comment, so bear with me if it reads awkwardly. Basically the following is just my thoughts on different approaches I could take to implement this feature request:

First, I did confirm that eject will not "just work" if /dev/cdrom does not exist. However, I haven't confirmed the udev assignment portion of this bug, so for right now I am going to leave this bug as unverified.

One thing I keep going back and forth on is if this is an error with udev or eject. One possibility is to make /dev/cdrom a non-persistent device name and have it point to the first detected CD-ROM on the system. However, udev has been around for about 5 years now and there might be many applications that depend on /dev/cdrom being a persistent name for a device.

Looking at eject now, I think the best thing to do is determine how many optical drives are connected to the system. If the number of optical drives is greater than 1, refuse to eject. If the number of optical drives is one, then automatically eject that device. The eject command is obviously created with the intention of mainly interfacing with CD-ROMs, so if you have no optical drives but there is another ejectable device that the eject command can interface with, eject should ignore that device unless it is explicitly specified.

So, the problem becomes determining the number of optical drives in the system. It was suggested by Bryce that we look for /dev/cdrom[1-9]. While most systems name their CD-ROMs in this manner, this naming is entirely based on udev rules that may not be consistent across all distributions. Hence, (as I said above) I don't think this is the best solution for this problem.

Bryce also suggested that /proc/sys/dev/cdrom/info be used. One advantage to using this file is that it uses the CD-ROM capabilities flags that are set when the drive is registered. The file appears to access these flags without opening each device which means the output is extremely reliable and probably renders extremely fast. However, from the research I did, proc is suppose to be used just for process information and the use of non-process related files in proc is deprecated. Also, there is a chance that the user did not include the proc file system in his/her kernel (although the chances of that are pretty low). Finally, the file is formatted in a human readable format and is not formatted for easy parsing (although parsing the file wouldn't be terribly hard).

In trying to find a more programmer friendly way of determining how many optical drives are in the system, I started looking at the udev source code. I figured that if udev can determine how many optical drives exist, then eject...


Sebastien Bacher (seb128) wrote :

don't use "fix commited" if the fix is not commited to an official packaging vcs, people will likely not review your bug otherwise since they will think the fix is commited and no work is needed

Changed in eject (Ubuntu):
status: Fix Committed → In Progress
importance: Undecided → Low
Andrei ILIE (andrei-ilie) wrote :

Same problem here; my CDROM device is "sr0" :)

andrei@cofee:~$ uname -a
   Linux cofee #1 SMP Tue Nov 29 11:53:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

andrei@cofee:~$ ls -l /dev/*cd*
   lrwxrwxrwx 1 root root 9 Jan 1 19:03 /dev/cdrom -> /dev/scd0
   lrwxrwxrwx 1 root root 3 Jan 1 19:04 /dev/cdrom1 -> sr0
   lrwxrwxrwx 1 root root 3 Jan 1 19:04 /dev/cdrw1 -> sr0
   lrwxrwxrwx 1 root root 3 Jan 1 19:04 /dev/scd0 -> sr0

Andrei ILIE (andrei-ilie) wrote :

Not to forget... I manually did a "sudo ln -s /dev/scd0 /dev/cdrom" before all of the above.

Ddorda (ddorda) wrote :

confirming the bug on MSI-FX620DX.

I was able to open the cdrom by using "eject" on the next:

OzzyFrank (ubuntu-ozzyfrank) wrote :

I get the same error after upgrading to Ubuntu 12.10. I actually found an eject package for Quantal (https://launchpad.net/ubuntu/quantal/amd64/eject), so figured it was an updated version of the command, but upon trying to install it I get "Error: no longer provides eject", so can't actually do anything with it.

Just confirming that the eject command worked for years, until this upgrade.

Hunk (enrique-garciasimon) wrote :

As commented by OzzyFrank, I get the same error after upgrading to Ubuntu 12.10, eject command worked for years for me.
(The eject command is a must for me in ubuntu, as the hardware button does not work properly (Acer Aspire 5810T)

Output (spanish)
"eject -V"
eject versión 2.1.5 por Jeff Tranter (<email address hidden>)

"eject" or "eject cdrom"
eject: incapaz de encontrar o abrir el dispositivo para: «cdrom»

"sudo lshw -C disk"
       descripción: DVD-RAM writer
       producto: DVDRAM GU10N
       fabricante: HL-DT-ST
       id físico: 0.0.0
       información del bus: scsi@4:0.0.0
       nombre lógico: /dev/cdrom3
       nombre lógico: /dev/cdrw3
       nombre lógico: /dev/dvd3
       nombre lógico: /dev/dvdrw3
       nombre lógico: /dev/sr0
       versión: AP03
       capacidades: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuración: ansiversion=5 status=nodisc

Workaround: It works for me using "eject /dev/cdrom3"

Øyvind Stegard (oyvinst) wrote :

Confirming breakage of eject command's notion of "default device" after upgrading to 12.10. It has worked fine for years until now. I have '/dev/cdrom1' pointing to '/dev/sr0', but no '/dev/cdrom'.

Øyvind Stegard (oyvinst) wrote :

The problem for me seems to be caused by /etc/udev/rules.d/70-persistent-cd.rules containing two entries for the same optical drive after upgrading to 12.10 from 12.04:

# HL-DT-ST_DVD+_-RW_GU10N (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

# HL-DT-ST_DVD+_-RW_GU10N (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrw1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvdrw1", ENV{GENERATED}="1"

The last one is in effect (giving device aliases for the only optical drive in my laptop a numeric suffix of "1" instead of none). Since the file is generated, I just deleted it and rebooted. Now there is only one entry, proper device links and eject works again. (Looks like the only difference between the entries is SCSI device numbering, "scsi-1:0:0:0" vs "scsi-0:0:0:0" in Ubuntu 12.10.)

Ankit Sinha (ankitbko) on 2013-07-05
Changed in eject (Ubuntu):
status: In Progress → Fix Committed
status: Fix Committed → In Progress
Ankit Sinha (ankitbko) wrote :

Hey guys,

I am new to bug fixing and would need help on the whole process. I am really interested in contributing to ubuntu by fixing bugs. Have gone through ubuntu wiki but would still like to know from an experienced developer about how everything works here. It seems this bug has been abandoned. Last comment was made about 7 months ago. Is there specific reason why has it been left out. So If I want to fix the bug should I just start working by getting the source code and changing "Assigned to" to myself?

 It still affects me on ubuntu 13.04. I have '/dev/cdrom5' and '/dev/cdrom6' while having only one physical cd drive.
Here is the result of lshw -C disk
       description: DVD-RAM writer
       product: DVD+-RW AD-7640S
       vendor: Optiarc
       physical id: 0.0.0
       bus info: scsi@1:0.0.0
       logical name: /dev/cdrom6
       logical name: /dev/cdrw6
       logical name: /dev/dvd6
       logical name: /dev/dvdrw6
       logical name: /dev/sr0
       version: HD18
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 status=open
       description: SCSI CD-ROM
       physical id: 0
       bus info: scsi@6:0.0.0
       logical name: /dev/cdrom5
       logical name: /dev/sr1
       capabilities: audio
       configuration: status=ready

I have created a SCSI CD-ROM in windows using daemon tool. Can it be that the second one is showing that?

Changed in eject (Ubuntu):
assignee: Raseel (raseel) → Ankit Sinha (ankitbko)
eviljoel (eviljoel-t) wrote :

Hey Ankit,

First, I am no Ubuntu expert but I am sure it is fine if you should just go ahead and take it.

I stopped working on it because I started playing around with the Doom 3 source code when it was released. The problem hasn't been fixed because it isn't exactly an easy problem to solve. I don't remember all the details but except for /proc/sys/dev/cdrom/info, the Kernel does not appear to provide a way to figure out what cdrom drives are available. I would probably go about using the information from /proc/sys/dev/cdrom/info as that file doesn't appear to be going anywhere very soon.

Be sure to try to fix the issue upstream. If not, I would try to submit it here.

I remember I posted more detailed information above. You should definitely read that.

Good luck,

Changed in eject (Debian):
status: Unknown → New
Hunk (enrique-garciasimon) wrote :

In comment #9 I explained it wasn't working, but now "eject cdrom" works for me

Output (spanish)

$eject -V
eject versión 2.1.5 por Jeff Tranter (<email address hidden>)
$sudo lshw -C disk
       descripción: DVD-RAM writer
       producto: DVDRAM GU10N
       fabricante: HL-DT-ST
       id físico: 0.0.0
       información del bus: scsi@4:0.0.0
       nombre lógico: /dev/cdrom
       nombre lógico: /dev/sr0
       versión: AP03
       capacidades: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuración: ansiversion=5 status=nodisc
$uname -a
Linux invitado 3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux


Filed a sync request from debian, actually pending (waiting for a sponsor)

Changed in eject (Ubuntu):
status: In Progress → Fix Committed
Changed in eject (Debian):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eject - 2.1.5+deb1+cvs20081104-13.1

eject (2.1.5+deb1+cvs20081104-13.1) unstable; urgency=low

  [ Ankit Sinha ]
  * Non-maintainer upload.
  * eject now iterates through /dev/device_name[0-9]
    (LP: #795239, Closes: #719110)

  [ Bart Martens ]
  * debian/rules: Create directory debian/eject-udeb if it doesn't exist yet.

 -- Gianfranco Costamagna <email address hidden> Fri, 14 Feb 2014 22:17:11 +0100

Changed in eject (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.