Project

General

Profile

Bug #16030

SquashFS errors during boot lead to false-positives on graphics card error reports

Added by sajolida about 1 year ago. Updated 9 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Hardware support
Target version:
-
Start date:
10/03/2018
Due date:
% Done:

0%

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

Description

The following happened to me yesterday:

  • I installed a USB stick using Tails Installer from Tails 3.9.
  • Starting it on my computer leads to GDM error message (Error starting GDM) while my graphics card works fine with Tails.
  • Having a closer look, I have tons of squashfs errors on boot.

I'm aware of #5856 which has been focused on errors while Tor is working (and detecting them from inside Tails). While I'd like to scope this ticket to preventing false-positives on graphics card error reports, while might lead to wrong information on /support/known_issues/graphics and be a problem for the project.


Related issues

Related to Tails - Feature #5856: Detect SquashFS errors (bad medium or optical drives) while Tails is running Confirmed
Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 08/31/2018
Related to Tails - Feature #6766: Display an error message when boot fails Confirmed 02/25/2014
Duplicated by Tails - Bug #12445: tails-installer should validate file integrity after unpacking the ISO on the sd-card Duplicate 04/13/2017

History

#1 Updated by sajolida about 1 year ago

  • Related to Feature #5856: Detect SquashFS errors (bad medium or optical drives) while Tails is running added

#2 Updated by mercedes508 about 1 year ago

  • Status changed from New to Confirmed
  • Assignee set to intrigeri

#3 Updated by intrigeri about 1 year ago

  • Duplicated by Bug #12445: tails-installer should validate file integrity after unpacking the ISO on the sd-card added

#4 Updated by intrigeri about 1 year ago

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

#5 Updated by intrigeri about 1 year ago

  • Subject changed from squashfs errors during boot lead to false-positives on graphics card error reports to SquashFS errors during boot lead to false-positives on graphics card error reports
  • Assignee deleted (intrigeri)

It's unlikely we manage to get all installers we support to check integrity of the data they wrote; besides, that would probably not be sufficient: a USB stick that works fine at initial installation time can wear out and start returning buggy data months later.

So I think we need to identify such issues at boot time, worst case between GDM startup failure and displaying "Error starting GDM with your graphics card". Putting aside more expensive generic solutions (see #5856), the cheapest way to address the specific problem this ticket is about is probably to adjust tails-gdm-failed-to-start.service so it displays a different error message when the Journal contains any SquashFS error. I think this should be quite simple to implement (although perhaps a bit harder to test) and could fall under the #14544 umbrella (which starts in 2019Q3). And if it's deemed high prio compared to the dozens of other tickets #14544 covers, if FT has sufficient available time it could possibly be done earlier than that.

#6 Updated by sajolida about 1 year ago

I'm fine with relating this to #14544, thought for me the more important concern is not so much UX but the reliability of the debugging information we get. I understand that Help desk and Foundations team spend a lot of time debugging graphics cards issues and I thought that having false-positive in the set would make their work even harder.

#7 Updated by intrigeri about 1 year ago

I'm fine with relating this to #14544, thought for me the more important concern is not so much UX but the reliability of the debugging information we get.

I see. FWIW I've proposed to bind this to #14544 because when such a false positive happens, currently we tell the user they cannot do anything themselves to solve the problem, while there's actually a rather simple way for them to fix it.

I understand that Help desk and Foundations team spend a lot of time debugging graphics cards issues and I thought that having false-positive in the set would make their work even harder.

Yes, this has been a time sink for both teams historically. Now, the situation has changed a lot:

  • In theory Help Desk should not spend much time on such issues these days. If they do, then perhaps they need to review their mission statement and adjust their practices.
  • On the FT side:
    • I receive extremely few bug reports about "GDM does not start" so even if there are a few false positives in there, this won't substantially affect my work.
    • More generally, since a few months I'm trying to strictly cap the amount of time I spend on such matters because the chances to get a positive outcome are very low in practice; either there's a well-known workaround (that's rather cheap to find online and to document) or we can only knock on wood and wait for a fix from upstream.

⇒ With this in mind, I'm not sure that "make their work even harder" is that much a reality than the UX issue here and I see no strong reason to prioritize this higher than "bundled as part of #14544" for now.

#8 Updated by sajolida about 1 year ago

⇒ With this in mind, I'm not sure that "make their work even harder" is that much a reality than the UX issue here and I see no strong reason to prioritize this higher than "bundled as part of #14544" for now.

Thanks for the additional info! I overestimated the negative impact of
the false-positives on our work.

#9 Updated by sajolida 9 months ago

Note that Etcher verifies the data written to the USB stick after writing it. So it might fix some of these issues.

#10 Updated by sajolida 9 months ago

  • Related to Feature #6766: Display an error message when boot fails added

Also available in: Atom PDF