Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore

[David M. Fellows]

On Sat, 5 Jan 2013 12:44:07 -0800 
Mark Knecht wrote -
> On Sat, Jan 5, 2013 at 11:53 AM, Mark Knecht <markknecht@×××××.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