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

[Graham Cobb]

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
>