Bug #12543

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

Added by intrigeri 2017-05-16 09:38:32 . Updated 2017-11-15 11:34:07 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Internationalization
Target version:
Start date:
2017-05-16
Due date:
% Done:

100%

Feature Branch:
bugfix/12543-default-keyboard-layout-not-applied
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

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.


Files


Subtasks


Related issues

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

History

#1 Updated by intrigeri 2017-05-16 09:41:35

  • 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 2017-05-18 09:53:38

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 2017-05-20 07:15:08

  • 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 2017-05-25 08:04:21

  • 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 2017-05-28 17:37:27

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 2017-05-29 11:04:35

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 2017-06-03 09:33:04

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 2017-06-03 09:37:48

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

#9 Updated by spriver 2017-06-04 12:32:07

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 2017-06-05 10:27:16

  • 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 (Bug #12543#note-7) ASAP once 3.0 is released and users start reporting this bug… or not, who knows.

#11 Updated by spriver 2017-06-05 12:11:53

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

#12 Updated by intrigeri 2017-06-07 13:14:43

That’s report f47b81dc7a81643f3ad9b9574ea8dd61.

#13 Updated by intrigeri 2017-06-07 13:15:51

  • 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 2017-06-07 13:20:37

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 2017-06-07 13:26:38

  • 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 2017-06-09 14:10:45

  • 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 2017-06-09 14:46:05

> 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 2017-06-09 15:35:54

  • 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 2017-06-11 09:42:52

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

#20 Updated by franps 2017-06-22 15:54:32

[removed: comment contained only quoted text]

#21 Updated by franps 2017-06-22 15:56:18

[removed: comment contained only quoted text]

#22 Updated by franps 2017-06-22 15:57:43

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 2017-06-23 15:02:01

@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 2017-06-28 11:32:51

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 2017-06-28 16:51:13

  • 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 2017-06-28 17:06:32

  • QA Check deleted (Info Needed)

#27 Updated by intrigeri 2017-06-29 10:21:56

#28 Updated by intrigeri 2017-07-17 08:21:23

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

#29 Updated by intrigeri 2017-07-17 08:21:37

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

#30 Updated by intrigeri 2017-07-17 13:28:04

  • 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 Feature #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 2017-08-12 18:07:09

  • 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 Feature #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 2017-08-13 15:29:20

  • 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 2017-09-24 13:23:28

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 2017-09-24 13:46:48

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

#35 Updated by intrigeri 2017-09-24 18:33:19

  • QA Check deleted (Info Needed)

#36 Updated by intrigeri 2017-10-01 09:50:30

#37 Updated by intrigeri 2017-10-01 09:50:35

  • blocked by deleted (Feature #13234: Core work 2017Q3: Foundations Team)

#38 Updated by intrigeri 2017-10-22 09:16:20

On Bug #12638#note-18 georg asked (about this problem, not about Bug #12638):

> Alright - anything I could do?

Sure! Sorry for the late reply.

I’m told that restarting GNOME Shell (with Alt+F2 r) fixes the issue for the session. Can you please try this and report back?

And if you feel comfortable hacking on Tails “glue” code and building modified ISO images, you could pick one of the options I’ve mentioned on Bug #12543#note-30 and tell me which one you’re working on (+ some ETA) so I focus on another one and avoid duplicating your work. Or the opposite: I’ll probably take a look today and will tell you which option I’ll try first.

And in any case, I can point you to test ISO images that you can try (IIRC I can’t reliably reproduce the bug here so I’ll need help to confirm it’s actually fixed).

#39 Updated by intrigeri 2017-10-22 10:00:25

I’ll try “move tails-configure-keyboard back to /etc/xdg/autostart and run it in the EarlyInitialization phase”.

#40 Updated by georg 2017-10-22 11:07:57

> I’m told that restarting GNOME Shell (with Alt+F2 r) fixes the issue for the session. Can you please try this and report back?

Will do!

I’m feeling comfortable to hack on the code myself, however, currently, I’m lacking time to do so.

> And in any case, I can point you to test ISO images that you can try (IIRC I can’t reliably reproduce the bug here so I’ll need help to confirm it’s actually fixed).

Please do! I’m happy to try out ISO images, at least.
Thanks!

#41 Updated by intrigeri 2017-10-22 11:18:39

Great, thanks :)

#42 Updated by intrigeri 2017-10-22 12:37:42

  • % Done changed from 10 to 20
  • Feature Branch set to bugfix/12543-default-keyboard-layout-not-applied
  • Type of work changed from Research to Code

georg, can you please try an experimental ISO once it’s built? It should land in
https://nightly.tails.boum.org/build_Tails_ISO_bugfix-12543-default-keyboard-layout-not-applied/lastSuccessful/archive/build-artifacts/ within 1 hour.

This branch configures the keyboard layout (with dconf) as part of the GNOME EarlyInitialization phase. Looking at the logs this does happen before gnome-settings-daemon is started, which was the goal, so presumably this should fix the bug, regardless of potential bugs in how g-s-d or GNOME Shell get the system-wide settings from systemd-localed, as long as they honor settings already configured in dconf.

I’ve tested this in libvirt/QEMU (booting from an ISO that likely is already loaded in disk cache) and on bare metal (booting from a USB stick, ThinkPad X200) and the ordering I see in the logs makes sense, but this bug comes from a race condition so it might be that my fix is buggy and I’m just lucky not to see any problem (besides, I could not reproduce the original bug on either of these setups).

#43 Updated by intrigeri 2017-10-22 12:38:55

intrigeri wrote:
> georg, can you please try an experimental ISO once it’s built?

Oops, I forgot: since this is a race condition, it would be nice to test in an environment as close as possible to the one where you can reproduce the bug (computer, USB stick, persistence, additional software packages, options chosen in the Greeter, etc.).

#44 Updated by intrigeri 2017-10-29 17:34:41

georg (and anyone else who can reproduce this bug): ping wrt. testing the experimental ISO image?

#45 Updated by spriver 2017-10-29 17:42:54

intrigeri wrote:
> georg (and anyone else who can reproduce this bug): ping wrt. testing the experimental ISO image?

if still needed I can test it in the same environment as it initially occurred on Wednesday (in three days (; )

#46 Updated by georg 2017-10-29 17:56:33

Sorry for the delay, it’s on my ToDo for tomorrow. Thanks for your work and stay tuned…

#47 Updated by intrigeri 2017-10-30 08:02:39

> if still needed I can test it in the same environment as it initially occurred on Wednesday (in three days (; )

Yes please. Thanks spriver!

#48 Updated by intrigeri 2017-10-30 08:02:47

> Sorry for the delay, it’s on my ToDo for tomorrow. Thanks for your work and stay tuned…

Excellent, thank you!

#49 Updated by georg 2017-10-30 23:15:56

tl;dr: LGTM!

I’ve booted an upgraded USB-stick which exhibited this bug with 3.1 and 3.2 on a X220i five times in a row. I’ve selected German in the greeter each time, and the language setting was correctly applied to the GNOME session each time. Still, I would like to wait for feedback of spriver on Wednesday.

Thanks for your work, highly appreciated!

#50 Updated by intrigeri 2017-10-31 06:32:29

> tl;dr: LGTM!

Wow, cool! Thanks for testing.

#51 Updated by spriver 2017-11-06 19:47:06

> tl;dr: LGTM!

Here, too! Tested in several setups where the error occurred, I could not reproduce it any time (:

#52 Updated by intrigeri 2017-11-06 21:32:59

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 50
  • QA Check set to Ready for QA

#53 Updated by anonym 2017-11-07 15:34:45

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

No regressions in my couple of tests => merged!

#54 Updated by anonym 2017-11-15 11:34:07

  • Status changed from Fix committed to Resolved