Tails

#1 Updated by goupille 2017-10-02 21:01:38

on the same computers, a clean install of tails 3.1 then an upgrade to 3.2 solved the issue.

#5 Updated by songoku 2017-11-20 19:12:19

I’m using tails in VirtualBox (I know - not recommended but anyway…) and having that exact same issue. So maybe I can provide some information for fixing this quite annyoing bug.

#6 Updated by mercedes508 2017-11-25 13:41:03

I just received a similar report for upgrade from 3.2 to 3.3, and asked the info from Bug #11839#note-11

#8 Updated by jgallias 2017-12-03 03:43:42

I seem to have something very similar for Tails 3.3 on Lenovo 11e Yoga (Intel)

The behavior first appeared doing an in-place upgrade over Tor to 3.3.
Thinking that maybe something went wrong with the auto-upgrade, I used Bittorrent to download the ISO, PGP verify, then latest Universal-USB-Installer.exe on Windows.
I pulled a new USB Stick out of the package to make sure it wasn’t a failing drive.
The resulting Intermediate Tails has no touchpad, no matter how many attempts I make across both drives.

Greeter and GNOME will only accept keyboard/touchscreen input, no touchpad.

I’ve submitted it through WhisperBack, but this was the closest existing bug I could find.

#9 Updated by Anonymous 2018-01-19 14:14:56

@helpdesk:

• Does this only happen for upgrades?
• Is this still an issue for many users?

#10 Updated by goupille 2018-01-19 15:25:14

> * Does this only happen for upgrades?

as far as I remember, it was only reported happening after upgrades

> * Is this still an issue for many users?

I don’t think so, there have been some reports these past months but not as much as when I opened the ticket. several users were asked for the debug infos, but most of them fixed their issue before by installing Tails from scratch.

#11 Updated by songoku 2018-01-20 15:49:25

I still have it - how can I help?

#12 Updated by goupille 2018-01-20 19:54:03

songoku wrote:
> I still have it - how can I help?

we still need the information asked by intrigeri in comment #2, could you start your computer with another tails device, plug in the problematic one, open a terminal and gather the output of the commands listed in Bug #11839#note-11 ?

#13 Updated by songoku 2018-01-22 09:59:34

Those commands won’t work, because there’s no Tails directory there, just TailsData - If I use this directory, there’s no live directory, hence no Tails.module file

Here the commands for reference:
cat /media/amnesia/Tails/live/Tails.module
sha256sum /media/amnesia/Tails/live/*

But also:

ls -l /media/amnesia/Tails/live/
df /media/amnesia/Tails/live/
the date/time when the upgrade was applied

#14 Updated by goupille 2018-04-05 16:47:38

there were several users reporting this issue after an upgrade from 3.6.1 to 3.6.2. I asked them the output of those commands, hopefully I’ll have something to forward to the FT.

#16 Updated by intrigeri 2018-04-30 09:33:05

So I got two reports with identical symptoms:

• automatic upgrade from 3.6.1 to 3.6.2
• 3.6.2.squashfs, initrd.img and vmlinuz have the right size and hash
• Tails.module was not updated and still lists only filesystem.squashfs

=> the fix I was refering to in Bug #11839#note-12 is not sufficient :/

Dear help desk, please ask the affected users to try this workaround: when upgrading to 3.6.2, add a line that contains “3.6.2.squashfs” (without the quotes) at the end of live/Tails.module. Adjust the version number depending on what version one is upgrading to, e.g. if users have the same problem after upgrading to 3.7, they should add a line that contains “3.7.squashfs” instead.

#18 Updated by sajolida 2018-05-09 07:29:36

intrigeri: Do you think that we should do something specific about this issue on top of Bug #15557?

#19 Updated by intrigeri 2018-05-29 10:46:24

sajolida wrote:
> intrigeri: Do you think that we should do something specific about this issue on top of Bug #15557?

I don’t see what else we can do than wait and see if my fix works (and in the meantime, document the workaround) :/

#21 Updated by intrigeri 2018-10-24 17:15:29

I’m told a user reported this problem after upgrading to 3.10.1 :/

#22 Updated by goupille 2018-10-25 12:43:40

intrigeri wrote:
> I’m told a user reported this problem after upgrading to 3.10.1 :/

indeed, we got a lot of users reporting that…

I’m wondering if it could just be that they rebooted before the end of the upgrade, tho…

#23 Updated by intrigeri 2018-11-16 08:06:15

goupille wrote:
> I’m wondering if it could just be that they rebooted before the end of the upgrade, tho…

A friend of mine reported to me “I’ve upgraded my Tails but it still tells me it needs to be upgraded” so we tried to reproduce the problem together. What happens is that our Upgrader displays a progress bar while downloading, then turns off the network and displays nothing whatsover while it’s applying the upgrade, which can take several minutes. It was super unclear to this user that they were supposed to wait before rebooting. I suspect this UX problem is exactly what leads to all these partially applied upgrades.

#25 Updated by intrigeri 2018-11-19 17:29:35

goupille wrote:
> I’m wondering if it could just be that they rebooted before the end of the upgrade, tho…

I’m starting to wonder if we have only one problem left here (“reboot before the end of the upgrade”, which is definitely a problem in the real world as shown by my last comment) or if there’s still a bug in the way our Upgrader updates Tails.module. I now suspect these bugs were fixed already but have been red herrings so far, that prevented us from zooming out at the overall UX of the upgrade process enough to identify the lack of feedback as another possible cause of trouble.

So in doubt, I think it makes more sense to first focus on fixing the first, obvious problem that we know does exist and can cause the reported behaviour: no feedback while applying the downloaded upgrade leads users to restart the system before the upgrade is fully applied. I’ll look at the implementation, will propose something and will ask sajolida to review the UX of my proposal.

And if that’s not enough to avoid partially applied upgrades: I took yet another look at the upgrade_modules_file method and have a couple ideas that could possibly fix it and would be worth trying (note to myself: create the temporary modules file in $self->tempdir i.e. on the system partition and then move it atomically; or replace all the code in that method with one single call to run_as_root(nocache + some command that appends the line to the modules file without bothering about replacing it atomically). These should be cheap so I might find time to sneak one of them in the same branch as the obvious UX fix.

#26 Updated by intrigeri 2018-11-19 17:54:52

intrigeri wrote:
> So in doubt, I think it makes more sense to first focus on fixing the first, obvious problem that we know does exist and can cause the reported behaviour: no feedback while applying the downloaded upgrade leads users to restart the system before the upgrade is fully applied. I’ll look at the implementation, will propose something and will ask sajolida to review the UX of my proposal.

Meh. The code to give such feedback is there. So I guess I “just” need to figure out why it doesn’t (always?) work and fix it.

#32 Updated by emmapeel 2018-11-20 16:06:54

I am not very sure… Well, maybe this upgrade was longer to apply than usual, but I think there are more reports of this ticket during this upgrade, and we had a lot of reports back in 3.1

(I am not so sure we get the same amount of reports in every update)

#33 Updated by intrigeri 2018-11-20 16:36:47

> I am not very sure… Well, maybe this upgrade was longer to apply than usual, but I think there are more reports of this ticket during this upgrade, and we had a lot of reports back in 3.1

Interesting! I suspect the regression (lack of feedback while applying the upgrade) was introduced in 3.0, which might explain a sudden surge of such reports when we released 3.1. OTOH we did release 3.0.1 so if my hunch was really correct, the problem should have shown up at that time. So I’m not sure either. At this point, without any clue wrt. how to reproduce the possibly remaining bug, the best I can do is to fix issues I understand first, see if it helps, then try random things that might fix issues I can’t reproduce.

#34 Updated by intrigeri 2018-11-20 16:38:19

Note to myself: once I have something that fixes the UI + adds Feature #15282, document for sajolida how he can test it for real and ask him to.

#37 Updated by intrigeri 2018-12-07 12:56:54

Scheduling note: this will also need to get a code review once you’ve done the UX part, and the deadline for merging this in time for 3.11 is at the end of the week.

#41 Updated by intrigeri 2018-12-08 18:34:06

> * “It is recommended to close all the open applications during the upgrade.\n” could become "We recommend you close all other applications during the upgrade.\n which is shorter, more personal, and more consistent with the language in the new dialog.

Done. That’s not a new string but it was cheap to change. We have the exact same phrasing in the doc (wiki/src/doc/first_steps/upgrade.mdwn) so I’ve updated it as well: even though the 2 other bullet points in the same bullet list are in the passive voice, I figured that consistency between the doc and the app is more important than intra-list consistency. Revert at any time if you disagree :)

Both changes will break translations but that’s life.

> I also wondered if we could remove it. Is closing all other application relevant as well while downloading?

It is: an already open application can start eating much more RAM (say, Tor Browser if you open a bunch of tabs) which can make the download fail.

> * It seems like we’re using everywhere sentence-style capitalization in button lables instead of header capitalization as per the GNOME guidelines: https://developer.gnome.org/hig/stable/buttons.html.en. This is serious nitpicking, so if changing everything breaks the test suite or translations we should stick to use sentence-style capitalization consistently within this app.

That will break translations and require ~1h of work to update the test suite go through QA.

> Sorry I didn’t spot this ealier.

Sorry Tails Upgrader is not good enough for you to use it more often :/

> * Please remove the bold on “The upgrade was successfully downloaded.”: this information is already in the title and not the most important thing for the user to learn here.

I’m on it (anonym: I’ll have to update a test suite image for this so it’s expected that what I’m pushing now breaks the test suite).

#42 Updated by intrigeri 2018-12-09 07:02:51

intrigeri wrote:
> > * Please remove the bold on “The upgrade was successfully downloaded.”: this information is already in the title and not the most important thing for the user to learn here.
>
> I’m on it (anonym: I’ll have to update a test suite image for this so it’s expected that what I’m pushing now breaks the test suite).

Adjusted the test suite, so all done here from my PoV as far as this first attempt for 3.11 is concerned.

#46 Updated by intrigeri 2018-12-09 13:22:54

(I’ll reassign to help desk who can gather the info I need, once I know who’ll be on duty the 2 weeks that follow the 3.12 release.)

#48 Updated by mercedes508 2019-02-07 13:09:02

intrigeri wrote:
> Any report of such issues after upgrading from 3.11 to 3.12?

It’s been reported twice since January 28th. But without any answer back from users.

#49 Updated by intrigeri 2019-02-08 11:38:06

> It’s been reported twice since January 28th.

Thank you. How does this compare with previous releases? (I would guess that this would have not made it into “hot topics for help desk” if it happened only twice per release, but a confirmation — at least guts feeling, ideally actual data — would be nice.)

> But without any answer back from users.

OK. Please nag them at least once after 2 weeks with no reply :)

#50 Updated by intrigeri 2019-02-18 18:08:04

#51 Updated by TheNerdyAnarchist 2019-02-20 15:18:52

I’ve come across several user requests on Reddit that appear to still have this problem upgrading from 3.11 -> 3.12. I don’t know if this persists into the 3.12.1 release, however. A few links to threads below:

• https://www.reddit.com/r/tails/comments/alduy4/keyboard_and_mouse_not_working_after_update_to_312/
• https://www.reddit.com/r/tails/comments/ao6mpx/version_312_keyboard_and_mouse_not_working_on_the/ (this one may have been a Mac compatibility issue - no report back from the user)
• https://www.reddit.com/r/tails/comments/areap6/updated_to_latest_version_not_working/
• And several who simply found my FAQ post and commented that they had the issue as well here: https://old.reddit.com/r/tails/comments/alut17/faq_i_upgraded_tails_and_now_my_keyboard_mouse/

#52 Updated by intrigeri 2019-03-10 08:20:28

intrigeri wrote:
> > It’s been reported twice since January 28th.
>
> Thank you. How does this compare with previous releases? (I would guess that this would have not made it into “hot topics for help desk” if it happened only twice per release, but a confirmation — at least guts feeling, ideally actual data — would be nice.)
>
> > But without any answer back from users.
>
> OK. Please nag them at least once after 2 weeks with no reply :)

Ping?

#53 Updated by goupille 2019-03-10 12:51:21

I’ve seen a couple users affected in the last 15 days, but I didn’t work in the first weeks post-release…

#55 Updated by intrigeri 2019-03-21 16:46:08

@mercedes508, to answer your question from XMPP, what I need is:

• primarily, answers to the question I asked in Bug #14754#note-49, that I should now update to:
  • How often did this get reported for the 3.11→3.12 upgrade?
  • How often did this get reported for the 3.12→3.12.1 upgrade?
  • Around April 8: How often did this get reported for the 3.12.1→3.13 upgrade?
  • Meta: this ticket was on the “Hot topics on our help desk” list for the last two months, so I assume it’s more than a couple affected users, right? I would love to understand better what qualifies as a “Hot topic” in practice :)
• ideally, but don’t bother too much since I doubt it will help me much more that what I’ve already received: debugging info (Bug #14754#note-2)

#58 Updated by intrigeri 2019-03-21 17:32:06

> It’s been reported twice from 3.12 release to february 10th

Thank you!

> and then I’ll assign to emma & then goupille.
>> How often did this get reported for the 3.12→3.12.1 upgrade?
> Don’t know because I wasn’t on shift.

Having to ask 3 different people, in order to get the quantitative user data Help Desk is meant to gather for me, is not a satisfying workflow for me. So:

• For this ticket I’ll do without the data from the past.
• To make this kind of requests for data work better in the future, I’ve send Help Desk a proposal: a small change to their workflow, which will allow me to compute myself, very cheaply, the occurrence rate of specific Redmine issues :)

#59 Updated by mercedes508 2019-03-28 13:49:22

696ebf78-47a7-1f74-7bd4-bf7a753dc919
9e6ddf0ccf9f1e657258bde757d291c9
1553881015.33850070

#61 Updated by intrigeri 2019-06-08 17:40:36

mercedes508, emmapeel, I see you were on duty since the 3.14 release, which was published 2.5 weeks ago. Generally this sort of issues gets reported in the couple weeks that follow a release and I see none. Can I infer from this that this problem did not get reported?

Also, emmapeel, goupille, @mercedes508, I see this made it in your “hot issues” for April (“Some issues”, no idea how many that is), but I see no WhisperBack ID reported on this ticket in April. Why? Is that because these reports contained no info that you thought would be useful to me?

#62 Updated by intrigeri 2019-06-08 17:43:52

@mercedes508, thanks for trying to share these reports with me… but something went wrong:

mercedes508 wrote:
> 696ebf78-47a7-1f74-7bd4-bf7a753dc919

What’s this? It does not look like a WhisperBack report ID.

> 9e6ddf0ccf9f1e657258bde757d291c9

Unfortunately, I think I did not receive the WhisperBack reports yet when you pasted that :/

> 1553881015.33850070

This looks like a timestamp from logs more than anything else. I can’t find it in my email. So I guess this one is lost, right?

#67 Updated by mercedes508 2019-06-10 13:57:29

intrigeri wrote:
> mercedes508, emmapeel, I see you were on duty since the 3.14 release, which was published 2.5 weeks ago. Generally this sort of issues gets reported in the couple weeks that follow a release and I see none. Can I infer from this that this problem did not get reported?

Yes, no report for this issue since then.

> > 696ebf78-47a7-1f74-7bd4-bf7a753dc919
>
> What’s this? It does not look like a WhisperBack report ID.

I can’t find this in my mails, so sorry don’t know what this actually is neither…

> > 9e6ddf0ccf9f1e657258bde757d291c9

Forwarded.

> > 1553881015.33850070

Forwarded as well.

#68 Updated by emmapeel 2019-06-11 08:02:45

mercedes508 wrote:
> intrigeri wrote:
> > mercedes508, emmapeel, I see you were on duty since the 3.14 release, which was published 2.5 weeks ago. Generally this sort of issues gets reported in the couple weeks that follow a release and I see none. Can I infer from this that this problem did not get reported?
>
> Yes, no report for this issue since then.
>
> > > 696ebf78-47a7-1f74-7bd4-bf7a753dc919
> >
> > What’s this? It does not look like a WhisperBack report ID.

It was not a WhisperBack report, but the message-id of a user’s email to tails-support

I have forwarded it now.

#69 Updated by goupille 2019-06-12 19:57:45

intrigeri wrote:

> Also, emmapeel, goupille, @mercedes508, I see this made it in your “hot issues” for April (“Some issues”, no idea how many that is), but I see no WhisperBack ID reported on this ticket in April. Why? Is that because these reports contained no info that you thought would be useful to me?

I looked back in april’s reports and couldn’t find any emails tagged with this ticket number, and only found one that might be an occurence of this but the user disappeared without confirmin it, so I think I made a mistake: given we were late for filling up the monthly report, I just pasted my notes and didn’t checked furthermore

#70 Updated by goupille 2019-06-27 18:27:21

it happened again after 3.14.2…

Message-ID: <CA+SoAwKmCubcOu1cB5WdKb1sTEeq9QMgTQSK2z6SNL=XqtHG-Q@

I still think that it is a UX problem, when I upgraded I almost rebooted, because I forgot that Tails was silently applying the upgrade. I think it would be better if an un closable popup was displayed from the begining of the process to the reboot.

#71 Updated by intrigeri 2020-03-09 19:59:47

Hi,

goupille wrote:
> I still think that it is a UX problem, when I upgraded I almost rebooted, because I forgot that Tails was silently applying the upgrade. I think it would be better if an un closable popup was displayed from the begining of the process to the reboot.

Agreed.

Since then:

• The part about “unclosable popup” is tracked via Feature #17312.
• One of the UX traps set by our Upgrader, which could easily make a user reboot too early, was fixed in 4.3 (Bug #16603) ⇒ dear Help Desk, please let me know if this class of problems happens again during upgrades from 4.3 to 4.4. Thanks in advance!

And on my side, I’d still like to implement the robustness improvements I mentioned on Bug #14754#note-66. It’s pretty simple, I “just” (sic) need to think about it next time I work on the Upgrader…