Project

General

Profile

Bug #17069

Tails Upgrader advertize to do manual upgrades to deprecated versions

Added by sajolida 3 months ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Upgrader

Description

For example, when run from Tails 3.5, I'm advertized to upgrade to 3.7 (16 months old at the time of writing).


Related issues

Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 08/31/2018

History

#1 Updated by sajolida 3 months ago

  • Related to Feature #14544: Spend software developer time on smallish UX improvements added

#2 Updated by intrigeri 3 months ago

Indeed, so far, we've only supported upgrading from a release that is less than 3 months old at the time we're preparing a new one.
IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

We can change this "less than 3 months old". I can think of no adverse consequence right now. But of course, for this sort of things, we tend to discover the drawbacks much later than at the time when we open the can of worms.

I assume the goal would be to do something like this: "For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release". Right?

Implementation-wise, there are two options:

  • Only change the release process doc. It's very cheap to do. But it's THE part of the release process that's already very complex and error prone, and this change would make it significantly worse. IMO, fixing the problem this ticket is about is not worth the cost (stress, energy, money) and the increased risk of breaking things occasionally for more common use cases.
  • Automate. It looks totally doable but it'll take more work. The nice thing is that if we do that, as a bonus it'll also simplify a lot this same (very complex and error prone) part of our release process. It would be a great and much welcome first step in the "streamline our release process" project we will probably have to tackle soon.

#3 Updated by sajolida 3 months ago

I don't quite understand your comment, so I'll ask for clarification.
I probably should have explained a bit more when I created the ticket,
sorry for that.

Indeed, so far, we've only supported upgrading from a release that is less than 3 months old at the time we're preparing a new one.
IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

You mean "automatic upgrade" here, right? Or are we also not supporting
manual upgrades from releases more than 3 months old?

What are users of 3.5 supposed to do if they want to update their Tails
to 3.16?

  • Currently Tails Upgrader tells them to do:
    • Manual upgrade from 3.5 to 3.7 (assuming that they can find a 3.7
      image which they can't).
  • I haven't tested the following steps but I guess that Tails Upgrader
    would then tell them to do:
    • Automatic upgrade from 3.7 to 3.8 (as per
      v1/Tails/3.7/amd64/stable/upgrades.yml)
    • Automatic upgrade from 3.8 to 3.10.1 (as per
      v1/Tails/3.8/amd64/stable/upgrades.yml)
    • Automatic upgrade from 3.10.1 to 3.12.1 (as per
      v1/Tails/3.10.1/amd64/stable/upgrades.yml)
    • Automatic upgrade from 3.12.1 to 3.14 (as per
      v1/Tails/3.12.1/amd64/stable/upgrades.yml)
    • Automatic upgrade from 3.14 to 3.16 (as per
      v1/Tails/3.14/amd64/stable/upgrades.yml)

What I want is to tell 3.5 users to do a manual upgrade to 3.16 straight
away. Tails Upgrader already knows that a manual upgrade is needed and
that the latest version is 3.16.

Why tell users to do a manual upgrade to anything else than the latest
version?

I would also be nice for Tails Upgrader to realize that it's not worth
doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand
that this might be more complicated and it's actually a different
problem than the one I reported here. And this might actually get fixed
by #15281.

I assume the goal would be to do something like this: "For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release". Right?

My goal when opening this ticket was simpler I think. When Tails
Upgrader already detects the need for a manual upgrade, it should always
tell me to upgrade to the latest version.

#4 Updated by sajolida 3 months ago

Regarding how frequent such cases are (your "more common use cases"), I have the feeling that we're assuming too much that people upgrade frequently. Tails being an OS that people use from time to time it's really not clear to me.

For example, from our personas, both Cris and Riou (or Riou's friends) could leave their Tails unused for many months before their next trip or wave of protests.

So I did some stats :)

I used 28 days of logs from the 3.13.1 release cycle.

It turns out that:

  • 16.6% of boots were from a USB stick that had no direct automatic upgrade path to 3.13.1. That's 3800 boots per day.
  • 3.8% of boots were stuck before 3.6, which had broken all automatic upgrades. That's 860 boots per day. The impact of breaking all automatic upgrades in 3.6 is still huge even 1 year later.

See spreadsheet in attachment.

(I added the 'Boot/Lifespan' column to understand the spike of 3.8 users: 3.8 had a much longer lifespan, so many more users still used 3.8 than 3.9.)

#5 Updated by intrigeri 3 months ago

Hi,

Indeed, so far, we've only supported upgrading from a release that is less than 3 months old at the time we're preparing a new one.
IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

You mean "automatic upgrade" here, right? Or are we also not supporting manual upgrades from releases more than 3 months old?

No, I mean any kind of upgrade path advertised by Tails Upgrader.

When we introduced automatic upgrades, initially we only provided upgrade paths from the current supported release to the new one. A few years later, we extended this to support some more relatively recent releases (IIRC after you noticed users don't upgrade as fast as we would have thought). But we've never advertised via Tails Upgrader any upgrade path for older releases. That's why I'm claiming we have never supported this use case so far: the UX we've been providing in this situation has always been crappy (see below).

To be clear, I'm not saying it's great, quite the opposite. I just want to establish what's the baseline, i.e. the situation since 7 years.

What are users of 3.5 supposed to do if they want to update their Tails to 3.16?

I think the only option we're providing currently is: read the release notes for the last release on our website and follow the upgrade instructions.

What I want is to tell 3.5 users to do a manual upgrade to 3.16 straight away.

I see.

After writing all that follows, I realized that #15281 will solve the problem this ticket is about, in most cases: see https://tails.boum.org/blueprint/Endless_upgrades/ ("Support upgrading very old Tails"). So I don't think we should do anything here right away: instead, we should keep it in mind when implementing #15281.

Still, I believe that what I wrote below will help you understand the constraints we have to work with, so it might be a useful read.

Tails Upgrader already knows that a manual upgrade is needed and that the latest version is 3.16.
Why tell users to do a manual upgrade to anything else than the latest version?

Thanks for asking. It helps me understand where you're coming from. I think you're misunderstanding how our upgrade system works so I'll explain. Our upgrade system has no concept of "the latest version" because there's no such thing as "the latest version" that works in every situation. Instead, our upgrade system learns, from update description files (UDFs):

  • which version Y users of version X on the channel Z should upgrade to
  • how this upgrade can be performed (depending on whether there are IUKs, on available disk space and memory)

And then, Tails Upgrader proposes the best upgrade path it knows about to the user. The only way to ensure that version Y is up-to-date (in your example: 3.16; in some other cases, it might be 4.0~whatever) is to update UDFs for version X when we release version Y. That's what I've been discussing previously in my "Implementation-wise, there are two options" paragraph.

I would also be nice for Tails Upgrader to realize that it's not worth doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand that this might be more complicated and it's actually a different problem than the one I reported here. And this might actually get fixed by #15281.

#15281 will indeed fix that in most cases.

I assume the goal would be to do something like this: "For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release". Right?

My goal when opening this ticket was simpler I think. When Tails Upgrader already detects the need for a manual upgrade, it should always tell me to upgrade to the latest version.

Ah, this is indeed different from what I'm proposing, which is based on what we decided to do last time we discussed this topic (== what our release process currently documents).

The key difference is about this part: "that has no incremental upgrade path to the new release". Last time we rethought this topic, we decided that it was better for users to do a multi-step automatic upgrade (for example, N → N+2 then N+2 → N+4) if available, than to force them to do a manual upgrade to the latest version (in my example, N → N+4). I don't remember the details of why we decided this but it's surely captured somewhere in Redmine. You seem to be arguing in favor of the opposite preference here. Anyway, I believe that in most cases, #15281 will make this question moot so I don't think it's a good time for us to revisit this.

#6 Updated by intrigeri 3 months ago

Regarding how frequent such cases are (your "more common use cases"), I have the feeling that we're assuming too much that people upgrade frequently. Tails being an OS that people use from time to time it's really not clear to me.

For example, from our personas, both Cris and Riou (or Riou's friends) could leave their Tails unused for many months before their next trip or wave of protests.

So I did some stats :)

Understood. Thanks for doing this research. It shows that "better support Tails older than N months" would provide value to a non-negligible and important part of our user base. Doing so requires more work than "just" (sic) advertising upgrades better, which this ticket is about. To give you an idea, for example, it requires changes to how we update our signing key, and which key we use for signing which UDFs at release time. Similarly, it has ramifications in the TLS certificates area. So I feel this project would be better tracked in its own ticket, where we can discuss and prioritize it separately from the smaller bit this ticket is about. This very ticket would be a nice first step and can be a child of the new ticket that tracks this bigger project.

#7 Updated by sajolida 3 months ago

Thanks for all the insights about our Tails Upgrader works. I'm learning
thing here :)

What are users of 3.5 supposed to do if they want to update their Tails to 3.16?

I think the only option we're providing currently is: read the release notes for the last release on our website and follow the upgrade instructions.

Ok. Then Tails Upgrader shouldn't, as of now, tell them that they should
do a manual upgrade to 3.7, which is both impossible (the image is not
available anymore) and in contradiction with what they are supposed to
do. That's precisely what this ticket is about, nothing else.

Tails Upgrader currently points 3.5 users to the 3.7 release notes.

The message is similar as this one, with 3.5 and 3.7 instead:

https://tails.boum.org/doc/first_steps/upgrade/upgrader_automatic.png

Which then forwards them to the download page which can only download
3.16. So yeah, I don't think that it will lead people to a critical dead
end and only a conflicting message.

It's not a really big deal but I don't think that #15281 will solve
this. For example, it might still affect people running, let's say 4.9,
while we are at 5.4. Will then be told to do a manual upgrade to 5.1
instead of 5.4?

So I don't think we should do anything here right away: instead, we should keep it in mind when implementing #15281.

I understand that #15281 won't prevent people from having to do manual
upgrades sometimes. For example:

  • Between 4.0 and 5.0.
  • Whenever we break automatic upgrades like we did between 3.5 and 3.6.

These are the cases that I'm trying to address here.

there's no such thing as "the latest version" that works in every situation.

Forgetting about other channels than "stable", in which situations would
https://tails.boum.org/inc/stable_amd64_version/ not be the latest
version people should do their manual upgrade to?

Off-topic discussion starts here:

I would also be nice for Tails Upgrader to realize that it's not worth doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand that this might be more complicated and it's actually a different problem than the one I reported here. And this might actually get fixed by #15281.

#15281 will indeed fix that in most cases.

Right.

You seem to be arguing in favor of the opposite preference here.

I'm not.

Anyway, I believe that in most cases, #15281 will make this question moot so I don't think it's a good time for us to revisit this.

Agreed.

#8 Updated by sajolida 3 months ago

To summarize the state of my understanding:

When Tails Upgrader detects the need for a manual upgrade on the stable channel, ie. when it displays https://tails.boum.org/doc/first_steps/upgrade/upgrader_automatic.png, it should always point to https://tails.boum.org/inc/stable_amd64_version/.

I don't think that requires any of the 2 solutions that you drafted in #17069#note-2 and could hopefully be simplier than that.

Also available in: Atom PDF