Revision history [back]

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

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

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

P.P.S.: Quick and dirty workaround:

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

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

P.P.S.: Workarounds

1. Quick and dirty workaround:

   fix, when the version displayed by ssu re differs from the output of version:
   
   A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

2. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

   [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 osupdate-check.timer.orig

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

P.P.S.: 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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

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

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
● 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

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

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: To point to trigger of the offender:

[root]# systemctl --user status osupdate-check
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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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 and Patchmanager. Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: To point to 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). ).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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: 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. dependencies.
Hence this affects the tools store-client, pkcon, rpm, libzypp and zypper supplied by Jolla, plus third party tools as Storeman and Patchmanager. Patchmanager.
Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: To point to 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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 and Patchmanager.
Letting any of these tools update all packages it manages results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: To point 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user unit again):

[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 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 this timer unit, but a deleted link is harder to remember when one wants to revert this change.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this user timer unit again):

[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 user-session.target.wants/osupdate-check.timer /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 this the timer unit, unit proper, but a deleted link is harder to remember when one wants to revert this change.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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 (by executing rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer ) instead of renaming the timer unit proper, proper (in the last line above), but a deleted link is harder to remember when one wants to revert this change.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client).). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps, plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final "Final clean up"-stepsup"-steps, plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

Observed for years 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.

P.S.: 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]#

P.P.S.: Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps, plus a zypper ref (if zypper zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

Context:

###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:
###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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work properly or even a completely broken SailfishOS installation.

Resolution:
###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 | rev | cut -f 2 -d ' ' | rev 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.

P.S.: To #####To depict the trigger of the offender: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]#

P.P.S.: Workarounds###Workarounds

a. Quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps, plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A semi-permanent fix, preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work properly or even a completely broken SailfishOS installation.

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 | rev | cut -f 2 -d ' ' | rev shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.

[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]#

[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

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev 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. Quick a. A quick fix, when the version displayed by ssu re differs from the output of version:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps, plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs or (if these are untraceable) perform a factory reset of SailfishOS.

b. A b. An additional, semi-permanent fix, fix preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again):

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev 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:

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps, plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again):again)

[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.

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 and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS to work 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

[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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

[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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

[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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

[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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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

Old

Former description of step b:*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.

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 Storeman and Patchmanager.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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours and maybe also by the store-client). hours). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up"-steps steps" plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one has to should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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 | rev | cut -f 2 -d ' ' | rev 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

A Issuing these commands (as root) ssu re "$(version | rev | cut -f 2 -d ' ' | rev)" (as root) rev)
pkill store-client
rm -f /home/nemo/.cache/sailfish-osupdateservice/os-info /home/nemo/.cache/store-client/os-info
followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours). After rebooting either run post_sfos-upgrade (if sfos-upgrade is installed) or manually execute the "Final clean up steps" plus a zypper ref (if zypper is installed) and a pkcon refresh!
But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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 | rev | cut -f 2 -d ' ' | rev 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. A quick fix, when the version displayed by ssu re differs from the output of version

Issuing these commands (as root)

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)
 pkill store-client
 rm -f /home/nemo/.cache/sailfish-osupdateservice/os-info /home/nemo/.cache/store-client/os-info
 rev)

(which sets SSU to the installed version), followed by a reboot resolves the issue until sailfish-osupdateservice osupdate-check is started again (every couple of hours). After rebooting reboot.
Then either run post_sfos-upgrade (if sfos-upgrade is installed) installed)
or manually execute the "Final clean up steps" (specifically killing the store-client followed by removing its SailfishOS upgrade release version info) plus a zypper ref (if zypper is installed) and a pkcon refresh!
.

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

b. b. An additional, semi-permanent fix preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a.!

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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)

(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 SailfishOS upgrade release version info) plus a zypper ref (if zypper is installed) and a pkcon refresh.

But if RPMs were updated or installed while ssu was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a.! (or redo it, 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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)

(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 were updated or installed while ssu was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo it, 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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)

(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 were updated or installed while ssu SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo it, 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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)
rev)"

(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 were updated or installed while SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo it, 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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)"

(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 were updated or installed while SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo it, 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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)"

(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 were updated or installed while SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs 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 (performing a SailfishOS upgrade may install this timer unit again)

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: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.

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 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 | rev | cut -f 2 -d ' ' | rev 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)"

(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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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 | rev | cut -f 2 -d ' ' | revgrep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*')" 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 (every couple of hours), issue

[root]# ssu re "$(version | rev | cut -s -f 2 -d ' ' | rev)"
grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*')"

(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 (performing a SailfishOS upgrade may install this timer unit again)

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.

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 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]*')" 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 (every couple of hours), issue

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

(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 (performing

Note that performing a SailfishOS upgrade may install this timer unit again)again.

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.

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 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]*')"'[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 (every couple of hours), issue

[root]# ssu re "$(version | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*')"
'[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 may install this timer unit again.

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.

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 (every couple of hours), 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 may install this timer unit again.

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.

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 (every couple of hours), 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) 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 may install this timer unit again.

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.

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')"'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 (every couple of hours), 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 may install this timer unit again.

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.

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 (every couple of hours), 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 may install 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 simple
rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer (as root) 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.

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 (every couple of hours), (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.