My apologies if I am interfering by posting to this thread. I mostly
run kernels that I have compiled myself, but keep a Debian stock kernel
installed in case bad things happen to my custom kernels.
I try to keep up to date on the LKML happenings, and the writing is
clearly on the wall that the developers there are favoring the new
libata subsystem, and are all but deprecating the old IDE stuff.
For 2.6.32, I decided to switch my custom '.config' over to libata. I
hadn't done the proper amount of reading beforehand, and had a hell of a
time getting a device name assigned for my optical drives in /dev. Once
I figure that out, I found that 'udev' was giving me non-optimal symlink
names for those devices.
After some playing around with 'udevadm info ...', I was able to craft
this (apologies for the line breaks, which are not present in the actual
file):
$ cat /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, probably 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.
# ASUS DRW-1814BL (pci-0000:00:14.1-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="cdrom1", \
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="cdrw", \
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="dvd1", \
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="dvdrw", \
ENV{GENERATED}="1"
# TSSTcorpDVD-ROM_SH-D162C (pci-0000:00:14.1-scsi-0:0:1:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:1:0", SYMLINK+="cdrom", \
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", \
ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:1:0", SYMLINK+="dvd", \
ENV{GENERATED}="1"
# TSSTcorpDVD-ROM_SH-D162C (pci-0000:00:14.1)
SUBSYSTEM=="block", ENV{ID_MODEL}=="TSSTcorpDVD-ROM_SH-D162C", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_MODEL}=="TSSTcorpDVD-ROM_SH-D162C", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="dvd", ENV{GENERATED}="1"
# ASUS_DRW-1814BL (pci-0000:00:14.1)
SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS_DRW-1814BL", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS_DRW-1814BL", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS_DRW-1814BL", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="dvd1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS_DRW-1814BL", \
ENV{ID_PATH}=="pci-0000:00:14.1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
Aside from the problem I had with the old IDE driver layer not
distinguishing the two drives properly (both matching ID_PATH of
0:0:14.1, forcing me to distinguish using ID_MODEL), my purposing in
posting this is to show that -- on my machine, at least -- it is
possible to have two different sets of rules that deliver the same symlinks.
(OTOH, a recent upgrade from udev 149-1 to 149-2 caused a complete
disconnection of inputs, so I had to downgrade back to 149-1. I doubt
that confusion here had anything to do with it, but now I have something
else to look into, at least. The machine doesn't roll over and die, so
I can still get in with 'ssh' and do the downgrade. Just haven't had
time to gather info and debug the issue yet.)
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
