Upgrading SailfishOS at the GUI (via Settings→SailfishOS updates) provides very little information about its progress / process / success, beyond reading /var/log/systemupdate.log
after an upgrade. This can make troubleshooting issues hard.
Furthermore the GUI offers no control which SailfishOS version to upgrade to.
In contrast to that, Jolla's guide how to upgrade SailfishOS at the command line offers full control, while lacking any logs or safety checks.
Furthermore it is tedious and error prone to issue multiple, critical commands manually at the command line.
sfos-upgrade performs the steps to upgrade SailfishOS at the command line in an automated manner, while providing extensive safety measures plus full log output at the screen and in a log file.
Safety measures:
Usage (as root user):
sfos-upgrade [\<version>]
With a version number provided as parameter, it sets SSU to this version and in release mode before upgrading to this SailfishOS version. This is the regular use case.
Without a version number, it retrieves the one set for SSU to perform slightly relaxed checks, but does not alter SSU's settings for upgrading. Hence the version to upgrade to and SSU's "release mode" have to be set (by e.g. ssu re <version>
) before executing sfos-upgrade
without a parameter.
sfos-upgrade --verify
Performs a "samegrade" operation, i.e. checks if the recent versions of all available RPMs are installed and updates or installs them accordingly.
This option was introduced with v3.7.0.
sfos-upgrade -?|--help
Emits a brief usage description.
When an upgrade succeeded, reboot, and do not miss to run post_sfos-upgrade (as root) then!
When sfos-upgrade failed, run post_sfos-upgrade (as root) before rebooting and then run sfos-upgrade again.
Not running post_sfos-upgrade (in either case) will result in an huge upgrade log file (containing many duplicate entries), plus may result (as any SailfishOS upgrade at the command line without tidying efforts afterwards) in RPMs failing to install (with "unmet dependency" / "Fatal error: nothing provides X needed by Y" errors) and annoying notifications from the store-client that an upgrade to the installed version is available.
Logs are originally written to /var/log/systemupdate_*.log-dupes.txt
and tidied by tidy_log-dupes (which is called by post_sfos-upgrade) to /var/log/systemupdate_*.log.txt
.
Notes:
sfos-upgrade <intended version>
, reboot, and repeat: it will guide you through all stop releases.post_sfos-upgrade
between consecutive SailfishOS upgrades (but do reboot each time!). But you shall run it after having upgraded to any SailfishOS release ≥ 4.1.0 or the ultimately intended version.sfos-upgrade --verify
; this will "samegrade" to the installed version, which is as close as one can get to the version --verify
lost since SailfishOS 2.2.1 (which only checked for missing or not up-to-date RPMs, while "samegrading" will also install them) without zypper. With it (per pkcon install zypper
), a zypper refresh && zypper verify --dry-run
comes closer to what version --verify
did (only checking). While zypper can also be used for up-/down-/same-grading, that is rather a "last resort"-measure than the primary recommendation, hence use sfos-upgrade for that.ssu re
and version --dup
, performing a multitude of checks before initiating the upgrade proper, while post_sfos-upgrade carries out the "Final clean up" steps from Jolla's manual upgrade guide plus an also necessary pkcon refresh
, which some seem to omit when upgrading manually at the command line (often running into aforementioned issues later, then).