Bug 1048592 - Wrong keyboard configuration if keymap= is used
Summary: Wrong keyboard configuration if keymap= is used
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-05 15:44 UTC by Keith Dixon
Modified: 2015-06-30 01:26 UTC (History)
7 users (show)

Fixed In Version: anaconda-21.16-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 01:26:10 UTC
Type: Bug


Attachments (Terms of Use)
screenshot (43.13 KB, image/png)
2014-01-05 15:44 UTC, Keith Dixon
no flags Details
Welcome Screen (161.01 KB, image/png)
2014-01-06 15:59 UTC, Keith Dixon
no flags Details

Description Keith Dixon 2014-01-05 15:44:01 UTC
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:

Comment 1 David Shea 2014-01-06 14:38:10 UTC
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 ¬)

Comment 2 Keith Dixon 2014-01-06 15:21:55 UTC
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

Comment 3 Keith Dixon 2014-01-06 15:59:08 UTC
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

Comment 4 David Shea 2014-01-06 17:36:31 UTC
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.

Comment 5 Keith Dixon 2014-01-06 17:42:29 UTC
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.

Comment 6 Keith Dixon 2014-01-06 17:47:13 UTC
No, I tell a lie, not my current F19, that was installed with a usb stick, but certainly F18.

Comment 7 Keith Dixon 2014-01-06 18:17:28 UTC
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

Comment 8 Vratislav Podzimek 2014-01-07 09:30:54 UTC
(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.

Comment 9 Keith Dixon 2014-01-07 11:25:11 UTC
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.

Comment 10 Vratislav Podzimek 2014-01-07 13:30:49 UTC
(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

Comment 11 Keith Dixon 2014-01-07 14:22:48 UTC
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

Comment 12 Fedora End Of Life 2015-05-29 10:20:49 UTC
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.

Comment 13 Fedora End Of Life 2015-06-30 01:26:10 UTC
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.


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