SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I am trying to use and understand udev. Running Slackware 10.2 with 2.6.15 kernel, in a shell atm.
Firstly, my /dev directory is populated with a whole stack of devices. I understood that with udev only devices in use are shown here. I have not created any udev rules. The only rules that exist are the ones that the slack 10.2 install put there.
This query seems similar to this thread , in which Yalla-One, the orginal poster, seemed to have a similar problem. However, he seemed satisfied with a response that seemed to say that out of the box udev rules will generate pretty much the same number of /dev nodes as devfs, but this doesn't gel with me.
From the first post in this thread (again), I get the same output as Yalla-One to
ps -ef | grep -i udev
, except that I don't have "--daemon" tacked on the end of my output. Not sure if that's significant, but I like to lay out as many cards as I know I have.
My /etc/rc.d/rc.udev file is executable. (-rwxr-xr-x )
Despite this first problem, I press on in an attempt to write rules, following the highly recommended guide Writing udev rules This guide is great - I've read it several times and (think) I've learnt a lot from it.
When I plug in my digital camera, dmesg tells me it is /dev/sda1. I can verify this by mounting it, and viewing the contents. (I then umount it, but keep it plugged in/on, etc).
Now, my second problem is that when I go
udevinfo -q path -n /dev/sda1
I get "device not found in database". (Same result for just "sda", without the 1). According to "Writing udev rules" (and man udev), this should tell me the device path for the digital camera. Nevertheless, I see from the examples in the guide that the device path for /dev/sda is likely to be "/sys/block/sda". So I try
udevinfo -a -p /sys/block/sda
to get the SYSFS info on the camera, and it works. I don't get why one works and the other doesn't. My gut feeling here is that the /dev/sda1 node is not being created or "run" by udev, either at all, or not properly. Apart from that thought, I'm clueless.
In summary, my problems are:
I still don't really understand why all those nodes are in /dev when udev is running.
1. I still don't really understand why all those nodes are in /dev when udev is running.
2. I don't understand why "udevinfo -q path -n /dev/sda1" isn't working.
1) There are a lot of devices in use at any time: disk drives, cpu, rtc, pci cards, printers, mouse, keyboard, monitor, built-in sound, built-in nic, and so on. Some of them contain features that become devices of their own. Is there something in particular you're wondering about?
2) Did you try the command after connecting the camera, without mounting it, and especially without unmounting it?
I've taken a different approach to colecting the udevinfo, for usb devices anyway. I did read the same guide, several times in fact (printed it even), to learn how to access the information and create the rules. I found that a file called /proc/bus/usb/devices contains the information in a human-readable format. If you open the file in a text reader and match the vendor name and/or model name you'll find the rest of the information that goes with that device. And each device is in seperate sections so you don't get them mixed up.
If you look at /var/log/packages/devs-2.3.1-noarch-22 (or whatever version you have) you will see that a load of devices are installed to /dev.
Although the notes refer to slack 11, it is interesting to read the section on devs here:
I assume that this list of devices is installed so that the system will still work even if udev is not running (maybe also so that some important devices exist before udev runs).
Now udev will install devices according to the rules in /etc/udev/rules.d, but it will not remove stuff that is already there.
Slackware 11 makes much more use of udev than previous versions, but I think what I have said holds true for 10.2
Thanks dracolich & tobyl for your responses. In answer to your queries / suggestions:
I am no longer really concerned about all the nodes appearing in /dev. I took this to be part of my problem, but it's not.
I have tried the command before mounting, during mounting, and after umounting. I don't feel it should make a difference, because device node management operates at a lower level to filesystem mounting. But I've tried ... a lot.
Thanks for the tip on getting more info for rule creation. I'm sure it'll be useful once I get over this hurdle.
After much reading and experimentation, I've come to understand my problem better, and feel it'd be best to re-summarise in different terms:
When I plug in a usb mass storage device, it is immediately identified, and the nodes /dev/sda and /dev/sda1 are created (likewise they are removed when the device is unplugged). Because I'm running udevd, and have no other /dev/sd?* nodes, this sounds like udev has placed the node.
BUT: udev doesn't seem to know about the device. I can prove this either by:
udevinfo -q path -n /dev/sda1
results in "device not found in database"
udevinfo -d | grep /dev/sda1
results in a blank.
To summarise my summary: If udev isn't placing the /dev/sda* nodes, what is, and why?
This is no longer about finding information to write rules - this is about understanding how these nodes are being managed outside of udev, and how to fix it.
Apart from a possible typo, this guy seemed to have exactly the same problem.
if it works on your system, try it with your device.
I will also say though, that slack 11 (if rc.udev is executable and kernel =2.6.15 or later) will take over from hotplug entirely, but before that, ie on a 10.2 slack installation, device management is shared in some way between hotplug & udev (i think)
With every kernel event a /sbin/hotplug process was started. That process invoked a script in the /etc/hotplug/*.agent directory, selected by the subsystem the kernel has passed with the event. These agents scripts possibly loaded modules or prepared the device for userspace to use.
The problem is solved. Many thanks to all of you who posted on this thread. No single post gave me the answer, but gave me things to try, and most importantly, things to read. The solution, as it always is, is simple. My udev version was too old for 2.6.15 kernel (or at least I think that's what the problem was).
I had: udev-064-i486-2.tgz (Slackware 10.2)
I upgraded to: udev-100-i486-2kjz.tgz (from www.linuxpackages.net)
Problem solved (except that I had to add a "start" argument after the udev invocation line in /etc/rc.d/rc.S).
Words cannot express my temporary feelings of competence.
[edit: grammar rulz, ok?]
Last edited by BeerIsGood; 10-14-2006 at 09:41 PM.
Actually how do I know if udev is running? how do I know if hotplug is running? ps aux|grep udev shows nothing in my system.
Is that proof that my sytem doesn't run udev?
How to enable udev?
If udev enabled? should the hotplug must be disabled?
How do i know which is being used in my system?
Since you have upgraded to udev-097, you should use the /rc.d/rc.udev that was written for it, which should be the rc.udev.new file you showed us. So as root
mv rc.udev rc.udev.old
mv rc.udev.new rc.udev
your original rc.udev was not exectutable, so it would not have started udev.
reboot, and run your ps command again.
the new rc.udev script runs a couple of sanity checks, eg 'is the kernel greater than 2.6.15?'
if all is well, udev will disable hotplug and take over, so it will not make any difference whether rc.hotplug is executable or not.
While you are there, check for other .new files in /etc/rc.d, and modify in the same way as above
you will probably get everything working ok without writing you own rules, the only common exception to that is if you have more than one network card, but you can fix that in /etc/udev/rules.d/network-devices.rules
edit: you must also make sure that your own kernel config has got tmpfs enabled, udev needs this.