Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#9935 - hlplip - HP USB printer not detected after last udev update(s)

Attached to Project: Arch Linux
Opened by David Spicer (azleifel) - Monday, 24 March 2008, 21:11 GMT
Last edited by Greg (dolby) - Monday, 21 July 2008, 22:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan de Groot (JGC)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No



As a consequence of one or the other of the last two udev updates, 118-5 -> 118-7 or 118-7 -> 119-1, (sorry for the lack of precision but the last time I used my printer was a week ago) my HP Photosmart D6160 USB printer was no longer being detected, i.e. there was no device node in /dev/bus/usb. The first fix I tried, which was to edit /etc/udev/rules.d/55-hpmud.rules and change every instance of SYSFS to ATTRS in line with the udev changes information in readme-udev-arch.txt, worked.

Additional info:
* hplip 2.8.2-2

Steps to reproduce: Just trying to print.
This task depends upon

Closed by  Greg (dolby)
Monday, 21 July 2008, 22:47 GMT
Reason for closing:  Fixed
Comment by David Spicer (azleifel) - Wednesday, 26 March 2008, 21:47 GMT
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.
Comment by Bartosz Kwitniewski (Zerg2000) - Friday, 28 March 2008, 15:41 GMT
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"
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.
Comment by Alexey (Alexey_RU) - Monday, 31 March 2008, 08:51 GMT
The same problem too. Every time I want to print something, I run /etc/start_udev
Comment by Alexey (Alexey_RU) - Monday, 31 March 2008, 08:53 GMT
udev 119-1 (base)
Comment by Rodrigo Dutra (SysDump) - Wednesday, 09 April 2008, 11:51 GMT
The same problem here. Only be able to print after run /etc/start_udev
Comment by Alexander Kaltsas (firewalker) - Wednesday, 09 April 2008, 12:45 GMT
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.
Comment by Aaron Griffin (phrakture) - Wednesday, 09 April 2008, 17:47 GMT
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.
Comment by Jan de Groot (JGC) - Wednesday, 09 April 2008, 17:59 GMT
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.
Comment by Bartosz Kwitniewski (Zerg2000) - Wednesday, 09 April 2008, 18:58 GMT
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).

- udev starts up (/etc/start_udev) ==> rule matches
- udev is running => matching by ATTR{idVendor} and SYSFS{idVendor} is broken, rule does not match
Comment by Bartosz Kwitniewski (Zerg2000) - Wednesday, 09 April 2008, 19:31 GMT
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.
Comment by Jan de Groot (JGC) - Wednesday, 09 April 2008, 20:38 GMT
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.
Comment by Bartosz Kwitniewski (Zerg2000) - Wednesday, 09 April 2008, 21:30 GMT
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.
Comment by Steven S (mintcoffee) - Monday, 14 April 2008, 21:10 GMT
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.
Comment by solsTiCe (zebul666) - Tuesday, 15 April 2008, 22:07 GMT
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"
Comment by Miguel (buo) - Sunday, 20 April 2008, 18:25 GMT
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.
Comment by Michael Towers (gradgrind) - Friday, 25 April 2008, 06:02 GMT
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.

Comment by Aaron Griffin (phrakture) - Friday, 25 April 2008, 15:04 GMT
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
Comment by Michael Towers (gradgrind) - Friday, 25 April 2008, 18:26 GMT
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).
Comment by Michael Towers (gradgrind) - Friday, 25 April 2008, 19:31 GMT
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.
Comment by Aaron Griffin (phrakture) - Friday, 25 April 2008, 19:36 GMT
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
Comment by solsTiCe (zebul666) - Saturday, 26 April 2008, 08:42 GMT
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.
Comment by Thomas Bächler (brain0) - Sunday, 27 April 2008, 07:17 GMT
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;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.
Comment by Will Smith (Factory) - Monday, 05 May 2008, 15:05 GMT
Similar problem when trying to import photos from a Digital Camera (Kodak Easyshare dx6340)."Fixed" when following these instructions:
Comment by solsTiCe (zebul666) - Sunday, 25 May 2008, 11:12 GMT
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.
Comment by Michael Towers (gradgrind) - Sunday, 25 May 2008, 12:15 GMT
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).
Comment by David Spicer (azleifel) - Sunday, 25 May 2008, 18:23 GMT
Since the update to initscripts-2008.05-1 (and kernel25 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!)
Comment by Greg (dolby) - Monday, 21 July 2008, 15:28 GMT
Whats the status of this? Is it solved?
Comment by Bartosz Kwitniewski (Zerg2000) - Monday, 21 July 2008, 22:31 GMT
WorksForMe (tm)