Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
Hi Simon This is embarassing but I found now what was the issue. There is one package that I installed some months ago that was not from Debian repos and for some reason it installs /lib/libusb. It's not even a deb file which is why dpkg-query does not know about it. The package in question is xiAPI, from ximea, a company for microscope cameras https://www.ximea.com/support/wiki/apis/xiAPI . Without the whole working from home thing, I would have never have installed on my computer. I'm very sorry for the noise. Thank you for the help, it was the process of answering your questions, and searching for other libs that dpkg did not know about, that made me remember this. David
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
dpkg maintainers: This looks similar to #896019 in GLib and #948318 in libcrypt, except instead of their transition from /lib/MULTIARCH to /usr/lib/MULTIARCH, it involves libusb's transition from /lib to /lib/MULTIARCH. I'm worried that we might see this more often as more /lib libraries, like libdbus in experimental, transition from /lib to /usr/lib. If we need to be preemptively detecting and fixing up this sort of thing in all packages that move libraries from one directory to another, then the script in https://salsa.debian.org/gnome-team/glib/-/merge_requests/9 might be a useful basis for that - review and testing would be appreciated. On Fri, 23 Oct 2020 at 22:10:11 +0100, Carnë Draug wrote: > I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0" > (provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which > seems to be what is loaded Please move that file to another directory for further investigation, for example: mkdir /lib/removed-for-bug-972703 mv /lib/libusb-1.0.so.0* /lib/removed-for-bug-972703/ (This should fix the immediate failure.) Then please send the results of: ls -l /lib/removed-for-bug-972703/* md5sum /lib/removed-for-bug-972703/* It would also be interesting to know whether there are other libraries in /lib and /usr/lib that dpkg doesn't know about: find /lib /usr/lib -name '*.so.*' | while read -r x; do dpkg -S "$x" >/dev/null; done You'll get messages on stderr like: dpkg-query: no path found matching pattern /lib/removed-for-bug-972703/libusb-1.0.so.0 Some of the results of this will be files that are managed by alternatives, like /usr/lib/x86_64-linux-gnu/libblas.so.3, which are harmless - but others might not be. > Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker > cache), makes it load the right libusb [...] > And gnome-boxes now works properly. This seems reminiscent of rare upgrade issues that we've seen before in GLib, when libglib-2.0.so.0 moved from /lib/x86_64-linux-gnu to /usr/lib/x86_64-linux-gnu - but you're maybe seeing it for a previous transition, when libusb-1.0.so.0 moved from /lib to /lib/x86_64-linux-gnu. > The thing is, I have no idea where this /lib/libusb came from. I'm > pretty sure I didn't install anything other than debs from the > official debian repos. dpkg-query also does not know which package > installed it: > > $ dpkg-query -S /lib/libusb-1.0.so.0.1.0 > dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0 The libusb-1.0-0 package installed /lib/libusb-1.0.so.0 before 2011. The ls -l and md5sum output will help to determine whether this is an outdated version from Debian, or a different version from outside Debian. Are these old Debian installations that were installed before 2011 and have been upgraded since then? If yes, did they have unreliable disks, frequent crashes, or anything like that in the 2011-2012 timeframe? > Any clues > where that file came from and what it may be used for? The best theory I have at the moment is: when you upgrade from an old package to a new package, and the new package ships different files, dpkg is meant to delete the old file, leaving only the new file. It is possible that there is a rare bug that causes it to *not* delete the old file. If that happens, then ldconfig prefers the new file, and you don't immediately notice that anything is wrong. Perhaps years later, the library moves from a lower-priority directory in the search path to a higher-priority directory, and suddenly ldconfig will be preferring the older version: but you *still* don't notice anything is wrong until a different program or library (in your case libusbredirhost.so.1 and qemu) requires a symbol that wasn't available in the new version. smcv
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
On Thu, 22 Oct 2020 at 21:47, Simon McVittie wrote: > > On Thu, 22 Oct 2020 at 19:14:54 +0100, David Miguel Susano Pinto wrote: >> gnome-boxes does not start. Trying from command line, issues this error: >> >> $ gnome-boxes >> gnome-boxes: symbol lookup error: >> /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: >> libusb_set_option >> >> Similar issue when starting qemu: >> >> $ qemu-system-x86_64 >> qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined >> symbol: libusb_set_option > > It starts fine on a Debian 10 system for me. According to > /var/lib/dpkg/info/libusb-1.0-0:amd64.symbols, that symbol has been provided > by libusb-1.0-0 since version 2:1.0.22, which you have. > > Do you have an older version of libusb-1.0.so.0 somewhere in the library > search path, perhaps in /usr/local/lib? I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0" (provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which seems to be what is loaded: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x7f49d1393000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7f49c88fb000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7f49c88f00 Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker cache), makes it load the right libusb: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x7fc22ff71000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7fc2274b3000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7fc2274a8000) And gnome-boxes now works properly. The thing is, I have no idea where this /lib/libusb came from. I'm pretty sure I didn't install anything other than debs from the official debian repos. dpkg-query also does not know which package installed it: $ dpkg-query -S /lib/libusb-1.0.so.0.1.0 dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0 I have one other Debian machine which has the same file. Any clues where that file came from and what it may be used for? Thank you David
Processed: Re: Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
Processing control commands: > tags -1 + moreinfo unreproducible Bug #972703 [gnome-boxes] gnome-boxes does not start, undefined symbol libusb_set_option Added tag(s) moreinfo and unreproducible. -- 972703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
Control: tags -1 + moreinfo unreproducible On Thu, 22 Oct 2020 at 19:14:54 +0100, David Miguel Susano Pinto wrote: > gnome-boxes does not start. Trying from command line, issues this error: > > $ gnome-boxes > gnome-boxes: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: > libusb_set_option > > Similar issue when starting qemu: > > $ qemu-system-x86_64 > qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined > symbol: libusb_set_option It starts fine on a Debian 10 system for me. According to /var/lib/dpkg/info/libusb-1.0-0:amd64.symbols, that symbol has been provided by libusb-1.0-0 since version 2:1.0.22, which you have. Do you have an older version of libusb-1.0.so.0 somewhere in the library search path, perhaps in /usr/local/lib? smcv
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
Package: gnome-boxes Version: 3.30.3-2 Severity: grave Justification: renders package unusable Dear Maintainer, gnome-boxes does not start. Trying from command line, issues this error: $ gnome-boxes gnome-boxes: symbol lookup error: /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: libusb_set_option Similar issue when starting qemu: $ qemu-system-x86_64 qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined symbol: libusb_set_option There is also issue #960330 for virt-viewer with the same error. Thank you -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-boxes depends on: ii dconf-gsettings-backend [gset 0.30.1-2 ii libarchive13 3.3.3-4+deb10u1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libfreerdp2-2 2.0.0~git20190204.1.2693389a+dfsg1-1+deb10u2 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgovirt2 0.3.4-3.1 ii libgtk-3-0 3.24.5-1 ii libgtk-vnc-2.0-0 0.9.0-1.1 ii libgudev-1.0-0 232-2 ii libosinfo-1.0-01.2.0-1 ii libosinfo-bin 1.2.0-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii librest-0.7-0 0.8.1-1 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-1 2.64.2-2 ii libspice-client-glib-2.0-8 0.35-2 ii libspice-client-gtk-3.0-5 0.35-2 ii libtracker-sparql-2.0-02.1.8-2 ii libusb-1.0-0 2:1.0.22-2 ii libvirt-daemon 5.0.0-4+deb10u1 ii libvirt-glib-1.0-0 1.0.0-1 ii libwebkit2gtk-4.0-37 2.28.4-1~deb10u1 ii libxml22.9.4+dfsg1-7+b3 ii mtools 4.0.23-1 ii tracker2.1.8-2 Versions of packages gnome-boxes recommends: ii qemu-system-x86 1:3.1+dfsg-8+deb10u8 gnome-boxes suggests no packages. -- no debconf information
