Unstability of OS upgrades (on CLI)

Bug Reports
#1

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:

3 Likes
Problems with installing the OS update 4.3.0
[4.3.0.12][X, XA2] Continuous reboot
[4.3.0.12] Jolla camera (also torch) does not start at all - as well as videos do not play
#2

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

1 Like
#3

Try this:

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

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
#5

To what avail?  

#6

@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
#7

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

#8

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

#9

@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: ?

#10

Are you sure
Where is this mentioned?

#11

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

#12

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
#13

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
#14

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
Scripted download of stop releases list fails!
Scripted download of stop releases list fails!
#15
  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”.

And I do not concur that users should upgrade SailfishOS by re-flashing to a newer release (instead of upgrading at the GUI or TUI)! While you sure did not intend to state that this way, it is ultimately what you are saying, because there is sufficient incentive (due to the many new bugs in every recent SailfishOS release since v3.2.1) to omit installing some releases (for me: all; I re-evaluate this with each new release).
Thus, I disagree that stop releases do “not have a big role any more”, especially when every release is a stop release (3.4.0, 4.0.1, 4.1.0, 4.2.0, 4.3.0, and there were not documented as such).

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 then some configuration change broke it, must be easily fixable.

P.S.: Does the fact that you as a sailor references the list of stop releases at the English Wikipedia imply, that this list officially maintained by Jolla (e.g., you)?
I.e., are you saying that I should use that one instead of the now un-retrievable one at Jolla’s Zendesk instance?
As denoted, I do not believe it is easier for you / Jolla to maintain multiple lists, rather the opposite!

2 Likes
Scripted download of stop releases list fails!
Scripted download of stop releases list fails!
#16

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

1 Like
#17

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

#18

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
#19

Yeah.

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

#20

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.

2 Likes