Understanding & Using udev
 

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 , 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
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 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:

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.

I do feel (after trawling through reams of threads on udev) that my lack of understanding of these issues is shared by at least a few LQers.

Troubleshooting Update
 

Firstly, I'm now certain that the allocation of the /dev/sda and /dev/sda1 device nodes is not being handled by udev. This is because a does not list any alloction to /dev/sd*.

Also, here is the tail of my dmesg after I plug in the camera, which is then put straight to /dev/sda1:

Clearly, I have not given up trying to work this through, however, I'd love some help.

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:

http://www.slackware.com/announce/changes11.0.php

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

tobyl

Thanks dracolich & tobyl for your responses. In answer to your queries / suggestions:

1. 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.
2. 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.
3. 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:

1. Code:

   ---

   udevinfo -q path -n /dev/sda1

   ---

   results in "device not found in database"
2. Code:

   ---

   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.

Hi BeerIsGood

I am also a long way from understanding how udev works, but I found something interesting.
On my system running (as root)

udevmonitor

shows what udev is doing. Here is the output I got when I plugged a usb joystick in and then removed it:

# udevmonitor
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]

UEVENT[1160823584.687907] add@/devices/pci0000:00/0000:00:10.3/usb4/4-1
UDEV [1160823584.688745] add@/devices/pci0000:00/0000:00:10.3/usb4/4-1
UEVENT[1160823584.694948] add@/devices/pci0000:00/0000:00:10.3/usb4/4-1/4-1:1.0
UEVENT[1160823584.719952] add@/class/input/input3
UEVENT[1160823584.719987] add@/class/input/input3/js0
UEVENT[1160823584.726058] add@/class/usb_device/usbdev4.3
UDEV [1160823584.752977] add@/devices/pci0000:00/0000:00:10.3/usb4/4-1/4-1:1.0
UDEV [1160823584.774780] add@/class/input/input3
UDEV [1160823584.779570] add@/class/usb_device/usbdev4.3
UDEV [1160823584.780784] add@/class/input/input3/js0
UEVENT[1160823653.516632] remove@/class/input/input3/js0
UEVENT[1160823653.516671] remove@/class/input/input3
UEVENT[1160823653.516686] remove@/devices/pci0000:00/0000:00:10.3/usb4/4-1/4-1:1.0
UEVENT[1160823653.516700] remove@/class/usb_device/usbdev4.3
UEVENT[1160823653.516714] remove@/devices/pci0000:00/0000:00:10.3/usb4/4-1
UDEV [1160823653.517665] remove@/class/input/input3/js0
UDEV [1160823653.519027] remove@/devices/pci0000:00/0000:00:10.3/usb4/4-1/4-1:1.0
UDEV [1160823653.520536] remove@/class/usb_device/usbdev4.3
UDEV [1160823653.521561] remove@/class/input/input3
UDEV [1160823653.522518] remove@/devices/pci0000:00/0000:00:10.3/usb4/4-1

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)

from
http://vrfy.org/log/recent-state-of-udev.html
tobyl

Solved!
 

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?]

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?

My slackware has 2 rc.udev
Is udev rules must be written by user?not generated automatically?
Just skimmed "writing udev rules". Little bit mind-boggled..

I use slackware 10.2 , my-own-config kernel 2.6.17.8 , udev-097 package installed.
I'm still confused about udev, let alone HAL and DBUS...

Tnx. Sorry if too many question...

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

cd /etc/rc.d
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

tobyl

edit: you must also make sure that your own kernel config has got tmpfs enabled, udev needs this.