sfos-upgrade

Rating: 
4.933335
Your rating: None Average: 4.9 (30 votes)

Scripts for safe and automated upgrading of SailfishOS with logging

 
Upgrading SailfishOS at the GUI (per 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.
And 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:

  • Check free space on the root filesystem.
  • Check BTRFS allocation, if the root filesystem uses BTRFS.
  • Check battery state (since v1.0).
  • Check if upgrading to a correct and available SailfishOS version.
  • Check if omitting (i.e., "jumping over") a stop release (since v0.3).
  • Automatically unapply all Patches, if Patchmanager is installed.
  • Stop systemd services for cron, btrfs-balance-checker etc. (since v2.2).
  • Terminate running processes, which may disturb upgrading SailfishOS (since v2.7).
  • Disable all OpenRepos' repositories, when upgrading from a SailfishOS version below 1.0.4 (since v0.4).
  • Emit a warning when downgrading.
  • Prevent downgrades, which would likely break the SailfishOS installation (since v3).

 
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. 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.
  • sfos-upgrade -h|--help
    Emits a brief usage description.

When an upgrade succeeded, reboot, and do not miss to run post_sfos-upgrade (as root) then!
Not running it 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:

  • When upgrading from a long outdated SailfishOS version (e.g., after a "factory reset"), sfos-upgrade eases and speeds up the process of upgrading to a recent SailfishOS release via consecutively installing all "stop releases" on the way.
    Simply run sfos-upgrade <intended version>, reboot, and repeat: it will guide you through all stop releases.
    Omit running post_sfos-upgrade between consecutive SailfishOS upgrades (but do reboot each time!), only run it once after having upgraded to the intended version.
  • To ensure that a SailfishOS installation is complete and up to date, use sfos-upgrade "$(version | rev | cut -s -f 2 -d ' ' | rev)"; this will "samegrade" to the installed version, which is as close as one can get to the long lost version --verify (which only checked for missing or not up-to-date RPMs, while "samegrading" will also install them).
  • sfos-upgrade supports all public SailfishOS releases and should work fine for upgrading from / to any release (it accepts only version numbers of at least 1.0.0.0 at the command line, but omits this check when called without a parameter after utilising ssu to pre-set a version to upgrade to).
  • sfos-upgrade is simply a frontend for 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 guide and an also necessary pkcon refresh, which some seem to omit when upgrading manually at the command line (often running into aforementioned issues later, then).
  • sfos-upgrade's source files are hosted at Github.
  • For discussing its specific scripts and RPM packaging, please use its issue tracker at Github.
  • Issues with this RPM package or the shell scripts it installs shall also be filed at sfos-upgrade's issue tracker at Github.

 
License:
MIT

Application versions: 
AttachmentSizeDate
File sfos-upgrade-1.2-1.noarch.rpm10.78 KB17/02/2019 - 17:53
File sfos-upgrade-2.1-2.noarch.rpm11.53 KB02/03/2019 - 19:55
File sfos-upgrade-2.2-1.noarch.rpm11.68 KB04/03/2019 - 16:42
File sfos-upgrade-2.3-1.noarch.rpm11.7 KB10/03/2019 - 16:21
File sfos-upgrade-2.4-1.noarch.rpm11.71 KB17/03/2019 - 17:09
File sfos-upgrade-2.5-1.noarch.rpm11.87 KB19/04/2019 - 16:51
File sfos-upgrade-2.6-1.noarch.rpm11.89 KB28/04/2019 - 16:54
File sfos-upgrade-2.9-1.noarch.rpm12.05 KB26/05/2019 - 12:06
File sfos-upgrade-3.1-3.noarch.rpm14.32 KB16/06/2019 - 15:59
File sfos-upgrade-3.1-4.noarch.rpm14.32 KB04/07/2019 - 19:45
File sfos-upgrade-3.2-1.noarch.rpm14.35 KB15/08/2019 - 15:18
Changelog: 

A coarse changelog is provided per release comments at Github.

Comments

olf's picture

If you own a device sold by Inoi (e.g. R7 or T8), Jala (Accione or Accione P) or Intex (Aquafish, not reflashed as Jolla C), please consider contributing information to issue 32, at least the output of version, ssu re and ssu s.
Thanks!

anasyntes's picture

Thank you! Much appreciated.

dalas_revo's picture

Thanks for the scripts, I use them on my XA2. Unfortunately upgrading from 3.0.2.8 to 3.0.3.10 on the Aigo (Jolla Tablet) fails for me with sfos-upgrade, complaining about a missing /sys/class/power_supply/battery/uevent.

olf's picture

@dalas_revo, please let us analyse this at Github's issue tracker: I opened an issue there with questions for you and "might introduce an override for this after some more analysis".

olf's picture

A proper solution for this (now also extracting the battery information on Aigo tablets and other devices with unusual battery paths) was implemented in the v3.1 pre-release.
One may download it from Github and manually install it (or per Storeman -> Local RPM files).
Feedback at Github for this or other functionality is appreciated, as always.

oxygenh's picture

I have same issue, that SrDweeb. Sfos-upgrade report abour DOWNGRADE when i try to 3.0.3.10 from 3.0.3.9

olf's picture

Can confirm that sfos-upgrade incorrectly warns about downgrading, when upgrading from SailfishOS 3.0.3.x to 3.0.3.10.
This is solely an usability issue, simply answer with y or Y when asked if you really want to perform the "downgrade", then sfos-upgrade will upgrade SailfishOS as usual.
This will be rectified in the 3.0 release.

oxygenh's picture

Thank you very much.

olf's picture

See issue #24 for details and a fix.

DrDweeb's picture

Upgrade from 3.0.3.9 to 3.0.3.10 sends a downgrade warning, suggesting you have a problem dealing with 2 digit point upgrades - an embarrassing oversight

DrDweeb's picture

Thanks, sadly I must manually install every time so this is fabulous!

Maximilian1st's picture

Just wanted to say thanks for the scripts, for some reason the only way for me to update an Xperia X 5122.

seiichiro0185's picture

Thanks for this nice script, upgrade on XA2 Plus from 3.0.1.14 to 3.0.2.8 worked without problem.

dyraig's picture

Great little helper - thank you very much!

olf's picture

You are welcome.

Actually (as usual with Free Software), I did not create sfos-upgrade out of altruism, but because I wanted a safe upgrade method at the command line:
I used to upgrade SailfishOS at the GUI for years, because of the (undocumented) checks it seems to perform and because it is the "officially" supported method, but I was always annoyed how slow it is (it uses only a fraction of the available bandwidth, when downloading). Furthermore upgrading at the command line per ssu re && version --dup is documented to be a fallback method only to be used, when upgrading at the GUI fails and it obviously takes a lot of care to remember and check all preconditions, plus carrying out the "Final clean up" steps and a pkcon refresh afterwards.
But as upgrading to SailfishOS 2.2.1 and later to 3.0.0 at the GUI failed for me, I tried the command line method and realised how much faster it is. Hence I wrote two little shell scripts automating this process, one performing the upgrade proper, the other one the post upgrade actions after rebooting.
Being afraid to forget to check the prerequisites (battery charge, free space on root filesystem etc.) when using these two scripts in the future, I started to add these checks in December 2018. Well, as one is a always a mediocre tester for ones own programming, I decided to invest more time to add more checks, make the scripts more fail-safe and release them on Openrepos in January. Apparently that worked well, as I have only received one minor complaint per PM, yet.

Happy upgrading,
olf

objectifnul's picture

Tested (and approved) on my good old Jolla phone, which is my test machine. Still not convinced by Sfos 3.0.1.11 UX, so my XperiaX still sports 2.2.0.29 «Mouhijoki».

Vieno's picture

Haha, same here. My Xperia Xc stays with 2.2.0.29 till there is enough reason(e.g. patches) to change and my Jolla One provides me a sneak preview of things to come.

olf's picture

So am I, but IMO this / there is no reason not to upgrade to SFOS 2.2.1.

objectifnul's picture

Some of my favourite patches are not compliant with SFOS > Mouhijoki 2.2.0.29. So I stick to it for now.

Historyscholar's picture

GOOD Thanks!

t0t3u's picture

Niiice! Can't wait for next release to test it.
Thank you!