On Linux startup, when udevd is starting, I get two errors of the form: udevd-events[PID-#]: missing file parameter for attr which appears to be generated by udevd while processing the /etc/udev/rules.d files - "70-hpmud.rules" and perhaps "71-hpmud_support". Reproducible: Always Steps to Reproduce: 1. emerge udev-141-r1 2. emerge hplip-3.9.4b-r1 3. shutdown and reboot linux Actual Results: Early in the initialization process, when udevd is being started the errors mentioned above are generated. The errors themselves are difficult to diagnose unless one changes the setting in /etc/udev/udev.conf from udev_log="err" to udev_log="info". Expected Results: Hplip devices should be created properly without generating error messages. *And* error messages should be "clear", indicating what files may be causing the error if it involves a syntax error in a file (my rules.d directory contains 17+ rules files). I would consider fixing this bug if I knew how the udev rules worked, but feel that is better done by someone who really understands them. There are at least 5 bugs in the udev/syslog-ng/openrc packages that this points out: 1) Udevd will produce cryptic / non-useful errors when rules files are not properly formatted. 2) There is no "debug" USE option to enable passing "--enable-debug" to the udev configuration file so udevd can be compiled with debugging information. If one wants a "debug" version of udevd one has to compile the sources by hand. 3) The standard syslog-ng configuration file do not have a "udevd" processing option so one can dump udevd errors into their own file. 4) Openrc is not configured to allow udev error logging (the udev init.d file does not require syslog-ng to be started before udev). 5) There is a chicken and egg problem between when udevd is started ans when syslog-ng is started. To log udevd errors, one needs syslog-ng. But if syslog-ng is on a mountable "/var" file system, one needs udevd to run and create the file system devices (/dev/sda?) *before* syslog-ng is started. A temporary solution is to allow syslog-ng to log udev errors into /root/udev.log but one normally dumps log messages onto /var rather than /root is because it may have more space available -- and given the volume of error that using udev_log="debug" will generate one *needs* a lot of space. It is impossible to debug udevd in debug/info mode if one leaves the output on stderr due to the sheer volume and production rate of the messages. And *yes* I do know that I should file 3-5 more bug reports on these topics but given the number of hours I've spent figuring out this much already, I'll leave it up to any readers as to whether they wish to do that (since the bugs may well be pushed to different upstream development individuals). The errors are showing up when dealing with a HP Color LaserJet 2605dn through the USB link though I don't think that has much to do with the core problem.
Can you please test if newer versions especially hplip-3.9.8-r2 fix your problem.
The problem still exists with hplip-3.9.12-r1 udev-145 on my amd64 system. The error messages appear when my HP Laserjet is switched on.
(In reply to comment #2) > The problem still exists with > > hplip-3.9.12-r1 > > udev-145 > > on my amd64 system. > > The error messages appear when my HP Laserjet is switched on. > Do you get the same results with and without USE udev-acl enabled? I am asking because this flag installs different udev rules.
I get the same result. Does this have something to do with extended attributes? The following two commands produce no output: getfattr -d /etc/udev/rules.d/40-hplip.rules getfattr -d /etc/udev/rules.d/56-hpmud_support.rules
(In reply to comment #4) > I get the same result. > > Does this have something to do with extended attributes? > > The following two commands produce no output: > > getfattr -d /etc/udev/rules.d/40-hplip.rules > > getfattr -d /etc/udev/rules.d/56-hpmud_support.rules > There is also no output for me. I can not reproduce such behavior, everything is fine here. There are no "udevd-events" messages in my syslog, no errors reported by "udevadm monitor" even when running udev with the "--debug-trace --debug" options. I would be very glad if someone experiencing this problems would open an upstream bug pointing to this bug here.
I've the same issue with hplip 3.9.12-r1 and 3.10.2*
just upgraded hplip from 2.8.6b to hplip-3.9.12-r1 on amd64. Have the same issue. When starting USB printer (hp lj 1300) the following error appears in log: Mar 22 22:10:55 vl udevd-work[3165]: missing file parameter for attr I've looked into changes in udev.d and saw that 70-hpmud.rules (small enough) was replaced with huge 55-hpmud.rules 56-hpmud_support.rules. The bad thing is that i got also non-working printer and following error: Mar 22 22:18:11 vl hp[5813]: prnt/backend/hp.c 839: ERROR: null print job total=0
The problem is (at least on my system) the line starting with "ATTRS" in "/etc/udev/rules.d/56-hpmud_support.rules": # Check for LaserJet products (0x03f0xx17). ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??17", ENV{hp_model}="$attrs{product}", ENV{hp_test}="yes" I commented it out, which made the error messages disappear. My printer doesn't need any plugins, so this is safe for me to do. "hp-mkuri -c" would print out a message on the console whether a plugin is required or optional for "hp_model".
Does replacing the following line ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??17", ENV{hp_model}="$attrs{product}", ENV{hp_test}="yes" in 56-hpmud_support.rules with ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??17", RUN+="/bin/sh -c 'hp_model=%E{ID_MODEL} /usr/bin/hp-mkuri -c &'" fix the problem?
(In reply to comment #9) > Does replacing the following line > > ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??17", > ENV{hp_model}="$attrs{product}", ENV{hp_test}="yes" > > in 56-hpmud_support.rules with > > ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??17", RUN+="/bin/sh -c > 'hp_model=%E{ID_MODEL} /usr/bin/hp-mkuri -c &'" > > fix the problem? > A patch which includes above fix is in hplip-3.10.2-r2 and above. Please report if this did fix the issue so we can close this bug or need to investigate further.
A version which is supposed to fix this issue is in the tree since over two months. Without feedback there is nothing I can do.
