Unstability of OS upgrades (on CLI)

REPRODUCIBILITY (% or how often):
BUILD ID = OS VERSION (Settings > About product):
HARDWARE (XA2, X10, X10 II, …):
UI LANGUAGE:
REGRESSION: (compared to previous public release: Yes, No, ?):

DESCRIPTION:

I needed to do the limbo and reset/upgrade my testing device(s).
As they are running the free version of SFOS one needs to do the upgrades via CLI.

PRECONDITIONS:

clean reset device, fully charged and on charger
no openrepos, no storeman, no nothing
clean vanilla SFOS
just one account: jolla account
just sfos-upgrade locally installed

STEPS TO REPRODUCE:

  1. update device on command line
  2. after each success version rebooted
    and ran post-sfos-upgrade before next version
  3. obeyed all stop releases

EXPECTED RESULT:

update goes through

ACTUAL RESULT:

update stalls or even reboots in between

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

Nothing to tell.
My X did this two times (once stalled, once rebooted)
3.3.x - 3.4.0 - 4.0.1 - stalled/reboot/bang
3.3.x - 3.4.0 - 4.0.1 - 4.1.0 unexpected-reboot/bang
On third try everything fine to 4.3.0.

My XA2 once
3.1.x - 3.2.0 - 3.4.0 - 4.0.1 - 4.1.0 stalled (blocked / device frozen)/reboot/bang
On second try everything fine to 4.3.0.

This is now really gambling :frowning:

2 Likes

To be honest, I don’t think upgrades via the CLI were ever supported - why not use the GUI?

1 Like

Try this:

  • Install screen
  • Install sfos-upgrade
  • Run sfos-upgrade in screen
2 Likes

In my case, I do not get offered updates through the GUI, as I am running FREE SailfishOS, which means updating via CLi, which I have done twice so far, largely without any problems, especially the last upgrade to 4.3 was really quite smooth, quick download, quick installation and quickly using my device once again, even my email accounts still work and Openrepos operates as expected despite not disabling any repos.

Regarding ‘official support’ for upgrading via CLi. . .

See: section 4.3

    https://jolla.zendesk.com/hc/en-us/articles/201836347
3 Likes

To what avail?  

@peterleinchen, Jolla (specifically @jovirkku) seems to model this primarily as a consequence of people “jumping over” a stop release.
While I do believe that this is one cause, I have the impression that there are other failure modes, which are not caused by the user, some of them even being common to GUI- and TUI-upgrades.

Thus it is essential to avoid the well know pitfall of “jumping over” a stop release, if you want to “prove” that the instability of the upgrade process also has other reasons.
Unfortunately you failed in two out of your three examples above:

My X […]: 3.3 - 3.4 - 4.0 - 4.1 reboot/bang

You were “jumping over” the stop release 4.0.1! “4.0” meant “4.0.1”!

My XA2 once: 3.1 - 3.4 - 4.0 - 4.1

You were “jumping over” the stop releases 3.2.0 and 4.0.1! 3.2.0 was accidentially omitted.

Side note
To avoid mishaps when upgrading at the TUI is the only reason why I wrote and maintain sfos-upgrade, among them “jumping over a stop release”.
It is sad to see that so many people still prefer to perform the process manually, which is known to be error-prone (also from my own experience). But all I can do is to explicitly denote in the description of sfos-upgrade the advantages it offers compared to manually typing the two commands to upgrade and maintain it. Sigh!

3 Likes

Killing the parent process (Terminal App, ssh session…) does not terminate the update process.

Lipstick restart shouldn’t kill the upgrade process with the terminal.

@olf
I just typed those releases as I remembered.
And yes as you said there was a 3.2 for the XA2 (now edited above) and the 4.0.1 is my 4.0, or?

And I explicitly used sfos-upgrade and relied on its intelligence. :wink:
At all times the releases were the same.
And the clash was for the X at different releases.
And it worked at the third try.

? :confused: ?

Are you sure
Where is this mentioned?

But screen is as well running under lipstick, same as fingerterm.
So it will be closed also, or?

No it will not.

(Neither will processes started with nohup or detached with the shell disown command, but screen, or if you prefer tmux and others, is more convenient.)

3 Likes

O.K., that was just some misunderstanding.
Please always include three digits for correctly identifying a SailfishOS release (branch), or Jolla / @jovirkku will likely come to the same conclusion.

And I explicitly used sfos-upgrade and relied on its intelligence. :wink:

Which in turn relies on Jolla to provide correct information, which they prevent programmatically and regularly fail to manually. :frowning_face:
This is why I ultimately changed my policy which SailfishOS releases are treated as “stop releases” by sfos-upgrade, though just 16 days ago.

At all times the releases were the same.
And the clash was for the X at different releases.
And it worked at the third try.

Good, so you have not been affected.

2 Likes

Stop Releases are listed at [1] and [2]. They are correct now on 2021-11-09.
Although I try to keep good care of them, mistakes may happen.

Stop Releases should not have a big role anymore, in my understanding, as most users are able to reflash their Xperia devices again, instead of taking the painful reset-device-and-update-via-stop-releases approach.

What comes to [1], at least I have done nothing to “prevent scripted downloads programmatically” - I do not even know how to do it.


[1] https://jolla.zendesk.com/hc/en-us/articles/201836347#4.1
[2] Sailfish OS - Wikipedia

2 Likes
  1. Thank you for updating them last week.
  2. Well, while “mistakes may happen”, to repeat the simple mistake “forgot to update the list for more than half a year” should be avoided IMO (which now happened for at least the second time, IIRC the third).
    For now I assume, that Jolla / you will pay more attention in the future. :slightly_smiling_face:

Stop Releases should not have a big role anymore, in my understanding, as most users are able to reflash their Xperia devices again, instead of taking the painful reset-device-and-update-via-stop-releases approach.

Well, you see how much grief issues cause, which may easily be caused by “jumping over” a stop release in this thread here and e.g., the thread “Problems with OS update 4.3.0
(although it seems the most of the issues are caused by something else, the effects are similar).
And it was your assumption that “traversing a stop release” is the reason for a good part of the issues discussed at “Problems with OS update 4.3.0”.

What comes to [1], at least I have done nothing to “prevent scripted downloads programmatically” - I do not even know how to do it.

  1. Thank you very much for addressing this issue (seriously); this is the very first time any sailor does that!
  2. Nobody ever stated that you personally have caused this AFAICS.
  3. Please let us continue to discuss this issue at its original thread.
    I provided an in-depth issue description, its history and proposed solutions.
    And I still believe, that something which has been working for years and some configuration change broke it must be easily fixable.
1 Like

I think I can test the some upgrade chain with my X…

1 Like

Was this meant as a statement?
Or more as a request to @Jolla?

Did not know screen!
Which is installed on my 3.2.1 device.

The screen session survives a lipstick restart and you can re-attach via screen -r :slight_smile:

Thanks
I hope to remember this on my next update sessions…

1 Like

Yeah.

But running sfos-upgrade (or version --dup) does run under fingerterm-bash directly.
And not detached.
Or?

Well, I considered to enable a fully scripted use of sfos-upgrade, but decided against it, because it is a lot of work with only a little gain.
Hence for now sfos-upgrade will stay an interactive tool … in its first phase!
The second, long phase (downloading and updating, which starts after the final question at line 628) does deliberately not expect, require or call for any user interaction, even when errors occur.
Likewise an ssu re <a.b.c.d>; version --dup & would not call for any user interaction, but also no logs will be recorded (and you will not be able to see any terminal output of a detached screen session) in contrast to running sfos-upgrade in a screen session, which can be detached after the “final upgrade question”.

P.S.: I do not understand which role you think fingerterm has!
sfos-upgrade is a written to be run with an ash (preferably in its bash-compatibility mode, but may do without), a real bash and basically any shell fully compatible to the Bourne shell (sh), while ssu and version shall run with any shell.

1 Like