No CD/DVD sym links in 13.1
I found a thread discussing this problem. I am experiencing the same thing.
/etc/udev/rules.d/70-persistent-cd.rules does not get generated when booting the system. I have to manually create the sym links. Any ideas? Thanks again. |
What does...
Code:
cat /proc/scsi/scsi |
Same thing as does the lsscsi command. :D
I should have mentioned that my DVD drive is PATA/IDE. Perhaps that might be part of the problem. Perhaps the rules generating the 70-persistent-cd.rules file presumes SATA devices only? I have two removable drive bays in the machine, one of which is PATA/IDE. On a reboot any drive in that bay is recognized. So udev does find PATA/IDE devices. I can delete /etc/udev/rules.d/70-persistent-net.rules and that file gets regenerated during a reboot, but not 70-persistent-cd.rules. I can reboot into 12.2 and the 70-persistent-cd.rules file gets regenerated. So the problem is limited to 13.1. Or my configurations. . . . |
To get more information, you could try stopping udevd and running it with --debug and without --daemon. If that does not provide enough information it might be worth trying modifing /etc/rc.d/rc.udev but boot logging would have to be enabled to capture the output. Experimentation showed that bootlogd is only effective when started after the file system it writes to is mounted (by design it buffers its output until then but this was not working) so these lines in rc.S after the "Mount non-root file systems in fstab ..." section are used:
Code:
#@ Start console logging Code:
kernel: scsi 4:0:0:0: CD-ROM Optiarc DVD RW AD-7220A 1.01 PQ: 0 ANSI: 5 |
Solved
Quote:
I booted Slackware 13.1 in a virtual machine (VM). When deleted, that system regenerates the 70-persistent-cd.rules file, but the VM uses a pseudo SCSI connection (sr0). Inconclusive, but showed that udev was more or less working. I started to think udev was not detecting IDE optical devices. I compared /lib/udev/rules.d/60-cdrom_id.rules between 12.2 and 13.1. I noticed a glaring difference in 13.1 --- the 'hd' prefix no longer was in the rule set. In 13.1 I copied /lib/udev/rules.d/60-cdrom_id.rules to /etc/udev/rules.d/60-cdrom_id.rules. Then I added the hd prefix: Code:
ACTION=="remove", GOTO="cdrom_end" My next question: is the hd prefix omission in /lib/udev/rules.d/60-cdrom_id.rules from Slackware or upstream from the udev developers? As udev creates a device node of /dev/hda* for my IDE hard drive, udev should support the hd prefix for optical drives too. I realize kernels these days are compiled with CONFIG_SCSI_SAS_ATA set to Yes, but as long as that option can be disabled to revert to the old behavior of using the hd prefix, then udev should support that prefix too. |
Code:
*** LIBATA SWITCHOVER *** |
Quote:
I posted the thread as solved. That should have been sufficient. Was your "silly" comment necessary? Should I send you a bigger horn to toot? ;) |
Quote:
As far as Slackware is concerned, "libata" is deprecated and no longer supported. If you still want to use it, by recompiling the kernel and re-enabling the ATA driver, then it is you who can add the support back into udev - exactly as you did. What's wrong with that? The Slackware distribution allows you to fiddle with the system without penalty, provided that you know what you are doing, and why. It is unjust to blame Slackware for not supporting the things you want back after they get deprecated. Eric |
Quote:
Quote:
That the hd prefix is supported for hard drives but not optical drives is inconsistent. That is a statement, not an accusation. My question was an attempt to discern from where the inconsistenty derives. If during Slackware development then I could send a note to Pat and let him know. If upstream then I could contact somebody in the udev group. I shared a solution that did not require fiddling with the default rules. Nowhere did I place blame on anybody. You are going out of your way to create that impression. |
Not sure if anyone has solved this but here is what I figured out.
I am running Debian Squeeze and installed a new sata Sony dvd-rw drive. First thing it would not play audio cds. Much frustration and swearing later (some years since I have had to get beneath the bonnet thanks to all the hard working devs out there). The obvious thing was that although the device is recognised and working it was not connected to /dev/cdrom etc. Since udev is something I have not really had to examine before things looked right on the surface. I tried hard linking the devices -> ln /dev/sr0 /dev/cdrom and that worked until a reboot. So this had to be something to do with the way udev is identifying the device and linking the device names. Examining /dev showed that /dev/sr0 was linked to /dev/cdrom3 etc and there was no cdrom. Returning to /etc/udev/rules.d/70-persistent-cd.rules I found in the last instructions they setup cdrom3 etc. I then pulled up /var/log/dmesg and looked at the allocation of the irq address and id of the sata device; sata_nv 0000:00:08.0: PCI INT A -> Link[LSA0] -> GSI 20 (level, low) -> IRQ 20 Now looking at the persistent rule; #DVD_RW_AD-7280S (pci-0000:00:08.0-scsi-1:0:0:0) SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="cdrom3", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="cdrw3", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="dvd3", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="dvdrw3", ENV{GENERATED}="1" cracked out the editor copied and then rem'ed the above lines, pasted back and edited the device to cdrom etc; SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:08.0-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1" Reboot the system and everything is the way it should be and the apps now finding the device. So check the device allocation ( mine /sr0) in /var/log/dmesg for cdrom then have a look in /dev and see which devices this device is linked to and then look at /etc/udev/rules.d/ ........cd.rules. Mine were the last lines. Hope this helps. Not sure why this has happened but similar thing happened with allocation of eth#'s in Lenny and it was a pain in the arse |
Quote:
Quote:
|
Quote:
Quote:
Since the use of udev and optical cdroms is not solely confined to Slackware people from other distros who Google this problem (#1 on Google results) might find the information useful. A polite g'day to you Sir. |
Although I posted that I found a work around and tagged the thread as solved, not long thereafter I surrendered. Slackware 13.1 was the first release where the /dev/hd* devices no longer were supported. The system was designed completely with libata in mind and that included the udev rules. In the end I had to throw in the proverbial towel and recompile my kernel to solely use libata. C'est la vie. :)
On my 12.2 systems I still use the hda reference to my hard drives, but those older kernels still support that. |
All times are GMT -5. The time now is 07:28 PM. |