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
