Red Hat Bugzilla – Bug 878433
Removing default English keyboard layout doesn't have effect in the installed system
Last modified: 2014-02-05 08:10:22 EST
Description of problem:
After adding another keyboard layout (Czech in my case) and removing the default English one, there are still two layouts available in the installed system.
Version-Release number of selected component (if applicable):
Fedora 18 Beta TC9
Steps to Reproduce:
1. Add another layout (e.g. Czech) in installer.
2. Remove the default English layout in the installer.
3. Install the system.
In GNOME, there are still two layouts available including the removed English one.
The English layout should be removed and there should be only one layout available - Czech.
This is on purpose, but I'll let Vratislav explain why since it's his code.
(In reply to comment #0)
> Description of problem:
> After adding another keyboard layout (Czech in my case) and removing the
> default English one, there are still two layouts available in the installed
> Version-Release number of selected component (if applicable):
> Fedora 18 Beta TC9
> How reproducible:
> Steps to Reproduce:
> 1. Add another layout (e.g. Czech) in installer.
> 2. Remove the default English layout in the installer.
> 3. Install the system.
> Actual results:
> In GNOME, there are still two layouts available including the removed
> English one.
What do you have in /etc/X11/xorg.conf.d/00-anaconda.cfg and /etc/vconsole.conf?
*** Bug 880755 has been marked as a duplicate of this bug. ***
*** Bug 875567 has been marked as a duplicate of this bug. ***
I've just tested the installation where I've set only 'Czech' layout. Configuration files contain:
#This file was generated by the Anaconda installer
Option "XkbLayout" "cz"
But typing reveals that active VConsole keymap is 'us'. This looks like a systemd bug. Reassigning to systemd. Please reassign this back to anaconda and me if there is any problem with these configuration files. Obviously anaconda can do nothing more than writing out configuration files.
What's the output of:
Note, I'm not sure why there should ever be a config file named anaconda.
That sounds pretty weird, as it is a plain system setting and nothing anaconda
Systemd reads and writes:
(In reply to comment #6)
> What's the output of:
> $ localectl
It gives 'cz-lat2'. The problem here is that 'cz-lat2' is a wierd layout that works like 'us' and after you hit some magic key (PrintScreen or something like that) it starts working as 'cz'. Sorry for the noise.
The problem here is that systemd-localed (used by anaconda) converts 'cz' X layout to 'cz-lat2' VConsole keymap instead of 'cz' VConsole keymap, but that's another story and a separate bug should be created for that.
Reassigning back to anaconda and me.
> Note, I'm not sure why there should ever be a config file named anaconda.
> That sounds pretty weird, as it is a plain system setting and nothing
> Systemd reads and writes:
That's because multiple X layouts can be configured in the installation and systemd-localed works only with one X layout. If you want to discuss this further, please use something else so that we don't create a lot of noise in this bug making it obfuscated.
Created attachment 654289 [details]
/etc/vconsole.conf from the system installed with Czech layout only
Created attachment 654290 [details]
/etc/X11/xorg.conf.d/00-anaconda-keyboard.conf from the system installed with Czech layout only
As attached files show, Anaconda correctly writes out configuration files with Czech layout only. Also there are no other files in /etc/X11/xorg.conf.d/. So English layout comes from a different place and it is not an anaconda issue. I'm going to reassign this to Gnome.
Hi Vratislav, I have a English f18 Final TC3 x86_64 install,and add Czech into the keyboard layout,the /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf seems to say different from yours .Actually,add Chinese into the keyboard layout,nothing happend in /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf
Created attachment 665948 [details]
Created attachment 665949 [details]
(In reply to comment #11)
> Hi Vratislav, I have a English f18 Final TC3 x86_64 install,and add Czech
> into the keyboard layout,the /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf
> seems to say different from yours .Actually,add Chinese into the keyboard
> layout,nothing happend in /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf
I have just tested both TC3 DVD and Live installation and in both cases setting 'Czech' as the only layout in the installation resulted in the configuration files I've attached before in comment #8 and comment #9.
What's the output of
$ gsettings get org.gnome.desktop.input-sources sources
in such a session right after logging in for the first time?
The 'bambara' problem from 873103 was referred here. Is that something to do with this bug?
If I do an install in French with a current F18 build (smoke9), after install, at GDM screen the panel shows 'en' and 'fr' keyboards available, but after creating a user and logging in as that user, it shows 'en' and 'bm' (Bambara) as the available keyboard layouts.
Is that part of this bug? Another bug? Does someone know what the hell is going on there?
For the case of doing a French install and the installed system having English and Bambara keyboard layouts available:
[test@localhost ~]$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'us'), ('xkb', 'ml')]
[root@localhost test]# cat /etc/vconsole.conf
[root@localhost test]# cat /etc/locale.conf
(note vconsole.conf is correct, if you don't check a checkbox on the front page of install, default will be the US layout, not the 'native' one)
[root@localhost test]# cat /etc/X11/xorg.conf.d/00-anaconda-keyboard.conf
#This file was generated by the Anaconda installer
Option "XkbLayout" "us,fr"
Option "XkbOptions" "grp:alt_shift_toggle"
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.