Project

General

Profile

Bug #12543

Keyboard layout chosen in the Greeter is sometimes not applied to the session once logged in

Added by intrigeri 5 months ago. Updated 22 days ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
Internationalization
Target version:
Start date:
05/16/2017
Due date:
% Done:

10%

QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Easy:
Affected tool:

Description

spriver wrote: "I can only reproduce the bug on Bare Metal when booting via DVD. The keyboard is applied correctly with VirtualBox/KVM."

Another person reported this with WhisperBack (bd68705224328b7b61b5eb0b87a9ea01), and the logs pretend it worked:

Mai 12 08:38:33 amnesia systemd-localed[7930]: Changed X11 keyboard layout to 'de' model 'pc105' variant '' options ''
Mai 12 08:38:33 amnesia systemd-localed[7930]: Changing virtual console keymap to 'de' toggle ''
Mai 12 08:38:33 amnesia systemd-localed[7930]: Failed to issue method call: Unit systemd-vconsole-setup.service not found.
Mai 12 08:38:33 amnesia systemd-localed[7930]: Failed to convert keymap data: No such file or directory
Mai 12 08:38:33 amnesia systemd-localed[7930]: Changed locale to LANG=de_DE.UTF-8.
Mai 12 08:38:33 amnesia systemd-localed[7930]: Changed locale to LC_NUMERIC=de_DE.UTF-8, LC_TIME=de_DE.UTF-8, LC_MONETARY=de_DE.UTF-8, LC_PAPER=de_DE.UTF-8, LC_MEASUREMENT=de_DE.UTF-8.
[...]
Mai 12 08:38:38 amnesia /usr/lib/gdm3/gdm-x-session[5860]: (**) Option "xkb_model" "pc105" 
Mai 12 08:38:38 amnesia /usr/lib/gdm3/gdm-x-session[5860]: (**) Option "xkb_layout" "de" 

In this last case, the logs indicate that the persistent volume is full, which can break stuff.

terminal_output.txt View (6.31 KB) spriver, 06/05/2017 12:11 PM

bug12543.txt View (3.67 KB) franps, 06/22/2017 03:57 PM

bug12543.txt View (5.29 KB) franps, 06/28/2017 11:32 AM


Related issues

Related to Tails - Feature #13178: Upgrade to Stretch 9.1 in Tails 3.1 Resolved 07/22/2017
Blocks Tails - Feature #13244: Core work 2017Q4: Foundations Team Confirmed 06/29/2017

History

#1 Updated by intrigeri 5 months ago

  • Assignee set to spriver
  • QA Check set to Info Needed

spriver and anyone else affected, can you please reproduce and post the output of localectl in the GNOME session once logged in? Also, please try with persistence disabled (if you had it enabled), and starting from a faster boot device (if you started from DVD): I suspect that there's a race condition caused by slow I/O and/or installing additional software.

#2 Updated by mercedes508 5 months ago

A user having this issue sent us output of localctl:

$ localectl
   System Locale: LC_NUMERIC=en_US.UTF-8
                  LC_TIME=en_US.UTF-8
                  LC_MONETARY=en_US.UTF-8
                  LC_PAPER=en_US.UTF-8
                  LC_MEASUREMENT=en_US.UTF-8
       VC Keymap: de
      X11 Layout: de
       X11 Model: pc105

#3 Updated by intrigeri 5 months ago

  • Assignee changed from spriver to mercedes508
  • Priority changed from Normal to Elevated

mercedes508 wrote:

A user having this issue sent us output of localctl:

Thanks! Can you please forward me the full bug report?

#4 Updated by intrigeri 5 months ago

  • Assignee changed from mercedes508 to intrigeri
  • QA Check deleted (Info Needed)

intrigeri wrote:

mercedes508 wrote:

A user having this issue sent us output of localctl:

Thanks! Can you please forward me the full bug report?

I got it and asked the OP some more info.

#5 Updated by intrigeri 5 months ago

The OP says that this only happens with persistence and additional software packages enabled. The packages they had enabled were: vlc, youtube-dl and ffmpeg.

#6 Updated by mercedes508 5 months ago

Received another email from the OP who says that "it happens completely randomly even with additional packages disabled. Sometimes I get the correct layout, sometimes I don't. So I have to revert my assumption about the additonal packages being the reason."

#7 Updated by intrigeri 5 months ago

Dear help desk & affected users, next time it happens, I'll need the output of:

locale
localectl
gsettings list-recursively org.gnome.desktop.input-sources
dconf dump /org/gnome/desktop/input-sources/
dconf dump /desktop/ibus/
for file in /etc/default/keyboard \
            /etc/default/locale \
            /var/lib/tails-user-session/keyboard ; do
   ls -l "$file" 
   echo "Content of ${file}:" 
   cat "$file" 
done
systemctl status systemd-localed.service
systemctl --user status
systemctl --user status tails-configure-keyboard.service
cat /var/lib/AccountsService/users/amnesia
sh -x /usr/local/lib/tails-configure-keyboard
localectl
gsettings list-recursively org.gnome.desktop.input-sources
dconf dump /org/gnome/desktop/input-sources/
cat /var/lib/AccountsService/users/amnesia

… and a complete WhisperBack bug report, again (so I can match time/dates with logs).

I'm also interested to know whether disabling MAC spoofing changes anything wrt. how often this problem occurs.

Notes to myself:

  • X.Org reads /etc/default/keyboard. Our code relies on the fact that this file is properly configured via PostLogin before amnesia's X.Org is started. However, looking for xkb in the Journal (on a system that did not expose this bug), I noticed that the first time amnesia's X.Org detects input devices on startup, it configures a "us" layout; only later, once tails-unblock-network has done some of its work (and likely after systemd-udev-trigger.service was run), X.Org re-detects input devices and sets the layout to what I chose in the Greeter, perhaps thanks to https://sources.debian.net/src/xorg-server/2:1.19.0-3/debian/local/64-xorg-xkb.rules/. So I wonder if our underlying assumption is wrong. But in the log I've received from a system that exposed this bug is different: amnesia's X.Org got the correct layout the first time. So perhaps that's a wrong lead.
  • We modify the keyboard settings with dconf later, in tails-configure-keyboard, that's started as part of desktop.target. I doubt we have any guarantees regarding the ordering of this script vs. the startup of X.Org and of the GNOME session (and especially the bits that read from /etc/default/keyboard).

#8 Updated by intrigeri 5 months ago

(Pointed the 2 OPs to the request for info above.)

#9 Updated by spriver 4 months ago

I was not able to reproduce it with ~rc1 (same setup: booting from DVD, same notebook used). I'm going to double-check tonight with the version I initially had the problem with (beta4).

#10 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to spriver

OK, cool!

There's still a slim chance we get enough debugging info to fix this bug in time for 3.0, let's try! And if we don't, I'll reassign to our help desk so they gather the needed info (#12543#note-7) ASAP once 3.0 is released and users start reporting this bug… or not, who knows.

#11 Updated by spriver 4 months ago

Retested with beta4, the error is occuring. I attached the terminal output, WhisperBack report has been sent, too.

#12 Updated by intrigeri 4 months ago

That's report f47b81dc7a81643f3ad9b9574ea8dd61.

#13 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to spriver

spriver: I don't see the output of the commands requested above in that bug report.

Help desk: the bug report you forwarded me is truncated.

#14 Updated by intrigeri 4 months ago

intrigeri wrote:

Help desk: the bug report you forwarded me is truncated.

Actually another help desk member forwarded me the complete bug report separately: f47b81dc7a81643f3ad9b9574ea8dd61 :) I'll take a look but I'm pretty sure I will still need the info I've asked spriver. And anyway, if that can't be reproduced in 3.0~rc1 anymore, perhaps we're good.

#15 Updated by intrigeri 4 months ago

  • Target version deleted (Tails_3.0)

Let's set a target version again if, and only if, this gets reported in something newer than 3.0~beta4.

#16 Updated by spriver 4 months ago

  • Assignee changed from spriver to intrigeri
  • QA Check set to Info Needed

I already attached the output of the commands you asked for to this ticket (: Or should I re-do it and attach the output to a WhisperBack report?

#17 Updated by intrigeri 4 months ago

I already attached the output of the commands you asked for to this ticket (:

Oops, sorry, I've missed that (and looked only in the body of comments).
Let me know if this happen again in 3.0 final.

#18 Updated by intrigeri 4 months ago

  • Assignee deleted (intrigeri)

Added some commands to the debugging instructions above. Couldn't understand based on spriver's bug report what's happening. Let's see if this happens in 3.0 final.

#19 Updated by spriver 4 months ago

This was also not reproducible while testing the 3.0 image. The layout was applied correctly when booting from DVD.

#20 Updated by franps 4 months ago

[removed: comment contained only quoted text]

#21 Updated by franps 4 months ago

[removed: comment contained only quoted text]

#22 Updated by franps 4 months ago

intrigeri wrote:

Dear help desk & affected users, next time it happens, I'll need the output of:

[...]

… and a complete WhisperBack bug report, again (so I can match time/dates with logs).

[...]

#23 Updated by intrigeri 4 months ago

@franps: thanks! But the output of some commands is truncated, or fully missing. I'll also need a WhisperBack bug report sent from the same session as the one you've generated the requested output.

#24 Updated by franps 4 months ago

intrigeri wrote:

Dear help desk & affected users, next time it happens, I'll need the output of:

[...]

… and a complete WhisperBack bug report, again (so I can match time/dates with logs).

I'm also interested to know whether disabling MAC spoofing changes anything wrt. how often this problem occurs.

Notes to myself:

  • X.Org reads /etc/default/keyboard. Our code relies on the fact that this file is properly configured via PostLogin before amnesia's X.Org is started. However, looking for xkb in the Journal (on a system that did not expose this bug), I noticed that the first time amnesia's X.Org detects input devices on startup, it configures a "us" layout; only later, once tails-unblock-network has done some of its work (and likely after systemd-udev-trigger.service was run), X.Org re-detects input devices and sets the layout to what I chose in the Greeter, perhaps thanks to https://sources.debian.net/src/xorg-server/2:1.19.0-3/debian/local/64-xorg-xkb.rules/. So I wonder if our underlying assumption is wrong. But in the log I've received from a system that exposed this bug is different: amnesia's X.Org got the correct layout the first time. So perhaps that's a wrong lead.
  • We modify the keyboard settings with dconf later, in tails-configure-keyboard, that's started as part of desktop.target. I doubt we have any guarantees regarding the ordering of this script vs. the startup of X.Org and of the GNOME session (and especially the bits that read from /etc/default/keyboard).

#25 Updated by intrigeri 4 months ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.1

During the help desk / foundations team meeting today, we deemed this ticket as high-priority (from a user-centric PoV). So adding to my plate at least to investigate a bit closer.

#26 Updated by intrigeri 4 months ago

  • QA Check deleted (Info Needed)

#27 Updated by intrigeri 4 months ago

#28 Updated by intrigeri 3 months ago

This looks somewhat related to https://bugs.debian.org/859268, that's going to be fixed in Stretch 9.1.

#29 Updated by intrigeri 3 months ago

  • Related to Feature #13178: Upgrade to Stretch 9.1 in Tails 3.1 added

#30 Updated by intrigeri 3 months ago

  • Status changed from Confirmed to In Progress
  • Target version changed from Tails_3.1 to Tails_3.2
  • % Done changed from 0 to 10
  • Affected tool deleted (Greeter)

Dear help desk & affected people: next time someone experiences this bug, please check if restarting GNOME Shell (ALT+F2 r) is enough to fix this bug.

Notes to myself: if the above "works", then it might be related to https://bugzilla.gnome.org/show_bug.cgi?id=780039, that apparently can be solved by reverting the patch added by https://bugzilla.gnome.org/show_bug.cgi?id=697597.

But the real solution would probably be to ensure we run tails-configure-keyboard before gnome-settings-daemon and GNOME Shell start (assuming they'll both do the right thing if the correct config is always set in dconf when they start). On my sid system I see that /etc/xdg/autostart/gnome-settings-daemon.desktop has X-GNOME-Autostart-Phase=Initialization; while our own etc/xdg/autostart/systemd-desktop-target.desktop has no such entry, so tails-configure-keyboard will probably start after g-s-d. I see two possible ways to achieve that result:

  • Either move tails-configure-keyboard.service to basic.target so it's run way earlier. It might be that some dependencies are not running at that point yet though, but it's cheap and worth giving it a try.
  • Or move tails-configure-keyboard back to /etc/xdg/autostart and run it in the EarlyInitialization phase (see https://git.gnome.org/browse/gnome-session/tree/gnome-session/README for details).

Now, there's a chance that the g-s-d update in Stretch 9.1 is enough to fix this problem, so for now I'll focus on #13178 and will come back here once Tails 3.1 is out, if the bug still happens: it's not worth my time to do anything more involved if the bug is essentially fixed already.

#31 Updated by intrigeri 2 months ago

  • Assignee changed from intrigeri to mercedes508
  • QA Check set to Info Needed

intrigeri wrote:

Dear help desk & affected people: next time someone experiences this bug, please check if restarting GNOME Shell (ALT+F2 r) is enough to fix this bug.
[…]
Now, there's a chance that the g-s-d update in Stretch 9.1 is enough to fix this problem, so for now I'll focus on #13178 and will come back here once Tails 3.1 is out, if the bug still happens: it's not worth my time to do anything more involved if the bug is essentially fixed already.

Dear help desk & bug reporters: does this still happen on Tails 3.1? If it does, then please gather the info I've requested above.

#32 Updated by intrigeri 2 months ago

  • Assignee changed from mercedes508 to emmapeel

Reassigning to the help desk person who's currently on-duty. Please check if this bug was reported since 3.1 is out, and then reassign to goupille whose shift starts tomorrow. Thanks!

#33 Updated by goupille 22 days ago

it is still happening sometimes in tails 3.1 and tails 3.2~rc1, but restarting GNOME Shell (with Alt+F2 r) fixes the issue for the session.

#34 Updated by goupille 22 days ago

  • Assignee changed from emmapeel to intrigeri
  • Target version changed from Tails_3.2 to Tails_3.3

#35 Updated by intrigeri 22 days ago

  • QA Check deleted (Info Needed)

#36 Updated by intrigeri 16 days ago

#37 Updated by intrigeri 16 days ago

Also available in: Atom PDF