Project

General

Profile

Bug #12543

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

Added by intrigeri 7 months ago. Updated 27 days ago.

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

100%

QA Check:
Pass
Feature Branch:
bugfix/12543-default-keyboard-layout-not-applied
Type of work:
Code
Blueprint:
Starter:
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

Associated revisions

Revision c57efccb (diff)
Added by intrigeri about 2 months ago

Add a systemd --user target for bits of GNOME EarlyInitialization managed by systemd (refs: #12543).

Revision 4cb901f2 (diff)
Added by intrigeri about 2 months ago

Configure they keyboard layout as part of the GNOME EarlyInitialization phase (refs: #12543).

Revision bcb1f61a
Added by anonym about 1 month ago

Merge remote-tracking branch 'origin/bugfix/12543-default-keyboard-layout-not-applied' into stable

Fix-committed: #12543

History

#1 Updated by intrigeri 7 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 7 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 7 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 7 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 7 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 7 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 6 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 6 months ago

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

#9 Updated by spriver 6 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 6 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 6 months ago

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

#12 Updated by intrigeri 6 months ago

That's report f47b81dc7a81643f3ad9b9574ea8dd61.

#13 Updated by intrigeri 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 months ago

[removed: comment contained only quoted text]

#21 Updated by franps 6 months ago

[removed: comment contained only quoted text]

#22 Updated by franps 6 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 6 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 6 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 6 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 6 months ago

  • QA Check deleted (Info Needed)

#27 Updated by intrigeri 6 months ago

#28 Updated by intrigeri 5 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 5 months ago

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

#30 Updated by intrigeri 5 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 4 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 4 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 3 months 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 3 months ago

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

#35 Updated by intrigeri 3 months ago

  • QA Check deleted (Info Needed)

#36 Updated by intrigeri 2 months ago

#37 Updated by intrigeri 2 months ago

#38 Updated by intrigeri about 2 months ago

On #12638#note-18 georg asked (about this problem, not about #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 #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 about 2 months ago

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

#40 Updated by georg about 2 months ago

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 about 2 months ago

Great, thanks :)

#42 Updated by intrigeri about 2 months ago

  • % 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 about 2 months ago

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 about 1 month ago

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

#45 Updated by spriver about 1 month ago

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 about 1 month ago

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

#47 Updated by intrigeri about 1 month ago

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 about 1 month ago

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 about 1 month ago

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 about 1 month ago

tl;dr: LGTM!

Wow, cool! Thanks for testing.

#51 Updated by spriver about 1 month ago

tl;dr: LGTM!

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

#52 Updated by intrigeri about 1 month ago

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

#53 Updated by anonym about 1 month ago

  • 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 27 days ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF