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. 
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.
? 
?
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.
Which in turn relies on Jolla to provide correct information, which they prevent programmatically and regularly fail to manually. 
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
- Thank you for updating them last week.
- 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.
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.
- Thank you very much for addressing this issue (seriously); this is the very first time any sailor does that!
- Nobody ever stated that you personally have caused this AFAICS.
- 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
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 
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.
2 Likes
Ah, my choice of words made it unambiguous: I meant it as a statement, which I haven’t yet been able to test myself. Based on my knowledge of Linux terminal and screen shenanigans, it should work 
(but only when already detached?)