udev rule doesn't use /bin/sh -c echo... in opensuse tumbleweed

Hi, I upgraded my 12.2 opensuse to 13.1 and included the tumbleweed repo (all in one step). All is perfect, except from a slight problem. I’ve got an mceusb (hauppauge), which was working perfectly well previously. I’ve got a udev rule that assigns it a static name and echoes ‘lirc’ as the protocol it uses for mythtv.

The first part of the rule is still working great, the symlink gets created, but the second line apparently doesn’t run, because I have to use the echo command by hand after reboots.
The rule file is called 10-lirc-mceusb.rules and it contains
KERNEL==“lirc[0-9]*”, ATTRS{idVendor}==“0609”, SYMLINK+=“lirc_mceusb”
SUBSYSTEM==“rc”, ATTRS{protocols}==“lirc” RUN+="/bin/sh -c ‘echo lirc > /sys/$env{DEVPATH}/protocols’"

rpm -qa | grep udev

udev-configure-printer-1.4.2-2.4.1.x86_64
udev-208-19.1.x86_64
libudev0-182-5.1.2.x86_64
libudev-devel-208-19.1.x86_64
udevmountd-0.81.5-30.1.x86_64
libudev1-208-19.1.x86_64
libgudev-1_0-0-208-19.1.x86_64
python-pyudev-0.16.1-25.4.noarch

The udevadm info -a -p $(udevadm info -q path -n /dev/lirc0) for the device is:

looking at device ‘/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc1/lirc0’:
KERNEL==“lirc0”
SUBSYSTEM==“lirc”
DRIVER==""

looking at parent device ‘/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc1’:
KERNELS==“rc1”
SUBSYSTEMS==“rc”
DRIVERS==""
ATTRS{protocols}==“rc-5 nec rc-6 jvc sony sanyo mce_kbd [lirc]”

looking at parent device ‘/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0’:
KERNELS==“2-3:1.0”
SUBSYSTEMS==“usb”
DRIVERS==“mceusb”
ATTRS{bInterfaceClass}==“ff”
ATTRS{bInterfaceSubClass}==“ff”
ATTRS{bInterfaceProtocol}==“ff”
ATTRS{bNumEndpoints}==“02”
ATTRS{supports_autosuspend}==“0”
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}==“00”

looking at parent device ‘/devices/pci0000:00/0000:00:02.0/usb2/2-3’:
KERNELS==“2-3”
SUBSYSTEMS==“usb”
DRIVERS==“usb”
ATTRS{bDeviceSubClass}==“00”
ATTRS{bDeviceProtocol}==“00”
ATTRS{devpath}==“3”
ATTRS{idVendor}==“0609”
ATTRS{speed}==“12”
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}==“1”
ATTRS{bMaxPacketSize0}==“8”
ATTRS{busnum}==“2”
ATTRS{devnum}==“2”
ATTRS{configuration}==""
ATTRS{bMaxPower}==“100mA”
ATTRS{authorized}==“1”
ATTRS{bmAttributes}==“a0”
ATTRS{bNumConfigurations}==“1”
ATTRS{maxchild}==“0”
ATTRS{bcdDevice}==“0100”
ATTRS{avoid_reset_quirk}==“0”
ATTRS{quirks}==“0x0”
ATTRS{serial}==“PA100707131807G”
ATTRS{version}==" 2.00"
ATTRS{urbnum}==“11052”
ATTRS{ltm_capable}==“no”
ATTRS{manufacturer}==“SMK CORPORATION”
ATTRS{removable}==“unknown”
ATTRS{idProduct}==“0334”
ATTRS{bDeviceClass}==“00”
ATTRS{product}==“MCE TRANCEIVR Emulator Device 2006”

looking at parent device ‘/devices/pci0000:00/0000:00:02.0/usb2’:
KERNELS==“usb2”
SUBSYSTEMS==“usb”
DRIVERS==“usb”
ATTRS{bDeviceSubClass}==“00”
ATTRS{bDeviceProtocol}==“00”
ATTRS{devpath}==“0”
ATTRS{idVendor}==“1d6b”
ATTRS{speed}==“12”
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}==“1”
ATTRS{bMaxPacketSize0}==“64”
ATTRS{authorized_default}==“1”
ATTRS{busnum}==“2”
ATTRS{devnum}==“1”
ATTRS{configuration}==""
ATTRS{bMaxPower}==“0mA”
ATTRS{authorized}==“1”
ATTRS{bmAttributes}==“e0”
ATTRS{bNumConfigurations}==“1”
ATTRS{maxchild}==“10”
ATTRS{bcdDevice}==“0314”
ATTRS{avoid_reset_quirk}==“0”
ATTRS{quirks}==“0x0”
ATTRS{serial}==“0000:00:02.0”
ATTRS{version}==" 1.10"
ATTRS{urbnum}==“53”
ATTRS{ltm_capable}==“no”
ATTRS{manufacturer}==“Linux 3.14.4-31.g0de0f93-desktop ohci_hcd”
ATTRS{removable}==“unknown”
ATTRS{idProduct}==“0001”
ATTRS{bDeviceClass}==“09”
ATTRS{product}==“OHCI PCI host controller”

looking at parent device ‘/devices/pci0000:00/0000:00:02.0’:
KERNELS==“0000:00:02.0”
SUBSYSTEMS==“pci”
DRIVERS==“ohci-pci”
ATTRS{irq}==“23”
ATTRS{subsystem_vendor}==“0x1458”
ATTRS{broken_parity_status}==“0”
ATTRS{class}==“0x0c0310”
ATTRS{enabled}==“1”
ATTRS{consistent_dma_mask_bits}==“32”
ATTRS{dma_mask_bits}==“32”
ATTRS{local_cpus}==“00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003”
ATTRS{device}==“0x0454”
ATTRS{msi_bus}==""
ATTRS{local_cpulist}==“0-1”
ATTRS{vendor}==“0x10de”
ATTRS{subsystem_device}==“0x5004”
ATTRS{numa_node}==“0”
ATTRS{d3cold_allowed}==“1”

looking at parent device ‘/devices/pci0000:00’:
KERNELS==“pci0000:00”
SUBSYSTEMS==""
DRIVERS==""

Has there been any change in the RUN+ command syntax?
Thanks in advance for any help.

As those that know more about Tumbleweed lurk in the Tumbleweed forum (which we created specialy for the Tumbleweed lovers), your thread will be moved there and is CLOSED for the moment.

BTW, can you please wrap your computer output between CODE tags when you post them? It is the # button in the tool bar of the post editor.

Moved from Hardware and open again.

Hi,

Seeing you got no reaction until now, I will try to throw in my two cents. But bear with me: I am not a Tumbleweed user and I have very limited knowledge about udev rules.

But one thing drew my attention:

/bin/sh -c 'echo lirc > /sys/$env{DEVPATH}/protocols'

I have no idea what $env{DEVPATH} evaluates into, but the /sys (and /proc and friends) usage and definitions seem to chance some time from Kernel version to Kernel version. Are you sure this still functions with the Kernel you have at the moment?

Hi, Henk, and thanks for your answer. The $env{DEVPATH} evaluates into “/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc1”, and everything is actually working. The problem was that there is a built-in udev rule in /usr/lib/udev/rules.d/70-infrared.rules that was running after my 10-… rule and it was affecting the protocol. I solved it by renaming mine to 99-… and I got lirc working again.

Either the 70-infrared rule is new or there is a change in the sequence the built in and user rules are executed, because before upgrading I had no trouble after (the rare) reboots.

Yianni.

Nice you solved it. Enjoy openSUSE.