[Bug] /usr/libexec/sailfish-osupdateservice osupdate-check sets ssu re

asked 2019-05-25 18:28:31 +0200

olf
10393 ●104 ●201 ●158

updated 2020-05-06 18:44:50 +0200

Table of content

• Context
• Bug description
• Resolution
• Environment
  • To depict the trigger of the offender
• Workarounds

Context

SailfishOS' systemd user unit osupdate-check.timer regularly triggers the systemd user unit osupdate-check.service, which executes /usr/libexec/sailfish-osupdateservice osupdate-check.

Bug description

/usr/libexec/sailfish-osupdateservice osupdate-check sets SSU to the latest release or next "stop release" of SailfishOS, instead of solely checking, if a new release is available and then notifying the user.
The severe consequences do not immediately become apparent to the user:
All tools and applications relying on the package management might offer and incorrectly install RPMs for a newer SailfishOS release than the installed one, or they might fail to install RPMs due to incorrectly resolved dependencies.
Hence this affects the tools store-client, pkcon, rpm, libzypp and zypper supplied by Jolla, plus third party tools as Storeman / Warehouse (Openrepos client apps) and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS not working properly or even a completely broken SailfishOS installation.

Resolution

Let /usr/libexec/sailfish-osupdateservice osupdate-check only perform the check and, if positive, emit an notification, but do not let it set SSU to a different release version than the installed one.
Consequently the output of version | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*' | sed -n '1p' shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Environment

Observed for many months (if not years) on Jolla 1 phones and an Xperia X, each time I did not upgrade to the recent SailfishOS "GA (general availability)" release immediately. Finally I found the time to analyse this annoying issue.

To depict the trigger of the offender

[root]# systemctl --user status osupdate-check.service
● osupdate-check.service - Store client os update check
Loaded: loaded (/usr/lib/systemd/user/osupdate-check.service; static; vendor preset: enabled)
Active: inactive (dead) since Sat 2019-05-25 15:47:30 CEST; 1min 39s ago
Process: 7275 ExecStart=/usr/bin/invoker --type=silica-qt5 -n -d 5 /usr/libexec/sailfish-osupdateservice osupdate-check (code=exited, status=0/SUCCESS)
Main PID: 7275 (code=exited, status=0/SUCCESS)
[root]#

Workarounds

a. A quick fix, when the version displayed by ssu re differs from the output of version

To resolve this issue until sailfish-osupdateservice osupdate-check is started again (10 minutes after a reboot plus every 7 hours 54 minutes), issue

[root]# ssu re "$(version | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*' | sed -n '1p')"

(which sets SSU to the installed version), followed by a reboot.
Then either run post_sfos-upgrade (if sfos-upgrade is installed)
or manually execute the "Final clean up steps" (specifically killing the store-client followed by removing its cached SailfishOS upgrade release version info),
plus a zypper ref (if zypper is installed) and a pkcon refresh.

But if RPMs or Patchmanager Patches were updated or installed while SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs / Patches or (if these are untraceable) perform a factory reset of SailfishOS.

b. An additional, semi-permanent fix preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer

Note that performing a SailfishOS upgrade enables this timer unit again.
Thus redo step b. each time after upgrading Sailfish OS, until Jolla has fixed this (apparently not in SailfishOS 3.3.0).

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo a. after b., if you have already carried out step a.), because meanwhile the sailfish-osupdateservice osupdate-check may have been triggered again (until step b. is done)!

Edit (2019-06-04): A simple
rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer (as root)
followed by a reboot is fully sufficient for performing this step b..

Former description of step b.:

[root]# systemctl --user stop osupdate-check.timer
[root]# systemctl --user disable osupdate-check.timer
[root]# cd /usr/lib/systemd/user/
[root]# mv osupdate-check.timer osupdate-check.timer.orig

A slightly cleaner semi-permanent fix is to remove the symbolic link /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer -> ../osupdate-check.timer (by executing rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer) instead of renaming the timer unit proper (in the last line above), but a deleted link is harder to remember when one wants to revert this change.