Tails

#3 Updated by intrigeri 2019-11-01 09:46:41

To debug this, I think we’ll need the output of tails-debugging-info (run as root in a text console), otherwise I’m afraid there’s no way to tell what’s going on :/

#6 Updated by goupille 2019-11-02 18:00:14

adding

 xorg-driver=intel

fixes the issue for that user (I still asked for the debugging info)

#8 Updated by intrigeri 2019-11-10 16:40:20

Hi @goupille!

goupille wrote:
> adding xorg-driver=intel fixes the issue for that user

Interestingly, after they reported that, you asked them to try xorg-driver=modesetting. The OP obliged, so the debugging info we got is about the latter, not about xorg-driver=intel; interestingly, the modesetting driver also makes Tails work :) Maybe you made a typo when asking them the debugging info?

Anyway, this was super useful:

• The kernel is 5.3.2-1~exp1 so that’s probably Tails 4.0
• That system has two GPUs, with vga_switcheroo doing its thing:
  • “00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)”
  • “02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M] [1002:6841]”
• With xorg-driver=modesetting, the Intel GPU is used by X.Org, because it’s the default drm device; the AMD GPU is ignored because there’s no support for multiple graphics cards there
• Without extra boot options:
  • The radeon X.Org driver is used for the AMD GPU, and the modesetting X.Org driver is used for the Intel one.
  • The Greeter loads just fine so there’s actually no X.Org hardware support issue here.
  • X.Org segfaults while logging in, during MAC spoofing, triggered by (II) config/udev: Adding drm device (/dev/dri/card1)

So I’m now almost convinced that this has nothing to do with GPU drivers, but rather, MAC spoofing breaks X.Org in some cases (possibly systems with multiple GPUs). I’ll ask the OP to test with MAC spoofing disabled.

#10 Updated by intrigeri 2019-11-11 07:58:28

If my hunch is correct and the problem is caused by MAC spoofing running udevadm trigger, one option could be to exclude graphics devices from the trigger action, e.g. with --subsystem-nomatch=SUBSYSTEM or one of the related options.

#11 Updated by intrigeri 2019-11-14 09:52:56

Disabling MAC spoofing does not fix the problem but I was slightly confused when I thought it would: the thing I believe could be breaking stuff here is not spoofing the MAC address per se, but rather the fact that our MAC spoofing implementation, based on blocking/unblocking network devices, triggers udevadm actions, regardless of whether MAC spoofing is enabled or not.

The logs I got this time suggest that systemd-logind is confused about the state of FDs (for /dev/dri/card{0,1} it passes to X.Org: when amnesia’s X.Org starts, it gets passed paused FDs which makes it abort. I suspect that’s because at least one of /dev/dri/card{0,1} seem to briefly disappear and come back again when we run udevadm trigger.

So one thing I’d like to try is to avoid triggering udev events for GPU devices.

#12 Updated by goupille 2019-11-14 13:56:16

I don’t know if it is related but we received an anonymous report (Bug report: 20c6669cc73aa96b4bcbf982a55b3d57) from a user with two gpu (Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] and [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] [1002:6600]), saying that setting an administrator password in the Greeter prevents Tails to fully start (it keeps coming back to the Greeter when clicking on the “start tails” button)

when no administrator password is set, Tails starts without issues (hence the logs)

#13 Updated by intrigeri 2019-11-22 11:44:35

> I don’t know if it is related but we received an anonymous report (Bug report: 20c6669cc73aa96b4bcbf982a55b3d57) from a user with two gpu (Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] and [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] [1002:6600]), saying that setting an administrator password in the Greeter prevents Tails to fully start (it keeps coming back to the Greeter when clicking on the “start tails” button)

> when no administrator password is set, Tails starts without issues (hence the logs)

Indeed, this could be related: setting an admin password could increase the chances that we win the systemd-logind vs. MAC spoofing vs. X.Org race condition I had a hunch about above.

So far we had reports of this class of problems affecting 2 users. If there are more, IMO this should become FT work.