Yes, that string is the same with the stock kernel. I think its probably Japanese characters. My desktop is running British English, I assume the bare kernel is US English. In either event, the rules look for vendor and product IDs, and these are correctly reported.

It has to be something to do with all those GOTO statements in the rules. I'm going to try commenting them all out, and see what happens.....!

--
Pete

Well, that was simple! It was the very first line: ACTION!="add", GOTO="libsane_rules_end" !

Commenting out that made it all work as it should. The other line:

# For Linux >= 2.6.22 without CONFIG_USB_DEVICE_CLASS=y
# If the following rule does not exist on your system yet, uncomment it
ENV{DEVTYPE}=="usb_device", MODE="0660", OWNER="root", GROUP="root"

could be left either commented or un-commented - it didn't make any difference! I've commented it out again, as that is the default state.

The only remaining questions are why this was happening, and what is the purpose of that first line? I'd be more comfortable knowing, in case there are any knock-on effects!

Bearing in mind that I'm not a programmer, I read that line as meaning "if the action requested is NOT add(device) then go to rules end". But surely, if this file is being called, it must be because a device IS being added!

I'm a little confused here!

--
Pete

referring to the manpage of udev you are right, != means "inequality". I would also have read it as you.

But it could mean something different, namely that the device is not added in the sense of "it is already available". That would match your experience that unpluging/pluging the device works (because then it is added).

Or in other words add refers to "plugged in yet in the moment".

Markus

ACTION==add means a device was connected (or, a new device was detected). ACTION==remove means the device was unplugged. The other action is ACTION==change, which you get when a CD is inserted into a drive, for example.

I can't think why removing the ACTION!="add" line from the rules file would fix it - that is just there to keep the rules from running on REMOVE or CHANGE events. If it was me, to be safest, I would leave it in, and then keep that local rule file for your scanner.

OK, if I had to guess: your scanner detection is resulting in a CHANGE action instead of ADD when you boot your system.

Markus: Thanks for confirming my reading of that line! I'm not sure I understand why it wouldn't detect the device and "add" it during boot.

ljb643: "OK, if I had to guess: your scanner detection is resulting in a CHANGE action instead of ADD when you boot your system." That sort of makes sense, and fits the symptoms, but I don't understand why detect would result in a "change" rather than an "add". The inner workings of the kernel are indeed mysterious, and only truly understood by wizards!

I note your advice to leave the offending line in and stick with my local rule. However, I think that may lead to a conflict if I re-plug the device with the local rule enabled, as both my local rule and the libsanerules would try to "grab" the same device. And since my local rule is lifted verbatim from the libsane rule - but without the "if - but - maybe" statements - then surely the same objection would arise?

This is a bit theoretical now, as I have found a solution that works for me, but I'm interested in understanding why this is happening. Perhaps I can then feed-back the problem *and* suggest a solution that not only works, but I can explain *why* it works!

--
Pete

No, it should be OK. The device isn't 'grabbed' - the rules run to set up the device file(s). As long as your local rule file sorts higher (starts with a number > 80), there will be no problem as your rule file will be applied after.

If your really want to, you could boot the system with a higher level of info messages from udevd. You do this by editing /etc/udev/udev.conf and changing "err" to "info" in the udev_log line. Then reboot and check the system log /var/log/messages or /var/log/syslog. Be prepared to wade through a whole lot of messages, from all devices. The messages will indicate what rules file (and line) were used, and what the rules actually did.

1 members found this post helpful.

Now that is a really useful tip! I've a busy work schedule for the next day or two, but when I get some time, I'll give that a try!

Many thanks!

--
Pete