On 27/11/2019 16:42, Ansgar wrote: > On Wed, 2019-11-27 at 15:22 +0000, Graham Cobb wrote: >>> I suspect there are some old binaries (from systemd-241) around for >>> some reason. >> >> That does seem to be the case. > > Did you ever (a) install systemd yourself, or (b) tried to convert the > system to merged-/usr (for example with the "usrmerge" program from the > package of the same name), or (c) copied these files manually there > (maybe something else expected them in /usr)?
No. I am sure I didn't do any of those things. > > That are the only three ways I currently can come up with how to end > with the files there. I have checked my online snapshot backups (these only go back 3 months) and I can see that the /usr/bin/systemd-machine-id-setup and /bin/systemd-machine-id-setup versions of the file are both present in all the snapshots. Also, in all but today's backup, /usr/lib/systemd/libsystemd-shared-241.so and /lib/systemd/libsystemd-shared-241.so are both present, but are different. That would be consistent with assuming the /usr versions got created some time before the upgrade to 241-7 and the non-/usr versions then got upgraded to 241-7 (slightly different but still 241). I will see if I can find anything other backups, but we may never know, I guess. > > What is the output from > > sha256sum /usr/bin/systemd-machine-id-setup # sha256sum /usr/bin/systemd-machine-id-setup 681145a9d0aefd9289281118ee8dd72ce0cad560b768149dfc96d3e5d338da8e /usr/bin/systemd-machine-id-setup > readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH # readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/lib/systemd] > We could check if that binary is identical to one provided by Debian; I am guessing it would be the 241-5 version as the dates are consistent. > the `readelf` command should list `/lib/systemd` as a directory where > the binary looks for shared libraries (it not being `/usr/lib/systemd` > is the reason it failed). > >> I note that dpkg -S can find packages responsible for the /bin >> executables but not the /usr/bin ones: >> >> # dpkg -S /bin/systemd-machine-id-setup >> systemd: /bin/systemd-machine-id-setup >> # dpkg -S /usr/bin/systemd-machine-id-setup >> dpkg-query: no path found matching pattern /usr/bin/systemd-machine-id-setup > > Note that on a merged-/usr system that would still be the case as dpkg > doesn't care about the /bin -> /usr/bin symlink and just puts the file > into /bin, following the symlink. dpkg's database would still record > the file under /bin. > > Ansgar >
