Red Hat Bugzilla – Full Text Bug Listing
|Summary:||eject is unable to find or open device for cdrom|
|Product:||[Fedora] Fedora||Reporter:||Andrei ILIE <andrei.ilie>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||harald, jonathan, kdudka, mluscon, stephent98, triad, udev-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 15:10:10 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Andrei ILIE 2012-01-01 12:28:01 EST
Description of problem: "eject" is unable to find or open device for my CDROM, unless I manually make a symlink with "sudo ln -s /dev/sr0 /dev/cdrom" Version-Release number of selected component (if applicable): andrei@cofee:~$ eject -V eject version 2.1.5 by Jeff Tranter (firstname.lastname@example.org) How reproducible: always Steps to Reproduce: andrei@cofee:~$ eject eject: unable to find or open device for: `cdrom' Additional info: andrei@cofee:~$ uname -a Linux cofee 184.108.40.206-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 3 Jan 1 19:18 /dev/cdrom1 -> sr0 lrwxrwxrwx 1 root root 3 Jan 1 19:18 /dev/cdrw1 -> sr0 lrwxrwxrwx 1 root root 3 Jan 1 19:18 /dev/scd0 -> sr0
Comment 1 Andrei ILIE 2012-01-01 12:30:54 EST
The "sudo ln -s /dev/sr0 /dev/cdrom" symlink gets lost after every restart/poweroff. It must be done once every time the system boots.
Comment 2 Andrei ILIE 2012-01-01 12:33:58 EST
This bug affects other distros too: https://bugs.archlinux.org/task/24597 https://bugs.launchpad.net/ubuntu/+source/eject/+bug/795239
Comment 3 Kamil Dudka 2012-01-01 17:00:47 EST
Could the udev rules be improved so that the /dev/cdrom symlink is created automatically on machines with one cdrom device?
Comment 4 Harald Hoyer 2012-01-05 05:37:27 EST
(In reply to comment #3) > Could the udev rules be improved so that the /dev/cdrom symlink is created > automatically on machines with one cdrom device? # echo 'KERNEL=="sr0", SYMLINK+="cdrom"' >> /etc/udev/rules.d/99-my-cdrom.rules
Comment 5 Steve Tyler 2012-01-28 16:01:50 EST
(In reply to comment #4) > (In reply to comment #3) > > Could the udev rules be improved so that the /dev/cdrom symlink is created > > automatically on machines with one cdrom device? > > # echo 'KERNEL=="sr0", SYMLINK+="cdrom"' >> /etc/udev/rules.d/99-my-cdrom.rules That's a workaround, not a fix. Andrei: This has been a problem before: Bug 570561 - /dev/cdrom is missing after optical drive replaced Here is a possible workaround: # rm /etc/udev/rules.d/70-persistent-cd.rules # reboot Another is to run: $ eject /dev/sr0
Comment 6 Steve Tyler 2012-01-28 19:39:37 EST
(In reply to comment #3) > Could the udev rules be improved so that the /dev/cdrom symlink is created > automatically on machines with one cdrom device? That's a good idea. If there is exactly one cdrom device a cdrom link would be automatically created. Likewise for dvd, dvdrw, etc. Previously auto-configured links, such as cdrom1, would be created as usual. Unfortunately, udev implicitly assumes that cdrom means cdrom0, and cdrom0 is never created ... Harald: Can udev count? ;-)
Comment 7 Kay Sievers 2012-01-28 21:09:06 EST
(In reply to comment #6) > (In reply to comment #3) > > Could the udev rules be improved so that the /dev/cdrom symlink is created > > automatically on machines with one cdrom device? > > That's a good idea. If there is exactly one cdrom device a cdrom link would be > automatically created. Likewise for dvd, dvdrw, etc. Previously auto-configured > links, such as cdrom1, would be created as usual. We could always make /dev/cdrom a link to /dev/sr0. > Unfortunately, udev implicitly assumes that cdrom means cdrom0, and cdrom0 is > never created ... No, udev does not count, and it's a problem that can't be solved with numbers. Device can come and go at any time. Simple enumeration numbers depend on device discovery order, which is entirely unpredictable. These numbers would not be stable. We recommend everybody who has multiple devices, and needs to reliably to identify them, to use /dev/disk/by-id/ links directly. In case of multiple identical devices, which do not expose a unique serial number, they can be identified by /dev/disk/by-path/ links. If these links are used, the device cannot be connected to a different port or connector, as that would change the link. These links are composed from device properties and never depend on enumeration order, or system-specific udev rules. They are far more reliable than any enumeration number.
Comment 8 Kamil Dudka 2012-01-29 05:22:39 EST
(In reply to comment #7) > We recommend everybody who has multiple devices, and needs to reliably to > identify them, to use /dev/disk/by-id/ links directly. Do you mean multiple devices connected during computer's lifetime or multiple devices connected at a time? The first should work out of the box I would say. If a user has exactly one optical device connected and wants to eject the media, it should be possible without any awareness of /dev, udev, etc.
Comment 9 Kay Sievers 2012-01-29 09:22:12 EST
The /dev//disk/by-id/ links are derived from the hardware properties, they are identical for completely identical hardware and can therefore not be used to uniquely identify identical hardware. If that's the case, the by-path/ links can be used. Most hardware though exports unique serial numbers. This applies only to devices device connected at the same time, sure. New versions of Fedora will not remember any settings about connected hardware, and reservation of device names will not happen anymore. This model causes too many problems for systems with many changes, or systems which media is booted in different environments. The by-id + by-path/ links are recommended to be used directly today instead of the enumeration names. If short or custom names are wanted, users can always add custom udev rules. We should probably add /dev/cdrom a static alias to /dev/sr0.
Comment 10 Kamil Dudka 2012-01-29 09:54:35 EST
(In reply to comment #9) > We should probably add /dev/cdrom a static alias to /dev/sr0. If optical devices always get assigned the device /dev/sr0 on machines with one optical device, it would solve the problem with eject.
Comment 11 Steve Tyler 2012-01-29 10:52:24 EST
(In reply to comment #9) > We should probably add /dev/cdrom a static alias to /dev/sr0. Would other links, such as /dev/dvd, also be created (according to the device capabilities)? xine uses /dev/dvd by default, although that is configurable. If a user has more than one optical device, would it be easy to change the default target from sr0? Would cdrom0 also be created?
Comment 12 Steve Tyler 2012-01-29 11:20:30 EST
(In reply to comment #9) ... > New versions of Fedora will not remember any settings about connected hardware, > and reservation of device names will not happen anymore. This model causes > too many problems for systems with many changes, or systems which media is > booted in different environments. If this means that 70-persistent-cd.rules will be eliminated, that would be great. > The by-id + by-path/ links are recommended to be used directly today instead > of the enumeration names. If short or custom names are wanted, users can always > add custom udev rules. OK, but users probably don't want to read a lot of documentation, so an example custom udev rules file would be helpful. Say, /etc/udev/rules.d/99-custom.rules with commented example lines for doing something like create a link from /dev/cdrom99 to /dev/disk/by-id/ata-ATAPI_iHAS424_Y. ...
Comment 13 Kay Sievers 2012-01-29 11:52:03 EST
(In reply to comment #11) > Would other links, such as /dev/dvd, also be created (according to the device > capabilities)? xine uses /dev/dvd by default, although that is configurable. We haven't really thought about any details, but I guess we would only provide the historic /dev/cdrom by default. We could provide dvd only for sr0 anyway, we can and should not really establish any udev logic which creates dependencies over otherwise independent devices. > If a user has more than one optical device, would it be easy to change the > default target from sr0? Udev rules can overwrite that, sure. > Would cdrom0 also be created? No, udev can not safely create any enumeration numbers. We can not solve that problem properly with the random device discovery order we see in the real world. So we should no longer pretend we can. We tried several strategies in the past already, udev had a built-in enumerator, we automatically created rules in /etc, none of that really worked out, so we need to admit, we can not solve this problem properly without creating a bunch of new others at the same time. (In reply to comment #12) > If this means that 70-persistent-cd.rules will be eliminated, that would be > great. It's gone in rawhide already. Fedora 17 will not write any rules to /etc. > OK, but users probably don't want to read a lot of documentation, so an > example custom udev rules file would be helpful. Say, > /etc/udev/rules.d/99-custom.rules > with commented example lines for doing something like create a link from > /dev/cdrom99 to /dev/disk/by-id/ata-ATAPI_iHAS424_Y. Sure, we can add that somewhere, but udev should not install any rule in /etc. RPM package content is not supposed to leave things behind which are meant to be edited/owned by users/admins. It's common practice, but it's a flawed concept in general and we work in the direction to leave /etc to the local admin only and not to packages or the distribution. All RPM shipped udev rules are in /lib/udev for that reason. If the admin places a rule with the same name in /etc, the rule in /lib is entirely ignored. We call that config-file-stack, and it provides a strict separation of default system-supplied config and local admin-configured overwrites. Many new actively developed projects like systemd, kmod (module-init-tools), udev follow these rules already. The goal is to minimize the use of /etc for system defaults.
Comment 14 Steve Tyler 2012-01-29 14:39:31 EST
Thanks for your clarifications and explanations, Kay. They all sound good. If 70-persistent-cd.rules is gone in F17, my question about cdrom0 is moot, and I am happy. :-) Clarifying my earlier question: Would links like cdrom, dvd, etc. point to sr0, but only if sr0 had the corresponding capability? cdrom -> sr0, if sr0 is a cdrom device dvd -> sr0, if sr0 is a dvd device cdrw -> sr0, if sr0 is a cdrw device dvdrw -> sr0, if sr0 is a dvdrw device The eject command uses cdrom and xine uses dvd. I don't know if any apps use cdrw or dvdrw. There is also a link called scd0. If those links are generated by a rules file in /lib/udev, there doesn't need to be a separate example file. It would be its own example. :-) The rules file could, however, have a comment saying something like: "To override these rules, copy this file to /etc/udev and modify it there." Kamil, was your [implicit] question answered? (Comment 10)
Comment 15 Linus Walleij 2012-05-10 17:00:17 EDT
I have this problem too, is there some consensus on how to solve it? If devkit-disks --show-info /dev/sr0 can come up with this: media: optical_cd compat: optical_cd optical_cd_r optical_cd_rw optical_dvd optical_dvd_plus_r optical_dvd_plus_r_dl optical_dvd_plus_rw optical_dvd_r optical_dvd_ram optical_dvd_rw optical_mrw optical_mrw_w Then I believe surely that same information is available to udev, or can be made available using some small program. Does anyone know where devkit-disks get this information from?
Comment 16 Fedora End Of Life 2012-08-07 15:10:13 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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