Created attachment 845779 [details] screenshot Description of problem: With GB keyboard, English(UK), the layout in the test window remains English (US). The text shown in the attached screenshot was created by holding the shift key down and hitting each printable key in turn. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Can you provide the steps that you took to get to this screen? What language and keyboard layout did you select on the welcome screen, did you change any configuration on the keyboard layout spoke, etc. I just tried both selecting the keyboard layout from the welcome screen and configuring it on the keyboard layout screen, and both seemed to work fine (shift 3 printed £, shift-` printed ¬)
I booted with the following grub entry: menuentry 'Install Fedora 20' --class fedora --class gnu-linux --class gnu --class os { insmod loopback set isofile=Fedora-20-x86_64-netinst.iso loopback loop (hd0,gpt3)/$isofile set root=(loop) linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:UUID=1f9f5c22-a2e1-4d4c-a384-3c33e6905f65:/$isofile inst.lang=en_GB.UTF-8 inst.keymap=uk inst.repo=http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/releases/20/Fedora/x86_64/os/ quiet initrdefi /images/pxeboot/initrd.img } Then clicked Continue at the Language Selection. Then clicked the Keyboard spoke
Created attachment 846153 [details] Welcome Screen I thought a screenshot of the Welcome Screen/Language Selection screen as I see it at startup might help
inst.keymap should be gb instead of uk. The problem seems to be that if anaconda is given an invalid keymap name on the command line, it will still add the keymap from the locale to the keyboard configuration, but it doesn't set that as the active keymap.
The keyboard is correct everywhere else, e.g. at the shell prompt. It is just that test area which is wrong. It always used to be uk. I have been doing this for years, including my current F19 install.
No, I tell a lie, not my current F19, that was installed with a usb stick, but certainly F18.
I just checked, there is no /usr/lib/kbd/keymaps/i386/qwerty/gb.map.gz on my machine, only /usr/lib/kbd/keymaps/i386/qwerty/uk.map.gz. I reference https://fedoraproject.org/wiki/Anaconda_Boot_Options, (which used to have a link to a draft of recent changes, where has that gone?), anyway, the keymap entry links to https://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard
(In reply to David Shea from comment #4) > inst.keymap should be gb instead of uk. The problem seems to be that if > anaconda is given an invalid keymap name on the command line, it will still > add the keymap from the locale to the keyboard configuration, but it doesn't > set that as the active keymap. inst.keymap could be both 'gb' or 'uk' if everything worked as expected. However, 'uk' should definitely work. And the layout indicator in the screenshot reveals that the 'gb' keyboard layout is properly set. I have no idea what's happening, but it's quite weird because the layout indicator is directly connected to the X server and should thus show the layout that is actually used by the X server. I'll need to investigate it a bit more.
I should just correct comment 5. I just tried entering characters in the Mount Point field of the Manual Partitioning screen and that is also English (US). So it would appear that the problem is across the graphical input. This is obviously going to cause problems to people entering strong passwords.
(In reply to Keith Dixon from comment #9) > I should just correct comment 5. I just tried entering characters in the > Mount Point field of the Manual Partitioning screen and that is also English > (US). So it would appear that the problem is across the graphical input. > This is obviously going to cause problems to people entering strong > passwords. Yeah, there is no difference between those entries. Patch posted to anaconda-patches. Could you please try the following updates image? http://vpodzime.fedorapeople.org/1048592_updates.img
That seems to have fixed it. I tried the keyboard test window and the Mount Point field and booted with: linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:UUID=1f9f5c22-a2e1-4d4c-a384-3c33e6905f65:/$isofile inst.lang=en_GB.UTF-8 inst.keymap=uk inst.updates=http://vpodzime.fedorapeople.org/1048592_updates.img quiet
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.