[RESOLVED] udev rules are always ignored.

#/etc/udev/rules.d/powersave.rules
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlp4s0", RUN+="/usr/sbin/iw dev %k set power_save on"
I have a simple udev rule like the above, but it's always ignored. Any ideas?
btw, udevadm test can pass.
Thanks.
Last edited by enihcam (2013-07-14 03:55:51)

brebs wrote:
enihcam wrote:KERNEL=="wlp4s0"
I would be suspicious of that. That's a name created by udev rules AIUI, so I would recommend using 91-blah.rules to ensure that the normal rules are processed *first*.
Just match on something easy, like ATTR{address}.
I changed it to KERNEL="wl*", and it works. Thanks!

Similar Messages

Udev rules not applied during bootup

I don't know if this problem is associated with the lates kernel-upgrade to 2.6.21 but I didn't have it before.
My problem:
I have an external USB-harddrive that gets mounted everytime I boot because it is listed in my fstab. To avoid confusion with other external storages (such as USB-sticks etc.) I worte an udev rule for it:
# Externe USB-Festplatte von TrekStor
BUS=="usb", KERNEL=="sd?1" SYSFS{serial}=="307541703010",SYMLINK+="externe"
As I've said this worked well before but now I get a message during the booting process saying that /dev/externe couldn't be found. But it actually IS recognised by udev. I just have to do a
mount -a
after the booting process and everything works again.
Does anyone have an idea what the problem could be? It seems to me that all the devices listed in fstab get mounted before the udev rules are applied.

Ok, I solved my problem: I'm not mounting my USB-HD through fstab anymore. I'm using udev-rules as described here.
Still I'd be interesting to know what went wrong.
Last edited by mata_svada (2007-05-21 05:11:06)

[solved] /etc/udev/rules.d/10-network.rules ignored

Hi.
I have 4 nics (eth0, eth1, eth2, eth3) mapped to MAC addresses in /etc/udev/rules.d/10-network.rules.
Some months ago, I had to symlink /etc/udev/rules.d/80-net-name-slot.rules to /dev/null in order to use these static names.
Now it doesn't work anymore (again and again and again) after a full update (kernel and I assume systemd). The "nic-names" are completely wrong. You call this "predictable". I call this "unpredictable". The only thing which is predictable is that after a kernel update, the network will stop working. It has been that way for months and months ... fortunately I don't update other machines anymore.
Was this non sense really necessary?
Anyway, if you could tell me what to do now to get my network rules applied again, I would really appreciate.
Right now all ethX/MAC are wrong and none of them gets an IP (had to set an IP manually to post here).
* I know what "predictable Network Interface Names" is about. I don't want this bullshit. It's much worse as it used to be. Keep it simple, folks!
Last edited by Agnelo de la Crotche (2013-03-27 07:14:05)

tomegun wrote:To narrow down the problem you are experiencing: What do you mean when you say that the names are "wrong"? Are they still eth0, eth1,... just in the wrong order, or are you actually seeing the "weird" new names given by udev?
To answer this question more precisely.
* with /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and /etc/udev/rules.d/10-network.rules posted earlier (in #4)
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
link/ether 66:64:b3:6a:26:61 brd ff:ff:ff:ff:ff:ff
The rules are ignored.
* after deleting /etc/udev/rules.d/80-net-name-slot.rules
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: enp6s1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
link/ether a2:ee:ec:d1:65:2d brd ff:ff:ff:ff:ff:ff
The rules don't apply.
* with /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and after replacing eth0, eth1, eth2, eth3 with arbitrary names net0, net1, net2, net3 in /etc/udev/rules.d/10-network.rules
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: net1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: net3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: net2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: net0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
link/ether ea:63:09:b7:1b:1b brd ff:ff:ff:ff:ff:ff
But the rules were applied in this case!
It solved the problem described originally. I think I was hit by the race condition after upgrating to kernel 3.8.4-1. This was actually my first 3.8 kernel.
With kernel 3.7, the rules were working even if the devices were named eth0, eth1, etc.
Those names don't work anymore, at least in my case.
Further I created this file for static ips:
# cat /etc/systemd/system/network.service
[Unit]
Description=Wired Static IP Connectivity
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-net0.device
After=sys-subsystem-net-devices-net0.device
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev net0 up
ExecStart=/sbin/ip addr add 192.168.101.9/24 dev net0
ExecStart=/sbin/ip link set dev net1 up
ExecStart=/sbin/ip addr add 192.168.102.9/24 dev net1
ExecStart=/sbin/ip link set dev net2 up
ExecStart=/sbin/ip addr add 192.168.104.9/24 dev net2
ExecStart=/sbin/ip link set dev net3 up
ExecStart=/sbin/ip addr add 192.168.105.9/24 dev net3
ExecStart=/sbin/ip route add default via 192.168.101.1
ExecStop=/sbin/ip addr flush dev net0
ExecStop=/sbin/ip link set dev net0 down
ExecStop=/sbin/ip addr flush dev net1
ExecStop=/sbin/ip link set dev net1 down
ExecStop=/sbin/ip addr flush dev net2
ExecStop=/sbin/ip link set dev net2 down
ExecStop=/sbin/ip addr flush dev net3
ExecStop=/sbin/ip link set dev net3 down
[Install]
WantedBy=multi-user.target
I disabled netcfg and enabled network.service.
Problem is solved now.

Mobile account rules are still being ignored!

We've been running Tiger server for a couple years in combination with mobile accounts for some years now, mostly without significant problems. Since the introduction with Leopard it started giving problems: all rules in the WGM mobile account setup are ignored, it simply syncs the COMPLETE home folder of all Leopard clients. We are a 'music for picture' company, clients have large iTunes libraries and their /Movie folders are also pretty filled up, so data management became really problematic.
I figured that upgrading to Leopard server would solve this problem, so I bought a copy and started testing on a spare Mini Mac. And to my surprise the problem is still there! Syncing a mobile account from a Tiger client is fine, all rules are followed but with Leopard clients the problem still remains.
So what does a proper system administrator do? It starts collecting information from the internet and asks colleagues in the field what their experience is. It comes down (after a few days of research and testing) that I can't find the solution!
My test system:
Mini Mac with Leopard server 10.5.6
Macbook with Leopard client 10.5.6 as a test machine
iMac with Tiger 10.4.11 as test machine
- I create a user in WGM
- I create a group in WGM and give it the proper preferences for syncing
- I assign the user to the group
- I make myself a cup of tea and take a deep breath
- login as the new user and start testing
What I've tried so far to solve it:
- turned around the 'what-to-sync': instead of syncing the home folder (~/) and make rules, I setup exactly what it should sync and no rules. Didn't work, still syncs complete home folder
- delete sync prefs on client machine (/Library/Managed Preferences and .FileSync in home/network folder) restart and login again
- instead of Full Path rules, I've tried to use 'Name' and others. Same problem.
- went to WGM --> Group --> Preferences --> Details and added System/Library/CoreServices/ManagedClient. Edited the com.apple.homeSync so it should work. It didn't.
- started all over again, didn't work.
It still syncs the complete home folder and does not listen to any rule whatsoever. Is there anyone that has any idea what can solve this? Where about to upgrade to a new server with Leopard and I need the mobile accounts for my clients.
Thnx!
Aux

I usually enable this on Computer Groups or the Guest Computer account rather than via workgroups. I don't know if that somehow makes a difference. May be worth switching to this to see if the problems miraculously go away.
Have you enabled the server-side tracking feature in Leopard Server?
You can run the following command for diagnostic purposes:
mcxquery -o <path to where you want it to go>/mcx_export.txt -format xml -user <username> -group <groupname>
You can look at that to see if the Server is doing its job of delivering the MCX correctly to the client for the user and group.

Are /etc/udev/rules.d/86-hpmud* files obsolete?

For a while now, I keep getting the following errors during boot:
Sat Jan 21 14:25:13 2012: udevd[148]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/86-hpmud-hp_laserjet_professional_p1102w.rules:9
Sat Jan 21 14:25:13 2012: udevd[148]: invalid rule '/etc/udev/rules.d/86-hpmud-hp_laserjet_professional_p1102w.rules:9'
... (repeat for every 86-hpmud-* file in that folder)
I found an (ancient) bug report from 2009 with the subject "hplip: obsolete udev rules files are not removed on upgrades", so I assume they're obsolete, but I've only recently starting seeing this problem, which wouldn't jive with a 3-year old issue.
Can I safely delete these files, assuming that their contents has been replaced with entries in the /lib/udev/rules.d tree? I am not that well-versed in udev, unfortunately....

OK - I backed them up and moved them out of /etc/udev/rules.d.
Confirming nothing broke is a bit of a problem right now. Printing is hit & miss from my laptop to my wireless HP P1102w printer at the best of times. I haven't figured out what the real issue is there, but since printing to other HPs works fine, I'll probably have to blame the printer or HPLIP. I wish HP would simplify their software and made simple drivers. I just need to print, I don't need all that hp-toolbox junk. I'll confirm this when I have a chance to print to a different HP printer.

After update Udev rule ignored: loading firmware of HP LJ 1020

Hi all
After one of the latest updates I have a problem with the udev rules. It worked some weeks ago perfectly. But after some updates of the past weeks it seems, that the rules in /etcudev/rules.d/11-hp-lj1020.rules are not triggered anymore. I cannot tell you the precise date as I update my mom's computer via ssh from another country and my mom told me weeks after that the printer is not working any more.
Was there any update of the udev package which is causing problems?
I read some threads and had also the problem, that renaming my network adapters does not work any more.
Issue was that "name" is deprecated in udev.
Best regards
Martin

Potomac wrote:
check these bugreports :
https://bugs.archlinux.org/task/42505
https://bugs.archlinux.org/task/42353
it seems that this bug related to i915 chip ( or intel graphic card ) is fixed in kernel 3.18rc3 mainline ( we can find this kernel package in AUR )
there is also another and complete different bug when we use a kernel 3.17 and even 3.18 ( it's a random bug ) but with a similar effect : boot can hang ( the boot process suddenly stops ) :
https://bbs.archlinux.org/viewtopic.php?id=189622
https://bbs.archlinux.org/viewtopic.php?id=189324
downgrading to kernel 3.16.x is the workaround
I assume my computer is affected by one of these bugs. While I can get to the point where my window manager is loaded, everything almost immediately hangs (but doesn't freeze). Terminal windows become non-responsive and Chromium will refuse input. It's very weird. This happens with both of the 3.17 kernel updates but not in any of the 3.16 releases (including 3.16.7).
This is on an AMD system (cpu/gpu w/ open source driver). Overall 3.17 seems rather buggy.

Udev rules file as an alternative to ASMLib

Grid Version: 11.2.0.3
OS: Oracle Enterprise Linux 6.3
I always wanted to avoid ASMLib. Now we are exploring the use of udev rules file to maintain
1. Ownership of shared LUNs
2. Permissions of shared LUNs.
But, as the below book suggests, udev only provides a way to maintain ownership and permission of LUNs (/dev entries)
How can I make sure that the device names, say /dev/xvda remains same across node reboots ? We have had Linux machines booting up with different /dev names in the past .
http://books.google.com.my/books?id=gbp5AAAAQBAJ&pg=PA144&lpg=PA144&dq=%22ASMLib+that+provides+an+alternative%22&source=bl&ots=6dcIeRfcU9&sig=V-xcAihZiS69LusLTBgEQpTJTOI&hl=en&sa=X&ei=U5ZNUofIBcHZrQeD7YGoCQ&redir_esc=y#v=onepage&q=%22ASMLib%20that%20provides%20an%20alternative%22&f=false

I set ownership of LUNs via the udev multipath rules file as described in Re: Can I use udev rules file for 11.2.0.3 RAC on Oracle Enterprise Linux 6 ?
I use multipath configuration to configure the LUNs as described in Re: Install Oracle 11gr2 2Node RAC on ASM

UDEV rules for Xilinx FPGA devices

I recently purchased a Digilent Nexys3 FPGA board with a Xilinx Spartan 5 FPGA on it. I finally got around to finding some time to using it, and setting up the development environment under Arch linux.
After spending ages reading around about various problems and workarounds, I finally managed to get Xilinx ISE Webpack installed and working, as well as Digilent Adept software for downloading the designs to the development board. One issue still remains though. I am unable to download the designs to the FPGA as a normal user, but only as root.
I'm pretty sure this is a udev rules problem. Digilent supplies a rules file (attached below) which is supposed to grant permissions to all users to access the FPGA devices over USB. I placed this rule file under /etc/udev/rules.d, but I am still unable to access the devices as normal user due to the following error:
$ djtgcfg enum
libusb couldn't open USB device /dev/bus/usb/001/003: Permission Denied.
libusb requires write access to USB device nodes.
$
I believe that udev rules syntax changed since the last time I had a look at it, so maybe the supplied rules file still uses the old syntax? Any suggestions to fixing this rules file (attached below)?
# 52-digilent-usb.rules -- UDEV rules for Digilent USB Devices #
# Author: MTA #
# Copyright 2010 Digilent Inc. #
# File Description: #
# This file contains the rules used by UDEV when creating entries for #
# Digilent USB devices. In order for Digilent's shared libraries and #
# applications to access these devices without root privalages it is #
# necessary for UDEV to create entries for which all users have read #
# and write permission. #
# Usage: #
# Copy this file to "/etc/udev/rules.d/" and execute #
# "/sbin/udevcontrol reload_rules" as root. This only needs to be done #
# immediately after installation. Each time you reboot your system the #
# rules are automatically loaded by UDEV. #
# Revision History: #
# 04/15/2010(MTA): created #
# 02/28/2011(MTA): modified to support FTDI based devices #
# Create "/dev" entries for Digilent device's with read and write
# permission granted to all users.
SYSFS{idVendor}=="1443", MODE="666"
ACTION=="add", SYSFS{idVendor}=="0403", SYSFS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/local/sbin/dftdrvdtch %s{busnum} %s{devnum}"
# The following rules (if present) cause UDEV to ignore all UEVENTS for
# which the subsystem is "usb_endpoint" and the action is "add" or
# "remove". These rules are necessary to work around what appears to be a
# bug in the Kernel used by Red Hat Enterprise Linux 5/CentOS 5. The Kernel
# sends UEVENTS to remove and then add entries for the endpoints of a USB
# device in "/dev" each time a process releases an interface. This occurs
# each time a data transaction occurs. When an FPGA is configured or flash
# device is written a large number of transactions take place. If the
# following lines are commented out then UDEV will be overloaded for a long
# period of time while it tries to process the massive number of UEVENTS it
# receives from the kernel. Please note that this work around only applies
# to systems running RHEL5 or CentOS 5 and as a result the rules will only
# be present on those systems.
Thanks!
-Igor
Last edited by UQ-igor (2011-12-24 03:56:10)

Try this
Use ATTR or ATTRS.
-SYSFS{idVendor}=="1443", MODE="666"
-ACTION=="add", SYSFS{idVendor}=="0403", SYSFS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"
+ATTRS{idVendor}=="1443", MODE="666"
+ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"
+ATTR{idVendor}=="1443", MODE="666"
+ACTION=="add", ATTR{idVendor}=="0403", ATTR{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"

3 unable to open '/etc/udev/rules.d/':m error during booting

After a recent upgrade to the kernel26-2.6.28.5-1-i686, I got the above error during booting in one of the laptop.
My search did not give any positive solution for this till now. I read that now udev gets its rules from /lib/udev/rules.d.
But still rules files in /etc/udev/rules.d and /lib/udev/rules.d are different. I know that any symllink work around will not work in this case, I tried but as expected the error message appears again.
So, I roll back to kernel26-2.6.28.4-1-i686 and everything back to normal.
Any Idea to resolve this? (package is not broken as I use the same mirror for another PC and in that I am not getting any error)
Last edited by kgas (2009-02-19 16:10:23)

This issue got resolved on its own with the latest kernel (kernel26-2.6.28.6-1-i686) update. I will leave this topic for some more time to see others response...

Udev rules and group / permission errors [solved] [outdated]

Latest udev is a miracle to me. It ignores every group ore permission settings. Anyone else having same experiences?
Last edited by Moo-Crumpus (2008-09-29 05:17:40)

Let's assume that you have two files with udev rules. The basic udev.rules and 00.udev.rules (with custom rules).
Udev first reads all rules from 00 file and then rules from the basic file.
This means that if you have a custom rule for a given device you should copy all rules that apply to it from the basic file to the 00 file (not only lines with GROUP). This is because with OPTIONS="last_rule" udev will stop processing rules for this device.
All rules are read and then applied in the order from the top to bottom except SUBSYTEM which is applied as the last rule (kind of held in a buffer). This is the reason why my cd burner /dev/hdc had permissions for disk group and not optical.
This is my 00.udev.rules (it still needs some cosmetic changes but it works and of course I don't have all the devices):
SUBSYSTEM="video4linux", GROUP="users"
SUBSYSTEM="sound", GROUP="users"
SUBSYSTEM="printer", GROUP="users"
SUBSYSTEM="block", GROUP="disk"
BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", SYMLINK="%c{1} %c{2}"
BUS="ide", KERNEL="hdc", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", SYMLINK="nagrywarka dvd cdrw", OPTIONS="last_rule"
BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", OPTIONS="last_rule"
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-floppy.sh %k", RESULT="floppy", NAME{all_partitions}="%k", GROUP="users", OPTIONS="last_rule"
BUS="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
BUS="scsi", KERNEL="sr[0-9]*", SYSFS{type}="5", NAME="scd%n", GROUP="users", OPTIONS="last_rule"
BUS="scsi", KERNEL="sg[0-9]*", SYSFS{type}="5", NAME="%k", GROUP="users", OPTIONS="last_rule"
KERNEL="fd[0-9]*", NAME="fd%n", GROUP="users", SYMLINK="floppy/%n fd%nu1440 fd%nu720 fd%nh1200 fd%nu360", OPTIONS="last_rule"
BUS="usb", SYSFS{serial}="CN16J1Q3HWSX", KERNEL="lp[0-9]*", NAME="usb/%k", GROUP="users", SYMLINK="drukarka_hp_845c drukarka", OPTIONS="last_rule"
BUS="usb", KERNEL="sd*", PROGRAM="/etc/udev/usb-storage.sh %k", RESULT="1", NAME="%k", GROUP="users", OPTIONS="last_rule"
KERNEL="rtc", NAME="misc/%k", SYMLINK="%k", GROUP="users", MODE="0664", OPTIONS="last_rule"
KERNEL="agpgart", NAME="misc/%k", SYMLINK="%k" GROUP="users", OPTIONS="last_rule"
KERNEL="nvidia*", GROUP="users", OPTIONS="last_rule"
KERNEL="fb[0-9]*", NAME="fb/%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="card[0-9]*", NAME="dri/%k", GROUP="users", OPTIONS="last_rule"
KERNEL="3dfx*", NAME="%k", GROUP="users", OPTIONS="last_rule"
KERNEL="dvb*", PROGRAM="/etc/udev/dvb.sh %k", NAME="%c", GROUP="users", OPTIONS="last_rule"
KERNEL="video[0-9]*", NAME="v4l/video%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="users", SYMLINK="radio%e", OPTIONS="last_rule"
KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="controlC[0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="hw[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="pcm[CD0-9cp]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="midi[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="timer", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="seq", NAME="snd/%k", OPTIONS="last_rule"
KERNEL="audio*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="dmmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="admmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="dsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="adsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="midi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="amidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="mixer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="sequencer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
KERNEL="pktcdvd", NAME="pktcdvd/control", GROUP="users", MODE="0660", OPTIONS="last_rule"
KERNEL="pktcdvd[0-9]*", NAME="pktcdvd/pktcdvd%n", GROUP="users", MODE="0660", OPTIONS="last_rule"
The problem with /dev/hdc was that first udev (version 057) was reading a rule from my 00 file (BUS="ide", KERNEL="hdc"...) with GROUP=users. Then it was reading SUBSYSTEM="block", GROUP="disk" rule from the basic file (but it wasn't executed at that time). And then it was reading BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1"... with GROUP=optical. Then it was executing SUBSYTEM rule (hdc is a block device). That's why only disk group had an access to /dev/hdc (with OPTIONS="last_rule" in the basic file in the GROUP="optical" line it would ignore SUBSYSTEM rule).
There are also other rules that you should add (IMO) to your custom rules if you are changing something. In my case it's for example BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k"... which creates symlinks for cd drives. This rule must be above other rules (the number of the symlinks is now unlimited - previously it was 5 IIRC).
So now the rules are mixed together in the lexical order (except SUBSYTEM rules which are executed at the end) unless OPTIONS="last_rule" is used or second (and other) rule has a NAME filed (only one rule for a given device can have NAME filed. Every other rule for the same device with NAME field is ignored IIRC). It also means you can now split rules for a device into several rules - only one of them can have NAME filed and the last should have OPTIONS="last_rule".
Since in your case you have custom rules only for a well defined usb devices (not /dev/sd*) IMO it should work as you think (only add OPTIONS="last_rule").
I hope it's now perfectly clear 8)

Udev rules for a modem

The following udev rule was given to me last February to get a friends dial-up working:
KERNEL=="ttyS[0-9]", NAME=="%k", MODE=="0660", GROUP=="tty", SYMLINK+="modem"
I have just updated the system and I am aware that the udev rules have changed. It is not an area that I usually venture into. What is now needed to achieve a suitable device creation at boot-up to have the modem recognised?
Thanks.

Thanks byte. This got rid of the messages but didn't solve the connection problem I have now reverted back to the orginal options file as this does match the old one. This is really strange. I created a separate partition and rsynced the original Arch install across and updated grub. I then updated one installation and left the other alone just in case I ran into problems. As it happened the upgrade went fine and both old and new installations run fine except the dial-up on neither works I am now beginning to think it might be a problem with the ISP (uklinux.net), but their website does not suggest any status issues.
I went back through the errors.log on the old installation and found that the:
Dec 28 18:27:51 hollowood pppd[3498]: Cannot determine ethernet address for proxy ARP
always occurs and does not stop the connection. I have checked the /etc/rc.conf as I had to make some changes in connecting and disconnecting to my network and have got rid of the other messages that way. There are no other error messages and wvdial runs through the connection and disconnection process perfectly. Is there anything else I could have overlooked or could this be problems with the ISP?

Udev rules or buggy hardware driver?

hello out there,
here's my situation, after setting this rule for my graphics tablet...
KERNEL=="event*", SYSFS{manufacturer}="AIPTEK International Inc.",
NAME="input/aiptektablet", MODE="0644"
i revieve the following on next boot...
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt and you might try running e2fsck with an alternate superblock
E2fsck -b 8193 <device>
after removing the rule and rebooting the drive check goes fine and everything runs smooth again.
note:The idea to remove the aiptek udev rule came when I noticed all udev events in /dev/disk/* pointed to the aiptek tablet instead of their usual sda sdb sdc sdd hda1 hda2 etc.
I would still like a consistent input point for my tablet someday, but this situation seems over my head.
any ideas?
thanks

Thanks for your answer Rexilion.
The author of the module, and the rule, suggest to put the rule in /etc/udev/rules.d under the file name 90-logitech-g710-plus.rules. So that is what I have tried up to now, along with putting the file in /usr/lib/udev/rules.d and changing the preceding number to 10 instead of 90. The only thing that my tinkering has done is that changing ACTION=="add" to ACTION=="add|change" has allowed udevadm trigger to apply the rule. Of course, I could use that to generate some real ugly workaround, but I would rather not. Otherwise, from what I have seen, you are probably right about a race condition, but I have been in the dark as to how to resolve it.
At this point, I have put the rule in /usr/lib/udev/rules.d and used "mkinitcpio -p linux" to rebuild the image, but it doesn't make a difference as to what default rules are in the image. In mkinitcpio.conf, I have the udev hook, but I figure that is kind of defautl, am I to modify that hook? What am I missing? I have read and reread the wiki about udev, and mkinitcpio, but I'm very unclear as to how to add the rule for the keyboard to the default set.
@jasonwryan: Perhaps I'm being stupid, but is loading a module and binding it to the keyboard considered a long running process? I would have thought it is an event which is very short and needs no further attention or resources once it is done.

Front End Runtimes in BI workload are always 0

Hi,
We have activated the technical content for BI Admin cockpit in Production. The delta process chains are
running fine daily. The issue is we do not see the front end runtimes in BI workload via ST03N. Only for a very
few queries we have RSDDSTAT settings activated at level 2. BI workload displays only OLAP and DM times
for those queries. But the frontend times are always 0. We are extracting all the step categories. I can see
the front end runtimes for all those queries in 0TCT_C01, but they are not shown in BI workload. Hence even
the Total Time of the query in BI workload is always smaller as it does not include the front end runtimes.
Any idea why the data for front end runtimes is missing from BI workload ?
Thanks,
Sonali

Hi,
depending on your data flow you have to use the routines .
Start routines - start routines:
It is used to perform preliminary calculations.if you have any modifications required before the actual transformation is done, then you must write those routines in the start routine of 7.0.
End routines - new:
You can use an end routine to postprocess data after transformation on a package-by-package basis.
Expert routine - update routine :
You can use the expert routine if there are not sufficient functions to perform a transformation. The expert routine should be used as an interim solution until the necessary functions are available in the standard routine. You can use this to program the transformation yourself without using the available rule types. If you have already created transformation rules, the system deletes them once you have created an expert routine.
Also Check the below link for detail info.
Routine in Transformation.
Reg
Pra

[SOLVED] udev rule no longer working

I have a udev rule set up to automatically mount an ext4 filesystem when I plug a certain thumb drive in. It was working fine until yesterday (probably due to updates). Here is the rule, in file /etc/udev/rules.d/99-gfk.rules:
KERNEL=="sd?2", SUBSYSTEM=="block", ATTRS{idVendor}=="0930", ATTRS{idProduct}=="6545", ATTRS{serial}=="1C6F654E4041ED601910053F", SYMLINK+="gfshare"
ACTION=="add", KERNEL=="sd?2", SUBSYSTEM=="block", ATTRS{idVendor}=="0930", ATTRS{idProduct}=="6545", ATTRS{serial}=="1C6F654E4041ED601910053F", RUN+="/bin/mkdir /media/gfshare"
ACTION=="add", KERNEL=="sd?2", SUBSYSTEM=="block", ATTRS{idVendor}=="0930", ATTRS{idProduct}=="6545", ATTRS{serial}=="1C6F654E4041ED601910053F", RUN+="/bin/mount -t ext4 -o ro,nosuid,nodev,noexec,noatime /dev/gfshare /media/gfshare"
The symlink and the mkdir command are both working fine, but the mount command is not being run for some reason. If I manually run the mount command it works fine. Some possibly helpful output:
# pacman -Qo $(which udevadm)
/usr/bin/udevadm is owned by systemd 212-1
# dmesg |tail -16
[26458.120628] usb 7-1.3: new high-speed USB device number 7 using ehci-pci
[26458.223059] usb-storage 7-1.3:1.0: USB Mass Storage device detected
[26458.223825] scsi10 : usb-storage 7-1.3:1.0
[26459.311607] scsi 10:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 4
[26460.834081] sd 10:0:0:0: [sdd] 15240576 512-byte logical blocks: (7.80 GB/7.26 GiB)
[26460.834931] sd 10:0:0:0: [sdd] Write Protect is off
[26460.834935] sd 10:0:0:0: [sdd] Mode Sense: 23 00 00 00
[26460.835617] sd 10:0:0:0: [sdd] No Caching mode page found
[26460.835621] sd 10:0:0:0: [sdd] Assuming drive cache: write through
[26460.839455] sd 10:0:0:0: [sdd] No Caching mode page found
[26460.839460] sd 10:0:0:0: [sdd] Assuming drive cache: write through
[26460.860579] sdd: sdd1 sdd2
[26460.867111] sd 10:0:0:0: [sdd] No Caching mode page found
[26460.867115] sd 10:0:0:0: [sdd] Assuming drive cache: write through
[26460.867118] sd 10:0:0:0: [sdd] Attached SCSI removable disk
[26461.041982] EXT4-fs (sdd2): mounted filesystem with ordered data mode. Opts: (null)
# udevadm test /sys/bus/usb/devices/7-1.3
calling: test
version 212
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
load module index
timestamp of '/etc/systemd/network' changed
timestamp of '/usr/lib/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context
timestamp of '/etc/udev/rules.d' changed
Skipping overridden file: /usr/lib/udev/rules.d/80-net-setup-link.rules.
read rules file: /usr/lib/udev/rules.d/10-dm.rules
read rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules
read rules file: /etc/udev/rules.d/12-android.rules
read rules file: /usr/lib/udev/rules.d/13-dm-disk.rules
read rules file: /usr/lib/udev/rules.d/40-hpet-permissions.rules
read rules file: /usr/lib/udev/rules.d/40-usb-media-players.rules
read rules file: /usr/lib/udev/rules.d/42-usb-hid-pm.rules
read rules file: /usr/lib/udev/rules.d/50-firmware.rules
read rules file: /usr/lib/udev/rules.d/50-udev-default.rules
read rules file: /usr/lib/udev/rules.d/51-android.rules
read rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules
read rules file: /usr/lib/udev/rules.d/60-drm.rules
read rules file: /usr/lib/udev/rules.d/60-keyboard.rules
read rules file: /usr/lib/udev/rules.d/60-pcmcia.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-input.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-serial.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
read rules file: /usr/lib/udev/rules.d/60-vboxdrv.rules
read rules file: /usr/lib/udev/rules.d/61-accelerometer.rules
read rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules
read rules file: /usr/lib/udev/rules.d/64-btrfs.rules
read rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules
read rules file: /usr/lib/udev/rules.d/69-cd-sensors.rules
read rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules
read rules file: /usr/lib/udev/rules.d/69-libmtp.rules
read rules file: /usr/lib/udev/rules.d/70-infrared.rules
read rules file: /usr/lib/udev/rules.d/70-power-switch.rules
read rules file: /usr/lib/udev/rules.d/70-uaccess.rules
read rules file: /usr/lib/udev/rules.d/71-seat.rules
read rules file: /usr/lib/udev/rules.d/73-seat-late.rules
read rules file: /usr/lib/udev/rules.d/75-net-description.rules
read rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules
read rules file: /usr/lib/udev/rules.d/75-tty-description.rules
read rules file: /usr/lib/udev/rules.d/78-sound-card.rules
read rules file: /usr/lib/udev/rules.d/80-drivers.rules
read rules file: /etc/udev/rules.d/80-net-setup-link.rules
read rules file: /usr/lib/udev/rules.d/80-udisks.rules
read rules file: /usr/lib/udev/rules.d/80-udisks2.rules
read rules file: /usr/lib/udev/rules.d/85-usbmuxd.rules
read rules file: /usr/lib/udev/rules.d/90-alsa-restore.rules
read rules file: /usr/lib/udev/rules.d/95-cd-devices.rules
read rules file: /usr/lib/udev/rules.d/95-dm-notify.rules
read rules file: /usr/lib/udev/rules.d/95-udev-late.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-dell.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-gateway.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-ibm.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-lenovo.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-toshiba.rules
read rules file: /usr/lib/udev/rules.d/95-upower-csr.rules
read rules file: /usr/lib/udev/rules.d/95-upower-hid.rules
read rules file: /usr/lib/udev/rules.d/95-upower-wup.rules
read rules file: /etc/udev/rules.d/99-gfk.rules
read rules file: /usr/lib/udev/rules.d/99-systemd.rules
read rules file: /usr/lib/udev/rules.d/kino.rules
rules contain 98304 bytes tokens (8192 * 12 bytes), 22360 bytes strings
10092 strings (88570 bytes), 8317 de-duplicated (67986 bytes), 1776 trie nodes used
IMPORT builtin 'usb_id' /usr/lib/udev/rules.d/50-udev-default.rules:9
IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:9
MODE 0664 /usr/lib/udev/rules.d/50-udev-default.rules:37
GROUP 1002 /usr/lib/udev/rules.d/51-android.rules:387
MODE 0660 /usr/lib/udev/rules.d/51-android.rules:387
RUN '/usr/share/virtualbox/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass} vboxusers' /usr/lib/udev/rules.d/60-vboxdrv.rules:6
PROGRAM '/usr/lib/udev/mtp-probe /sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3 7 7' /usr/lib/udev/rules.d/69-libmtp.rules:1204
starting '/usr/lib/udev/mtp-probe /sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3 7 7'
'/usr/lib/udev/mtp-probe /sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3 7 7'(out) '0'
'/usr/lib/udev/mtp-probe /sys/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3 7 7' [24644] exit with return code 0
IMPORT builtin 'path_id' /usr/lib/udev/rules.d/71-seat.rules:43
RUN 'uaccess' /usr/lib/udev/rules.d/73-seat-late.rules:15
handling device node '/dev/bus/usb/007/007', devnum=c189:774, mode=0660, uid=0, gid=1002
preserve permissions /dev/bus/usb/007/007, 020660, uid=0, gid=1002
preserve already existing symlink '/dev/char/189:774' to '../bus/usb/007/007'
ACTION=add
BUSNUM=007
DEVNAME=/dev/bus/usb/007/007
DEVNUM=007
DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_DRIVE_THUMB=1
ID_FOR_SEAT=usb-pci-0000_00_1a_7-usb-0_1_3
ID_MODEL=DataTraveler_2.0
ID_MODEL_ENC=DataTraveler\x202.0
ID_MODEL_FROM_DATABASE=Kingston DataTraveler 102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
ID_MODEL_ID=6545
ID_PATH=pci-0000:00:1a.7-usb-0:1.3
ID_PATH_TAG=pci-0000_00_1a_7-usb-0_1_3
ID_REVISION=0100
ID_SERIAL=Kingston_DataTraveler_2.0_1C6F654E4041ED601910053F
ID_SERIAL_SHORT=1C6F654E4041ED601910053F
ID_USB_INTERFACES=:080650:
ID_VENDOR=Kingston
ID_VENDOR_ENC=Kingston
ID_VENDOR_FROM_DATABASE=Toshiba Corp.
ID_VENDOR_ID=0930
MAJOR=189
MINOR=774
PRODUCT=930/6545/100
SUBSYSTEM=usb
TAGS=:seat:uaccess:
TYPE=0/0/0
USEC_INITIALIZED=26452326568
adb_user=yes
run: '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 774 00 vboxusers'
run: 'uaccess'
unload module index
Unloaded link configuration context
# udevadm test /sys/bus/usb/devices/7-1.3:1.0
calling: test
version 212
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
load module index
timestamp of '/etc/systemd/network' changed
timestamp of '/usr/lib/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context
timestamp of '/etc/udev/rules.d' changed
Skipping overridden file: /usr/lib/udev/rules.d/80-net-setup-link.rules.
read rules file: /usr/lib/udev/rules.d/10-dm.rules
read rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules
read rules file: /etc/udev/rules.d/12-android.rules
read rules file: /usr/lib/udev/rules.d/13-dm-disk.rules
read rules file: /usr/lib/udev/rules.d/40-hpet-permissions.rules
read rules file: /usr/lib/udev/rules.d/40-usb-media-players.rules
read rules file: /usr/lib/udev/rules.d/42-usb-hid-pm.rules
read rules file: /usr/lib/udev/rules.d/50-firmware.rules
read rules file: /usr/lib/udev/rules.d/50-udev-default.rules
read rules file: /usr/lib/udev/rules.d/51-android.rules
read rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules
read rules file: /usr/lib/udev/rules.d/60-drm.rules
read rules file: /usr/lib/udev/rules.d/60-keyboard.rules
read rules file: /usr/lib/udev/rules.d/60-pcmcia.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-input.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-serial.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
read rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
read rules file: /usr/lib/udev/rules.d/60-vboxdrv.rules
read rules file: /usr/lib/udev/rules.d/61-accelerometer.rules
read rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules
read rules file: /usr/lib/udev/rules.d/64-btrfs.rules
read rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules
read rules file: /usr/lib/udev/rules.d/69-cd-sensors.rules
read rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules
read rules file: /usr/lib/udev/rules.d/69-libmtp.rules
read rules file: /usr/lib/udev/rules.d/70-infrared.rules
read rules file: /usr/lib/udev/rules.d/70-power-switch.rules
read rules file: /usr/lib/udev/rules.d/70-uaccess.rules
read rules file: /usr/lib/udev/rules.d/71-seat.rules
read rules file: /usr/lib/udev/rules.d/73-seat-late.rules
read rules file: /usr/lib/udev/rules.d/75-net-description.rules
read rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules
read rules file: /usr/lib/udev/rules.d/75-tty-description.rules
read rules file: /usr/lib/udev/rules.d/78-sound-card.rules
read rules file: /usr/lib/udev/rules.d/80-drivers.rules
read rules file: /etc/udev/rules.d/80-net-setup-link.rules
read rules file: /usr/lib/udev/rules.d/80-udisks.rules
read rules file: /usr/lib/udev/rules.d/80-udisks2.rules
read rules file: /usr/lib/udev/rules.d/85-usbmuxd.rules
read rules file: /usr/lib/udev/rules.d/90-alsa-restore.rules
read rules file: /usr/lib/udev/rules.d/95-cd-devices.rules
read rules file: /usr/lib/udev/rules.d/95-dm-notify.rules
read rules file: /usr/lib/udev/rules.d/95-udev-late.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-dell.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-gateway.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-ibm.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-lenovo.rules
read rules file: /usr/lib/udev/rules.d/95-upower-battery-recall-toshiba.rules
read rules file: /usr/lib/udev/rules.d/95-upower-csr.rules
read rules file: /usr/lib/udev/rules.d/95-upower-hid.rules
read rules file: /usr/lib/udev/rules.d/95-upower-wup.rules
read rules file: /etc/udev/rules.d/99-gfk.rules
read rules file: /usr/lib/udev/rules.d/99-systemd.rules
read rules file: /usr/lib/udev/rules.d/kino.rules
rules contain 98304 bytes tokens (8192 * 12 bytes), 22360 bytes strings
10092 strings (88570 bytes), 8317 de-duplicated (67986 bytes), 1776 trie nodes used
IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11
RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb7/7-1/7-1.3/7-1.3:1.0
DEVTYPE=usb_interface
DRIVER=usb-storage
ID_MODEL_FROM_DATABASE=Kingston DataTraveler 102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
ID_VENDOR_FROM_DATABASE=Toshiba Corp.
INTERFACE=8/6/80
MODALIAS=usb:v0930p6545d0100dc00dsc00dp00ic08isc06ip50in00
PRODUCT=930/6545/100
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=452326811
run: 'kmod load usb:v0930p6545d0100dc00dsc00dp00ic08isc06ip50in00'
unload module index
Unloaded link configuration context
Last edited by bentglasstube (2014-04-03 20:51:36)

I see. That is somewhat aggravating but I will find another way to achieve what I wanted I suppose.
Thank you. Should I mark this is solved or unsolvable or something? Sorry, I'm new to posting on these forums.
Edit: I was able to achieve what I wanted with udevil as recommended by the wiki.
Last edited by bentglasstube (2014-04-03 20:55:45)

Rules are not working correctly in OCS 10.1.2

Hi,
A few days ago we have encountered a problem in which the BCC rules or any other rules are not processed out of the user's mailbox.
For example, a user goes to Oracle Mail (the web access, but not WAC), goes to Filters and creates a new rule for dealing with incoming mail (delivered or read, doesn't matter). The rule is processed ONLY if the the user asked to move/copy the mail to a subfolder IN HIS MAILBOX.
If the user asks to forward ("Send a blind copy to") the delivered mails to a different mailbox (e.g. in OCS or to externally to gmail), the mail is NOT processed by the filter.
Other than that mails are treated normally, incoming and outgoing. Manually forwarding to other OCS users also works, as well as forwarding to external mail systems such as gmail. Only the 'automatic' forward rule does not work.
We have checked that the rules/filters are created with " oesrl -p" - and they are created.
How can we troubleshoot this issue? Has anyone encountered it?
System details:
OCS 10.1.2
Platform: Red Hat AS 4
DB version: 10.1.0.4.2
Thanks,
-- Itay.

Update:
Problem resolved. restarted the SMTP-out service.

[RESOLVED] udev rules are always ignored.

Similar Messages

Maybe you are looking for