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

[pvuorela]

Been doing some more testing here. Forced the ssu configuration to 4.5.0, avoiding all RnD modes etc and generally trying to make what a proper 4.5.0 should be having. Then initiated check via the osupdateservice or OS update settings page.

At the same time printing out the versions in another shell: while [ true ] ; do ssu re; sleep 1; done

Result: there’s some 10-15 second window with the new version after it has found an update and doing the update size calculations. Then it rolls back to 4.5.0. Works as expected.

Can’t still figure out how this wouldn’t work. It should be restoring the ssu version being it success or failure to do the things.

For one last option, I’m pondering if there’s any chance those storeman/openrepos type of things could be messing up something. No idea how and e.g. extra repositories shouldn’t really matter. Still worth noting if someone has experienced the problem with just plain sailfish + harbour apps.

[attah]

@pvuorela

Result: there’s some 10-15 second window with the new version after it has found an update and doing the update size calculations. Then it rolls back to 4.5.0. Works as expected.

Let’s say that calculation fails for one reason or another - or something close to it, can it bail out past resetting the version?
Where in the code is this BTW? Looks to be doable from QML, but is that what (re-)sets it here?
(Then closing the app or something like that could be the culprit).

@pvuorela

No idea how and e.g. extra repositories shouldn’t really matter.

I think my SeaPrint sharing plugin was blamed for pulling in the update once; presumably by depending on a newer transfer-engine.

[pvuorela]

@attah

Let’s say that calculation fails for one reason or another - or something close to it, can it bail out past resetting the version?
Where in the code is this BTW? Looks to be doable from QML, but is that what (re-)sets it here?
(Then closing the

Should be resetting the version no matter if there was an error or not.

Code is unfortunately closed, the os update handler is part of store-client. Though it’s having a background daemon for doing its things, implemented in c++. No app to be closed.

The daemon crashing would sure explain it, but based on the initial report here, it exits with success.

@attah

I think my SeaPrint sharing plugin was blamed for pulling in the update once; presumably by depending on a newer transfer-engine.

Package dependencies shouldn’t matter. I’m thinking more of extra repositories or even something doing things with ssu config.

[olf]

@pvuorela, thank you very much for still trying to find the source of the disruptive behaviour of /usr/libexec/sailfish-osupdateservice osupdate-check, because IMO this issue (especially in conjunction with the “Remove the following packages”-issue) is the worst and most disruptive issue of SailfishOS which is outstanding for many years, as it results in broken SailfishOS installations which are unfixable for the average user without reflashing or a factory-reset.

@pvuorela

I’m thinking more of extra repositories or even something doing things with ssu config.

1. Extra repositories
   It is very likely that all reporters had some RPM repositories at OpenRepos enabled. SailfishOS is no fun at all without software from community repositories, so why would one not use them (maybe except for @vige).
   Additional notes:
   • For my devices I can tell for sure, that no OpenRepos repositories were / are enabled, which contain RPM packages which replace “system packages” (i.e. packages from Jolla’s RPM repos), i.e. the packages which are listed for removal when upgrading SailfishOS per GUI (known offending OpenRepos repos are lachs0r, lpr* and NielDK) since SailfishOS 3.4.0 (but this issue occurred years before SailfishOS 3.4.0), with a single exception: My Bluetooth OBEX Filter off, which I deem harmless (for reasoning, see the notes there).
   • The SailfishOS:Chum community repository (rsp. RPM repositories at SailfishOS-OBS in general) is very unlikely to contribute to this issue, because this issue occurred years before user were instructed to use RPM repos at at SailfishOS-OBS directly.
2. SSU configuration
   I think it is likely that most (all?) reporters of these issue used the command line to upgrade SailfishOS at least once: Either by executing the commands Jolla recommends (i.e. ssu re X.Y.Z.N && version --dup as root) or by using sfos-upgrade which does exactly the same. But I assume that does not constitute “distorting the SSU configuration” for you, right?
   P.S.: I always wondered, why one is not instructed to kill the store-client, empty zypper’s dist-upgrade cache (rm -f /home/.pk-zypp-dist-upgrade-cache/*), remove Jolla’s OS-info cache file (rm -rf $HOME/.cache/sailfish-osupdateservice/os-info) and / or kill ssud followed by removing its caches (rm -rf /var/cache/ssu/*) before executing the ssu re X.Y.Z.N command (which should also automatically start ssud again, as any ssu command), and / or executing ssu ur after the ssu re X.Y.Z.N but before the version --dup? Due to Jolla’s advice in aforementioned documentation (which consistently stayed the same, now already for a decade), I ultimately decided against performing these steps before upgrading SailfishOS in sfos-upgrade proper, but let the user perform them after upgrading SailfishOS by post_sfos-upgrade.
   a. Do I interpret Jolla’s documentation correctly?
   b. Would it be beneficial to employ these considerations, which I have been dismissing all the time? Or the contrary: May these extra commands cause any harm if employed as described before issuing version --dup?

P.S. / side note: In latest rework of Jolla’s documentation how to upgrade SailfishOS at the command line some sections with basically duplicated content were created (e.g. here and there, also here and there, and here, there and there). In general the variants of these sections lower on this page are the more modern ones, but one would have to consolidate them carefully with their corresponding sections further up in order to avoid eliminating any significant information.

Additionally statements were inserted which regularly confuse users, as “For instance, 4.5.0.25 is a stop release but 4.5.0.24 is not.”: This is not really correct, because all point releases of SailfishOS 4.5.0 constitute a sub-version of the same stop release, but it is recommended to upgrade to the latest point release of a stop release from a prior release (e.g. 4.4.0.N). I.e. Jolla’s GUI updater also does upgrade from 4.5.0.24 to 4.6.0.N directly, not from 4.5.0.24 to 4.5.0.25 first and then to 4.6.0.N, AFAIK.
Another such statement is “Never try to downgrade the OS version as this could brick your device.”, which is fearmongering IMO: This might likely make the installed SailfishOS instance unusable and may make it unbootable, but it will not damage hardware (as “brick your device” suggests), prevent using the recovery console, or prevent reflashing a Sony Xperia.

[pvuorela]

Quite a few things mentioned here. The “remove the following packages” I was planning on also checking but didn’t manage yet.

@olf

Either by executing the commands Jolla recommends (i.e. ssu re X.Y.Z.N && version --dup as root) or by using sfos-upgrade which does exactly the same. But I assume that does not constitute “distorting the SSU configuration” for you, right?

I would assume ‘ssu re’ stuff being ok, but can’t say I’m 100% confident on that. I might try do some more testing on that.

@olf

P.S.: I always wondered, why one is not instructed to kill…

Actually noticed the docs are out of date there. Suggests killing store-client while the update check is done with the sailfish-osupdateservice these days. Changed the wording there.

Then why not instructed to kill and clear stuff after ‘ssu re’: well, that should be only writing the mentioned version to ssu config. Os update doesn’t depend on it more than when starting the os update size calculations it stores the current version (fetched via Ssu::release(), doesn’t use daemon) and then restores the same version when calculations are done.

The osupdateservice killing is suggested because it caches the available update info in process. If just the files are deleted behind its back, it won’t notice.

Didn’t spot suggestions to kill ssud. But did spot ssud being way too eager to autostart and autoquit itself if just using the command line tool without need for the daemon. Did a PR for avoiding some silly behavior.

Adjusted the 4.5.0.24 stop release wording too.

@olf

Another such statement is “Never try to downgrade the OS version as this could brick your device.” , which is fearmongering IMO: This might likely make the installed SailfishOS instance unusable and may make it unbootable, but it will not damage hardware (as “brick your device” suggests), prevent using the recovery console, or prevent reflashing a Sony Xperia.

Depending on the device might be also that recovery or reflashing are not available even if for Xperias those are. And even otherwise couldn’t recommend that. We implement migration (database schema updates, rpm .spec stuff etc) when going forward, but not backwards.

[pvuorela]

Regardless of if I’m able to reproduce this, got thinking that maybe should do something more to ensure the version gets reset. After all there can be something unexpected happening e.g. device is restarted while the update check is doing these parts, or device runs out of battery, osupdateservice crashes or whatever.

Syncing the installed version to ssu might be too much, as it might have been manually adjusted, but maybe something like storing the previous version to a file when ssu override is being done, clearing that when reset back, or if osupdateservice gets started with a leftover override, then reset to that.