Something strange. Rules (in 90-local.rules) containing KERNEL=="", DRIVER=="", SYMLINK+="" or KERNEL=="", PROGRAM=="", SYMLINK+="" (I badly need these to transform to static the /dev/input/eventX devices, here are examples: KERNEL=="event*", DRIVER=="wacom", SYMLINK+="input/tablet" KERNEL=="event*", PROGRAM=="/etc/udev/scripts/evremote.sh %k", SYMLINK+="input/remote" ) Won't work at boot time (first time, no soft-reboot). After boot time doin an #udevstart or a softreboot cause these rules to work. Reproducible: Always Steps to Reproduce: 1.put these kind of rules in 90-local.rules 2.shutdown (no reboot) and wait 5 minutes 3.restart computer, check symlinks are not there. Do udevstart and then symlinks appear!
Oooops, seems to be already fixed in 0.68-r1, sorry if I bothered.
Ok, marking as fixed.
argh.... I'm really idiot, someway I re-turned on my computer too early. 0.68-r1 didn't fixed that (although I'm using unstable baselayout, if someone can try similar rules on standard baselayout I would thanks...)
I don't understand, what is wrong? What do you expect to see happen? What is happening? What is the output of running 'udevtest' with the device node you are trying to create?
Just these kind of rules don't apply at first boot. (after a shutdown and 5-10 minutes waiting). Symlinks will not appear,so no "static devices". If AFTER TURNING ON, from the shell, I do from root: #udevstart these rules apply fine.
# udevtest /dev/input/remote input main: looking at device '/dev/input/remote' from subsystem 'input' main: sysfs_open_class_device_path failed # udevtest /dev/input/volito input main: looking at device '/dev/input/volito' from subsystem 'input' main: sysfs_open_class_device_path failed
This report is a but confusing: You miss the symlinks created by udev for input devices, right? You expect "/dev/input/tablet" and "/dev/input/remote". Both are missing after reboot but get created by udevstart, right? After reboot and the links missing (don't run udevstart!), how does: ls -l /sys/class/input look like? For every eventX, what does: udevinfo -a -p /class/input/eventX print? Same for udevtest. What does: udevtest /class/input/eventX input print?
udev-0.69 partially solevd: (PROGRAM== kind of rules seems to work, note that I also know a workaround for DRIVER== rule, but in the form given below this won't work right at present time) ------------------------------------------------------------------------- USING RULES: KERNEL=="event*", DRIVER=="wacom", SYMLINK+="input/tablet" KERNEL=="event[2-9]", PROGRAM=="/etc/udev/scripts/evremote.sh %k", SYMLINK+="input/remote" RESULT (remote symlink is created, tablet not): ls -l /sys/class/input totale 0 drwxr-xr-x 2 root root 0 15 set 01:31 event0 drwxr-xr-x 2 root root 0 15 set 01:31 event1 drwxr-xr-x 2 root root 0 15 set 01:30 event2 drwxr-xr-x 2 root root 0 15 set 01:31 event3 drwxr-xr-x 2 root root 0 15 set 01:30 mice drwxr-xr-x 2 root root 0 15 set 01:31 mouse0 drwxr-xr-x 2 root root 0 15 set 01:31 mouse1 udevinfo -a -p /class/input/event2 udevinfo starts with the device the node belongs to and then walks up the device chain, to print for every device found, all possibly useful attributes in the udev key format. Only attributes within one device section may be used together in one rule, to match the device for which the node will be created. device '/sys/class/input/event2' has major:minor 13:66 looking at class device '/sys/class/input/event2': KERNEL=="event2" SUBSYSTEM=="input" SYSFS{dev}=="13:66" udevinfo -a -p /class/input/event3 udevinfo starts with the device the node belongs to and then walks up the device chain, to print for every device found, all possibly useful attributes in the udev key format. Only attributes within one device section may be used together in one rule, to match the device for which the node will be created. device '/sys/class/input/event3' has major:minor 13:67 looking at class device '/sys/class/input/event3': KERNEL=="event3" SUBSYSTEM=="input" SYSFS{dev}=="13:67" follow the "device"-link to the physical device: looking at the device chain at '/sys/devices/pci0000:00/0000:00:10.1/usb3/3-2/3-2:1.0': BUS=="usb" ID=="3-2:1.0" DRIVER=="wacom" SYSFS{bAlternateSetting}==" 0" SYSFS{bInterfaceClass}=="03" SYSFS{bInterfaceNumber}=="00" SYSFS{bInterfaceProtocol}=="02" SYSFS{bInterfaceSubClass}=="01" SYSFS{bNumEndpoints}=="01" SYSFS{modalias}=="usb:v056Ap0060d0141dc00dsc00dp00ic03isc01ip02" looking at the device chain at '/sys/devices/pci0000:00/0000:00:10.1/usb3/3-2': BUS=="usb" ID=="3-2" DRIVER=="usb" SYSFS{bConfigurationValue}=="1" SYSFS{bDeviceClass}=="00" SYSFS{bDeviceProtocol}=="00" SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8" SYSFS{bMaxPower}==" 40mA" SYSFS{bNumConfigurations}=="1" SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0141" SYSFS{bmAttributes}=="80" SYSFS{configuration}=="" SYSFS{devnum}=="2" SYSFS{idProduct}=="0060" SYSFS{idVendor}=="056a" SYSFS{manufacturer}=="WACOM" SYSFS{maxchild}=="0" SYSFS{product}=="FT-0405-UV1.4-1" SYSFS{speed}=="1.5" SYSFS{version}==" 1.10" looking at the device chain at '/sys/devices/pci0000:00/0000:00:10.1/usb3': BUS=="usb" ID=="usb3" DRIVER=="usb" SYSFS{bConfigurationValue}=="1" SYSFS{bDeviceClass}=="09" SYSFS{bDeviceProtocol}=="00" SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8" SYSFS{bMaxPower}==" 0mA" SYSFS{bNumConfigurations}=="1" SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0206" SYSFS{bmAttributes}=="e0" SYSFS{configuration}=="" SYSFS{devnum}=="1" SYSFS{idProduct}=="0000" SYSFS{idVendor}=="0000" SYSFS{manufacturer}=="Linux 2.6.13-gentoo-r1 uhci_hcd" SYSFS{maxchild}=="2" SYSFS{product}=="VIA Technologies_ Inc. VT82xxxxx UHCI USB 1.1 Controller _#2_" SYSFS{serial}=="0000:00:10.1" SYSFS{speed}=="12" SYSFS{version}==" 1.10" looking at the device chain at '/sys/devices/pci0000:00/0000:00:10.1': BUS=="pci" ID=="0000:00:10.1" DRIVER=="uhci_hcd" SYSFS{class}=="0x0c0300" SYSFS{device}=="0x3038" SYSFS{irq}=="11" SYSFS{local_cpus}=="1" SYSFS{modalias}=="pci:v00001106d00003038sv00001458sd00005004bc0Csc03i00" SYSFS{subsystem_device}=="0x5004" SYSFS{subsystem_vendor}=="0x1458" SYSFS{vendor}=="0x1106" looking at the device chain at '/sys/devices/pci0000:00': BUS=="" ID=="pci0000:00" DRIVER=="unknown" udevtest /class/input/event2 input main: looking at device '/class/input/event2' from subsystem 'input' main: opened class_dev->name='event2' udev_rules_get_name: rule applied, 'event2' becomes 'input/event2' run_program: '/etc/udev/scripts/evremote.sh event2' run_program: '/etc/udev/scripts/evremote.sh' returned with status 0 udev_rules_get_name: add symlink 'input/remote' create_node: creating device node '/dev/input/event2', major = '13', minor = '66', mode = '0600', uid = '0', gid = '0' create_node: creating symlink '/dev/input/remote' to 'event2' udevtest /class/input/event3 input main: looking at device '/class/input/event3' from subsystem 'input' main: opened class_dev->name='event3' udev_rules_get_name: rule applied, 'event3' becomes 'input/event3' udev_rules_get_name: add symlink 'input/tablet' run_program: '/etc/udev/scripts/evremote.sh event3' run_program: '/etc/udev/scripts/evremote.sh' returned with status 1 create_node: creating device node '/dev/input/event3', major = '13', minor = '67', mode = '0600', uid = '0', gid = '0' create_node: creating symlink '/dev/input/tablet' to 'event3' -----------------------------------------------------------------------------
(I forgot to explain myself: my workaround for DRIVER== rule is just to not use DRIVER== but SYSFS{}== .....)
Maybe a sysfs timing issue. Does adding this rule anywhere before your DRIVER rule makes it work? KERNEL="input*", BUS=="usb", WAIT_FOR_SYSFS="device/driver"
nope, didn't fixed. Also 0.70 re-introduce the issue also for PROGRAM== rule.
Is "evdev" a module or compiled in? If it's a module, does "rmmod evdev" "modprobe evdev" create the nodes? What does "udevmonitor --env" print when loading the module? Does compiling evdev into the kernel fix it?
evdev is a module. However normal rules for event* work fine (so the module is present when symlinks should be created), doin rmmod evdev will result in a "module in use" error.
I was just caught by a crazy idea..... remote rule seems to return working if I move it from odd line to even line in rule file (starting to count from the first uncommented line). Are we sure that every line of custom rule file (90-local.rules in my case) are processed???
Try 077 udev release and the latest kernel version please.