Bug 432392
| Summary: | xsane: no devices available | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Felix Schwarz <felix.schwarz> | ||||
| Component: | kernel-xen | Assignee: | Xen Maintainance List <xen-maint> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 8 | CC: | harald | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-01-09 05:58:26 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Felix Schwarz
2008-02-11 19:20:59 UTC
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. 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. (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? 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. (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? 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). 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. Created attachment 295213 [details]
strace as requested when running scanimage as a user
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. 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? Scratch that question, you've answered that one before. I should learn to read ;-). Another question: Which kernels do you have installed and which are you running
("rpm -qa kernel\*; uname -a")?
BTW, new scratch build waiting for you at: http://koji.fedoraproject.org/koji/taskinfo?taskID=441368 $ 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?). 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. BTW: The new sane-backends packages are just to ensure that we're on the same page with regard to what's being tested. 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 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. |