Red Hat Bugzilla – Bug 110174
glibc update breaks xsane scanning
Last modified: 2007-04-18 12:59:31 EDT
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):
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.
"No devices available"
Xsane should find the scanner and use it.
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)
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
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:
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
*** 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?
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
*** 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:
and please let me know that it still keeps the problem fixed.
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
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.
..and experimental packages for Red Hat Linux 9 are here:
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,
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.
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:
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
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.