(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?)

(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.

(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.

(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.

(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.

(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.

Adding to the F13Blocker list for review

Tested with F13 Beta (Live/Gnome) : problem is now solved.
Thanks!

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

(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.

(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.

> 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/

(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.

> 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. :)

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.

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

(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).

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.

*** Bug 587500 has been marked as a duplicate of this bug. ***

clumens, what's the status on this? final freeze tomorrow!



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

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?

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

(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.

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.

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

(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.

> 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.

> 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.

(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.

(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).

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.

system-config-keyboard folks (Adel or Lubomir), do you have any thoughts on dcantrell's analysis in comment#31?

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.

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.

Turns out we're just shipping too old a version of system-setup-keyboard

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

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

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!

Thanks very much for the confirmation, Petri, that's very helpful.



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

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

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.

Looks like we can close this one out.

well, I was keeping it open to track the potential issue with Czech.



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

Works for me with a CF keymaps.

(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.