This bug report was filed in May 2019 at TJC, received a “Tracked by Jolla” by @jiit plus some additional explanatory edits by me in June 2019, and some details were discussed in its comments with @pvuorela in July 2019: [Bug] /usr/libexec/sailfish-osupdateservice osupdate-check sets ssu re
The very last statement from Jolla in July 2019 was:
Need to investigate if there’s any chance of things going wrong.
Well “things”, specifically /usr/libexec/sailfish-osupdateservice osupdate-check do go awry, as documented back then and observed many times before doing so (as mentioned there).
Because Together.Jolla.com has been put into read-only state more than a year after this little, initial conversation about this issue, and the promised transfer of content from TJC to this forum never materialised, this issue has to be re-filed here to be able to track and discuss it any further.
I still would appreciate any feedback on the content of this issue (in contrast to formal feedback and questions, which were already answered).
I also do not have the impression that this issue was ever addressed technically, at least I have found nothing mentioned in the release notes and changelogs of SailfishOS releases ever since.
P.S.: Cut & Paste of the core content of this issue.
[Bug] /usr/libexec/sailfish-osupdateservice osupdate-check sets ssu re
Tracked by Jolla
asked May 25 2019
olf
10393 ●104 ●201 ●158
Table of content
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 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
Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo a. after b.), because meanwhile the sailfish-osupdateservice osupdate-check may have been triggered again (until step b. is done)!
To resolve this issue until sailfish-osupdateservice osupdate-check is started again (10 minutes after a reboot plus every 7 hours 54 minutes), issue (as 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 (i.e., always when doing this manually instead of using post_sfos-upgrade).
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 (obviously not in SailfishOS 3.3.0 and apparently also not in any later version of SailfishOS as of August 2021).
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.
