LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-30-2011, 12:09 AM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 04-30-2011, 12:48 AM   #2
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,574

Rep: Reputation: 463Reputation: 463Reputation: 463Reputation: 463Reputation: 463
What does...
Code:
cat /proc/scsi/scsi
...give?
 
Old 04-30-2011, 11:21 AM   #3
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Same thing as does the lsscsi command.

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. . . .
 
Old 04-30-2011, 12:27 PM   #4
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
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
 
Old 04-30-2011, 03:47 PM   #5
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 04-30-2011, 03:54 PM   #6
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,297

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
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.
 
Old 04-30-2011, 04:06 PM   #7
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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?
 
Old 04-30-2011, 04:21 PM   #8
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,379

Rep: Reputation: Disabled
Quote:
Originally Posted by Woodsman View Post
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
 
Old 04-30-2011, 04:56 PM   #9
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 08-17-2011, 05:21 AM   #10
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
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
 
Old 08-17-2011, 05:38 AM   #11
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,574

Rep: Reputation: 463Reputation: 463Reputation: 463Reputation: 463Reputation: 463
Quote:
Originally Posted by TigerOC View Post
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.
 
Old 08-17-2011, 06:18 AM   #12
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
Quote:
Originally Posted by Richard Cranium View Post
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.
 
Old 08-17-2011, 01:36 PM   #13
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Original Poster
Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sym links and hard links akudewan Linux - Newbie 4 02-09-2005 06:08 AM
sym links -- RealPlayer lmellen Linux - Newbie 2 08-29-2004 03:29 PM
Dead sym links Hangdog42 Linux - General 5 10-02-2003 05:35 AM
Sym Links and vsFTPd Datacraft Linux - Software 1 05-24-2003 06:20 PM
dead sym links dewcansam Linux - General 1 02-08-2002 05:49 PM


All times are GMT -5. The time now is 09:02 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration