Bug 1151519 - gnome-initial-setup resets keyboard layout
Summary: gnome-initial-setup resets keyboard layout
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 21
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1160252 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-10 15:21 UTC by Michael Catanzaro
Modified: 2014-11-10 06:34 UTC (History)
8 users (show)

Fixed In Version: gnome-initial-setup-3.14.1-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-10 06:34:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda layout settings reset to one layout from gnome-initial-setup (352.64 KB, image/png)
2014-11-04 13:02 UTC, Lukas Brabec
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 738789 0 None None None Never

Description Michael Catanzaro 2014-10-10 15:21:31 UTC
Description of problem: Installing Fedora 21 Alpha Workstation, in anaconda I picked the Dvorak keyboard layout, which was correctly used after installation. Then I ran a system update, and gnome-initial-setup started after the update. It asked me to choose my system's language, then on the next page it immediately reset my keyboard layout to US English and I had to pick Dvorak again, without being able to type properly....

Then that was it -- g-i-s opened up the getting started help was done. It looks like there was literally no purpose in running g-i-s other than to reset my previous choice of language and keyboard layout. Why are we starting it at all?

Comment 1 Adam Williamson 2014-10-10 16:09:00 UTC
well, AIUI two reasons:

* on multi-user systems users may have different preferences for lang/loc than the system setting
* it lets users set up online accounts

it sounds like it's somehow buggy, though. it should show up on first graphical login, and it sounds like it didn't?

I'd expect it'd use the system layout until/unless you pick another, but not sure if that's actually in the design.

I'd recommend filing this bug upstream if you haven't already, GNOME folks like to work it there; a downstream copy can be useful for blocker/freeze exception status if necessary.

Comment 2 Marko Myllynen 2014-10-22 11:58:18 UTC
I seeing pretty much the same: in Anaconda I chose English (US) language and Finnish + Finnish(classic) keyboard layouts. After booting up, in GDM there are three keyboards to choose from: Finnish (the default), Finnish(classic), and English (US) (I think it's ok since the system language is English (US) but not having it there would be no issue either, IMHO).

When I log in for the first time, initially I see those three keyboard layouts as the available alternatives in gnome-shell's top bar, Finnish still being the default (so far so good).

But then g-i-s starts showing the following screens:

1) Welcome - asks to select language, English (US) being the default, others shown are German, French, Chinese, Korean, etc (no Finnish)

2) Typing - English (US) is the default, others shown are Cameroon Multilingual (??) and four English variants (no Finnish), need to search for Finnish so that the default keyboard will be the one I already selected during installation. And after selecting it, the keyboard layout selection in the top bar of gnome-shell is gone. And if I would go with the g-i-s suggested default, I'd lose quick availability of both keyboard layouts I already chose in Anaconda.

3) Connect Your Online Accounts
4) You're all set!

So I think keyboard layout wise g-i-s could be improved a bit.

Thanks.

Comment 3 Adam Williamson 2014-10-22 15:46:09 UTC
The choices for keyboard layout depend on what you choose for language, note. It makes some fairly bizarre choices for a lot of languages - that's filed as https://bugzilla.gnome.org/show_bug.cgi?id=729210 .

The behaviour here changed a bit between Alpha and Beta, though the 'weird choices' bug isn't fixed - it now lets you choose from all existing layouts (after clicking ...) on the keyboard layout selection. I don't know if it handles multiple layouts, though.

Comment 4 Marko Myllynen 2014-10-23 08:00:41 UTC
> I don't know if it handles multiple layouts, though.

Seems that it doesn't, only one layout can be selected (gnome-initial-setup-3.14.1-2.fc21).

I agree with Michael that currently it's pretty hard to see any benefits of g-i-s on the language/keyboard front and hope that its design and/or implementation could be re-evaluated.

Thanks.

Comment 5 Marko Myllynen 2014-10-23 08:21:18 UTC
Oh, I selected German lang/keyb in g-i-s to see what happens, well nothing happened - g-i-s was in German but then the GNOME session was still in English. I had to log out / log in to have German in use, g-i-s did not suggest it.

Comment 6 Adam Williamson 2014-10-25 14:17:06 UTC
that shouldn't be necessary, sounds like possibly a (different) bug. for me the choice I make in g-i-s always seems to apply immediately (e.g. i install with UK and US English, g-i-s forces me to pick one or the other, I do, and that's the only one I have available in the desktop session).

perhaps g-i-s should display the current system config, including multiple layout configs, and offer to let you simply accept it? it seems to already have this *intent* - in that the current system layout is pre-selected in the shortlist if it's present in the shortlist - but there are problems in the implementation (the case where the system layout isn't in the shortlist, and the case where the system config has multiple layouts).

Comment 7 Marko Myllynen 2014-10-27 10:16:04 UTC
(In reply to Adam Williamson (Red Hat) from comment #6)
> that shouldn't be necessary, sounds like possibly a (different) bug. for me
> the choice I make in g-i-s always seems to apply immediately (e.g. i install
> with UK and US English, g-i-s forces me to pick one or the other, I do, and
> that's the only one I have available in the desktop session).

I tried this again and it still fails for me (used English US as system language and selected German in g-i-s). This also mean that GNOME Help which pops up is not using the language selected in g-i-s. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1157467 about this.

> perhaps g-i-s should display the current system config, including multiple
> layout configs, and offer to let you simply accept it? it seems to already
> have this *intent* - in that the current system layout is pre-selected in
> the shortlist if it's present in the shortlist - but there are problems in
> the implementation (the case where the system layout isn't in the shortlist,
> and the case where the system config has multiple layouts).

I think this is a great idea - this would allow most users just to click through g-i-s and retain system settings and then those who really want to change them would have the possibility to do so in g-i-s already.

https://bugzilla.redhat.com/show_bug.cgi?id=1157209 also mentions keyboard selection issue but that aspect of the bug should clearly be handled here.

Thanks.

Comment 8 Matthias Clasen 2014-10-27 12:54:23 UTC
(In reply to Adam Williamson (Red Hat) from comment #6)
> that shouldn't be necessary, sounds like possibly a (different) bug. for me
> the choice I make in g-i-s always seems to apply immediately (e.g. i install
> with UK and US English, g-i-s forces me to pick one or the other, I do, and
> that's the only one I have available in the desktop session).

keyboard layouts are different from language in this respect - with the way localization is currently implemented, it is pretty much impossible to change the display language at runtime without restarting the session.

Comment 9 Marko Myllynen 2014-10-27 12:58:33 UTC
(In reply to Matthias Clasen from comment #8)
> keyboard layouts are different from language in this respect - with the way
> localization is currently implemented, it is pretty much impossible to
> change the display language at runtime without restarting the session.

FWIW, I proposed a systemd based enhancement on this front which in theory could be helpful:

https://bugzilla.redhat.com/show_bug.cgi?id=1014347

Thanks.

Comment 10 Michael Catanzaro 2014-10-27 13:03:27 UTC
(In reply to Matthias Clasen from comment #8)
> keyboard layouts are different from language in this respect - with the way
> localization is currently implemented, it is pretty much impossible to
> change the display language at runtime without restarting the session.

g-i-s could restart the session (yuck), or gdm could run it in its own session and before the usual one (that sounds right), or g-i-s shouldn't offer to change the language in the first place (if need be). It shouldn't just fail with no warning, and from bug #1157467 I guess that's what's happening. Methinks we need some release criteria for g-i-s....

Comment 11 Matthias Clasen 2014-10-27 13:09:12 UTC
(In reply to Marko Myllynen from comment #9)
> (In reply to Matthias Clasen from comment #8)
> > keyboard layouts are different from language in this respect - with the way
> > localization is currently implemented, it is pretty much impossible to
> > change the display language at runtime without restarting the session.
> 
> FWIW, I proposed a systemd based enhancement on this front which in theory
> could be helpful:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1014347

No, doesn't help.

Comment 12 Matthias Clasen 2014-10-27 13:12:59 UTC
(In reply to Michael Catanzaro from comment #10)
> (In reply to Matthias Clasen from comment #8)
> > keyboard layouts are different from language in this respect - with the way
> > localization is currently implemented, it is pretty much impossible to
> > change the display language at runtime without restarting the session.
> 
> g-i-s could restart the session (yuck), or gdm could run it in its own
> session and before the usual one (that sounds right), or g-i-s shouldn't
> offer to change the language in the first place (if need be). It shouldn't
> just fail with no warning, and from bug #1157467 I guess that's what's
> happening. Methinks we need some release criteria for g-i-s....

The designed workflow for g-i-s is exactly this: 

- no user exists
- gdm launches g-i-s to create account and set it up
- transitions into session for the newly created account

The problems you are dealing with here are due to the fact that we still have user creation in anaconda (and its own initial-setup), and due to us adding an exiting-user mode to g-i-s as a stopgap to still offer some of the setup steps.

Jasper had killed the existing-user mode upstream already. I brought it back because Fedora guys where moaning about its lack. Now they are moaning about the existing-user mode :-(

I'm open to just killing it again. It is not meant to work like this in the first place.

Comment 13 Marko Myllynen 2014-10-27 13:22:48 UTC
(In reply to Matthias Clasen from comment #11)
> (In reply to Marko Myllynen from comment #9)
> > FWIW, I proposed a systemd based enhancement on this front which in theory
> > could be helpful:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1014347
> 
> No, doesn't help.

Why?

Comment 14 Matthias Clasen 2014-10-27 13:27:25 UTC
(In reply to Marko Myllynen from comment #13)
 
> > No, doesn't help.
> 
> Why?

Because applications and toolkits are not written with runtime locale changes in mind. For code like:

 string = g_strdup_printf (_("look how BIG: %d\n"), num);
 /* send string elsewhere for display */
 num = even bigger number

it is essentially impossible to change the language after the fact. You'd have to wrap up all the ingredients that go into the translated string, and keep them around for as long as the string exists, so you can retranslate it later.

You can find this kind of problem everywhere in application code, and all over the stack.

-> unfixable

Comment 15 Adam Williamson 2014-10-27 14:58:07 UTC
mcatanzaro: Fedora has release criteria for initial setup utilities, but something like 'you have to re-login to apply changes' wouldn't hit them.

Going back to one of the issues we were initially discussing - use of the system-wide input method - I do have https://bugzilla.gnome.org/show_bug.cgi?id=729211 open upstream. I can tweak that a bit to reflect the idea from c#6.

Matthias, when you say "Fedora guys where moaning about its lack", I think you're talking about https://bugzilla.redhat.com/show_bug.cgi?id=1116316 , where in fact only one person actually requested it (the filer, Jens Petersen). It was proposed as a freeze exception issue so we had to review it, and the decision was "well, if this is a bug, it gets an FE, but if actually they want it gone, that's fine too":

"There's some indication that this might be an intentional change, but that seems odd, so if that's the case obviously FE status is irrelevant and this should be closed NOTABUG, but assuming it's actually just an oversight, we'll take a fix as this is a useful workflow that we want people to test (and can't be fixed with a post-release update)."

I kinda like the way it exposes the online account functionality (which is one of GNOME 3's nicest features), but that's kind of an incidental benefit. I  don't think there'd be riot in the streets if you took it out again, I mean, ultimately it's a design choice.

Comment 16 Kalev Lember 2014-10-27 15:16:42 UTC
(In reply to Matthias Clasen from comment #12)
> The problems you are dealing with here are due to the fact that we still
> have user creation in anaconda (and its own initial-setup), and due to us
> adding an exiting-user mode to g-i-s as a stopgap to still offer some of the
> setup steps.

Would it make sense to try and fix this for F22 by removing the user creation step from Anaconda and only doing it in gnome-initial-setup? At least for the Workstation image.

Comment 17 Michael Catanzaro 2014-10-27 16:15:12 UTC
(In reply to Matthias Clasen from comment #12) 
> I'm open to just killing it again. It is not meant to work like this in the
> first place.

I'm not opposed to that, but that would not solve the problem. The current flow is:

Language -> Keyboard -> Wireless Network -> Online Accounts -> Summary

Or if a user was not created:

Language -> Keyboard -> Wireless Network -> Timezone -> Online Accounts -> Account Creation -> Password -> Summary

Language and Keyboard are redundant/unwanted (as well as buggy) *regardless* of whether a user was created in Anaconda or not, and the same with Timezone (although Timezone only runs in the case where a user was not created), since all of these are already handled by Anaconda. That is, the Language, Keyboard, and Timezone panels should *never* be displayed: Fedora would be best-off by patching out these three panels completely. (That is my recommendation for F21.)

Network and Online Accounts, however, would be desirable to keep regardless of whether the user was created in the installer, which I take as a hint that maybe existing user mode should remain.

(In reply to Kalev Lember from comment #16)
> Would it make sense to try and fix this for F22 by removing the user
> creation step from Anaconda and only doing it in gnome-initial-setup? At
> least for the Workstation image.

I don't think this would be sufficient. What we really need is a complete rethink of what will be handled by the installer and what will be handled by g-i-s.  Language and keyboard layout, for instance, pretty much need to be set by the installer, unless the installer presents no text and no input forms. Timezone should be in either one place or the other, not both (how important is getting the time right before installation?).

Comment 18 Michael Catanzaro 2014-10-27 16:22:47 UTC
(In reply to Kalev Lember from comment #16)
> Would it make sense to try and fix this for F22 by removing the user
> creation step from Anaconda and only doing it in gnome-initial-setup? At
> least for the Workstation image.

In fact, perhaps the opposite approach would be best: we could assume that the installer will always create a user account unless the install is performed by an OEM, and then the language/keyboard/timezone panels all immediately make sense to have when there is no existing user. I think that assumption would invalidate most of my comment #17, and I wonder if that's what the g-i-s designers were aiming for as everything makes so much more sense in that case....

Comment 19 Adam Williamson 2014-10-27 16:29:14 UTC
"Timezone should be in either one place or the other, not both (how important is getting the time right before installation?)."

IIRC the anaconda folks have explained that there are systems with busted RTCs or something where the date and time will be something crazy like 1969 unless the user configures it, and if that's not fixed, then certain things during installation will go wrong. I think in theory it might be possible for the installer to just do something like "if date is 1969; set date to 2014" or whatever - to just get close enough for install to work, if people really wanted to make this be part of post-install not part of install - but it'd be best to work together with them on that.

Comment 20 Adam Williamson 2014-10-27 16:30:25 UTC
"In fact, perhaps the opposite approach would be best: we could assume that the installer will always create a user account unless the install is performed by an OEM"

You can't do that with anaconda, it does not force creation of a user account and likely will not do so, because we have use cases where people don't want local user accounts in their deployments.

Comment 21 Michael Catanzaro 2014-10-27 20:48:21 UTC
So that takes us back to "gut g-i-s by removing language, keyboard, and timezone selection." This seems like a reasonable approach for F21.

P.S. All of the comments here would apply equally also to openSUSE, Debian, and Ubuntu GNOME: their installers all handle the same things that Anaconda does.

Comment 22 Matthias Clasen 2014-10-27 21:04:13 UTC
we'll fix the keyboard page to leave multi-layout setups alone

Comment 23 Fedora Update System 2014-10-31 16:58:50 UTC
gnome-initial-setup-3.14.1-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gnome-initial-setup-3.14.1-3.fc21

Comment 24 Fedora Update System 2014-11-01 16:40:58 UTC
Package gnome-initial-setup-3.14.1-3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-initial-setup-3.14.1-3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14098/gnome-initial-setup-3.14.1-3.fc21
then log in and leave karma (feedback).

Comment 25 Lukas Brabec 2014-11-04 13:02:36 UTC
Created attachment 953597 [details]
anaconda layout settings reset to one layout from gnome-initial-setup

Comment 26 Lukas Brabec 2014-11-04 13:05:59 UTC
oh, wrong tab wrong bug.. creating 1160252 which is probably duplicate to this one

Comment 27 Rui Matos 2014-11-04 13:29:08 UTC
*** Bug 1160252 has been marked as a duplicate of this bug. ***

Comment 28 Fedora Update System 2014-11-10 06:34:26 UTC
gnome-initial-setup-3.14.1-3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.