I have a simple hp deskjet printer that is configured and working fine if it is connected to the system before boot. If I unplug the printer (to use with laptop) and plug it back in than I get the following error messages in /var/log/messages and the printer queue stops sending print jobs to the printer. ============================================== Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 549: invalid product id string: Operation not permitted Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 1003: unable to open hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Deskjet_D2400_series?serial=TH77D3612704Y7: INFO: open device failed; will retry in 30 seconds... hpijs: io/hpmud/musb.c 549: invalid product id string: Operation not permitted hpijs: io/hpmud/musb.c 1003: unable to open hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 549: invalid product id string: Operation not permitted Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 1003: unable to open hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Deskjet_D2400_series?serial=TH77D3612704Y7: INFO: open device failed; will retry in 30 seconds... Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 549: invalid product id string: Operation not permitted Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 1003: unable to open hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Deskjet_D2400_series?serial=TH77D3612704Y7: INFO: open device failed; will retry in 30 seconds... Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 549: invalid product id string: Operation not permitted Deskjet_D2400_series?serial=TH77D3612704Y7: io/hpmud/musb.c 1003: unable to open hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Deskjet_D2400_series?serial=TH77D3612704Y7: INFO: open device failed; will retry in 30 seconds... ===================================================================== lsusb gives the following: Bus 005 Device 002: ID 03f0:7a04 Hewlett-Packard This is a DELL Precision 390, x86_64 system, running F8 with all the updates and updates-testing. Thanks
What do these commands say?: 1. rpm -q hplip 2. hp-probe -busb (run this as root)
============================================================= # rpm -q hplip hplip-2.7.7-6.fc8 ============================================================= # hp-probe -busb HP Linux Imaging and Printing System (ver. 2.7.7) Printer Discovery Utility ver. 3.2 Copyright (c) 2001-7 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Device URI Model -------------------------------------------------- ----------------------- hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 HP Deskjet D2400 series Found 1 printer(s) on the 'usb' bus. ============================================================= After this /var/log/messges contains: ============================================== python: hp-probe[10630]: warning: No devices found on the 'usb' bus. If this isn't the result you are expecting, python: hp-probe[10630]: warning: check to make sure your devices are properly connected and powered on. python: hp-probe[10632]: warning: No devices found on the 'usb' bus. If this isn't the result you are expecting, python: hp-probe[10632]: warning: check to make sure your devices are properly connected and powered on. =============================================== the other error messages don't come until a print job is submitted. Again, the printer works fine if we boot while it is plugged in.
What does 'hp-info' say?
# hp-info HP Linux Imaging and Printing System (ver. 2.7.7) Device Information Utility ver. 3.4 Copyright (c) 2001-7 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. warning: Inrecognized URI: ipp://a117107.n1.vanderbilt.edu:631/printers/DeskJet5850 warning: Inrecognized URI: ipp://nano.local/printers/HL-5050_series warning: Inrecognized URI: ipp://atom.phy.vanderbilt.edu:631/printers/LaserJet4200 warning: Inrecognized URI: ipp://a117107.n1.vanderbilt.edu:631/printers/LaserJet4240PS warning: Inrecognized URI: ipp://atom.phy.vanderbilt.edu:631/printers/Phaser8500 Using device: hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 Device Parameters (dynamic data): Parameter Value(s) ---------------------------- ---------------------------------------------------------- agent1-ack False agent1-desc Black cartridge agent1-dvc 0 agent1-health 0 agent1-health-desc Good/OK agent1-hp-ink False agent1-id 9 agent1-kind 3 agent1-known False agent1-level 74 agent1-level-trigger 0 agent1-sku 21(C9153A/G) agent1-type 1 agent1-virgin False agent2-ack False agent2-desc Tri-color cartridge agent2-dvc 0 agent2-health 0 agent2-health-desc Good/OK agent2-hp-ink False agent2-id 10 agent2-kind 3 agent2-known False agent2-level 57 agent2-level-trigger 0 agent2-sku 22(C9352A/G) agent2-type 2 agent2-virgin False agent3-ack False agent3-desc Photo cartridge agent3-dvc 0 agent3-health 1 agent3-health-desc Not installed agent3-hp-ink False agent3-id 0 agent3-kind 3 agent3-known False agent3-level 0 agent3-level-trigger 7 agent3-sku 58 (C6658x) agent3-type 3 agent3-virgin False back-end hp cups-printer Deskjet_D2400_series cups-uri hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 dev-file device-state 1 device-uri hp:/usb/Deskjet_D2400_series?serial=TH77D3612704Y7 deviceid MFG:HP;MDL:Deskjet D2400 series;CMD:LDL,DYN;CLS:PRINTER;DES:D2460;SN:TH77D3612704Y7 ;S:0380008000020020002c148004ac2500039;Z:007,0A20000,05000 000000000; duplexer 0 error-state 0 host in-tray1 True in-tray2 False is-hp True media-path 2 panel 0 panel-line1 panel-line2 photo-tray 0 port 1 r 0 revision 3 rg 000 rr 000000 rs 000000000 serial TH77D3612704Y7 status-code 1000 status-desc The printer is idle. supply-door 0 top-door 1 Model Parameters (static data): Parameter Value(s) ---------------------------- ---------------------------------------------------------- align-type 5 clean-type 2 color-cal-type 0 copy-type 0 embedded-server-type 0 fax-type 0 fw-download 0 icon Deskjet_3740.png io-mfp-mode 6 io-mode 1 io-support 2 linefeed-cal-type 0 model Deskjet_D2400_series model-ui HP Deskjet d2400 series model1 Deskjet D2400 Series model2 HP Deskjet D2430 Printer model3 HP Deskjet D2445 Printer model4 HP Deskjet D2460 Printer panel-check-type 0 pcard-type 0 pq-diag-type 0 r-type 1 r0-agent1-kind 3 r0-agent1-sku 21(C9153A/G) r0-agent1-type 1 r0-agent2-kind 3 r0-agent2-sku 22(C9352A/G) r0-agent2-type 2 r0-agent3-kind 3 r0-agent3-sku 58 (C6658x) r0-agent3-type 3 r1-agent1-kind 3 r1-agent1-sku 21(C9351A/G) r1-agent1-type 1 r1-agent2-kind 3 r1-agent2-sku 22(C9352A/G) r1-agent2-type 2 r1-agent3-kind 3 r1-agent3-sku 58 (C6658x) r1-agent3-type 3 r10-agent1-kind 3 r10-agent1-sku 816 (C8816A/B/G) r10-agent1-type 1 r10-agent2-kind 3 r10-agent2-sku 817 (C8817A/G) r10-agent2-type 2 r10-agent3-kind 3 r10-agent3-sku 58 (C6658x) r10-agent3-type 3 r2-agent1-kind 3 r2-agent1-sku 21 (C9351A/G) r2-agent1-type 1 r2-agent2-kind 3 r2-agent2-sku 22 (C9352A/G) r2-agent2-type 2 r2-agent3-kind 3 r2-agent3-sku 58 (C6658x) r2-agent3-type 3 r3-agent1-kind 3 r3-agent1-sku 21 (C9351A/G) r3-agent1-type 1 r3-agent2-kind 3 r3-agent2-sku 22 (C9352A/G) r3-agent2-type 2 r3-agent3-kind 3 r3-agent3-sku 58 (C6658x) r3-agent3-type 3 r4-agent1-kind 3 r4-agent1-sku 21 (C9351A/G) r4-agent1-type 1 r4-agent2-kind 3 r4-agent2-sku 22 (C9352A/G) r4-agent2-type 2 r4-agent3-kind 3 r4-agent3-sku 58 (C6658x) r4-agent3-type 3 r5-agent1-kind 3 r5-agent1-sku 21 (C9351A/G) r5-agent1-type 1 r5-agent2-kind 3 r5-agent2-sku 22 (C9352A/G) r5-agent2-type 2 r5-agent3-kind 3 r5-agent3-sku 58 (C6658x) r5-agent3-type 3 r6-agent1-kind 3 r6-agent1-sku 21 (C9351A/G) r6-agent1-type 1 r6-agent2-kind 3 r6-agent2-sku 22 (C9352A/G) r6-agent2-type 2 r6-agent3-kind 3 r6-agent3-sku 58 (C6658x) r6-agent3-type 3 r7-agent1-kind 3 r7-agent1-sku 816 (C8816A/B/G) r7-agent1-type 1 r7-agent2-kind 3 r7-agent2-sku 817 (C8817A/G) r7-agent2-type 2 r7-agent3-kind 3 r7-agent3-sku 58 (C6658x) r7-agent3-type 3 r8-agent1-kind 3 r8-agent1-sku 21 (C9351A/G) r8-agent1-type 1 r8-agent2-kind 3 r8-agent2-sku 22 (C9352A/G) r8-agent2-type 2 r8-agent3-kind 3 r8-agent3-sku 58 (C6658x) r8-agent3-type 3 r816-agent1-kind 3 r816-agent1-sku r816-agent1-type 1 r816-agent2-kind 3 r816-agent2-sku r816-agent2-type 2 scan-style 0 scan-type 0 status-battery-check 0 status-dynamic-counters 0 status-type 2 support-released 1 support-type 2 support-ver 1.7.4 tech-class DJ3600 tech-type 2 usb_pid usb_vid Status History (most recent first): Date/Time Code Status Description User Job ID -------------------- ----- ---------------------------------------- -------- -------- 12/14/2007 08:49:22 1000 The printer is idle. root
PS: I just noticed that sometimes I get the line: kernel: hpijs[18647]: segfault at 0000000000c10256 rip 000000000041cb5f rsp 00007fff08970fb8 error 4
Do you have SELinux enabled? If so, does 'setenforce 0' work around the problem? The hpijs segfault isn't good news. :-(
No SELinux is disabled. I have been running kernels 2.6.23.9-85.fc8 and 2.6.23.9-90.fc8 both of which have the problem. I have not tried this with another kernel.
To elaborate more... I am pretty sure this was working in the past (like two weeks ago) since we got these printers new and all I had to do was to plug them in and the printer icon popped up and it was ready to go. So, it must be some upgrade that is breaking this now.
OK....it is not the kernel. The 55-hpmud.rules file below fixes the problem. I am not sure which part is making the difference but if I keep the idProduct lines and replace the top part with the one from Fedora it does not work. So, more likely it is something in the top lines that is making the difference. I am attaching the file.
Created attachment 289341 [details] 55-hpmud.rules
I have faced the same problem having connected after the boot the DeskJet 930C printer. The following patch solved the problem: [root@wrobel rules.d]# diff -u 55-hpmud.rules.orig 55-hpmud.rules --- 55-hpmud.rules.orig 2007-12-19 23:47:44.000000000 +0100 +++ 55-hpmud.rules 2007-12-19 23:49:57.000000000 +0100 @@ -3,5 +3,5 @@ ATTR{devnum}!="?*", GOTO="hpmud_rules_end" ATTR{busnum}!="?*", GOTO="hpmud_rules_end" ACTION!="add", GOTO="hpmud_rules_end" -SYSFS{idVendor}=="03f0", GROUP="lp", MODE="0664" +SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="1204", GROUP="lp", MODE="0664" LABEL="hpmud_rules_end"
Damian: are you sure? That change looks like it makes the permissions more restrictive (i.e. only exact product matches get the permissions, rather than any product from that vendor). Can you attach the complete working file you have?
I tried a similar thing with SYSFS{idProduct}=="??04" form and it did not make any difference.
*** Bug 426549 has been marked as a duplicate of this bug. ***
What's happening is that something is doing the equivalent of 'chmod 644 /dev/bus/usb/.../...' for that device node, *after* we've already set the mode to 664 and added an ACL for the console user. The relevant udev rules are: 40-redhat.rules: 12 ACTION=="add", SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644" 50-default-udev.rules: 52 SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" 55-hpmud.rules: 1 # TODO: add PROGRAM rule for 7/xx/xx printer class interface 2 SUBSYSTEM!="usb", GOTO="hpmud_rules_end" 3 ATTR{devnum}!="?*", GOTO="hpmud_rules_end" 4 ATTR{busnum}!="?*", GOTO="hpmud_rules_end" 5 ACTION!="add", GOTO="hpmud_rules_end" 6 SYSFS{idVendor}=="03f0", GROUP="lp", MODE="0664" 7 LABEL="hpmud_rules_end" The ACLs are set using HAL, details in these files: /usr/share/hal/fdi/policy/10osvendor/10-hplip.fdi /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi The udev rules attached by Sammy in comment #10 are not correct for Fedora, for a couple of reasons: 1. there is no need to set both the owner and the group to 'lp' -- we have been using group permissions in Fedora, so the group should be lp and the owner should be left alone (or set as 'root'). 2. 0666 is far too permissive -- it allows users who are not in the 'lp' group or logged in at the console to get raw USB access to the device. I'd like to find out why group permissions are not working as expected, rather than switching to owner permissions. I can reproduce the broken 'getfacl' state of the device node using these operations on a test file: rm -f test touch test chgrp lp test chmod 664 test setfacl -m u:sue:rw test chmod 644 test getfacl test The trouble is that I don't understand why 'chmod 644' would occur after the setfacl (which comes from the HAL rules invoking hal-acl-tool).
Aha, it seems to be a race condition between hal (which sets the ACL) and udev (which sets the owner, group, and file permissions). CCing davidz: how does ConsoleKit intend to avoid racing with HAL rules?
(In reply to comment #16) > Aha, it seems to be a race condition between hal (which sets the ACL) and udev > (which sets the owner, group, and file permissions). > > CCing davidz: how does ConsoleKit intend to avoid racing with HAL rules? By integrating the hal/udev bits for doing this. But that is a bit out in the future. I need to look at this in more detail; udev always sees events before hal does so what you are suggesting can never really happen. Need to investigate.
Why don't you simply peruse the access_control.grant_group [1] property to do what you want? E.g. I'd just use <append key="access_control.grant_group" type="strlist">hplip</append> in the fdi file. [1] : see /usr/share/doc/hal-0.5.10/spec/hal-spec.html#device-properties-access-control
(In reply to comment #15) > I can reproduce the broken 'getfacl' state of the device node using these > operations on a test file: > > rm -f test > touch test > chgrp lp test > chmod 664 test > setfacl -m u:sue:rw test > chmod 644 test > getfacl test > > The trouble is that I don't understand why 'chmod 644' would occur after the > setfacl (which comes from the HAL rules invoking hal-acl-tool). The trouble is that the last chmod effectively sets the ACL mask to read-only, see setfacl(1): [...] * If an ACL contains named user or named group entries, and no mask entry exists, a mask entry containing the same permissions as the group entry is created. Unless the -n option is given, the permis- sions of the mask entry are further adjusted to include the union of all permissions affected by the mask entry. (See the -n option description). [...] if hal-acl-tool would set an explicit ACL mask on the file, we shouldn't have a problem with the order in which udev and hald set the file mode/ACLs.
David: access_control.grant_group certainly looks like a simpler solution than the udev rules. Unfortunately the problem still occurs. Here's what I tried: # rm -f /etc/udev/rules.d/55-hpmud.rules # udevcontrol reload_rules # vim /usr/share/hal/fdi/policy/10osvendor/10-hplip.fdi Then I added the grant_group line so that the first part reads: <!-- HPLIP-driven printers and scanners --> <match key="info.bus" contains="usb_device"> <match key="usb_device.vendor_id" int="0x03f0"> <append key="info.capabilities" type="strlist">scanner</append> <append key="access_control.grant_group" type="strlist">lp</append> </match> </match> # service haldaemon restart I power-cycled the device. # getfacl /dev/bus/usb/003/004 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/004 # owner: root # group: root user::rw- group::r-- group:lp:rw- #effective:r-- mask::r-- other::r-- It doesn't happen every time. This seems to be racing with udev. In fact, a subsequent strace of both hald-runner and udevd (attached) shows that this is the case, with /dev/bus/usb/003/006 being the relevant device. udevd is marked with '%', and hald with '#': % [pid 19242] 1199442861.181834 chmod("/dev/bus/usb/003/006", 020644 <unfinished ...> # [pid 19249] 1199442861.204104 setxattr("/dev/bus/usb/003/006", "system.posix_acl_access"..., "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff\x08\x00\x06\x00\x07\x00\x00\x00\x10\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 44, 0) = 0 % [pid 19294] 1199442861.892492 lsetxattr("/dev/bus/usb/003/006", "security.selinux"..., "system_u:object_r:usb_device_t:s0", 34, 0 <unfinished ...> % [pid 19294] 1199442861.892654 chmod("/dev/bus/usb/003/006", 020644 <unfinished ...>
Created attachment 290836 [details] hal-udev-strace.tar.bz2 strace -ttt -fp 574 2> udevd-log strace -ttt -fp 18185 2> hald-runner-log The resulting device is /dev/bus/usb/003/006: # getfacl /dev/bus/usb/003/006 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/006 # owner: root # group: root user::rw- group::r-- group:lp:rw- #effective:r-- mask::r-- other::r-- This is with /etc/udev/rules.d/55-hpmud.rules removed and the grant_group line added to /usr/share/hal/fdi/policy/10osvendor/10-hplip.fdi as described.
(FWIW, I was not logged in at the console on this occasion, hence no user ACL.)
I think this is pam_console at work. Can you reproduce this if you temporarily rename /etc/udev/rules.d/95-pam-console.rules to /etc/udev/rules.d/85-pam-console.rules?
Unfortunately, I can still reproduce the problem even then.
Well. You need to debug it some more then I guess; in particular it would be useful to get the name of the program that runs after hal and ruins everything. Thanks.
This is the rule that causes the problem, from 40-redhat.rules: ACTION=="add", SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644" If I comment it out and run 'udevcontrol reload_rules', everything works fine. strace shows that chmod() only gets called once on the resulting device node, and that happens before hal is notified. When I re-enable that rule, the permissions go wrong again. There are two chmod() calls in udev, and the second one races with hal.
Adding the udev upstream maintainer to the Cc. Kay, please see comment 26 - how is this possible? Tim, what version of udev are you seeing this on? Thanks.
I guess you are providing old and new USB devices and the _same_ time and have rules for both devices that create the same device nodes, two events compete about the same node. Just delete this old rule, it's not part of standard udev! And you should also disable the deprecated CONFIG_USB_DEVICE_CLASS in the kernel.
This is with udev-116-3.fc8. Changing component to udev and reassigning since 40-redhat.rules is owned by that package.
Thanks for figuring this out for us Kay. Harald, can we make that change? Thanks.
By the way, commenting out this rule not only fixes my printer problems but also the fact that gphoto2 was unable to access my usb digital camera, presumably due to the same permissions problem. I think the latter is bug #400491 which is supposed to be closed but there is someone still complaining about it there.
*** Bug 427802 has been marked as a duplicate of this bug. ***
FWIW I see exactly the same thing with an HP Deskjet F380, and the issue is resolved by remoing the same line in 40-redhat.rules
It's not surprising this happens with other devices; basically the line in 40-redhat.rules will break permissions any USB device (sometimes since it's racy). Harald, can we fix this? Thanks.
I am confused about what is going on here! Does hplip-2.7.7-7 solve this problem? or does one still have to remove the line from 40-redhat.rules? Thanks
Hplip can not solve it. You have to disable the old devices in the kernel config, or remove the rule, you can't have both types of kernel devices _and_ two udev rules to create the same files.
hplip-2.7.7-7.fc8 just simplifies the way that the lp group is given access to the device. It does not fix the problem, but the changelog does reference this bug report because that's where the suggestion came from (comment #18). Sorry for the confusion. The problem still needs to be fixed in udev.
will fix now
*** Bug 427324 has been marked as a duplicate of this bug. ***
*** Bug 428172 has been marked as a duplicate of this bug. ***
udev-118-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update udev'
Now works fine for me, having added myself to the 'lp' group and logged off/on. Thanks!
No, do not add yourself to the lp group. Only the CUPS backends need to be in that group.
udev-118-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 235080 has been marked as a duplicate of this bug. ***
I get this on FC7 (2.6.23.14-64.fc7) with OfficeJet Pro K550. Problem started only after yum update last week. Is the change to 55-hpmud valid here? [root@frodo les]# hp-probe -busb HP Linux Imaging and Printing System (ver. 2.7.7) Printer Discovery Utility ver. 3.2 Copyright (c) 2001-7 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Device URI Model -------------------------------------------- --------------------- hp:/usb/Officejet_Pro_K550?serial=MY5BD210J7 HP Officejet Pro K550 Found 1 printer(s) on the 'usb' bus.
I pasted the changes to 55-hpmud.rules into /etc/udev/rules.d/55-hpmud.rules and unplugged/replugged the usb cable getting [root@frodo les]# tail /var/log/messages Feb 10 17:03:08 frodo nmbd[2283]: ***** Feb 10 17:03:08 frodo nmbd[2283]: Feb 10 17:03:08 frodo nmbd[2283]: Samba name server FRODO is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.3 Feb 10 17:03:08 frodo nmbd[2283]: Feb 10 17:03:08 frodo nmbd[2283]: ***** Feb 10 17:30:26 frodo kernel: usb 1-2: USB disconnect, address 2 Feb 10 17:30:26 frodo kernel: usblp0: removed Feb 10 17:30:34 frodo kernel: usb 1-2: new full speed USB device using uhci_hcd and address 3 Feb 10 17:30:34 frodo kernel: usb 1-2: configuration #1 chosen from 1 choice Feb 10 17:30:34 frodo kernel: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x03F0 pid 0x1812 I then could print (which I couldn't before) SO, I guess it works for FC7 as well. Someone with more insight into udev might outghta verify.
Les: it looks like you are trying to use a Fedora 8 HPLIP package on Fedora 7. Don't do that; it won't work.
Tim, Everything installed on the FC7 box is installed via YUM. IF there is anything from FC8, YUM did it. It might be that someone ought to look into that. If I can help, pls contact me.
Les: please file a separate bug report, as this bug report is specific to Fedora 8.
Hi, I am seeing this problem after updating Fedora 8 and rebooting last night. udev-118-1.fc8 hplip-2.7.12-4.fc8 kernel-2.6.24.3-34.fc8 Mar 21 12:01:11 localhost hp_LaserJet_1320_series?serial=00CNHC59C5VF: io/hpmud/musb.c 135: unable get_string_descriptor -1: Operation not permitted Mar 21 12:01:11 localhost hp_LaserJet_1320_series?serial=00CNHC59C5VF: io/hpmud/musb.c 603: invalid product id string ret=-1 Mar 21 12:01:11 localhost hp_LaserJet_1320_series?serial=00CNHC59C5VF: io/hpmud/musb.c 1057: unable to open hp:/usb/hp_LaserJet_1320_series?serial=00CNHC59C5VF Mar 21 12:01:11 localhost hp_LaserJet_1320_series?serial=00CNHC59C5VF: prnt/backend/hp.c 636: INFO: open device failed; will retry in 30 seconds... Everything was working up until now.
# lsusb Bus 001 Device 001: ID 0000:0000 Bus 003 Device 002: ID 03f0:1d17 Hewlett-Packard LaserJet 1320 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 # getfacl /dev/bus/usb/003/002 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/002 # owner: root # group: root user::rw- group::r-- mask::r-- other::r--
for the ACL do not assign the bugs to udev, but HAL/PolicyKit
Changing component and reassigning.
This is still a problem with newest fedora 8: hal-0.5.10-1.fc8.2 udev-118-1.fc8 cups-1.3.6-4.fc8 kernel-2.6.24.4-64.fc8 hplip-2.8.2-1.fc8 PolicyKit-0.6-2.fc8 Every time I reboot, I have to set permissions manually!
Still broken: hal-0.5.11-2.fc9 udev-124-1.fc9.2 cups-1.3.7-8.fc9 kernel-2.6.25.11-97.fc9 hplip-2.8.2-2.fc9 PolicyKit-0.8-2.fc9
Here is a new twist. On bootup, the permissions are wrong, but if I unplug/plug the USB, the permissions are set and things work immediately. hal-0.5.11-2.fc9.i386 udev-124-2.fc9.i386 cups-1.3.8-2.fc9.i386 kernel-2.6.26.5-45.fc9.i686 hplip-2.8.2-2.fc9.i386 PolicyKit-0.8-3.fc9.i386
This bug is probably solved. I will open a new bug with the problem I am having (usb printer detected ONLY when not plugged in at boot time).
This is broken for me at the moment, using a Deskjet F2280 (includes a scanner). When plugged in on boot, it prints fine. While running, however, it doesn't. Note that the scanner function of the printer works OK, even when printing doesn't. The device: usb 6-1: new full speed USB device using uhci_hcd and address 3 usb 6-1: configuration #1 chosen from 1 choice usblp0: USB Bidirectional printer dev 3 if 1 alt 0 proto 2 vid 0x03F0 pid 0x2404 usb 6-1: New USB device found, idVendor=03f0, idProduct=2404 usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 6-1: Product: Deskjet F2200 series usb 6-1: Manufacturer: HP usb 6-1: SerialNumber: CN89H4Q0HJ0534 In /var/log/messages: Jan 12 10:29:46 rhapsody python: io/hpmud/jd.c 84: unable to read device-id Jan 12 10:29:46 rhapsody python: hp-toolbox(UI)[6976]: error: Unable to communicate with device (code=12): hp:/net/HP_LaserJet_4000_Series?ip=137.44.14.164 Jan 12 10:29:46 rhapsody python: hp-toolbox(UI)[6976]: warning: Device not found Jan 12 10:30:06 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 135: unable get_string_descriptor -1: Operation not permitted Jan 12 10:30:06 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 603: invalid product id string ret=-1 Jan 12 10:30:06 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 1104: unable to open hp:/usb/Deskjet_F2200_series?serial=CN89H4Q0HJ0534 Jan 12 10:30:06 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: prnt/backend/hp.c 679: INFO: open device failed stat=12; will retry in 30 seconds... Jan 12 10:30:36 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 135: unable get_string_descriptor -1: Operation not permitted Jan 12 10:30:36 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 603: invalid product id string ret=-1 Jan 12 10:30:36 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: io/hpmud/musb.c 1104: unable to open hp:/usb/Deskjet_F2200_series?serial=CN89H4Q0HJ0534 Jan 12 10:30:36 rhapsody Deskjet_F2200_series?serial=CN89H4Q0HJ0534: prnt/backend/hp.c 679: INFO: open device failed stat=12; will retry in 30 seconds... Permissions: [root@rhapsody rules.d]# getfacl /dev/bus/usb/006/003 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/006/003 # owner: root # group: root user::rw- user:james:rw- group::r-- mask::rw- other::r-- Of course, if I set these wide open printing starts to work. Software versions: hal-0.5.12-12.20081027git.fc10.x86_64 hal-info-20081219-1.fc10.noarch udev-127-3.fc10.x86_64 hplip-2.8.12-1.fc10.x86_64 cups-1.3.9-6.fc10.x86_64 PolicyKit-0.9-4.fc10.x86_64
James: this looks like a different problem, as the ACLs are incorrect (no group:lp:rw- ACL). Please file a separate bug against hplip.
See also #478495, which is a similar ACL problem.
btw I tested this with F10 and it worked *almost* perfectly. The only problem was that if no previous printer existed, the new printer was not made default. This caused unhelpful error messages when using apps with just a "Print" button that print to the default printer.
Thanks. I've noted that here: https://fedorahosted.org/hal-cups-utils/ticket/6
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to Sammy from comment #8) > To elaborate more... I am pretty sure this was working in the past (like > two weeks ago) since we got these printers new and all I had to do was to > plug them in and the printer icon popped up and it was ready to go. So, it > must be some upgrade that is breaking this now. This is a good way to connect printer on a system. I have to change a setting before update the driver result I work smoothly with the help of https://printerssupport.org/ricoh-printer-support/ is a good company expert in printer service repair
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days