LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   No CD/DVD sym links in 13.1 (https://www.linuxquestions.org/questions/slackware-14/no-cd-dvd-sym-links-in-13-1-a-877946/)

Woodsman 04-29-2011 11:09 PM

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.

Richard Cranium 04-29-2011 11:48 PM

What does...
Code:

cat /proc/scsi/scsi
...give?

Woodsman 04-30-2011 10:21 AM

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. . . .

catkin 04-30-2011 11:27 AM

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
#@ This is as soon as it is known to work
if [ -x /sbin/bootlogd ]; then
        echo 'Starting bootlogd'
        /sbin/bootlogd
        echo 'Bootlogd started (this is the first boot message that appears in /var/log/boot).'
fi

I am willing to try the same to get comparable output for a working IDE-attached CD/DVD (Sony NEC Optiarc, model AD-7200A-OB) on Slackware64 13.1. It shows up in /var/log messages as a SCSI device:
Code:

kernel: scsi 4:0:0:0: CD-ROM            Optiarc  DVD RW AD-7220A  1.01 PQ: 0 ANSI: 5

Woodsman 04-30-2011 02:47 PM

Solved
 
Quote:

It shows up in /var/log messages as a SCSI device
That comment got me thinking. I wondered why udev saw my IDE hard drive but not my IDE optical drive.

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"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|hd[a-z]|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

ENV{ID_CDROM}="1"
IMPORT{program}="cdrom_id --export $tempnode"

LABEL="cdrom_end"

I deleted /etc/udev/rules.d/70-persistent-cd.rules and rebooted. The sym links were created and 70-persistent-cd.rules was regenerated. :)

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.

T3slider 04-30-2011 02:54 PM

Code:

*** LIBATA SWITCHOVER ***

The "old" ide subsystem in the the linux kernel is now deprecated in favor
  of the newer libata subsystem, and this affects the naming of device nodes
  for almost all types of disk drives -- hard drives in particular will now
  have an "sd" named node.  The following information should allow you to
  handle that changeover gracefully.

  1. Upgrade the kernel and kernel-modules packages normally.
   
  2. Edit /etc/fstab to reflect the change from hd* to sd*.
   
    If you have multiple SATA devices, and especially if you have some of
    both hd* and sd* devices present already, then you're basically going
    to be playing a guessing game right now, and you probably want to
    consider using some of the persistent symlinks in the /dev/disk/by-*/
    directories instead of raw device nodes -- for example, the links in
    /dev/disk/by-id/ should always point to the same device, even if its
    raw device node changes from e.g. sda1 to sdc1 or some such across
    reboots.
 
    * If you are using one of the generic kernels (requiring an initrd),
      then use the sd* name for the root device when creating the image.
   
    * You will almost surely want to remove the udev rules file for cdrom
      devices (it will be regenerated on the next boot with correct
      information reflecting the new libata stuff): 
        # rm -f /etc/udev/rules.d/70-persistent-cd.rules

    * Speaking of optical devices, if you have multiple disk drives and an
      optical drive using the old ide subsystem, then be aware that the
      optical drive will get a /dev/sr* name instead of /dev/sd* -- this is
      relevant because you might see something like this (if your optical
      drive is currently /dev/hdb):
 
        Old Name --> New Name
        /dev/hda    /dev/sda
        /dev/hdb    /dev/sr0
        /dev/hdc    /dev/sdb
 
  3. Run lilo.  Note that you have made no edits at all to it yet, unless
    you needed to edit it for the new kernel.  Specifically, do not make
    any changes with respect to hd* --> sd*.
 
  4. Reboot.  At the lilo prompt, press <TAB> and add an append for the
    real root device (which will no longer be /dev/hd*).  For example, if
    the old root device was /dev/hda1, and it will now be /dev/sda1, and
    the name of your kernel image is "Linux" then you would do this:

      Linux root=/dev/sda1

  5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and
    reboot again to be sure everything is correct.

From 13.1's CHANGES_AND_HINTS.TXT and expected to be relevant from here on out. /dev/hd* shouldn't exist, and if it does then you're not using libata (why aren't you using libata?). If you're doing silly things with the kernel then you would be expected to sort out udev issues yourself...the udev rules are appropriate as shipped when using libata as far as I can tell.

Woodsman 04-30-2011 03:06 PM

Quote:

From 13.1's CHANGES_AND_HINTS.TXT and expected to be relevant from here on out. /dev/hd* shouldn't exist, and if it does then you're not using libata (why aren't you using libata?). If you're doing silly things with the kernel then you would be expected to sort out udev issues yourself...the udev rules are appropriate as shipped when using libata as far as I can tell.
Deprecated but not removed. The CONFIG_SCSI_SAS_ATA option is still in the kernel. That udev supports the hd prefix with hard drives but not optical drives is inconsistent. That is not a problem I caused. If udev was consistent then I should not see device nodes for anything hd*, including hard drives.

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? ;)

Alien Bob 04-30-2011 03:21 PM

Quote:

Originally Posted by Woodsman (Post 4342198)
Deprecated but not removed. The CONFIG_SCSI_SAS_ATA option is still in the kernel. That udev supports the hd prefix with hard drives but not optical drives is inconsistent. That is not a problem I caused. If udev was consistent then I should not see device nodes for anything hd*, including hard drives.

You can recompile every piece of Slackware to your liking, but you can not expect that Slackware supports all your changes.
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

Woodsman 04-30-2011 03:56 PM

Quote:

The Slackware distribution allows you to fiddle with the system without penalty, provided that you know what you are doing, and why.
I agree. That there is an inconsistency in the udev rules is not something I caused but discovered. My fiddling is not the point of this discussion. My fiddling unveiled an inconsistency. I wanted to know who to inform.

Quote:

It is unjust to blame Slackware for not supporting the things you want back after they get deprecated.
Where did I blame anybody? I asked whether the omission of the hd prefix from the optical drive rule was something done during Slackware development or upstream from the udev developers.

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.

TigerOC 08-17-2011 04:21 AM

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

Richard Cranium 08-17-2011 04:38 AM

Quote:

Originally Posted by TigerOC (Post 4445336)
Not sure if anyone has solved this but here is what I figured out.

Well the OP did write "I posted the thread as solved."

Quote:

I am running Debian Squeeze[...]
Good for you. I'm not sure why you feel the urge to post in a Slackware forum.

TigerOC 08-17-2011 05:18 AM

Quote:

Originally Posted by Richard Cranium (Post 4445348)
Well the OP did write "I posted the thread as solved."

I would say that this is not a total solution since the original poster is playing with deprecated code and other senior members have pointed this out. My work around is far simpler to implement and understand.


Quote:

Good for you. I'm not sure why you feel the urge to post in a Slackware forum.
I apologise to you for posting in your forum without your specific approval.

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.

Woodsman 08-17-2011 12:36 PM

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.