[BUG] After updating to 4.4.0 getting lib preload error even after uninstalling Patchmanager

[JacekJagosz]

SailfishOS VERSION (Settings → About product → Build): 4.4.0
HARDWARE (Settings → About product → Manufacturer & Product name): Sony Xperia 10
PATCHMANAGER VERSION (Settings → Patchmanager → [Top pulley] About): 3.2.2

BUG DESCRIPTION

Each time I enter the terminal or execute a command I get ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. printed many times. This keeps happening even after I uninstalled Patchmanager.

STEPS TO REPRODUCE

Had newest Patchmanager on 4.3.0 with option to apply patches at boot enabled. Installed 4.4.0 through GUI.

ADDITIONAL INFORMATION

(Please consider which other pieces of information may be relevant, e.g. denote if this is not always reproducible, if it is a regression, attach relevant data such as log files or the systemd journal, provide screenshots etc.)

[JacekJagosz]

Ok, I managed to fix it by removing /usr/lib/libpreloadpatchmanager.so from /etc/ld.so.preload

[Olf0]

@JacekJagosz, thank you for your comprehensive report. While the fact that Patchmanager currently fails on SailfishOS 4.4.0 is not nice at all, your bug report really is. Thank you!

We are trying to analyse the issue.

For the sub-issue why this message persists after removing ("uninstalling") Patchmanager, I have to admit I am confused, because libpreloadpatchmanager.so should be unregistered form /etc/ld.so.preload by the %postun section of Patchmanager's spec file.

Hence my question: How did you remove Patchmanager and did that work flawlessly (i.e., without any errors or warnings)?

P.S.: I am also really astonished by the reference to Patchmanager 2.3.3 at FSO in this context. Upgrade at the CLI (likely version --dup) stalled with:

Finished transaction (status=1, runtime=129586ms)
UPGRADING SYSTEM
[67 %] [Install] patchmanager 2.3.3-10.41.1.jolla: [100 %]

[nephros]

Note that /var/log/zypp/history should contain output from the %post macro, so if there is something interesting there please share it.

[JacekJagosz]

I am very confused. After update to 4.4.0 the Patchmanager seemed broken. When I entered its page in settings I only got a spinning wheel, which was the only result I could get. Not patch was applied either. I also was getting those terminal error I mentioned. I uninstalled it using pkcon, don't know if that makes a difference, but /var/log/zypp/history tell me nothing:

# 2022-03-21 22:47:13 patchmanager-2.3.3-10.41.1.jolla.armv7hl removed ok
# Additional rpm output:
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ig
nored.
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ig
nored.
# Uninstalling package
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ig
nored.
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ig
nored.
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
# Uninstalling package
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
# ERROR: ld.so: object '/usr/lib/libpreloadpatchmanager.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
# 
2022-03

The weirdest thing is that patchmanager does work on 4.4.0. After a suggestion of @lolek on forum.sailfishos.org I installed it manually from chum and it does work flawlessly, not even terminal errors. So that is good news, you probably don't need to patch anything for 4.4.0. Just weird it didn't survive the update. Maybe it was just on my phone and will be fine for others?

[Olf0]

There it is again, a reference to Patchmanager 2.3.3 (in the first line of the part of the log you quoted)! According to lolek's post at FSO I quoted above, it became installed during the upgrade from SFOS 4.3.0 to 4.4.0. patchmanager-2.3.3-10.41.1.jolla is the last Patchmanager 2 version and Coderus still offers it at his Pachmanager 3.0 page at OpenRepos (and hence in his RPM repository there).

I assume you still have the coderus repository at OpenRepos enabled. Please check via ssu lr | fgrep coderus if that outputs a line containing openrepos-coderus. If it does, I suggest that you disable it via ssu dr openrepos-coderus.

Please report your results here, most importantly if you still had the coderus repository at OpenRepos enabled.

[Olf0]

BTW, user s_mario at FSO also reports that Patchmanager 3.2.2 compiled for SFOS 4.3.0 is installing and working fine on SFOS 4.4.0.

[nephros]

There it is again, a reference to Patchmanager 2.3.3 (in the first line of the part of the log you quoted)! According to the lolek's post at FSO I quoted above, it became installed during the upgrade from SFOS 4.3.0 to 4.4.0. patchmanager-2.3.3-10.41.1.jolla is the last Patchmanager 2 version and Coderus still offers it at his Pachmanager 3.0 page at OpenRepos (and hence in his RPM repository there).

I assume you still have the coderus repository at OpenRepos enabled. Please check via ssu lr | fgrep coderus if that outputs a line containing openrepos-coderus. If it does, I suggest that you disable it via ssu dr openrepos-coderus.

Please report your results here, most importantly if you still had the coderus repository at OpenRepos enabled.

I think this warrants a section in the Release Notes. Users should disable the coderus repo before upgrading if this can actually make the update fail. Users should also upgrade to our version if they have 2.x installed currently.

There's little we can do about that situation from here.

[JacekJagosz]

There it is again, a reference to Patchmanager 2.3.3 (in the first line of the part of the log you quoted)! According to the lolek's post at FSO I quoted above, it became installed during the upgrade from SFOS 4.3.0 to 4.4.0. patchmanager-2.3.3-10.41.1.jolla is the last Patchmanager 2 version and Coderus still offers it at his Pachmanager 3.0 page at OpenRepos (and hence in his RPM repository there).

I assume you still have the coderus repository at OpenRepos enabled. Please check via ssu lr | fgrep coderus if that outputs a line containing openrepos-coderus. If it does, I suggest that you disable it via ssu dr openrepos-coderus.

Please report your results here, most importantly if you still had the coderus repository at OpenRepos enabled.

YUP. I had this enabled! Thank you, hope others can now have smooth experience when upgrading!

[Olf0]

Ok, I managed to fix it by removing /usr/lib/libpreloadpatchmanager.so from /etc/ld.so.preload

Installing a current release of Patchmanager (> 3.1.0) also fixes this, see s_mario's last bullet point here.

[Olf0]

Summary & preliminary analysis

Something goes wrong in Jolla's upgrade procedure for SailfishOS 4.4.0: It automatically installs the (historic) patchmanager-2.3.3-10.41.1.jolla and hence removes and newer version of Patchmanager previously installed, when the RPM repository openrepos-coderus is enabled.

Note that patchmanager-2.3.3-10.41.1.jolla is oldest version of Patchmanager in that repository, so it appears as if something explicitly installs this version of Patchmanager. Which does sound very strange indeed.

No SailfishOS upgrade before this one (4.3.0 → 4.4.0) exhibited this behaviour.

Note that all reporters so far (e.g., JacekJagosz and lolek) seem to have upgraded SFOS 4.3.0 → 4.4.0 at the CLI (either by version --dup or sfos-upgrade, which uses version --dup).

[nephros]

Maybe this ancient version of PM does not have a dependency on librpm and hence is the one decided on by pkcon/zypper as the only installable version?

[JacekJagosz]

@nephros I think that is exactly what happened. Just after the update I uninstalled and was trying to install Patchmanager it, complained about lacking librpm.

[Olf0]

Maybe this ancient version of PM does not have a dependency on librpm and hence is the one decided on by pkcon/zypper as the only installable version?

Well, that is a build-dependency on rpm. But "Yes", it was introduced with PM 3.0, see spec-file of PM 3.0 versus spec-file of PM 2.0.

Does that translate into a run-time dependency, which can be checked with rpm -qR patchmanager? I still fail to fully comprehend what is happening.

[nephros]

rpmbuild adds runtime deps to the package dynamically, so even if there is no Requires: in the spec, if a binary in the package links against libfoo.so it will Require libfoo.so.

I think one can see those requirements using rpm -qR <name> (and rpm -qRp <file>.rpm), yes.

So my theory is that all PM versions except that old one link to a library version that is not present in 4.4, so none of them are installable.

A pkcon installor pkcon update --allow-downgrade will then select that old version if the coderus repo is enabled, unless there is a 4.3 chum repo active as well.
I would expect that configuration to be typical for a freshly upgraded device by a long-time user (so using PM, therefore has coderus repo enabled, plus hopefully the patchmanger repo and maybe chum). Also, because of the vendor field that chum sets, even an enabled chum repo will not be considered a valid upgrade path unless the currently installed patchmanager was already from chum and not from openrepos.

If that is so, one solution would be to put a special 4.3-compiled version (from Github CI, or OBS, but NOT Chum) on Openrepos, so updaters find a compatible version.

[Olf0]

A pkcon installor pkcon update --allow-downgrade will then select that old version if the coderus repo is enabled, ~unless there is a 4.3 chum repo active as well~. I would expect that configuration to be typical for a freshly upgraded device by a long-time user (so using PM, therefore has coderus repo enabled, plus hopefully the patchmanger repo and maybe chum). Also, because of the vendor field that chum sets, even an enabled chum repo will not be considered a valid upgrade path unless the currently installed patchmanager was already from chum and not from openrepos.

That is the point I missed. Thanks!

If that is so, one solution would be to put a special 4.3-compiled version (from Github CI, or OBS, but NOT Chum) on Openrepos, so updaters find a compatible version.

GitHub CI does not work for that AFAIU, see #303. As this should be done before SFOS 4.4.0 goes GA, I used OBS for that and uploaded these RPMs to OpenRepos.

[Olf0]

Vendor for PM 3.2.2 is now "meego" instead of "chum" at OpenRepos, before it was unset for the GitHub builds I used (PM 3.1 and 3.2, including 3.2.2) at OpenRepos. For PM 2 & 3.0 all RPMs have the vendor set to "meego", so I assume this should be fine (because PM 2.3.3 was installed on SFOS upgrade to 4.4.0), right?

[nephros]

Thank you.

I guess that should do it, although I'm not sure vendor change of "unset" -> "meego" or the other way around will work.

[Olf0]

I guess that should do it, although I'm not sure vendor change of "unset" -> "meego" […] will work.

I am sure it does, because …

[…] For PM 2 & 3.0 all RPMs have the vendor set to "meego", so I assume this should be fine (because PM 2.3.3 was installed on SFOS upgrade to 4.4.0), right?

the other way around

… is irrelevant, because that is not the case here.