[Bug 609424] New: Error in udev rules for hplip package
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c0 Summary: Error in udev rules for hplip package Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: i686 OS/Version: openSUSE 11.1 Status: NEW Severity: Minor Priority: P5 - None Component: Printing AssignedTo: jsmeix@novell.com ReportedBy: dgersic@niu.edu QAContact: jsmeix@novell.com Found By: --- Blocker: --- User-Agent: Opera/9.80 (X11; Linux i686; U; en) Presto/2.2.15 Version/10.10 /etc/udev/rules.d/55-hpmud.rules The rules in this file use OWNER="root", GROUP="lp" which doesn't work correctly with kernel 2.6.27.45-0.1-pae. The result is seen in /var/log/messages as: May 27 06:51:47 linux kernel: usb 2-2: new full speed USB device using uhci_hcd and address 3 May 27 06:51:48 linux kernel: usb 2-2: configuration #1 chosen from 1 choice May 27 06:51:48 linux kernel: usb 2-2: New USB device found, idVendor=03f0, idProduct=4811 May 27 06:51:48 linux kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 May 27 06:51:48 linux kernel: usb 2-2: Product: PSC 1600 series May 27 06:51:48 linux kernel: usb 2-2: Manufacturer: HP May 27 06:51:48 linux kernel: usb 2-2: SerialNumber: MY5AGF229PL0 May 27 06:51:48 linux kernel: usblp0: USB Bidirectional printer dev 3 if 1 alt 0 proto 2 vid 0x03F0 pid 0x4811 May 27 06:51:48 linux kernel: usbcore: registered new interface driver usblp May 27 06:51:48 linux kernel: Initializing USB Mass Storage driver... May 27 06:51:48 linux kernel: scsi4 : SCSI emulation for USB Mass Storage devices May 27 06:51:48 linux kernel: usbcore: registered new interface driver usb-storage May 27 06:51:48 linux kernel: USB Mass Storage support registered. May 27 06:51:48 linux kernel: usb-storage: device found at 3 May 27 06:51:48 linux kernel: usb-storage: waiting for device to settle before scanning May 27 06:51:48 linux kernel: ppdev0: registered pardevice May 27 06:51:48 linux hp: io/hpmud/pp.c 627: unable to read device-id ret=-1 May 27 06:51:48 linux kernel: ppdev0: unregistered pardevice May 27 06:51:49 linux kernel: scsi 4:0:0:0: Direct-Access HP PSC 1610v 1.00 PQ: 0 ANSI: 2 May 27 06:51:49 linux kernel: sd 4:0:0:0: [sdc] Attached SCSI removable disk May 27 06:51:49 linux kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0 May 27 06:51:49 linux kernel: usb-storage: device scan complete May 27 06:51:55 linux PSC_1600_series?serial=MY5AGF229PL0: io/hpmud/musb.c 135: unable get_string_descriptor -1: Operation not permitted May 27 06:51:55 linux PSC_1600_series?serial=MY5AGF229PL0: io/hpmud/musb.c 603: invalid product id string ret=-1 May 27 06:51:55 linux PSC_1600_series?serial=MY5AGF229PL0: io/hpmud/musb.c 1058: unable to open hp:/usb/PSC_1600_series?serial=MY5AGF229PL0 May 27 06:51:55 linux PSC_1600_series?serial=MY5AGF229PL0: prnt/backend/hp.c 675: INFO: open device failed; will retry in 30 seconds... Reproducible: Always Steps to Reproduce: 1. Install hplip (hplip-2.8.7-7.1) 2. Turn on printer 3. tail -F /var/log/messages Actual Results: 1. Errors in /var/log/messages. 2. Printer doesn't work. Expected Results: Change the OWNER="root", GROUP="lp" in 55-hpumd.rules to OWNER="lp", GROUP="lp" and restart the printer and everything works fine. Setting the Severity to Minor on this one, as the fix is relatively easy (as described above). But it would be nice if printing worked out of the box without having to dig around in udev rules. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c1 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Johannes Meixner <jsmeix@novell.com> 2010-05-27 12:51:29 UTC --- By default only root should be allowed to change owner, group, and permissions of device files. Therefore the default OWNER="root", GROUP="lp" is the right one. With OWNER="lp" any process which runs as user "lp" (e.g. any printer filter/driver or backend) could change owner, group, and permissions of those device files as it likes. What you may change is the MODE="..." therein to something like MODE="0664" to grant "lp" read/write permissions or even to MODE="0666" to grant any user read/write permissions if your system is in a trusted environment. This works fine for me with kernel 2.6.27. Above note "the default" - i.e. of course you can change it as you need it on your particular system but we cannot have e.g. OWNER="lp" by default so that in the end the bug report is invalid for us. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c2 --- Comment #2 from Johannes Meixner <jsmeix@novell.com> 2010-05-27 13:00:32 UTC --- I wonder why plain printing did not work out of the box for you because our defaults are OWNER="root", GROUP="lp", MODE="0664" so that the user "lp" which runs the printing filters/drivers and the CUPS backend has read/write permissions for those device files so that plain printing works out of the box and it worked and works out of the box all the time for me with my HP LaserJet 1220 all-in-one USB device. In contrast e.g. running hp-toolbox as normal user to get device status information or scanning as normal user requires read/write permissions for normel users for the device file. Do you really have our original openSUSE HPLIP packages (hplip and hplip-hpijs) installed or do you have perhaps HPLIP packages installed from somewhere else - e.g. from a non-official repository in the openSUSE build service or from PackMan? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c3 --- Comment #3 from David Gersic <dgersic@niu.edu> 2010-05-28 03:01:22 UTC --- According to YaST, the HPLIP package is from the OpenSuSE 11.1 OSS repo. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c4 --- Comment #4 from David Gersic <dgersic@niu.edu> 2010-05-28 03:17:50 UTC --- Changing the udev rule to use MODE=0666 does not work. Same errors in /var/log/messages as above. Kernel version is now 2.6.27.45-0.1-pae Prior to upgrading the kernel, I had printing working fine. So it did work, out of the box, but broke with the most recent kernel update. Looking at the zypp/history file, it looks like I upgraded from kernel 2.6.27.37-0.1.1. Exactly what 2.6.27 kernel build are you running where it's working for you? While yes, default means that I can change it as needed, I'm not running a highly customized system here where I should have to just to get printing working again. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c5 --- Comment #5 from Johannes Meixner <jsmeix@novell.com> 2010-05-28 08:45:45 UTC --- "uname -a" shows "2.6.27.7-9-pae" on my openSUSE 11.1 system. If printing does no longer work after a kernel version upgrade there seems to be a bug in the kernel-related software (e.g. something like udev or libusb). To verify this, please check whether or not the actual device file permissions are what is specified in the udev rules as root as follows: Run "lsusb" and remember bus and device number for your printer, then run "ls -l /dev/bus/usb/<bus-number>/<device-number>" like on my system (using the udev default rules): ----------------------------------------------------------------------- root@host# lsusb | grep -i laserjet Bus 003 Device 002: ID 03f0:0417 Hewlett-Packard LaserJet 1200 series root@host# ls -l /dev/bus/usb/003/002 crw-rw-r-- 1 root lp 189, 257 May 28 09:47 /dev/bus/usb/003/002 ----------------------------------------------------------------------- For HP all-in-one devices there is a special complication in the udev rules because HP all-in-one devices have additional udev rules from the sane-backends package to set read/write permissions via ACL (run "getfacl /dev/bus/usb/*/*" to show them) for the one normal "desktop" user who is currently logged in locally (i.e. logged in via graphical XDM/Kdm) but not logged in from remote (and as far as I know also not logged in via local text console) so that the currently logged in "desktop" user gets sufficient permissions to use the scanner unit as normal user (see comment #2). The udev rules from the sane-backends package are /etc/udev/rules.d/55-libsane.rules which are set after /etc/udev/rules.d/55-hpmud.rules and which contain e.g. for my LaserJet 1220 all-in-one device: ----------------------------------------------------------------------------- ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="0417", MODE="0664", GROUP="lp"... ----------------------------------------------------------------------------- where the MODE="0664" therein would overwite any MODE="0666" in /etc/udev/rules.d/55-hpmud.rules For your PSC 1600 series with idVendor=03f0 and idProduct=4811 there is also a rule in /etc/udev/rules.d/55-libsane.rules ----------------------------------------------------------------------------- ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="4811", MODE="0664", GROUP="lp"... ----------------------------------------------------------------------------- where you would have to set MODE="0666" so that in the end udev would actually set "rw-rw-rw- 1 root lp" for the device file. But this does not explain why plain printing does no longer work after a kernel version upgrade because the defaults are GROUP="lp" and read/write permissions for this group so that the user "lp" (who is member of the group "lp") has sufficient permissions for plain printing (see comment #2). Please report what there actually is in your udev rules files and what the actual device file settings are in the end on your system. After changing udev rules files you need to unplug and re-plug the device at the USB to generate the kernel events which trigger udev so that udev applies what is specified in its rules to the device file. Note that after each unplug and re-plug of the device at the USB udev generates a new device file with a higer USB device number or with different USB bus and device numbers if you re-plug it at a different USB connector at your computer. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c6 --- Comment #6 from Johannes Meixner <jsmeix@novell.com> 2010-05-28 08:55:30 UTC --- Do you perhaps have a sane-backends package installed which is not an original openSUSE 11.1 package? In our sane-backends package I change intentionally the SANE upstream default GROUP="scanner" to GROUP="lp" to make sure that plain printing works out of the box. Reason: There is no group "scanner" in /etc/group for openSUSE. For all-in-one devices (i.e. printer + scanner, e.g. "EPSON Stylus" devices) the group must be "lp" so that the CUPS usb backend which runs as user "lp" (who is member of the group "lp") can send printing data to the printer unit (i.e. the printer interface of the USB device). It is sufficiently secure and reasonable easy to use by default the same group "lp" for printers and scanners because both kind of devices usually require physical user access (to get the printed paper or to place a paper on the scanner) so that both kind of devices should usually require the same kind of security. If you have a sane-backends package from whatever source, you may have the SANE upstream default GROUP="scanner" which gets set by udev for the device file and then the user "lp" could no longer write to the device file. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c7 --- Comment #7 from Johannes Meixner <jsmeix@novell.com> 2010-05-28 09:05:35 UTC --- FYI, this HPLIP upstream issue looks related: https://answers.launchpad.net/hplip/+question/112533 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c8 --- Comment #8 from David Gersic <dgersic@niu.edu> 2010-06-03 06:14:36 UTC --- Hi Johannes, I think comment #5 may have put me on the right track. linux:/etc/udev/rules.d # lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 003: ID 03f0:4811 Hewlett-Packard PSC 1600 Bus 002 Device 002: ID 047d:1022 Kensington Orbit Optical Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 167b:2007 Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub linux:/etc/udev/rules.d # ls -l /dev/bus/usb/002/003 crw-rw-r--+ 1 root vboxusers 189, 130 2010-06-03 00:53 /dev/bus/usb/002/003 With this, printing does not work. I tracked down the group being set to 'vboxusers' to 60-vboxdrv.rules, which contains: KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600" SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664" SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664" This is from the VirtualBox package, and appears to be intended to allow the virtual machines to access USB devices. When I remove 60-vboxdrv.rules and retest, I get: linux:/etc/udev/rules.d # lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 005: ID 03f0:4811 Hewlett-Packard PSC 1600 Bus 002 Device 002: ID 047d:1022 Kensington Orbit Optical Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 167b:2007 Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub linux:/etc/udev/rules.d # ls -l /dev/bus/usb/002/005 crw-rw-r--+ 1 root lp 189, 132 2010-06-03 01:04 /dev/bus/usb/002/005 and printing works. What's strange is that this was working before I upgraded, but looking at it here, I can't see how it could have been. I'll see if there's an update to VirtualBox. Maybe they have a better set of udev rules for USB devices by now. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c9 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Error in udev rules for |printing longer works when |hplip package |VirtualBox overwrites udev | |rules of hplip and | |sane-backends --- Comment #9 from Johannes Meixner <jsmeix@novell.com> 2010-06-08 08:04:07 UTC --- Many thanks for your feedback which will help me a lot to debug such issues in the future! Some time ago I noticed some user reports about printing issues related to VirtualBox but I didn't have this in mind when I tried to imagine what might be the root cause on your particular system. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c10 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|i686 |All Resolution|INVALID |WONTFIX --- Comment #10 from Johannes Meixner <jsmeix@novell.com> 2010-06-08 08:08:04 UTC --- I changed the resolution from "invalid" to "wontfix" because it is a valid issue but at the moment I have no idea which better default could solve it (one would need to assign two groups "lp" and "vboxusers" to the same USB device file so that both plain printing and access via VirtualBox works out of the box). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c11 --- Comment #11 from David Gersic <dgersic@niu.edu> 2010-06-09 16:10:56 UTC --- I have some further info, maybe. The VirtualBox udev rules are part of the problem, but only part. If I remember correctly, VirtualBox actually puts its udev rules in as 10-vboxdrv.rules so that they execute first. Their rules don't do much, just: KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600" SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664" SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664" With this configuration, I couldn't get VirtualBox to access a specific USB device (Logitech HarmonyOne remote). I suspect that something else later in the /etc/udev/rules.d was getting in the way. If I remember correctly, I "fixed" this problem by moving 10-vboxdrv.rules to 60-vboxdrv.rules. This was a while ago, and I'm not sure that this is what I did, hence the "maybe" as to whether this is good information or not. I have since moved the vboxdrv rules back to 10-vboxdrv.rules, and now printing works, but I lost access to the HarmonyOne again. I solved that by adding my own 60-harmonyone.rules to the /etc/udev/rules.d directory: # udev rules file for HarmonyOne remote to work with VirtualBox. ATTR{idVendor}=="046d", ATTR{idProduct}=="c121", OWNER="root", GROUP="vboxusers", MODE="0664" Now VirtualBox, the HarmonyOne, and printing with HPLIP all work. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=609424 http://bugzilla.novell.com/show_bug.cgi?id=609424#c12 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|printing longer works when |VirtualBox udev rules |VirtualBox overwrites udev |conflict with udev rules of |rules of hplip and |other packages (e.g. hplip, |sane-backends |sane-backends,...) --- Comment #12 from Johannes Meixner <jsmeix@novell.com> 2010-06-15 09:05:32 UTC --- Summary: VirtualBox udev rules conflict with udev rules of other packages (e.h. hplip, sane-backends, whatever-belongs-to-HarmonyOne,...). If VirtualBox udev rules execute first, they become (partially) invalidated by udev rules of other packages which execute later, but if VirtualBox udev rules execute last, they invalidate the udev rules of other packages. I think that such general VirtualBox udev rules as in comment #11 cannot provide correct settings for specific cases like yours (i.e. have different rules for HarmonyOne and the printer) so that your specific solution as described in comment #11 is the right one for your specific case. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com