Bug 432392 - xsane: no devices available
xsane: no devices available
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-11 14:20 EST by Felix Schwarz
Modified: 2009-12-14 15:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 00:58:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace as requested when running scanimage as a user (227.12 KB, text/plain)
2008-02-18 16:54 EST, Felix Schwarz
no flags Details

  None (edit)
Description Felix Schwarz 2008-02-11 14:20:59 EST
# ls -l /dev/scanner*
lrwxrwxrwx 1 root root 9 Feb 11 18:49 /dev/scanner-usbdev2.4 -> usbdev2.4

Description of problem:
xsane does not find my usb scanner when running xsane as normal user (although
the scanner is connected). This worked already with Fedora 8 some weeks ago and
stopped working suddenly (after an update, I guess).

Scanning as root works fine.

$ lsusb
Bus 002 Device 004: ID 04b8:0110 Seiko Epson Corp. Perfection 1650
Bus 002 Device 003: ID ...
Bus 002 Device 002: ID ...
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000  

$ sane-find-scanner 
...
found USB scanner (vendor=0x04b8, product=0x0110) at libusb:002:004


Obviously, it has something to do with permissions:
$ ls -l /dev/scanner*
lrwxrwxrwx 1 root root 9 11. Feb 20:02 /dev/scanner-usbdev2.4 -> usbdev2.4

$ ls -l /dev/usbdev*
crw-rw---- 1 root root 189,   0 11. Feb 20:02 /dev/usbdev1.1
crw-rw---- 1 root root 251,   0 11. Feb 20:02 /dev/usbdev1.1_ep00
crw-rw---- 1 root root 251,   1 11. Feb 20:02 /dev/usbdev1.1_ep81
crw-rw---- 1 root root 189, 128 11. Feb 20:02 /dev/usbdev2.1
crw-rw---- 1 root root 251,   2 11. Feb 20:02 /dev/usbdev2.1_ep00
crw-rw---- 1 root root 251,   3 11. Feb 20:02 /dev/usbdev2.1_ep81
crw-rw---- 1 root root 189, 129 11. Feb 20:02 /dev/usbdev2.2
crw-rw---- 1 root root 251,   4 11. Feb 20:02 /dev/usbdev2.2_ep00
crw-rw---- 1 root root 251,   5 11. Feb 20:02 /dev/usbdev2.2_ep81
crw-rw---- 1 root root 189, 130 11. Feb 20:02 /dev/usbdev2.3
crw-rw---- 1 root root 251,   6 11. Feb 20:02 /dev/usbdev2.3_ep00
crw-rw---- 1 root root 251,   7 11. Feb 20:02 /dev/usbdev2.3_ep81
crw-rw---- 1 fs   lp   189, 131 11. Feb 20:02 /dev/usbdev2.4
crw-rw---- 1 root root 251,   8 11. Feb 20:02 /dev/usbdev2.4_ep00
crw-rw---- 1 root root 251,  10 11. Feb 20:02 /dev/usbdev2.4_ep02
crw-rw---- 1 root root 251,   9 11. Feb 20:02 /dev/usbdev2.4_ep81

Unfortunately, even something like "chown foo.foo /dev/usb*; chmod 0777 /dev/usb*" 
does lead to xsane working with a normal user. 

I found bug 244444 which looks quite similar but:
$ rpm -q udev
udev-118-1.fc8

I suspect that there is some problem with udev involved but I want to let you make
the choice to which package this belongs.


Version-Release number of selected component (if applicable):
$ rpm -q xsane
xsane-0.994-4.fc8

$ rpm -q sane-backends
sane-backends-1.0.18-17.fc8

How reproducible:
Always


Steps to Reproduce:
1. Connect scanner to computer
2. launch xsane as normal user
Comment 1 Nils Philippsen 2008-02-12 10:01:50 EST
I've been working on using PolicyKit for the permission thing instead of udev in
the current Rawhide packages of sane-backends-1.0.19. I've made a scratch build
of the current revision for i386 and x86_64:

http://koji.fedoraproject.org/koji/taskinfo?taskID=418970

Please test the packages suitable for your hardware and report back whether this
improves the situation.
Comment 2 Felix Schwarz 2008-02-12 14:36:49 EST
After installing the packages from koji
(sane-backends-1.0.19-0.2.fc8.x86_64.rpm,
sane-backends-libs-1.0.19-0.2.fc8.x86_64.rpm,
sane-backends-libs-gphoto2-1.0.19-0.2.fc8.x86_64.rpm), the situation is still
the same. 

The only change is that there is no /dev/scanner... link any more.
Comment 3 Nils Philippsen 2008-02-13 04:40:17 EST
(In reply to comment #2)
> After installing the packages from koji
> (sane-backends-1.0.19-0.2.fc8.x86_64.rpm,
> sane-backends-libs-1.0.19-0.2.fc8.x86_64.rpm,
> sane-backends-libs-gphoto2-1.0.19-0.2.fc8.x86_64.rpm), the situation is still
> the same. 
> 
> The only change is that there is no /dev/scanner... link any more.

What are the permissions/ownership of the device file?
Comment 4 Felix Schwarz 2008-02-13 13:20:31 EST
Which device file?
$ ls -l /dev/usbdev*
crw-rw---- 1 root root 189,   0 13. Feb 18:53 /dev/usbdev1.1
crw-rw---- 1 root root 251,   0 13. Feb 18:53 /dev/usbdev1.1_ep00
crw-rw---- 1 root root 251,   1 13. Feb 18:53 /dev/usbdev1.1_ep81
crw-rw---- 1 root root 189,   3 13. Feb 18:57 /dev/usbdev1.4
crw-rw---- 1 root root 251,   8 13. Feb 18:57 /dev/usbdev1.4_ep00
crw-rw---- 1 root root 251,  10 13. Feb 18:57 /dev/usbdev1.4_ep02
crw-rw---- 1 root root 251,   9 13. Feb 18:57 /dev/usbdev1.4_ep81
crw-rw---- 1 root root 251,  11 13. Feb 18:57 /dev/usbdev1.4_ep83
crw-rw---- 1 root root 189, 128 13. Feb 18:53 /dev/usbdev2.1
crw-rw---- 1 root root 251,   2 13. Feb 18:53 /dev/usbdev2.1_ep00
crw-rw---- 1 root root 251,   3 13. Feb 18:53 /dev/usbdev2.1_ep81
crw-rw---- 1 root root 189, 129 13. Feb 18:53 /dev/usbdev2.2
crw-rw---- 1 root root 251,   4 13. Feb 18:53 /dev/usbdev2.2_ep00
crw-rw---- 1 root root 251,   5 13. Feb 18:53 /dev/usbdev2.2_ep81
crw-rw---- 1 root root 189, 130 13. Feb 18:53 /dev/usbdev2.3
crw-rw---- 1 root root 251,   6 13. Feb 18:53 /dev/usbdev2.3_ep00
crw-rw---- 1 root root 251,   7 13. Feb 18:53 /dev/usbdev2.3_ep81
crw-rw---- 1 root root 189, 131 13. Feb 19:12 /dev/usbdev2.4
crw-rw---- 1 root root 251,  12 13. Feb 19:12 /dev/usbdev2.4_ep00
crw-rw---- 1 root root 251,  14 13. Feb 19:12 /dev/usbdev2.4_ep02
crw-rw---- 1 root root 251,  13 13. Feb 19:12 /dev/usbdev2.4_ep81

But changing the ownership for all devices listed above to my user does change
anything.
Comment 5 Nils Philippsen 2008-02-14 02:51:13 EST
(In reply to comment #4)
> But changing the ownership for all devices listed above to my user does change
> anything.

"Does" or "doesn't"? I assume the latter ;-). Do you have SELinux enabled? What
does "sane-find-scanner" and "scanimage -L" give?
Comment 6 Felix Schwarz 2008-02-14 13:37:42 EST
Yes, "doesn't" is correct - fortunately, humans are much smarter than computers :-)

$ cat /etc/selinux/config  | grep -v '^#'
SELINUX=disabled
SELINUXTYPE=targeted 
SETLOCALDEFS=0 
$ sane-find-scanner 
  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x04b8, product=0x0110) at libusb:002:004
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.

$ scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
Comment 7 Nils Philippsen 2008-02-18 09:49:41 EST
Would you please strace scanimage both as normal user and as root and attach a)
the output and b) the strace output (don't paste)? The command would be
(provided strace is installed):

strace -Ff -o <stracefile> scanimage -L -v > <outputfile> 2>&1

Here, <stracefile> would be the file getting the strace output and <outputfile>
would get the output of scanimage.
Comment 8 Felix Schwarz 2008-02-18 16:54:02 EST
Created attachment 295213 [details]
strace as requested when running scanimage as a user
Comment 9 Felix Schwarz 2008-02-18 16:57:00 EST
As you can see in the previously attached strace log, The normal user is lacking
permissions on /proc/bus/usb/002/004 (where my scanner is attached). Changing
the owner from root/root (0644) to <user> fixes the issue.

Therefore the only remaining question for me is why these permissions are not
set automatically.
Comment 10 Nils Philippsen 2008-02-19 04:34:43 EST
The strace shows that /proc/bus/usb is used which is an obsolete interface. This
is likely because it doesn't seem to find /dev/bus/usb -- which version of udev
do you have?
Comment 11 Nils Philippsen 2008-02-19 04:43:13 EST
Scratch that question, you've answered that one before. I should learn to read ;-).
Comment 12 Nils Philippsen 2008-02-19 05:07:39 EST
Another question: Which kernels do you have installed and which are you running
("rpm -qa kernel\*; uname -a")?
Comment 13 Nils Philippsen 2008-02-19 05:24:50 EST
BTW, new scratch build waiting for you at:

http://koji.fedoraproject.org/koji/taskinfo?taskID=441368
Comment 14 Felix Schwarz 2008-02-19 14:37:57 EST
$ rpm -qa kernel\*; uname -a
kernel-headers-2.6.23.15-137.fc8
kernel-xen-2.6.21-2957.fc8
kernel-xen-debuginfo-2.6.21-2952.fc8
kernel-xen-2.6.21-2952.fc8
kernel-xen-2.6-debuginfo-common-2.6.21-2952.fc8
kernel-xen-devel-2.6.21-2957.fc8
kernel-xen-devel-2.6.21-2952.fc8
kernel-2.6.23.14-107.fc8
kernel-2.6.23.15-137.fc8
Linux ws2.schwarz.lokal 2.6.21-2957.fc8xen #1 SMP Tue Feb 12 13:07:27 EST 2008
x86_64 x86_64 x86_64 GNU/Linux

Maybe its the Xen kernel I'm running?
Upgrading to the referenced koji RPMs did not fix the problem (do I have to
restart some daemon?).
Comment 15 Nils Philippsen 2008-02-20 03:32:46 EST
That you're running the XEN kernel may just be the culprit -- it's the
/dev/bus/usb hierarchy missing which causes libsane/libusb to fallback to using
/proc/bus/usb which doesn't (can't) have the permissions setup correctly for
your user.

I'm moving this to the kernel-xen component and adding Harald Hoyer and myself
to Cc. Harald is the Fedora maintainer for udev and mentioned some incompatible
changes made in the kernel w.r.t. udev and I suspect that these haven't been
done in the kernel-xen package yet.
Comment 16 Nils Philippsen 2008-02-20 03:34:34 EST
BTW: The new sane-backends packages are just to ensure that we're on the same
page with regard to what's being tested.
Comment 17 Bug Zapper 2008-11-26 04:47:10 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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
Comment 18 Bug Zapper 2009-01-09 00:58:26 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.

Note You need to log in before you can comment on or make changes to this bug.