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
