Anne Wilson wrote:
On Friday 19 January 2007 16:00, Roberto Malinverni wrote:
Our strategies seem to be different. You wrote a rule file with a high
number, so that it is the last to be parsed and nothing *should* interfere
with it. I wrote a rule file with a low number, so that it is parsed at the
beginning excluding every interference from other scripts.
The sintax for the option I mentioned is IIRC:
OPTIONS="last_rule"
The string as to be appended, after the usual comma, at the end of a given
rule. This prevents that other rules are parsed against the same device.
Other interesting info about what is involved in the process of creating
devices are here:
http://www.fedoraforum.org/forum/showthread.php?t=103665&highlight=udev+bla
c k+magic
http://www.fedoraforum.org/forum/showpost.php?p=668532&postcount=4
Sorry if I can't be of more help.
The second one is the 'meat' from the first one. Interesting, though.
I tried the suggestion in there, and from then on the symlink failed to be
created at all :-)
Anne
Several things about this bother me.
The first is that the symlink for the DC10 (or whatever) thingy
was pointing to hard drives. But your rule clearly had a
match of KERNEL=="video*" and there should be no way that a
hard drive has a kernel name of video anything. Therefore, your
rule should not be creating symlinks to hard drives.
Now you say that when you made udev stop processing at the end
of your rules produced no symlink seems to suggest that something
other than your rules are creating the symlinks.
I'll pose a "wild hypothesis". But you'll need to do some testing
to see if it "holds water" as they say. I am going to suggest that
one of the udev rules, most likely one that matches hard drives,
also uses the PROGRAM or the RUN option to run a program or script.
Is it possible that one of the standard programs or scripts run
by udev has somehow become corrupt, or you've named your own
script the same as the standard script, and it's directory
occurs earlier in the PATH list, or something like that?
I still state that this is a "wild" hypothesis, and the problem
likely lies elsewhere. Still, if you exhaust all other hypotheses,
than this one may be true. (Sherlock Holmes said something like
that in one of Conan Doyle's stories.)
Someone else will need to help us out here. I think that there
is some way to do testing of udev to see what programs it runs,
either in the PROGRAM or the RUN options. Then you could do
a check to see if there were any spurious programs with the same
names, or even if the standard programs had been overwritten by
something.
