Red Hat Bugzilla – Full Text Bug Listing
|Summary:||glibc update breaks xsane scanning|
|Product:||[Retired] Red Hat Linux||Reporter:||Robert M. Riches Jr. <rmriches>|
|Component:||sane-backends||Assignee:||Tim Waugh <twaugh>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||8.0||CC:||danielfdickinson, frank.schmidt, hugh, jakub, jari.oksanen, keith.adamson, nclnxusr|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-03-01 15:33:05 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Robert M. Riches Jr. 2003-11-15 21:59:25 EST
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.
Comment 1 Michael 2003-11-16 12:42:49 EST
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).
Comment 2 Ulrich Drepper 2003-11-20 13:03:37 EST
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.
Comment 3 Robert M. Riches Jr. 2003-11-21 14:40:49 EST
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 ...).
Comment 4 Robert M. Riches Jr. 2003-11-21 14:54:14 EST
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.
Comment 5 Robert M. Riches Jr. 2003-11-22 20:29:58 EST
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.
Comment 6 Jakub Jelinek 2003-11-23 05:38:00 EST
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.
Comment 7 Robert M. Riches Jr. 2003-11-24 19:15:30 EST
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.
Comment 8 Jakub Jelinek 2003-11-25 09:37:59 EST
*** Bug 110906 has been marked as a duplicate of this bug. ***
Comment 9 Tim Waugh 2003-12-03 07:00:07 EST
This seems to affect 7.3, 8.0 and 9.
Comment 10 Jakub Jelinek 2003-12-03 07:02:42 EST
Probably not 7.3, because I haven't touched 7.3 ldconfig, just 8.0/9.
Comment 11 Tim Waugh 2003-12-03 08:12:50 EST
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
Comment 12 Robert M. Riches Jr. 2003-12-03 13:30:51 EST
I will download and try it at my earliest opportunity. Best case would be this evening or tomorrow afternoon.
Comment 13 Robert M. Riches Jr. 2003-12-03 22:02:53 EST
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?
Comment 14 Tim Waugh 2003-12-04 12:22:10 EST
Has to go through QA first, but yes I hope this will be released as an official update.
Comment 15 Tim Waugh 2003-12-23 10:31:56 EST
*** Bug 110110 has been marked as a duplicate of this bug. ***
Comment 16 Tim Waugh 2003-12-23 10:35:37 EST
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.
Comment 17 Robert M. Riches Jr. 2003-12-23 18:56:49 EST
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.)
Comment 18 Tim Waugh 2003-12-24 04:45:33 EST
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.
Comment 19 Robert M. Riches Jr. 2003-12-27 17:30:42 EST
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.
Comment 20 Daniel F. Dickinson 2003-12-31 19:59:47 EST
I can test 8.0 stuff if any more is created.
Comment 21 Tim Waugh 2004-01-02 08:50:20 EST
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
Comment 22 Tim Waugh 2004-01-02 09:32:52 EST
..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
Comment 23 Robert M. Riches Jr. 2004-01-02 17:08:18 EST
The 1.0.8-5.6 packages for RHL 8.0 from comment #21 appear to work for me. Thanks!
Comment 24 Daniel F. Dickinson 2004-01-03 22:32:11 EST
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).
Comment 25 D. Hugh Redelmeier 2004-01-23 03:52:44 EST
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.
Comment 26 Robert M. Riches Jr. 2004-01-23 14:10:49 EST
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.
Comment 27 Tim Powers 2004-03-01 15:33:05 EST
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
Comment 28 Frank Schmidt 2004-03-04 15:58:49 EST
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>>
Comment 29 Tim Waugh 2004-03-05 12:20:55 EST
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.
Comment 30 Robert M. Riches Jr. 2004-03-06 11:59:51 EST
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.