Bug 424331

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