Arch Linux

A little extra information: From a cold boot with the original 55-hpmud.rules installed and the printer either switched on or powered but switched off (actually this is just standby) the printer is not detected and will not switch itself on like it should if I send a print job. The printer will, however, be detected if I run /etc/start_udev from a terminal. If I switch to the modified 55-hpmud.rules with ATTRS substituted for SYSFS throughout then the printer is detected from a cold boot even if it is switched to standby and switches itself on normally when I send a print job.

I have same problem here. Udev is unable to find match by ATTR{idVendor}/SYSFS{idVendor} after system is up and running. Matching by ATTR{idProduct}, ATTR{serial}, ATTR{product} works fine but ATTR{idVendor} does not so all rules using idVendor are broken.

Rule that matches my printer:
ATTR{idVendor}=="03f0", ATTR{idProduct}=="5611", OWNER="root", GROUP="lp", MODE="0666"

Here is what I do:
1. Turn on printer
2. Turn on computer
3. "ls -l /dev/bus/usb/002/..." returns "crw-rw-rw- 1 root lp 189, 150 (...)"
4. Turn off printer
5. Turn on printer.
6. "ls -l /dev/bus/usb/002/..." returns "crw-r--r-- 1 root root 189, 151 (...)"
7. Turn off printer
8. Change udev rule from:
ATTR{idVendor}=="03f0", ATTR{idProduct}=="5611", OWNER="root", GROUP="lp", MODE="0666"
To:
ATTR{idProduct}=="5611", OWNER="root", GROUP="lp", MODE="0666"
9. udevadm control --reload_rules
10. Turn on printer
11. "ls -l /dev/bus/usb/002/..." returns "crw-rw-rw- 1 root lp 189, 152 (...)"

I've checked out attributes with "udevinfo --attribute-walk --name=/dev/bus/usb/(...)" and ATTR{idVendor} is displayed correctly there.

Matching by other attributes like ATTR{idProduct}, ATTR{serial}, ATTR{product} works, only ATTR{idVendor} is broken (but it does work during bootup). Permissions for /dev/usbdev* are always set correctly, only permissions for /dev/bus/usb/* are affected.

The same problem too. Every time I want to print something, I run /etc/start_udev

udev 119-1 (base)

The same problem here. Only be able to print after run /etc/start_udev

Same problem here. Only able to print after running /etc/start_udev or having the printer turned on before udev starts during boot up process.

So are there two separate issues here, or just one? I see 2 suggestions that the rule is wrong, and two suggestions that simply restarting udev works fine.

I have been fighting with my printer last weekend too, took me an hour to find out what was wrong here.
In the end, just replacing SYSFS with ATTRS in the rules file and reloading with udevadm worked for me.

Rule for my printer is correct if I execute /etc/start_udev, but it does not work when udev is running (unless I remove ATTR{idVendor} from it).

So:
- udev starts up (/etc/start_udev) ==> rule matches
- udev is running => matching by ATTR{idVendor} and SYSFS{idVendor} is broken, rule does not match

Erm, sorry, it is more complicated, again:

1. If printer is online during system boot, rule matches.
2. If printer is online during system boot, and I turn it off and on later, rule does not match anymore.
3. If printer is offline during system boot, and I turn it on later, rule does not match.
4. If printer is offline during system boot, and I turn it on later, and there is no ATTR{idVendor} in that rule, rule matches.
5. If printer is offline during system boot, and I execute /etc/start_udev later, turn on printer, rule matches and everything is ok, matching by ATTR{idVendor} works.

You're all talking about ATTR{idVendor}, but in my case using ATTRS{idVendor} works. Mind the extra S, don't know if it makes any difference.

ATTR/ATTRS/SYSFS - neighter of them matches if there is idVendor parameter. From what I can see on IRC, there are similar problems in other distributions (testing branches) so it is probably something in udev itself. I do not have older copy of udev in pacman cache so I can't tell in which version it broke. :/ I'll compile older udev to check it out when I have time.

I having this problem with udev, but not with a scanner instead of a printer. When plugging in my printer (Canoscan N670U) after system startup, the /dev/bus/usb/xxx directory is not part of the scanner group. If I execute /etc/start_udev again, then the correct group permissions are set.

SYSFS has changed to ATTRS in udev since 0.98
isn't it the cause of the problem because 55-hpmud.rules use SYSFS instead of ATTRS ?

i notice the problem because i couldn't print.
the permission on /dev/usbdev2.6 are correct
crw-rw-rw- 1 root lp
but they are wrong for /dev/bus/usb/002/006
crw-r--r-- 1 root root
when i change them to
crw-rw-r-- 1 root lp
the printer begin to print the jobs that were in the queue and that couldn't be printed because of the permission problem

i have a photosmart C3180
ATTRS{idVendor}=="03f0" ATTRS{idProduct}=="5611"

Just adding my 0.02 here. I have an HP Photosmart 8250 that also stopped working after a recent upgrade. hp-toolbox saw the printer, but print jobs were failing -- the printer ignored anything sent to it, even by root. hp-toolbox reported a "communications problem".

Eventually I tracked the problem to the printer device (under /dev/usb/00x/00y) having permissions set to 440 and owner set to root:root.

I peeked in /etc/udev/rules.d and found hpmud.rules. I was unable to get udev to set the right permissions until I replaced the whole rules file with:

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="c202", GROUP:="lp", MODE:="0660"

Note that it still works with SYSFS, and that I used := instead of just = after GROUP and MODE. c202 is the id of my printer. HTH track down and solve the problem.

I think I might have found the problem here, or at least part of it, thanks to a forum post by tuxom. In /lib/initcpio/udev/start_udev in the klibc-udev package, there is the line (87):

echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug

The -e option doesn't work with the klibc shell! Removing the '-e' (and rebuilding the initramfs) seems to solve the problem (at least with my camera and printer), i.e.:

echo '\000\000\000\000' > /proc/sys/kernel/hotplug

Maybe this error was masked in the past because start_udev was called again from /etc/rc.sysinit, which in the latest initscripts package is no longer the case.

hmmm, that's a good catch. However, echoing the literal "\000" four times is different than a null byte 4 times. We should try and use printf for this instead, I think

Ah, yes, you're right, sort of - echo '\000' apparently doesn't echo a null byte, but it also doesn't echo a literal'\000'. I just tested it and it echoed nothing at all, just a newline! This shell has very confusing behaviour with backslashes ...

But printf seems to work predictably, so that's a good suggestion. 'printf "\0\0\0\0\n"' outputs four null bytes followed by a newline (assuming that's what is wanted).

Actually, is there any reason why null bytes need to be written to /proc/sys/kernel/hotplug? I haven't been able to find any info on this, and in my little test an 'echo "" >/proc/sys/kernel/hotplug' seemed to be enough.

Not sure, that may be an old paradigm that we've just stuck with. Adding Thomas to the ticket as he might be able to answer that part better

if i remember well /proc/sys/kernelhotplug contains the name of the hotplug program to run when an event occurs. By default, this is /sbin/hotplug.
This was used for hotplugging before udev could do it or before the use of udev in 2.4 kernel.

i guess this is not needed now. but echo "" into it mgiht be enoguh
I see no reason to try to do complicated stuff like 4 zeros or null bytes.... unless there is a good reason for it. but i doubt.

I can't find anything on that, but clearing out /proc/sys/kernel/hotplug seems to fix several udev problems (Pierre was actually able to reproduce it). I guess the NULL bytes are not needed, so I'll change that commit to make more sense http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=521d7678cecb3018923f7c869bc8a5f74dc29268

About the original problem: Do we have the right (new) udev syntax in there now? SYSFS has been deprecated for quite a while in favor of ATTR and ATTRS.

Similar problem when trying to import photos from a Digital Camera (Kodak Easyshare dx6340)."Fixed" when following these instructions: http://bbs.archlinux.org/viewtopic.php?pid=361451#p361451

any progress on that bug ?
it is a simple fix. (echo "") and i am using it for some time without any side effect.

but i see more and more people complaining about their printer not working ... and not knowing why.

initscripts-2008.05-1 has 'echo > /proc/sys/kernel/hotplug' in /etc/rc.sysinit, which should fix this problem (although klibc-udev still has the bug).

Since the update to initscripts-2008.05-1 (and kernel25 2.6.25.4-1 etc.) everything still works but the time to process UDev uevents at boot has doubled from 3s to 6s. I've look in the logs for anything new but the only udev-related entries are the ones that always turn up:

May 25 19:14:01 darkstar udevd[1170]: lookup_user: specified user 'lp' unknown
May 25 19:14:02 darkstar udevd-event[1392]: node_symlink: rename(/dev/fb.udev-tmp, /dev/fb) failed: Is a directory

(I'd love to know why user 'lp' is unknown - she definitely exists!)

Whats the status of this? Is it solved?

WorksForMe (tm)