Description of problem: The latest glibc update appears to have broken USB scanners. Both Jacob Heider and I have seen similar symptoms. (See newsgroups linux.redhat on Nov. 15 if you need verification of Jacob's situation.) Version-Release number of selected component (if applicable): 2.3.2-4.80.8 How reproducible: 100% Steps to Reproduce: 1. have a working USB scanner configuration using an HP ScanJet 6300C. 2. update to glibc 2.3.2-4.80.8. 3. (optionally reboot for good measure) 4. try to run xsane. Actual results: "No devices available" Expected results: Xsane should find the scanner and use it. Additional info: sane-find-scanner finds it. 'scanimage --list-devices' does not. /dev/usb/scanner0 is o+rw as normal. 'rpm -qA' shows no significant changes from before the update. /etc/sane.d/hp.conf is o+r and has correct contents, same as before the update. lsusb finds the scanner, looks normal. There is no change when I power cycle the scanner, unplug and then replug the USB cable, and rmmod and then modprobe the 'scanner' module. /var/log/messages show scanner.c attaching to scanner0, as normal. One thing I have not _noticed_ seeing before in /var/log/messages is /etc/hotplug/usb.agent "setting usbcam for USB product 3f0/601/100", which is the scanner. I'm using stock RHL 8.0 plus all updates as of Nov. 15. Again, a second person has confirmed in newsgroup linux.redhat that he sees similar (but slightly different) symptoms.
On RHL9 the glibc update seems to break the cmd line "scanimage", but xsane still works. (I've got an Epson 1240U.) This is also being tracked under bug #110110 (RHL9/sane-backends).
Run scanimage with strace -f -o SOMEFILE scanimage PARAMS... with the old and the new glibc so that we can see the difference. The device handling is nothing glibc does itself. So it can be only a problem with scanimage using some interface incorrectly.
Created attachment 96129 [details] from strace -f -o ... scanimage -L This is the output from strace -f -o with-new-glibc scanimage -L. I see an item in a related report about a DEBUG_DLL environment variable. I'll attach that too. I'll downgrade glibc and run the strace of scanimage at the next opportunity (hopefully within a day or three or ...).
I tried setting environment variable SANE_DEBUG_DLL to 4 and running scaminage, but it didn't produce any additional output than without the variable. Maybe that variable is only active in RHL 9.
Created attachment 96139 [details] with old glibc, strace -f -o with-old-glibc scanimage -L This is the output of 'strace -f -o with-old-glibc scanimage -L' with the old glibc, glibc-2.3.2-4.80.6. Scanning works fine. One obvious difference is the path where libsane.so.1 is found. The two paths have different contents. There is no mismatch found when doing 'rpm -V' on any *sane* package.
That looks like sane-backends bug. Having two different libsane.so.1 libraries with different functionality in ld.so.cache is very bad idea. What glibc-2.3.2-4.80.8 changed is the search order in ldconfig: the old hjl's ldconfig searched first paths specified in ld.so.conf and then the default (/lib and /usr/lib), while ldconfig in glibc used to search the default ones first and then the ld.so.conf ones. The latter has the serious drawback that /lib and /usr/lib really couldn't be overrided. glibc-2.3.2-4.80.8 changes things to how they look in CVS glibc. You can work around it by adding /lib and /usr/lib to the beginning of /etc/ld.so.conf and rerunning ldconfig, but as I said, sane should be fixed instead. Looking at sane-backends in Fedora Core 1 (where ldconfig behaves the same way as in glibc-2.3.2-4.80.8) there is no /usr/lib/sane/libsane.so.1 symlink.
The move to sane-backends sounds reasonable. Thanks for the suggested workaround. I found one that IMHO is even more precise (less global impact). For xsane, scanimage, and gimp (and any others I might run in to, make a script in /usr/local/bin of the following form: #!/bin/csh -f set noglob setenv LD_LIBRARY_PATH /usr/lib exec /usr/bin/xsane $* The run time overhead for this appears to be negligible. Thanks again for the quick resolution--at least to the workaround stage.
*** Bug 110906 has been marked as a duplicate of this bug. ***
This seems to affect 7.3, 8.0 and 9.
Probably not 7.3, because I haven't touched 7.3 ldconfig, just 8.0/9.
Okay. Robert, here is an experimental fixed package for 8.0. Could you please verify that it fixes the problem for you? ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.3.i386.rpm
I will download and try it at my earliest opportunity. Best case would be this evening or tomorrow afternoon.
Best case worked out. It seems to be working. I can do "/usr/lib/scanimage -L" and "/usrlib/xsane" and get the expected or correct results. Doing "file `rpm -ql sane-backends`" shows the new package has dropped the symlink to the v4l-related library and a ton of .man files from /usr/share/doc. Was the last omission intentional? (No answer needed.) Is there any reason I should back out this experimental package and revert to the workaround? Will this package be released to production for 8.0?
Has to go through QA first, but yes I hope this will be released as an official update.
*** Bug 110110 has been marked as a duplicate of this bug. ***
The solution used in 1.0.8-5.3 was not the best one available. Please try this replacement: ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.4.i386.rpm and please let me know that it still keeps the problem fixed.
Nope. The new 5.4 package breaks it. This new package brought back /usr/lib/sane/libsane.so.1 as a symbolic link to libsane-v4l.so.1.0.8, and the latter apparently only looks for v4l devices, not USB (or other?) scanners. I reverted to the 5.3 package, and it works again. (In a week or three, I plan to move to RHL 9, so I won't be able to test more RHL 8.0 packages. Of course, in a week, EOL will make it irrelevant for 8.0, and EOL is why I'm moving to RHL 9 until April, when I will have to move to another distribution. Don't know which it will be: maybe Fedora, maybe something else, because I can't afford $540 per year, especially for only a partial distribution.)
Please try: ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.5.i386.rpm which really should fix the problem. Sorry about that.
I hate to be the bearer of bad news, but this one failed for me, too. It appears something, likely one of the post-install scripts, is creating /usr/lib/sane/libsane.so.1 as a symlink to libsane-v4l.so.1.0.8, and this causes the problem, given the new ldconfig search policy in the new glibc from back in November.
I can test 8.0 stuff if any more is created.
Oops. Please try 1.0.8-5.6. If you tried one of the experimental fixes, please downgrade to the official 1.0.8-5.2 upgrade using 'rpm -Uvh --oldpackage sane-backends-*1.0.8-5.6*' first. ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.6.i386.rpm ftp://people.redhat.com/twaugh/tmp/sane-backends-devel-1.0.8-5.6.i386.rpm
..and experimental packages for Red Hat Linux 9 are here: http://cyberelk.net/tim/data/tmp/sane-backends-1.0.9-5.5.i386.rpm http://cyberelk.net/tim/data/tmp/sane-backends-devel-1.0.9-5.5.i386.rpm
The 1.0.8-5.6 packages for RHL 8.0 from comment #21 appear to work for me. Thanks!
This works for me, both for launching xsane directly and from gimp-1.2. (Using a script wrapper didn't like launching xsane from gimp for some reason).
I experienced this problem with RHL8 and 9. I found that the fix was to the sane-backends rpm's postinstall script: eliminate /usr/lib/sane from /etc/ld.so.conf. (I see that this is the fix that Tim has implemented, but I think that it is worth mentioning here.) I wonder if the same bug is in Fedora Core 1. The symlink in /usr/lib/sane/libsane.so.1 is there, but no longer to libsane-v4l. /usr/lib/sane still appears in /etc/ld.so.conf, contrary to what /usr/share/doc/xsane*/xsane.PROBLEMS specifies. I don't have FC1 and a scanner on the same system to test.
In case it helps cross-correlate any other observations, my main machine is now running RHL 9, stock plus updates, and here is what I see, with only the stock, official, packages: sane-find-scanner finds the scanner twice, as /dev/usb/scanner0 and as libusb:002:002. scanimage -L finds my BTTV card, dev/video0 but not the scanner. xsane finds both the scanner (once) and the BTTV card. I use xsane, so I'm happy, for now.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-043.html
Hi, I am on Fedora CORE 1 Kernel 2.4.22-1.2166.nptl the rest is upgrade to newest and greatest. My printer/scanner is HP PSC 2175. I must say I went to Fedora since I had tremendous problems on Redhat 7.3.3, although eventually "xsane" works fine. Unfortunately, I cannot upgrade security upgrades of this old kernel (==> kernel crashes, when switching on printer) I have the exact problem as described in this error #110174. I tried to follow the advice given in the Comments about this bug but to no avail. The sane related installed packages are: xsane-gimp-0.91-1 sane-frontends-1.0.11-3 sane-backends-devel-1.0.12-4 sane-backends-1.0.12-4 xsane-0.91-1 libsane-hpoj-0.90-19 I find my scanner with "sane-find-scanner" found USB scanner (vendor=0x03f0, product=0x2b11) at libusb:001:005 However "scanimage -L" finds nothing. How to get it work>>
Frank, it's not clear what product or version you are running -- in any case, it doesn't seem to be Red Hat Linux 8.0 or Red Hat Linux 9, and if you are running Fedora Core 1 it is certainly a different problem you are seeing. Please file a separate bug report, including as much detail as you can. Thanks.
On RHL 9, I just updated to the just-released sane-backends-1.0.9-5.5, and everything looks grand: sane-find-scanner finds the scanner as /dev/usb/scanner0 and as libusb:002:003, scanimage -L finds both the BTTV card and hp:/dev/usb/scanner0, and xsane finds both. Tim, thanks for the update.