Description of problem: I replaced my optical drive and, after rebooting, found that the "eject" command returned an error instead of ejecting the drive tray. [stephent@walnut ~]$ eject eject: unable to find or open device for: `cdrom' However, this works as expected: [stephent@walnut ~]$ eject /dev/sr0 The problem is that "eject" uses /dev/cdrom by default, but udev does not create it -- udev creates /dev/cdrom2 instead. I have had three optical drives installed in my system, and they are recorded in /etc/udev/rules.d/70-persistent-cd.rules (So they are cdrom0, cdrom1, cdrom2, IIUC.) There has been only one at a time, though. Bug 570490 says that this behavior is by design, and that the work-around is to edit 70-persistent-cd.rules. Version-Release number of selected component (if applicable): eject-2.1.5-15.fc12.x86_64 udev-145-15.fc12.x86_64 How reproducible: Reproduced on F11, F12, F13, and Ubuntu 9.10. Steps to Reproduce: 1. Check that the eject command works. 2. Shutdown and replace the optical drive. 3. Restart and try the eject command. Actual results: "eject" fails with an error messages. Expected results: "eject" ejects the drive tray. Additional info: Bug 570490 - /dev/cdrom not created after optical drive replaced This bug also applies to "xine", which by default uses /dev/dvd.
(In reply to comment #0) > How reproducible: > Reproduced on F11, F12, F13, and Ubuntu 9.10. Correction: Reproduced on F11, F12, F13. "eject" works as expected on Ubuntu 9.10.
Steve, thank you for reporting the bug! Harald, how exactly is it supposed to be fixed within eject?
Here is a link to the Ubuntu version of "eject": http://packages.ubuntu.com/karmic/eject Source links are in the box to the right: http://archive.ubuntu.com/ubuntu/pool/main/e/eject/eject_2.1.5+deb1+cvs20081104.orig.tar.gz http://archive.ubuntu.com/ubuntu/pool/main/e/eject/eject_2.1.5+deb1+cvs20081104-6.diff.gz I haven't found a source browser yet.
Are you saying it works well on Fedora with the eject from Ubuntu? If so, I can of course dig the differences myself. I thought that udev on Ubuntu worked differently. It was misunderstanding on my part...
(In reply to comment #4) > Are you saying it works well on Fedora with the eject from Ubuntu? > > If so, I can of course dig the differences myself. > > I thought that udev on Ubuntu worked differently. It was misunderstanding on > my part... I'm not really a Ubuntu user, but udev on Ubuntu has created /dev/cdrom1 and not /dev/cdrom, yet "eject" on Ubuntu works as expected. Anyway, I DL'ed both orig and patch and it looks like the function: static char *FindDevice(const char *name) just tries a bunch places. You guys are the experts ... :-)
On Ubuntu ... stephent@pecan:~$ ls -ld /dev/* | grep 'sr[0-9]' lrwxrwxrwx 1 root root 3 2010-03-04 10:04 /dev/cdrom1 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-04 10:04 /dev/cdrw1 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-04 10:04 /dev/dvd1 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-04 10:04 /dev/dvdrw1 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-04 10:04 /dev/scd0 -> sr0 brw-rw----+ 1 root cdrom 11, 0 2010-03-04 10:04 /dev/sr0 On Ubuntu "strace eject" shows an open() call at the end: stephent@pecan:~/xfr$ tail eject-ubuntu-strace.1.log mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbfe8955000 read(3, "# /etc/fstab: static file system"..., 4096) = 1027 close(3) = 0 munmap(0x7fbfe8955000, 4096) = 0 stat("/dev/scd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(11, 0), ...}) = 0 geteuid() = 1000 open("/dev/scd0", O_RDWR|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0) = 0 close(3) = 0 exit_group(0) = ? stephent@pecan:~/xfr$ On Ubuntu, eject opens /dev/scd0 which is a link to /dev/sr0: open("/dev/scd0", O_RDWR|O_NONBLOCK) = 3
On Ubuntu ... stephent@pecan:~$ eject -V eject version 2.1.5 by Jeff Tranter (tranter) stephent@pecan:~$ eject -v eject: using default device `cdrom' eject: device name is `cdrom' eject: expanded name is `/media/cdrom' eject: `/media/cdrom' is a link to `/media/cdrom0' eject: `/media/cdrom0' is not mounted eject: `/dev/scd0' can be mounted at `/media/cdrom0' eject: `/dev/scd0' is not a multipartition device eject: trying to eject `/dev/scd0' using CD-ROM eject command eject: CD-ROM eject command succeeded stephent@pecan:~$ ls -lF /media total 6 lrwxrwxrwx 1 root root 6 2010-01-26 14:09 cdrom -> cdrom0/ drwxr-xr-x 2 root root 4096 2010-01-26 14:09 cdrom0/ drwxr-xr-x. 8 root root 1024 2010-03-01 12:28 cedar_boot/ stephent@pecan:~$
On Ubuntu ... this could be where "eject" finds /dev/scd0. stephent@pecan:~$ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid -o value -s UUID' to print the universally unique identifier # for a device; this may be used with UUID= as a more robust way to name # devices that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # / was on /dev/sda5 during installation UUID=05fe594a-bd90-44ba-8dbc-2e6c1de27094 / ext4 errors=remount-ro 0 1 # /home was on /dev/sda6 during installation UUID=a377bcbc-0c4d-4f9e-b804-15c14d639ab3 /home ext4 defaults 0 2 # swap was on /dev/sda7 during installation UUID=39d61b09-9391-4dbd-ab77-e91ebf7cc8d2 none swap sw 0 0 # swap was on /dev/sdb3 during installation #UUID=407b21a6-d91d-408b-9fcd-96e234cb3115 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 stephent@pecan:~$
On Ubuntu ... "eject" parses /etc/fstab here: static int MountableDevice(const char *name, char **mountName, char **deviceName)
(In reply to comment #9) Thank you for gathering all the info in the first place! > On Ubuntu ... "eject" parses /etc/fstab here: > > static int MountableDevice(const char *name, char **mountName, char > **deviceName) The same on F-12 eject: $ gdb -q --args ./eject -v gdb) b MountableDevice Breakpoint 1 at 0x403057: file eject.c, line 985. (gdb) r Starting program: eject -v eject: using default device `cdrom' eject: device name is `cdrom' eject: expanded name is `/mnt/cdrom' eject: `/mnt/cdrom' is not mounted Breakpoint 1, MountableDevice (name=0x60a090 "/mnt/cdrom", mountName=0x7fffffffd9a8, deviceName=0x7fffffffd9b0) at eject.c:985 985 fp = fopen("/etc/fstab", "r"); (gdb) n 986 if (fp == NULL) { (gdb) n 999 while (fgets(line, sizeof(line), fp) != 0) { (gdb) b 1007 Breakpoint 2 at 0x403182: file eject.c, line 1007. (gdb) c Continuing. Breakpoint 2, MountableDevice (name=0x60a090 "/mnt/cdrom", mountName=0x7fffffffd9a8, deviceName=0x7fffffffd9b0) at eject.c:1007 1007 return 1; (gdb) print *mount mount mountName (gdb) print *mountName $1 = 0x60b3b0 "/mnt/cdrom" (gdb) print *deviceName $2 = 0x60b390 "/dev/sr0" (In reply to comment #7) > On Ubuntu ... > > stephent@pecan:~$ eject -V > eject version 2.1.5 by Jeff Tranter (tranter) > stephent@pecan:~$ eject -v > eject: using default device `cdrom' > eject: device name is `cdrom' > eject: expanded name is `/media/cdrom' > eject: `/media/cdrom' is a link to `/media/cdrom0' I guess the difference on Ubuntu is above ^^^. Please try the following on both systems: $ grep `readlink -f /dev/cdrom` /etc/fstab
Thanks for looking into this, Kamil. On Ubuntu 9.10 ... stephent@pecan:~$ grep `readlink -f /dev/cdrom` /etc/fstab stephent@pecan:~$
On F12 ... [stephent@walnut ~]$ grep `readlink -f /dev/cdrom` /etc/fstab [stephent@walnut ~]$
> Please try the following on both systems: > > $ grep `readlink -f /dev/cdrom` /etc/fstab Oops, looking once again, I can see /media/cdrom is used instead of /dev/cdrom. Unfortunately right now I have no genuine F-12 installation around. I'll give it a try tomorrow if nothing urgent happens.
Created attachment 398043 [details] 70-persistent-cd.rules with three optical drive records; from F12 system /etc/udev/rules.d/70-persistent-cd.rules I can reproduce the problem on F13 by using 70-persistent-cd.rules from my F12 system (multi-boot, same hardware). NB: The problem occurred on F13 after I replaced the optical drive, but the 70-persistent-cd.rules that was generated then was lost during subsequent F13 installation testing (which included formatting the target partition).
From what I understand, there is nothing wrong with the eject utility itself. The fix must go into udev - bug 570490, right?
(In reply to comment #15) > From what I understand, there is nothing wrong with the eject utility itself. > The fix must go into udev - bug 570490, right? Yes, I am coming to that view. Although eject could be extended to search more places (e.g. /dev/scd0), that would not fix other apps (e.g. xine) that also assume certain device links exist. Basically, udev needs to support legacy apps that look for certain device links by default.
(In reply to comment #16) > Although eject could be extended to search more places (e.g. /dev/scd0), that > would not fix other apps (e.g. xine) that also assume certain device links > exist. The question is how to figure out that '/dev/scd0' is the right device. You wanted eject to dig the info in /etc/fstab, but that already happens. Do you have the line with '/dev/scd0' in your /etc/fstab? Does each optical device have a mount point there?
(In reply to comment #17) > (In reply to comment #16) > > Although eject could be extended to search more places (e.g. /dev/scd0), that > > would not fix other apps (e.g. xine) that also assume certain device links > > exist. > > The question is how to figure out that '/dev/scd0' is the right device. You > wanted eject to dig the info in /etc/fstab, but that already happens. Do you > have the line with '/dev/scd0' in your /etc/fstab? Does each optical device > have a mount point there? The link /dev/scd0 appears to be generated by yet another udev rule: [stephent@walnut rules.d]$ grep scd /lib/udev/rules.d/50-udev-default.rules SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom" [stephent@walnut ~]$ readlink -ev /dev/scd0 /dev/sr0 There are no optical devices in my /etc/fstab. NB: I am a udev rules noob, so please take anything I say with a grain of salt. :-)
Not sure why sr* is deprecated in this doc, since sr* is certainly being used: /usr/share/doc/kernel-doc-2.6.32.9/Documentation/devices.txt Anyway, it looks like scd* and sr* both refer to optical devices: 11 block SCSI CD-ROM devices 0 = /dev/scd0 First SCSI CD-ROM 1 = /dev/scd1 Second SCSI CD-ROM ... The prefix /dev/sr (instead of /dev/scd) has been deprecated. Apparently devices.txt needs to be fixed: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg09915.html
*** Bug 527123 has been marked as a duplicate of this bug. ***
Same issue here after switching the IDE mode slave to master for a DVD drive. After this action, file /etc/udev/rules.d/70-persistent-cd.rules shows two entries cdrom and cdrom1 for the same drive but the one being used is the new one which assigns the drive to /dev/cdrom1. This applies to a fully updated F12 system with udev-145-20.fc12.x86_64.
I am reassigning the bug to udev as so far nobody has proposed any solution addressing the eject utility itself. Feel free to reassign it back once you have any idea how can I improve eject in this aspect.
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
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.
Reopening against F14. udev-161-8.fc14.x86_64 Reproduce by moving SATA cable to a different port.
edit or remove: /etc/udev/rules.d/70-persistent-cd.rules
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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