Ubuntu
eject package

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	Unknown	debbugs #719110
	eject (Ubuntu)	Fix Released	Low	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.

Tags:

Related branches

lp:~ankitbko/ubuntu/saucy/eject/fix-for-795239

On hold for merging into lp:ubuntu/saucy/eject

Gianfranco Costamagna: Disapprove on 2014-02-25

Sebastien Bacher: Needs Fixing on 2013-11-07

Jamie Strandboge: Needs Fixing on 2013-07-22

lp:debian/eject

lp:ubuntu/trusty/eject

Revision history for this message

Bryce Harrington (bryce) wrote on 2011-06-09:

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

Revision history for this message

Raseel (raseel) wrote on 2011-10-22:

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

Revision history for this message

eviljoel (eviljoel-t) wrote on 2011-10-24:

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).

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 should be able to do the same thing.  If you look at /lib/udev/rules.d/60-cdrom_id.rules, you will see that udev uses a program called cdrom_id to help it determine if a device is an optical drive.  It assumes the kernel assigned the CD-ROM a device name of either /dev/sr[0-9], /dev/hd[a-z] or /dev/xvcd* (apparently a Xen virtual drive).  Since the kernel supplies these names, they should be consistent across all recent distros.

The cdrom_id program uses uses an ioctl call in an attempt to access the drive's CD-ROM capabilities flags.  If the drive's capabilities flags are available, the drive is assumed to be an optical drive.  Unfortunately, the ioctl call requires an open file handle to the device.  Since this is a special character file, I'm not sure how much latency this open operation will introduce.  If you look in the cdrom_id source code, you will see that there is an intentional delay between attempts to obtain a file handle although I am not sure if it is necessary to repeat this delay in eject.  Overall, using this method to determine the number of optical drives is probably more maintainable but slower.

I'm currently looking into how udisks (derived from the old HAL code) determines if a device is an optical drive.  I still haven't located the code which does this.  If I can't turn up anything useful in udisks, I think I'll probably have exhausted my research options and will choose an ideal implementation.

Of course, the ideal implementation could use a series of different methods to determine if there is a single optical drive.  For example, first see if /dev/cdrom exists (for backward compatibility).  If /dev/cdrom does not exists, next see if /proc/sys/dev/cdrom/info exists.  If not, then use the udev method for optical drive detection.

Please note that I do not have a lot of experience modifying Linux utilities and the method used in Raseel's patch might be totally appropriate.  I would appreciate any thoughts from others who are more experienced in C, Ubuntu and/or Linux development.  At some point we should also contact Jeff Tranter upstream to see what he thinks of all this.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2011-11-17:

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

Revision history for this message

Andrei ILIE (andrei-ilie) wrote on 2012-01-01:

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

andrei@cofee:~$ uname -a
Linux cofee 2.6.41.4-1.fc15.x86_64 #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

Revision history for this message

Andrei ILIE (andrei-ilie) wrote on 2012-01-01:

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

Revision history for this message

Ddorda (ddorda) wrote on 2012-09-05:

lshw -C disk Edit (1.1 KiB, text/plain)

confirming the bug on MSI-FX620DX.

I was able to open the cdrom by using "eject" on the next:
/dev/cdrom1
/dev/cdrw1
/dev/dvd1
/dev/dvdrw1
/dev/sr0

Revision history for this message

OzzyFrank (ubuntu-ozzyfrank) wrote on 2012-10-29:

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.

Revision history for this message

Hunk (enrique-garciasimon) wrote on 2012-12-12:

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)
https://help.ubuntu.com/community/AspireTimeline/Fixes#DVD_Not_Mounted)

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"
...
  *-cdrom
       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"

Revision history for this message

Øyvind Stegard (oyvindstegard) wrote on 2012-12-25:

#10

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'.

Revision history for this message

Øyvind Stegard (oyvindstegard) wrote on 2012-12-25:

#11

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

Revision history for this message

Ankit Sinha (ankitbko) wrote on 2013-07-06:

#12

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
  *-cdrom
       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
  *-cdrom
       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)

Revision history for this message

eviljoel (eviljoel-t) wrote on 2013-07-09:

#13

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,
eviljoel

Bug Watch Updater (bug-watch-updater) on 2013-08-08

Changed in eject (Debian):
status:	Unknown → New

Revision history for this message

Lester Carballo Pérez (vampireuh) wrote on 2013-11-20:

#14

Please, see https://bugs.launchpad.net/ubuntu/+source/udev/+bug/875543

Revision history for this message

Hunk (enrique-garciasimon) wrote on 2014-02-14:

#15

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
...
  *-cdrom
       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

Revision history for this message

Gianfranco Costamagna (costamagnagianfranco) wrote on 2014-02-25:

#16

https://bugs.launchpad.net/ubuntu/+source/eject/+bug/1284541

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

Sebastien Bacher (seb128) on 2014-02-25

Changed in eject (Ubuntu):
status:	In Progress → Fix Committed

Bug Watch Updater (bug-watch-updater) on 2014-02-25

Changed in eject (Debian):
status:	New → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2014-02-27:

#17

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

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

Bug #1199691

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

lshw -C disk Edit

Add attachment

Remote bug watches

debbugs #719110
[done normal patch] Edit

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

Ubuntueject package

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

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
eject package