Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

Ansgar ansgar at 43-1.org
Wed Nov 27 16:42:10 GMT 2019


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)?

That are the only three ways I currently can come up with how to end
with the files there.

What is the output from

  sha256sum /usr/bin/systemd-machine-id-setup
  readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH

We could check if that binary is identical to one provided by Debian;
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



More information about the Pkg-systemd-maintainers mailing list