This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 571900 - Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha -
Keyboard mapping not correct (USA instead of Belgium) when first login after ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: system-setup-keyboard (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Adel Gadllah
Fedora Extras Quality Assurance
: Triaged
: 587500 (view as bug list)
Depends On:
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-03-09 14:49 EST by Michel Duquaine
Modified: 2013-01-10 00:46 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-06 17:30:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michel Duquaine 2010-03-09 14:49:08 EST
Description of problem:

During installation of Fedora 13 Alpha I have chosen Belgium as keyboard mapping.
At first login screen, the default keyboard mapping is USA but should be Belgium.


Version-Release number of selected component (if applicable):
Fedora 13 Alpha

How reproducible:


Steps to Reproduce: see description
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Petri Laine 2010-04-08 07:50:13 EDT
(In reply to comment #0)
> Description of problem:
> 
> During installation of Fedora 13 Alpha I have chosen Belgium as keyboard
> mapping.
> At first login screen, the default keyboard mapping is USA but should be
> Belgium.
> 

Same problem with Finnish keyboard and installation with nightly-compose:
desktop-x86_64-20100406.18.iso 

Finnish keyboard was chosen during installation and characters were ok for example when setting the hostname.

First boot and LUKS partition passphrase, console and GDM login are using USA mapping instead of Finnish.

$ cat /etc/sysconfig/keyboard
KEYTABLE="us"
MODEL="pc105+inet"
LAYOUT="us"

(Perhaps this is anaconda bug instead of gdm?)
Comment 2 He Rui 2010-04-09 00:04:35 EDT
(In reply to comment #0)
> Description of problem:
> 
> During installation of Fedora 13 Alpha I have chosen Belgium as keyboard
> mapping.
> At first login screen, the default keyboard mapping is USA but should be
> Belgium.
> 
> 
> Version-Release number of selected component (if applicable):
> Fedora 13 Alpha

Did you choose Belgian(Be-latin1)? I tested it using Fedora 13 Beta RC5, but didn't reproduce the issue.

Steps:
1. Install F13-beta-rc5 and proceed.
2. Choose Belgian(Be-latin1) as keyboard. 
3. Encrypt the system with a password.
4. Choose minimal install 

After install, LUKS partition passphrase, log in and console are using Belgian keyboard.
Comment 3 Petri Laine 2010-04-09 02:58:49 EDT
(In reply to comment #2)
My steps with Finnish settings:
1. Download F13-Beta-RC5 image F13-Beta-x86_64-Live.iso, check sha256sum, use dd to copy the image to 1 GB usb stick.
2. Boot from the usb stick
3. Live GDM login: set language and keyboard to Finnish: suomi (Suomi), Finland
4. GNOME language and keyboard is ok
5. Now I also checked the system language:
GNOME menu: Järjestelmä/Ylläpito/Kieli: English (USA)
and from Terminal
cat /etc/sysconfig/keyboard
KEYTABLE="us" etc
I didn't change those settings
6. Start installation, language is Finnish and keyboard is correctly preselected "suomalainen", proceed
7. Reformat the earlier testing partitions and encrypt /home ie select "Salaa"
8. Set passphrase ie Syötä salalause: my-passwd
9. Installation ok, reboot
10. LUKS prompt "/home on salasanasuojattu", typing "my-passwd" fails, typing "my+passwd" succeeds
11. ... GDM login shows: Kieli(language): Suomi, Näppäimistö(keyboard): USA
12. After Ctrl-Alt-F2 console login you have to type as with US mapped layout and
cat /etc/sysconfig/keyboard shows
KEYTABLE="us" etc like previously

Same keyboard problem even when you don't choose encryption.

I hope this helps.
Comment 4 He Rui 2010-04-09 03:42:32 EDT
(In reply to comment #3)
> (In reply to comment #2)
> My steps with Finnish settings:
> 1. Download F13-Beta-RC5 image F13-Beta-x86_64-Live.iso, check sha256sum, use
> dd to copy the image to 1 GB usb stick.
> 2. Boot from the usb stick
> 3. Live GDM login: set language and keyboard to Finnish: suomi (Suomi), Finland
> 4. GNOME language and keyboard is ok
> 5. Now I also checked the system language:
> GNOME menu: Järjestelmä/Ylläpito/Kieli: English (USA)
> and from Terminal
> cat /etc/sysconfig/keyboard
> KEYTABLE="us" etc
> I didn't change those settings

System language and keyboard won't change, since you only change the user's ones. So these are not bugs.

> 6. Start installation, language is Finnish and keyboard is correctly
> preselected "suomalainen", proceed
> 7. Reformat the earlier testing partitions and encrypt /home ie select "Salaa"
> 8. Set passphrase ie Syötä salalause: my-passwd
> 9. Installation ok, reboot
> 10. LUKS prompt "/home on salasanasuojattu", typing "my-passwd" fails, typing
> "my+passwd" succeeds
> 11. ... GDM login shows: Kieli(language): Suomi, Näppäimistö(keyboard): USA
> 12. After Ctrl-Alt-F2 console login you have to type as with US mapped layout
> and
> cat /etc/sysconfig/keyboard shows
> KEYTABLE="us" etc like previously
> 
> Same keyboard problem even when you don't choose encryption.
> 
> I hope this helps.    

Wow, if only I know about Finnish. :) Thanks for your detailed steps, I will try to reproduce it using a live image.
Comment 5 Petri Laine 2010-04-09 05:18:55 EDT
(In reply to comment #4)
I did one more test and there were no keyboard mapping problems with Finnish settings when I did a netinstall from nearby mirror and started it with a fresh .../os/images/boot.iso image.
Comment 6 He Rui 2010-04-09 05:40:40 EDT
(In reply to comment #5)
> (In reply to comment #4)
> I did one more test and there were no keyboard mapping problems with Finnish
> settings when I did a netinstall from nearby mirror and started it with a fresh
> .../os/images/boot.iso image.    

Verified it happens when using live images to install. The only difference I had is that after installation and reboot, the LUKS passwd works fine, the others are the same as yours.
Comment 7 James Laska 2010-04-09 07:51:34 EDT
Adding to the F13Blocker list for review
Comment 8 Michel Duquaine 2010-04-14 06:53:11 EDT
Tested with F13 Beta (Live/Gnome) : problem is now solved.
Thanks!
Comment 9 Adam Williamson 2010-04-16 12:44:31 EDT
Petri, He Rui - what's the current state of the issues with live install that you're tracking? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 He Rui 2010-04-19 04:57:19 EDT
(In reply to comment #8)
> Tested with F13 Beta (Live/Gnome) : problem is now solved.
> Thanks!    

Which version did you test? I tested F13-beta-rc5 live image and the problem still existed.
Comment 11 He Rui 2010-04-19 06:01:48 EDT
(In reply to comment #9)
> Petri, He Rui - what's the current state of the issues with live install that
> you're tracking? Thanks.
> 

We both verified that:
when non-english keyboard was chosen, in anaconda, keyboard were ok for setting the hostname and passwd etc.

After installation, First boot, console and GDM login are using USA
mapping instead of the chosen keymap.


The difference between our testing is that, LUKS partition passphrase asked after install uses USA keymap for Petri but for me uses the same keymap as installation.
Comment 12 Michel Duquaine 2010-04-19 13:57:49 EDT
> Which version did you test? I tested F13-beta-rc5 live image and the problem
> still existed.

I tested with the official F13 Beta release.  
Readme file downloaded with the iso mentionned:
Sources for all packages used in this live image can be found under: 
http://kojipkgs.fedoraproject.org/mash/branched-20100408/13/source/SRPMS/
Comment 13 He Rui 2010-04-20 07:05:10 EDT
(In reply to comment #12)
> > Which version did you test? I tested F13-beta-rc5 live image and the problem
> > still existed.
> 
> I tested with the official F13 Beta release.  
> Readme file downloaded with the iso mentionned:
> Sources for all packages used in this live image can be found under: 
> http://kojipkgs.fedoraproject.org/mash/branched-20100408/13/source/SRPMS/    

I tested the official F13 Beta live from the official website:
http://download.fedoraproject.org/pub/fedora/linux/releases/test/13-Beta/Live/i686/F13-Beta-i686-Live.iso

And what I did is: 
1. On the live desktop, click 'Install to Hard drive' icon to access to anaconda. 
2. Choose Belgian(Be-latin1) as keyboard and proceed the installation.
3. After installation and reboot, it still used USA keyboard from the firstboot step.
Comment 14 Petri Laine 2010-04-20 13:19:03 EDT
> 3. After installation and reboot, it still used USA keyboard from the firstboot
> step.    

And still the same problem with Finnish and the F13-Beta-x86_64-Live.iso linked at https://fedoraproject.org/get-prerelease.

In setting the LUKS partition passphrase I used 2 characters I knew map differently with USA vs Finnish settings, ":" and "-", and with my Finnish keyboard I had to replace them "Ö" and "+" in order to get pass the LUKS prompt. It works OK after I changed the keyboard setting from american english to finnish with system-config-keyboard. It is a little more cryptic thing to use this way. :)
Comment 15 Michel Duquaine 2010-04-21 15:48:11 EDT
Sorry my fault. F13 Beta live system on usb is ok (without installation ...) but the installation of F13 Beta live (on Virtual Box) is NOT OK : keyboard still USA.
Comment 16 Adam Williamson 2010-04-23 13:26:40 EDT
This was discussed at today's blocker bug review meeting. We agreed this is a blocker issue; no single criteria exactly covers it, but it arguably constitutes a failure to properly install and boot the system, when using a non-default keymap. Assigning to system-setup-keyboard, where we believe the problem lies; drago01 will investigate.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Adel Gadllah 2010-04-23 15:26:46 EDT
(In reply to comment #16)
> This was discussed at today's blocker bug review meeting. We agreed this is a
> blocker issue; no single criteria exactly covers it, but it arguably
> constitutes a failure to properly install and boot the system, when using a
> non-default keymap. Assigning to system-setup-keyboard, where we believe the
> problem lies; drago01 will investigate.

(In reply to comment #1)
> [...]
> $ cat /etc/sysconfig/keyboard
> KEYTABLE="us"
> MODEL="pc105+inet"
> LAYOUT="us"

I should have spotted this earlier ... system-setup-keyboard just reads this information from here and write it out as a xorg config file.

I did a test install and even though I selected a German layout it ended up with LAYOUT="us" here too, so system-setup-keyboard is not at fault here.

It looks like the chosen layout isn't written out during installation correctly.

system-config-keyboard itself writes the file out just fine though.

So this looks like an interaction issue between system-config-keyboard (which iirc anaconda uses for writing out the data) and anaconda.

I will reassign to anaconda for now (as system-config-keyboard when run as  standalone app seems to be just fine).
Comment 18 Kamil Páral 2010-04-26 10:46:49 EDT
I just tested on Fedora 13 Beta DVD. I chose Czech (non-qwerty) layout and entered encryption password "háčkyčárky". Please note that those characters may be inserted on czech keyboard by single key strokes (č) or composing multiple strokes (ˇc creates č). After doing minimal install and rebooting, I was able to unlock partition only when using single strokes, not using compose strokes. In anaconda both types worked ok.

After logging in VT1, the single strokes work, but the compose strokes produces completely wrong results (ˇc creates è). This is current setup:

# cat /etc/sysconfig/keyboard 
KEYTABLE="cz-us-qwertz"
MODEL="pc105"
LAYOUT="cz,us"
OPTIONS="grp:shifts_toggle,grp_led:scroll"

I suppose plymouth has probably the same problem (wrong composing of characters), that's why entering passphrase failed.
Comment 19 Chris Lumens 2010-04-30 10:04:48 EDT
*** Bug 587500 has been marked as a duplicate of this bug. ***
Comment 20 Adam Williamson 2010-05-03 11:02:31 EDT
clumens, what's the status on this? final freeze tomorrow!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Chris Lumens 2010-05-03 15:44:30 EDT
I just did a live install, picking the Belgian keyboard layout.  During installation, the Belgian layout was used.  After installation, the Belgian layout was used on the console but GDM defaulted to using US.  Is this in line with what other people are seeing?
Comment 22 Adam Williamson 2010-05-03 16:00:31 EDT
I think so, but Kamil is exposing a wrinkle with layouts that have multiple-stroke composes: these don't work correctly at the console after install. I believe this is plausible, from what I know about how this works (i.e. single-stroke characters working per the chosen layout, but multi-stroke composes not), but can't quite dredge the details to the surface of my mind.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Igor Pires Soares 2010-05-03 20:20:53 EDT
(In reply to comment #21)
> I just did a live install, picking the Belgian keyboard layout.  During
> installation, the Belgian layout was used.  After installation, the Belgian
> layout was used on the console but GDM defaulted to using US.  Is this in line
> with what other people are seeing?    


clumens, that is exactly what's happening but this bug also affects the keyboard layout parameter when using a kickstart file to install or create a live spin.
Comment 24 Kamil Páral 2010-05-04 04:40:36 EDT
Ok, tested again with F13 Final TC1. I must say it's highly broken.

I picked Czech language and Czech 'qwerty' keyboard layout for installation (I suppose it's cz-lat2 keymap, but who knows). In anaconda password prompt the key layout seems to be working fine, even multistroke characters (although because of bug 588648 I can't really tell what I entered).

However after reboot, I'm not able to unlock my partition at all. Multistroke characters don't work at all (I see two stars instead of one), but even singlestroke characters don't help - invalid password. Kernel line GRUB in grub has KEYTABLE=cz-lat2 option.

When I run anaconda in rescue mode and pick cz-lat2 layout, I still can't decrypt disk. When I drop in shell, it is not czech layout but standard english layout - not possible to enter any czech characters. That would explain why I can't unlock the disk. When I run rescue mode again and pick cz-us-qwertz layout and drop in shell, the layout is completely messed up. I can enter acute characters (ýáíéú), but I can't enter caron characters (ěščřž), some mess is printed instead. Again, can't unlock partition.

I would recommend to fix bug 588648 as prerequisite for this, because without it it makes the whole testing pointless - I just don't know what is the encryption phrase, because I don't know whether the keyboard layout was broken even in the installation phase or not.
Comment 25 Adam Williamson 2010-05-04 08:46:55 EDT
aren't there other places during installation where you can type stuff, to see what keyboard layout is in use? e.g. tell it you want to add a new network repo or something?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 26 Kamil Páral 2010-05-05 05:45:19 EDT
(In reply to comment #25)
> aren't there other places during installation where you can type stuff, to see
> what keyboard layout is in use? e.g. tell it you want to add a new network repo
> or something?
> 

Oh, very good idea. Tested again. In anaconda graphics installer both layouts (cz-lat2 and cz-us-qwertz) work perfectly. In anaconda text installer there is unfortunately no text field to try it.
Comment 27 Chris Lumens 2010-05-05 10:05:42 EDT
> clumens, that is exactly what's happening but this bug also affects the
> keyboard layout parameter when using a kickstart file to install or create a
> live spin.    

That's not an anaconda problem, then.  That'd be something to look at in livecd-creator.
Comment 28 Chris Lumens 2010-05-05 10:17:10 EDT
> I picked Czech language and Czech 'qwerty' keyboard layout for installation (I
> suppose it's cz-lat2 keymap, but who knows). In anaconda password prompt the
> key layout seems to be working fine, even multistroke characters (although
> because of bug 588648 I can't really tell what I entered).

Yes - if you pick the Czech keyboard, you get cz-lat2.  That's been what we've used in anaconda since at least 2005.  In stage2 there's also "Czech (qwerty)".  Sure.

> However after reboot, I'm not able to unlock my partition at all. Multistroke
> characters don't work at all (I see two stars instead of one), but even
> singlestroke characters don't help - invalid password. Kernel line GRUB in grub
> has KEYTABLE=cz-lat2 option.

If your grub conf has the correct KEYTABLE= and your /etc/sysconfig/i18n file has the correct settings, anaconda has done its job.  After that if the layout does not work, it's another tool that is to blame.

> When I run anaconda in rescue mode and pick cz-lat2 layout, I still can't
> decrypt disk. When I drop in shell, it is not czech layout but standard english
> layout - not possible to enter any czech characters. That would explain why I
> can't unlock the disk. When I run rescue mode again and pick cz-us-qwertz
> layout and drop in shell, the layout is completely messed up. I can enter acute
> characters (ýáíéú), but I can't enter caron characters (ěščřž), some mess is
> printed instead. Again, can't unlock partition.

This could very well be an anaconda problem, but it's not what this bug report is tracking.
Comment 29 Igor Pires Soares 2010-05-05 10:42:34 EDT
(In reply to comment #27)
> > clumens, that is exactly what's happening but this bug also affects the
> > keyboard layout parameter when using a kickstart file to install or create a
> > live spin.    
> 
> That's not an anaconda problem, then.  That'd be something to look at in
> livecd-creator.    

What I meant was that the same issue is affecting live spin builds and a normal installation using Anaconda too. Whether you create a live spin or install Fedora using the DVD media, you'll get the USA keyboard layout on GDM, no matter which layout you have set in the kickstart file or during the installation. Since this is also affecting non-live images I guess this is not a livecd-creator issue. Both issues might have the same origin.
Comment 30 Adel Gadllah 2010-05-05 11:36:39 EDT
(In reply to comment #28)
> > I picked Czech language and Czech 'qwerty' keyboard layout for installation (I
> > suppose it's cz-lat2 keymap, but who knows). In anaconda password prompt the
> > key layout seems to be working fine, even multistroke characters (although
> > because of bug 588648 I can't really tell what I entered).
> 
> Yes - if you pick the Czech keyboard, you get cz-lat2.  That's been what we've
> used in anaconda since at least 2005.  In stage2 there's also "Czech (qwerty)".
>  Sure.
> 
> > However after reboot, I'm not able to unlock my partition at all. Multistroke
> > characters don't work at all (I see two stars instead of one), but even
> > singlestroke characters don't help - invalid password. Kernel line GRUB in grub
> > has KEYTABLE=cz-lat2 option.
> 
> If your grub conf has the correct KEYTABLE= and your /etc/sysconfig/i18n file
> has the correct settings, anaconda has done its job.  After that if the layout
> does not work, it's another tool that is to blame.

/etc/sysconfig/keyboard should be correct (which currently isn't).
Comment 31 David Cantrell 2010-05-05 17:45:21 EDT
I just did installs of F-13 Beta in gui and text mode.  I selected Czech for the language and the Czech keyboard layout.  The installation ran in Czech.  Here are what showed up in the concerned files on the target system:


GUI mode:

/etc/sysconfig/keyboard:
KEYTABLE="cz-lat2"
MODEL="pc105"
LAYOUT="cz"
VARIANT="qwerty"
OPTIONS="grp:shifts_toggle,grp_led:scroll"

Options in /etc/grub.conf:
LANG=cs_CZ.UTF-8 KEYTABLE=cz-lat2



Text mode:

/etc/sysconfig/keyboard:
KEYTABLE="cz-lat2"
MODEL="pc105"
LAYOUT="cz"
VARIANT="qwerty"

Options in /etc/grub.conf:
LANG=cs_CZ.UTF-8 KEYTABLE=cz-lat2


So is this bug still a bug?  If the contents of /etc/sysconfig/keyboard are the problem, then we should reassign this bug to system-config-keyboard because anaconda does not write that file.  We create a keyboard object from the system_config_keyboard Python module, call the set() method to set it to the keyboard you select during installation, and then after packages are installed we call the write() method on the keyboard object to write out the /etc/sysconfig/keyboard file.

The keymap names and descriptions presented to the user during installation come from:

/usr/lib/python2.6/site-packages/system_config_keyboard/keyboard_models.py

Which is also part of system-config-keyboard, so if the mapping settings or names are wrong, it would have to be fixed in that file.
Comment 32 James Laska 2010-05-05 20:01:21 EDT
system-config-keyboard folks (Adel or Lubomir), do you have any thoughts on dcantrell's analysis in comment#31?
Comment 33 Igor Pires Soares 2010-05-06 01:14:42 EDT
I found out something interesting, and it points to a GDM bug. My first tests were based on Fedora 13 TC 1 which included gdm-2.30.0-1.fc13. Yesterday gdm got updated to 2.30.2-1.fc13 and this bug seems fixed to me. I just tested with a image built by myself.
Comment 34 Kamil Páral 2010-05-06 09:38:05 EDT
I tried to install Fedora 12 (twelve!) with Czech language and Czech qwerty keyboard, to compare it with F13.

GUI mode:

/etc/sysconfig/keyboard:
KEYTABLE="cz-lat2"
MODEL="pc105"
LAYOUT="cz"
KEYBOARDTYPE="pc"
VARIANT="qwerty"

Options in /etc/grub.conf:
LANG=cs_CZ.UTF-8 KEYTABLE=cz-lat2

GDM has Czech language and Czech qwerty keyboard after startup as default. VT has US layout. Running system-config-keyboard in VT shows Czech (qwerty) as currently selected).

Text mode:

not possible because of anaconda crash

Installation with encrypted partitions:

The same problem as for F13. When encrypted with passphrase "háčkyčárky" I'm not able to unlock it, even though kernel boot options specify correct keyboard layout.
Comment 35 Ray Strode [halfline] 2010-05-06 12:54:24 EDT
Turns out we're just shipping too old a version of system-setup-keyboard
Comment 36 Adam Williamson 2010-05-06 13:06:22 EDT
more details: it seems that TC1 contains:

./Packages/system-setup-keyboard-0.8.4-1.fc13.x86_64.rpm

but the repos contain:

system-setup-keyboard-0.8.5-1.fc13.x86_64.rpm

this was a significant change for our purposes here. It seems that 0.8.4-1 got back into the repos after 0.8.5-1 was pushed (the classic problem with an earlier update superseding a later one that we've seen a few times this cycle). We fixed this, but not in time for the TC1 build.

The reason different people saw different things is just that if you did an install with the network repos enabled, you got the working s-s-k. Kamil was testing with TC1 without network repos, so he had the broken s-s-k.

I will try and test an 0505/network install with a couple of different layouts to confirm the behaviour here with the correct packages, but I'm currently stuck because of a conflict between initscripts and NetworkManager in the repos...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 James Laska 2010-05-06 13:22:41 EDT
Posting for future reference (mainly mine).  Kamil was running through a series of tests to determine what functionality had regressed between F12 and F13.  The following summarizes that testing.

Selecting a CZ language and CZ keymap in anaconda, the observed results are summarized as follows:

 F12  | F13   | Test performed
======+=======+==============================================
 PASS | PASS  | anaconda uses selected LANG and keymap during install
 FAIL | FAIL" | anaconda rescue-mode uses selected LANG and keymap when
                unlocking encrypted devices
 PASS | PASS  | bootloader setup with expected LANG and KEYTABLE values
 PASS | PASS  | /etc/sysconfig/keyboard contains expected values
 FAIL | FAIL  | Plymouth uses selected LANG and keyboard to unlock
                encrypted devices
 PASS | PASS+ | GDM defaults to selected LANG and keyboard 
 FAIL | FAIL* | Console defaults to selected LANG and keyboard settings

["] - FAIL w/ CZ keymap, but suspect this will work w/ others (e.g. French)
[+] - PASS, requires system-setup-keyboard-0.8.5-1
[*] - FAIL w/ CZ keymap, but works with French keymap
Comment 38 Petri Laine 2010-05-06 14:46:56 EDT
As my problem with Finnish settings above were only with live images, I tested now the latest nighly compose desktop-x86_64-20100506.01.iso

First boot after install and LUKS, GDM and console(=VT?) had correct settings.

$ cat /etc/sysconfig/keyboard
KEYTABLE="fi"
MODEL="pc105"
LAYOUT="fi"
KEYBOARDTYPE="pc"

instead of "us" layout like it was earlier.

Installed versions with the mentioned live image were:
system-setup-keyboard-0.8.5-1.fc13.x86_64
system-config-keyboard-1.3.1-1.fc12.x86_64   (fc12?)

So there's no bugs with Finnish settings.

Kiitos!
Comment 39 Adam Williamson 2010-05-06 15:19:51 EDT
Thanks very much for the confirmation, Petri, that's very helpful.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 40 Adam Williamson 2010-05-06 15:44:55 EDT
I just tested a clean VM install with the 0505 installer (13.40) and current repo packages (s-s-k 0.8.5), with encrypted partitions, with UK keyboard layout, using UK keymap specific characters like ", £ and \. Everything passes. Anaconda correctly uses the selected keymap, so does plymouth when unlocking the partitions, so does GDM and console login, and the logged in desktop. This is all good for me. It sounds like there may be remaining wrinkles with multi-stroke composes in Czech, but we should re-test that with current packages.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 41 Adel Gadllah 2010-05-06 16:01:58 EDT
desktop-x86_64-20100506.01.iso seems fine here too using a German setup,
plymouth, firstboot, gdm everything seems fine and the configuration files do have the right content.
Comment 42 Jesse Keating 2010-05-06 17:30:44 EDT
Looks like we can close this one out.
Comment 43 Adam Williamson 2010-05-06 18:10:26 EDT
well, I was keeping it open to track the potential issue with Czech.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 44 Carl G. 2010-05-06 18:39:22 EDT
Works for me with a CF keymaps.
Comment 45 Kamil Páral 2010-05-07 02:16:08 EDT
(In reply to comment #43)
> well, I was keeping it open to track the potential issue with Czech.
> 

I'll create separate tickets for issues with Czech keymap, Adam. It seems to be really specific to Czech, other languages/keymaps seem to be working fine.

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