On Sat, 5 Jan 2013 12:44:07 -0800
Mark Knecht wrote -
> On Sat, Jan 5, 2013 at 11:53 AM, Mark Knecht <markkne...@gmail.com> wrote:
> > I think I touched on this a couple of weeks ago but never had time to
> > dig in. At that time I thought this problem was only on one machine
> > but now I see it's on every machine I've looked at this morning. Not a
> > single machine has /dev/cdrom anymore, nor /dev/dvd or any of the
> > other incantations that have existed forever.
> >
> <SNIP>
>
> OK, this is solved using udevadm and changing the
> 70-persistent-cd.rules file to key off a different identifier.
>
> Old way:
> #SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
> ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom",
> ENV{GENERATED}="1"
>
> New way:
> SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
> ENV{ID_MODEL}=="Optiarc_DVD_RW_AD-7241S", SYMLINK+="cdrom",
> ENV{GENERATED}="1"
I had the same problem. Came to a different solution. Following for
your amusement and edifcation are my notes taken as I debugged.
------------
==2012-11-26
udev is not creating /dev/cdrom symlinks so all my scripts that use
/dev/cdrom or attempt to moun /dev/cdrom fail.
Not sure when this actually started happening. I last burned a dvd on Oct
23 so it was OK then. /etc/udev/roules.d/70-persistent-cdrom.rules is dated
Oct 30. It looks plausible.
Documentation implies that removing said file and rebooting will cause udev
to recreate it "correctly". I was unable to cause it to be rebuilt,
correctly or otherwise, in this manner.
==2012-11-27
Created /dev/cdrom -> /dev/sr0 symlink manually because burn script wants
to mount /dev/cdrom on /mnt/cdrom.
This time the backup copy/burn went flawlessly. I think udev is also
causing problems.
70-persistent-cd.rules may be wrong for my current kernel
I don't think the ID_PATH has scsi as a path anymore.
==2012-12-04
I syncd on Friday(Dec 1), but did not do emerge.
Doing the regular upgrade emerge.
new virtual/udev-171 I guess this is prep for the proposed udev fork.
open-rc goes from 0.11.5 to 0.11.6 This might bear on cd.rules issue.
But apparently not, there seems to be no change.
No config files
revdep-rebuild was clean
udev should be restarted. (reboot might be better)
On reboot 70-persistent-net.rules was created. It was the same as the old
one. No cd rules file.
I then inserted my memorex usb stick that has a "cdrom" partition on it.
Lo! a 70-persistent-cd.rules file appeared with 2 lines for the memorex.
plus /dev/cdrom /dev/cdrw symlinks to sr1.
If I pull the stick sr1, cdrom, and cdrw go away. They come back if I
reinsert it. 70*cd.rules remains unchanged.
Note: Running udevadm control --log-priority=info
puts copious amounts of stuff into /var/log/everything/current
Debug even more
Remember to reset it to err when not experimenting.
Findings:
/lib/udev/rules.d/75-cd-aliases-generator.rules
invokes
/lib/udev/write_cd_rules
to actually write the /etc/udev/rules.d/70-persistent-cd.rules file.
for usb cdroms it calls it with "by-id" as an arg. Non usb device no arg
which defaults to "by-path" in the callee.
by-path requires $ID_PATH variable to have a value. Turns out that
udevadm info --query=all --name=/dev/sr0
shows that for the built -in drive there is no BY_PATH variable set.
(it is set for sr1 the usb stick!)
So it looks like the write_cd_rules script bails with return code of 1
without actually writing anything.
Solution to try:
Copy /lib/udev/rules.d/75-cd-aliases-generator.rules to /etc/udev/rules.d
and edit it there to invoke /write_cd_rules with "by-id" in both cases
and see what happens.
==2012-12-05
Yess!
Did above and it "just worked".
----------------
My 70-persistent-cd.rules file now contains:
# HL-DT-ST_DVDRAM_GH22NS70 ()
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="HL-DT-ST_DVDRAM_GH22NS70_K24B5GJ2632", SYMLINK+="cdrom",
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="HL-DT-ST_DVDRAM_GH22NS70_K24B5GJ2632", SYMLINK+="cdrw",
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="HL-DT-ST_DVDRAM_GH22NS70_K24B5GJ2632", SYMLINK+="dvd",
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="HL-DT-ST_DVDRAM_GH22NS70_K24B5GJ2632", SYMLINK+="dvdrw",
ENV{GENERATED}="1"
# TD_ID_UFD_301B (pci-0000:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="Memorex_TD_ID_UFD_301B_07630E9000EB-0:0", SYMLINK+="cdrom1",
ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="Memorex_TD_ID_UFD_301B_07630E9000EB-0:0", SYMLINK+="cdrw1",
ENV{GENERATED}="1"
Modifying 75-cd-aliases-generator.rules has an advantage over Mark's solution
in that it will automatically catch all installed cdrom- type devices and it
should add the dvd rules as appropriate to the device's capabilities.
Dave F
