udev never ever works for me

Dusty · 2008-12-02 00:55:58

Udev is supposed to be so simple, but every time I play with it, I get edgy. Can somebody explain to me (in very very small words;)) why this is happening:

dusty:~ $ ls -l /dev/misc/nvram
crw-r----- 1 root kmem 10, 144 2008-12-01 19:23 /dev/misc/nvram

dusty:~ $ grep nvram /etc/udev/rules.d/00-custom.rules 
KERNEL=="nvram",   NAME="misc/%k", SYMLINK+="%k", GROUP="kmem", MODE="0660"

# I even changed it in arch.rules:
dusty:~ $ grep nvram /etc/udev/rules.d/81-arch.rules 
KERNEL=="nvram",   NAME="misc/%k", SYMLINK+="%k", GROUP="kmem", MODE="0660"

dusty:~ $ sudo udevadm control --reload-rules
dusty:~ $ ls -l /dev/misc/nvram 
crw-r----- 1 root kmem 10, 144 2008-12-01 19:23 /dev/misc/nvram

If you can't see the problem immediately: I'm setting the MODE to 0660 in the udev rules, but the device is getting created with no write permissions for the group. Which is what I want --write permissions for the group.

I grepped the other rules files but nvram isn't set or reset in any of them.

I have a feeling I've overlooked something painfully obvious. Is there a log for this sort of thing?

Dusty

brebs · 2008-12-02 08:34:33

Turn on udev debugging, and see what rules are being applied.

man udevadm

udevadm control command
Modify the internal state of the running udev daemon.
--log_priority=value
Set the internal log level of udevd. Valid values are the numerical
syslog priorities or their textual representations: err, info and
debug.

Dusty · 2008-12-04 16:11:31

Thanks,

I tried that... the log indicates that the permissions are getting set to 640 instead of 660, and then later in the log it says the device already exists so its not going to try again. I don't have the log available right now, but can anyone think why the nvram would be already set?

Thanks,
Dusty

Dusty · 2008-12-04 22:21:38

It looks as though the device is being created before my rules are executed... how can this be?

Dusty wrote:

dusty:log $ sudo grep nvram messages.log | grep "Dec 4"
Dec 4 17:10:58 apoeiro udevadm[5082]: device 0x98ee9c0 has devpath '/class/misc/nvram'
Dec 4 17:10:58 apoeiro udevadm[5082]: device 0x98ee9c0 filled with db symlink data '/dev/nvram'
Dec 4 17:10:47 apoeiro udevd-event[1601]: rule applied, 'nvram' becomes 'nvram'
Dec 4 17:10:47 apoeiro udevd-event[1601]: no db file to read /dev/.udev/db/\x2fclass\x2fmisc\x2fnvram: No such file or directory
Dec 4 17:10:47 apoeiro udevd-event[1601]: mknod(/dev/nvram, 020640, (10,144))
Dec 4 17:10:47 udevd-event[1601]: chmod(/dev/nvram, 020640)
Dec 4 17:10:47 apoeiro udevd-event[1601]: chown(/dev/nvram, 0, 9)
Dec 4 17:10:47 apoeiro udevd-event[1601]: creating index: '/dev/.udev/names/char\x2f10:144/\x2fclass\x2fmisc\x2fnvram'
Dec 4 17:10:47 apoeiro udevd-event[1601]: create db link (nvram char/10:144)
Dec 4 17:10:47 apoeiro udevd-event[1601]: update symlink 'char/10:144' of '/class/misc/nvram'
Dec 4 17:10:47 apoeiro udevd-event[1601]: found '/class/misc/nvram' for 'char/10:144'
Dec 4 17:10:47 udevd-event[1601]: compare (our own) priority of '/class/misc/nvram' 0 >= 0
Dec 4 17:10:47 apoeiro udevd-event[1601]: creating symlink '/dev/char/10:144' to '../nvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: rule applied, 'nvram' becomes 'nvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: found db symlink
Dec 4 17:10:48 udevd-event[2214]: got db link node: 'nvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: removing index: '/dev/.udev/names/nvram/\x2fclass\x2fmisc\x2fnvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: removing index: '/dev/.udev/names/char\x2f10:144/\x2fclass\x2fmisc\x2fnvram'
Dec 4 17:10:48 udevd-event[2214]: creating device node '/dev/nvram', major=10, minor=144, mode=0640, uid=0, gid=9
Dec 4 17:10:48 apoeiro udevd-event[2214]: preserve file '/dev/nvram', because it has correct dev_t
Dec 4 17:10:48 apoeiro udevd-event[2214]: creating index: '/dev/.udev/names/char\x2f10:144/\x2fclass\x2fmisc\x2fnvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: create db link (nvram char/10:144)
Dec 4 17:10:48 apoeiro udevd-event[2214]: creating index: '/dev/.udev/names/nvram/\x2fclass\x2fmisc\x2fnvram'
Dec 4 17:10:48 udevd-event[2214]: update symlink 'char/10:144' of '/class/misc/nvram'
Dec 4 17:10:48 apoeiro udevd-event[2214]: found '/class/misc/nvram' for
'char/10:144'
Dec 4 17:10:48 udevd-event[2214]: compare (our own) priority of '/class/misc/nvram' 0 >= 0
Dec 4 17:10:48 apoeiro udevd-event[2214]: 'char/10:144' with target 'nvram' has the highest priority 0, create it
Dec 4 17:10:48 udevd-event[2214]: found existing symlink '/dev/char/10:144'
Dec 4 17:10:48 apoeiro udevd-event[2214]: preserve already existing symlink '/dev/char/10:144' to '../nvram'

phrakture · 2008-12-05 05:27:56

Check the rules in /usr/lib/udev (or is it /lib/udev?), see if maybe they are munging this

Dusty · 2008-12-08 22:40:04

phrakture wrote:

Check the rules in /usr/lib/udev (or is it /lib/udev?), see if maybe they are munging this

I didn't know there were rules there. That was indeed the problem. Bad udev. Hiding rules all over the place!

Dusty

byte · 2008-12-08 22:46:28

Distros shouldn't invent the wheel over and over again and instead rely on a standard set of Udev rules. That's why they moved to /lib instead of /etc. The latter should only contain distro-specific tweaks.

Arch Linux

#1 2008-12-02 00:55:58

udev never ever works for me

#2 2008-12-02 08:34:33

Re: udev never ever works for me

#3 2008-12-04 16:11:31

Re: udev never ever works for me

#4 2008-12-04 22:21:38

Re: udev never ever works for me

#5 2008-12-05 05:27:56

Re: udev never ever works for me

#6 2008-12-08 22:40:04

Re: udev never ever works for me

#7 2008-12-08 22:46:28

Re: udev never ever works for me

Board footer