On Mon, Jan 7, 2013 at 7:18 AM, Grant Edwards <grant.b.edwa...@gmail.com> wrote:
> On 2013-01-07, Dale <rdalek1...@gmail.com> wrote:
>
>> I'm not sure that is a bug.  As I posted earlier, this was changed a
>> good while back.  There was a reason for it but I can't recall what it
>> was.  The new devices for CD/DVDs is /dev/sr*.
>
> It's been something like 6-8 years hasn't it?

IIRC the SATA interface has always labeled them as /dev/sdX /dev/srX.
Everything I've built using new hardware in the last 5 years has been
SATA based and I've not had a new machine with /dev/hdX in longer than
I can remember.

However, best I can tell, that has _nothing_ to do with why /dev/cdrom
/dev/dvd disappeared in the last couple of months. Remember, my
machines have all had /dev/srX.

Going back to my post with one of many solutions to this issue:

First - the old way that udev was recognizing the cdrw/dvd drive on my
system was via an ID_PATH value for the pci device:

#SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom",
ENV{GENERATED}="1"

However you will note that ID_PATH (the key used by udev) doesn't exist any more

c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep ID_PATH
c2stable ~ #


Best guess I have is that ID_PATH may have been changed to DEVPATH

c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep DEVPATH
E: 
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata11/host10/target10:0:0/10:0:0:0/block/sr0
c2stable ~ #

What I did was ask udev to identify by the drive's model number using ID_MODEL:

New way:
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_MODEL}=="Optiarc_DVD_RW_AD-7241S", SYMLINK+="cdrom",
ENV{GENERATED}="1"

A little playing around suggest you can use anything unique to the device.

Now, my point is that change to /dev/srX was the root cause is FUD. It
isn't the root cause of this change because it didn't change on my
systems. All I know is that ID_PATH (from the old file) used to work
and no longer does. Whatever is responsible for creating that, likely
some portion of the kernel, changed the value and created a need to
modify how udev looks at the system. Is it a bug? I don't know.  It's
just the way it is.

Just my views,
Mark

Reply via email to