Bug 834071 - cdrom has a erroneous symlink called cdrom2 to /dev/sr0 - bad /dev/cdrom symlink - /dev/sr0 is OK, the bug is erroneous symlink of "cdrom"
cdrom has a erroneous symlink called cdrom2 to /dev/sr0 - bad /dev/cdrom syml...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev (Show other bugs)
All Linux
unspecified Severity low
: rc
: ---
Assigned To: udev-maint
Depends On:
  Show dependency treegraph
Reported: 2012-06-20 14:28 EDT by xset1980
Modified: 2012-06-29 14:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-29 14:13:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description xset1980 2012-06-20 14:28:36 EDT
Description of problem:

The eject command, and other software, no find cdrom devices, because the symlink on /dev/ is called cdrom2:

/dev/cdrom2 -> /dev/sr0

If the symlink is deleted, after the reboot, is created newly with the name cdrom2 again.

Version-Release number of selected component (if applicable):

Scientific Linux 6.2

How reproducible:


Steps to Reproduce:
Actual results:

cdrom no exists, and cdrom2 point to /dev/sr0

Expected results:

That cdrom exist and cdrom2 no.

Additional info:

The contente of /etc/udev/rules.d/70-persistent-cd.rules is:

# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.

# DVDRAM_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"

# DVDRAM_GSA-U10N (pci-0000:00:1f.1-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0", SYMLINK+="cdrw1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0", SYMLINK+="dvdrw1", ENV{GENERATED}="1"

# DVDRAM_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+="cdrom2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrw2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvd2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvdrw2", ENV{GENERATED}="1"

The real device is pci-0000:00:1f.2-scsi-0:0:0:0 in my case, if comment all lines (#), and reboot, udev create que correct entry with cdrom, cdrw and dvdrw and not 2, so, eject and other software, recognize "cdrom" device.

dmesg: sr 1:0:0:0: Attached scsi CD-ROM sr0
Comment 2 xset1980 2012-06-20 23:14:54 EDT
The same bug that: https://bugzilla.redhat.com/show_bug.cgi?id=505639

"Need Real Name 2009-11-19 01:50:13 EST
I disagree. EXACT same problem occurs in F12 final.
Installation hangs.
Console shows /dev/cdrom doesn't exist.
BTW, I am installing into VMWARE where the cdrom is pointed to the DVD iso (i.e. the cdrom driver acts as if the iso is a physical cdrom)."

So, el6 is based on F12 and F13.

Maybe with a updated rpm of udev rules solve this i think
Comment 3 Harald Hoyer 2012-06-29 14:13:28 EDT
Just remove /etc/udev/rules.d/70-persistent-cd.rules. Seems like your VM rearranges the hardware.

Note You need to log in before you can comment on or make changes to this bug.