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.

This bug affects other distros too:
    https://bugs.archlinux.org/task/24597
    https://bugs.launchpad.net/ubuntu/+source/eject/+bug/795239

Could the udev rules be improved so that the /dev/cdrom symlink is created automatically on machines with one cdrom device?

(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

(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

(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? ;-)

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

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

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.

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

(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?

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

...

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

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)

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?

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