Bug #17200

The "Error starting GDM with your graphics card" splash screen is not displayed with Tails 4.0

Added by goupille 2019-10-29 12:23:44 . Updated 2019-11-13 19:32:20 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Hardware support
Target version:
Tails_4.1
Start date:
Due date:
% Done:

100%

Feature Branch:
bugfix/17200-gdm-failed-to-start
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

since the latest release, we had no reports from users being displayed our custom error message in case of gdm not working. we usually have some of them after each release.
However we received a few reports about graphics issues, with the greeter being in a loop for example (Bug #17199) and, I may be wrong, but I think that those users should have triggered the error message.

Subtasks

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2019-10-31 11:28:47

#2 Updated by intrigeri 2019-10-31 11:30:10

  • Category set to Hardware support
  • Status changed from New to Confirmed
  • Assignee deleted (intrigeri)
  • Target version set to Tails_4.1

I suspect that the memory saving stuff I implemented in 4.0 (killing the Greeter’s GNOME session during the login process) broke this :/

#3 Updated by intrigeri 2019-11-11 06:48:37

goupille wrote:
> since the latest release, we had no reports from users being displayed our custom error message in case of gdm not working. we usually have some of them after each release.

I’ve seen one such bug report that included that error message.

> However we received a few reports about graphics issues, with the greeter being in a loop for example (Bug #17199) and, I may be wrong, but I think that those users should have triggered the error message.

I don’t know about the other reports you’re referring to, but in Bug #17199 the (GDM) Greeter does start so it’s expected that the error message does not show up: “only” logging in fails and returns to the Greeter.

Next research step: forcibly trigger the error condition that yields this error splash screen and see what happens. In passing, it would be a good time to tweak config/chroot_local-includes/usr/lib/gdm3/gdm-x-session.tails so that when a certain debugging command line option is passed (e.g. force_gdm_startup_failure), it does not even try to start /usr/lib/gdm3/gdm-x-session.real, and instead directly triggers the failure handling code.

#4 Updated by intrigeri 2019-11-11 08:03:20

  • Assignee set to intrigeri

I’ll give this a try: this feature is a key piece of our user/hardware support feedback loop.

#5 Updated by intrigeri 2019-11-11 08:04:42

  • Subject changed from the custom error message linking to the gpu known issues is not displayed with tails 4.0 to The "Error starting GDM with your graphics card" splash screen is not displayed with Tails 4.0
  • Feature Branch set to bugfix/17200-gdm-failed-to-start

#6 Updated by intrigeri 2019-11-11 08:34:31

I confirm this is broken: I’ve passed xorg-driver=nouveau on a computer that has an Intel GPU, which of course breaks GDM startup. All I see is the text console with, on the last line, “Started GNOME Display Manager”. tty5 (where this splash screen is supposed to be displayed) is empty.

tails-gdm-failed-to-start.service was not started. gdm.service is seen as running, with one single process: /usr/sbin/gdm3.
Manually starting tails-gdm-failed-to-start.service yields the expected splash screen. I think I understood why and am testing a fix.

> In passing, it would be a good time to tweak […]

Forget it: this would not help debug this sort of issues, because bypassing GDM X session entirely has side effects; and there’s a better way to test this (see above), which I’ve documented on my branch.

#7 Updated by intrigeri 2019-11-11 08:41:18

  • Status changed from Confirmed to In Progress

#8 Updated by intrigeri 2019-11-11 09:58:46

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

This branch fixes the problem for me on bare metal (ThinkPad X200, Lenovo EliteBook 840G1) and libvirt/QEMU (QXL). Tested with xorg-driver=nouveau.

But it does not work on libvirt/QEMU with virtio graphics with 3D accel: once X.Org fails to start, all I see is a black screen with a blinking cursor in the top left corner; I suspect that’s a virtio + 3D accel problem and I would bet it was the same on Tails 3.x, so I’ll ignore this: X.Org does start in such VMs, as long as one does not intentionally break it for debugging purposes.

#9 Updated by segfault 2019-11-13 19:32:20

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:tails|162aa5e35acb82ece29190c8b6d11736f20d5d8a.