Bug 570561

Summary: /dev/cdrom is missing after optical drive replaced
Product: [Fedora] Fedora Reporter: Steve Tyler <stephent98>
Component: udevAssignee: udev-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: gofish, harald, jfrieben, jonathan, kdudka
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 18:22:26 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 570490    
Bug Blocks:    
Attachments:
Description Flags
70-persistent-cd.rules with three optical drive records; from F12 system none

Description Steve Tyler 2010-03-04 12:59:23 EST
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.
Comment 1 Steve Tyler 2010-03-04 13:03:19 EST
(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.
Comment 2 Kamil Dudka 2010-03-04 13:10:25 EST
Steve, thank you for reporting the bug!

Harald, how exactly is it supposed to be fixed within eject?
Comment 3 Steve Tyler 2010-03-04 15:50:25 EST
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.
Comment 4 Kamil Dudka 2010-03-04 16:01:09 EST
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...
Comment 5 Steve Tyler 2010-03-04 16:18:20 EST
(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 ... :-)
Comment 6 Steve Tyler 2010-03-04 16:36:46 EST
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
Comment 7 Steve Tyler 2010-03-04 16:59:30 EST
On Ubuntu ...

stephent@pecan:~$ eject -V
eject version 2.1.5 by Jeff Tranter (tranter@pobox.com)
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:~$
Comment 8 Steve Tyler 2010-03-04 17:02:27 EST
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:~$
Comment 9 Steve Tyler 2010-03-04 17:05:55 EST
On Ubuntu ... "eject" parses /etc/fstab here:

static int MountableDevice(const char *name, char **mountName, char **deviceName)
Comment 10 Kamil Dudka 2010-03-04 17:28:32 EST
(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@pobox.com)
> 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
Comment 11 Steve Tyler 2010-03-04 17:48:17 EST
Thanks for looking into this, Kamil.

On Ubuntu 9.10 ...
stephent@pecan:~$ grep `readlink -f /dev/cdrom` /etc/fstab
stephent@pecan:~$
Comment 12 Steve Tyler 2010-03-04 17:51:32 EST
On F12 ...
[stephent@walnut ~]$ grep `readlink -f /dev/cdrom` /etc/fstab
[stephent@walnut ~]$
Comment 13 Kamil Dudka 2010-03-04 17:56:42 EST
> 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.
Comment 14 Steve Tyler 2010-03-05 07:31:30 EST
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).
Comment 15 Kamil Dudka 2010-03-16 16:48:26 EDT
From what I understand, there is nothing wrong with the eject utility itself.  The fix must go into udev - bug 570490, right?
Comment 16 Steve Tyler 2010-03-16 17:22:30 EDT
(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.
Comment 17 Kamil Dudka 2010-03-16 17:50:36 EDT
(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?
Comment 18 Steve Tyler 2010-03-16 18:22:25 EDT
(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. :-)
Comment 19 Steve Tyler 2010-03-17 06:05:07 EDT
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
Comment 20 Harald Hoyer 2010-03-17 08:01:19 EDT
*** Bug 527123 has been marked as a duplicate of this bug. ***
Comment 21 Joachim Frieben 2010-05-23 00:16:14 EDT
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.
Comment 22 Kamil Dudka 2010-05-23 03:53:17 EDT
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.
Comment 23 Bug Zapper 2010-11-03 16:48:13 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 24 Bug Zapper 2010-12-03 17:02:41 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 25 Steve Tyler 2010-12-04 13:12:07 EST
Reopening against F14.
udev-161-8.fc14.x86_64

Reproduce by moving SATA cable to a different port.
Comment 26 Harald Hoyer 2010-12-06 04:58:27 EST
edit or remove:

/etc/udev/rules.d/70-persistent-cd.rules
Comment 27 Fedora Admin XMLRPC Client 2011-10-20 12:10:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 28 Fedora Admin XMLRPC Client 2011-10-20 12:12:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 29 Fedora Admin XMLRPC Client 2011-10-20 12:15:13 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 30 Fedora End Of Life 2012-08-16 18:22:29 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