libreport version: 2.0.6 executable: /usr/bin/python hashmarkername: anaconda kernel: 3.1.0-7.fc16.i686 product: Fedora reason: KeyError: 'en-gb' time: Sun Feb 12 17:26:39 2012 version: 16 anaconda-tb-gkU7UN: Text file, 240927 bytes description: :The following was filed automatically by anaconda: :anaconda 16.25 exception report :Traceback (most recent call first): : File "/usr/lib/python2.7/site-packages/system_config_keyboard/keyboard.py", line 81, in set : kb = self.modelDict[keytable] : File "/usr/lib/python2.7/site-packages/pyanaconda/kickstart.py", line 429, in execute : self.anaconda.keyboard.set(self.keyboard) : File "/usr/lib/python2.7/site-packages/pyanaconda/kickstart.py", line 1226, in execute : obj.execute() : File "/usr/lib/python2.7/site-packages/pyanaconda/kickstart.py", line 1277, in doKickstart : anaconda.ksdata.execute() : File "/usr/lib/python2.7/site-packages/pyanaconda/dispatch.py", line 373, in dispatch : self.dir = self.steps[self.step].target(self.anaconda) : File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 88, in return_false : func(*args, **kwargs) :KeyError: 'en-gb'
Created attachment 561241 [details] File: anaconda-tb-gkU7UN
In debug, keytrable is always set to 'en-gb' nomatter what menu option I select on the initial screen. I've tried editing the grub command line to add KEYTABLE=uk (which seems to be a valid entry for this dict), but it didn't change anything. I don't know how to make anaconda use the keyboard setting I've given it. This is preupgrading F14 to F16.
It appears to have copied a legacy value of KEYTABLE from /etc/sysconfig/keyboard into /boot/upgrade/ks.cfg and that then isn't being checked for a valid value. I have gotten around it by fixing the ks.cfg file. Anaconda should probably check at least that value there before using them; alternatively, preupgrade should have not written it if it were unacceptable ( I think the list of valid kickstart keyboard settings is fixed).
This bug blocks unattended installation in Gnome Boxes. I get same trackback.
Please attach your kickstart (with private info removed).
Created attachment 582992 [details] Kickstart file by Gnome Boxes I attached kickstart file created by Gnome Boxes.
Comment on attachment 582992 [details] Kickstart file by Gnome Boxes > Created attachment 582992 [details] > Kickstart file by Gnome Boxes > > I attached kickstart file created by Gnome Boxes. Thats *not* the kickstart file but the binary image of the floppy disk on which the kickstart file is put. You can grab the kickstart file using: mcopy -i ~/.cache/gnome-boxes/fedora17-unattended.img ::ks.cfg .
Created attachment 582993 [details] Kickstart file image by Gnome Boxes I attached correct kickstart file image created by Gnome Boxes. strings decoded dump follows: mkdosfs FAT12 This is not a bootable disk. Please insert a bootable floppy and press any key to try again ... KS CFG install keyboard cz lang cs_CZ.UTF-8 network --onboot yes --device eth0 --bootproto dhcp --noipv6 --activate rootpw redhat firewall --disabled authconfig --enableshadow --enablemd5 selinux --enforcing timezone --utc CEST bootloader --location=mbr zerombr clearpart --all --drives=sda firstboot --disable part biosboot --fstype=biosboot --size=1 part /boot --fstype ext4 --recommended --ondisk=sda part pv.2 --size=1 --grow --ondisk=sda volgroup VolGroup00 --pesize=32768 pv.2 logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=768 --grow --maxsize=1536 logvol / --fstype ext4 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow reboot user --name=test --password=redhat %packages @base @core @hardware-support @base-x @gnome-desktop @graphical-internet @sound-and-video # QXL video driver and SPICE vdagent xorg-x11-drv-qxl spice-vdagent %end %post --erroronfail # Add user to admin group usermod -a -G wheel test # Enable autologin echo "[daemon] AutomaticLoginEnable=true AutomaticLogin=test [security] [xdmcp] [greeter] [chooser] [debug] " > /etc/gdm/custom.conf %end
The problem appears that these tools are using invalid keyboard values. There isn't anything anaconda can do about this other than display an error message that is a bit clearer.
I've added a patch that will tell you when the keyboard value is invalid. You will need to open bugs against the components that generate the invalid kickstarts if you want them to change their behavior.
(In reply to comment #9) > The problem appears that these tools are using invalid keyboard values. Looking at this list: http://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard 'cz' is invalid while 'cz' and 'cz-lat2, cz-us-qwertz' are valid? OTOH bot 'de' and 'de-latin1' are valid. So are 'dk', 'dk-latin1', 'fi', 'fi-latin1', 'fr', 'fr-latin1' etc. To me that just seems like your list is incomplete. > There > isn't anything anaconda can do about this other than display an error message > that is a bit clearer. And add missing layouts to its db?
(In reply to comment #11) > (In reply to comment #9) > > The problem appears that these tools are using invalid keyboard values. > > Looking at this list: http://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard > > 'cz' is invalid while 'cz' and 'cz-lat2, cz-us-qwertz' are valid? OTOH bot 'de' > and 'de-latin1' are valid. So are 'dk', 'dk-latin1', 'fi', 'fi-latin1', 'fr', > 'fr-latin1' etc. To me that just seems like your list is incomplete. I see this file on my F16: /lib/kbd/keymaps/i386/qwertz/cz.map.gz
Lorax (which builds the installer image) just uses whatever kbd and kbd-misc provide. The cz file you found is, I think, cz-us-qwertz which has z and y swapped. That list likely need to be updated. You can get the list of supported keyboards by running this python script: #!/usr/bin/python from system_config_keyboard.keyboard_models import KeyboardModels k = KeyboardModels() print sorted(k.get_models().keys())
(In reply to comment #13) > Lorax (which builds the installer image) just uses whatever kbd and kbd-misc > provide. The cz file you found is, I think, cz-us-qwertz which has z and y > swapped. > > That list likely need to be updated. You can get the list of supported > keyboards by running this python script: > > #!/usr/bin/python > from system_config_keyboard.keyboard_models import KeyboardModels > > k = KeyboardModels() > print sorted(k.get_models().keys()) Ah, thanks for the info. Now if you could confirm that we can reliably get the hosts' system keyboard layout by reading '/etc/sysconfig/keyboard'. This should be easy to fix in boxes.
According to the system_config_keyboard code the value for KEYTABLE is the key used to look it up in the get_models() dictionary.
(In reply to comment #15) > According to the system_config_keyboard code the value for KEYTABLE is the key > used to look it up in the get_models() dictionary. Cool. Martin, Could you please confirm that on your host, KEYTABLE in '/etc/sysconfig/keyboard' file is pointing to one of the supported layouts (see comment#13)?
(In reply to comment #14) > Ah, thanks for the info. Now if you could confirm that we can reliably get the > hosts' system keyboard layout by reading '/etc/sysconfig/keyboard'. This should > be easy to fix in boxes. Isn't /etc/sysconfig/keyboard containing the 'default' layout which was set at install time? Thanks to xkb/ibus, this can be different from the currently used layout in X (ie the one you set from the "country and language" GNOME capplet, which can be dynamically changed at runtime)
grep KEYTABLE /etc/sysconfig/keyboard KEYTABLE="cz-us-qwertz" python keytable.py ['ar-azerty', 'ar-azerty-digits', 'ar-digits', 'ar-qwerty', 'ar-qwerty-digits', 'be-latin1', 'ben', 'ben-probhat', 'bg_bds-utf8', 'bg_pho-utf8', 'br-abnt2', 'cf', 'croat', 'cz-lat2', 'cz-us-qwertz', 'de', 'de-latin1', 'de-latin1-nodeadkeys', 'dev', 'dk', 'dk-latin1', 'dvorak', 'es', 'et', 'fi', 'fi-latin1', 'fr', 'fr-latin1', 'fr-latin9', 'fr-pc', 'fr_CH', 'fr_CH-latin1', 'gr', 'guj', 'gur', 'hu', 'hu101', 'ie', 'is-latin1', 'it', 'it-ibm', 'it2', 'jp106', 'ko', 'la-latin1', 'mk-utf', 'nl', 'no', 'pl2', 'pt-latin1', 'ro', 'ro-cedilla', 'ro-std', 'ro-std-cedilla', 'ru', 'sg', 'sg-latin1', 'sk-qwerty', 'slovene', 'sr-cy', 'sr-latin', 'sv-latin1', 'tj', 'tml-inscript', 'tml-uni', 'trq', 'ua-utf', 'uk', 'us', 'us-acentos'] "cz-us-qwertz" is supported
Christophe, you're right, I changed keyboard layout in System Settings to US and KEYTABLE in /etc/sysconfig/keyboard is still set to "cz-us-qwertz".
(In reply to comment #17) > (In reply to comment #14) > > Ah, thanks for the info. Now if you could confirm that we can reliably get the > > hosts' system keyboard layout by reading '/etc/sysconfig/keyboard'. This should > > be easy to fix in boxes. > > Isn't /etc/sysconfig/keyboard containing the 'default' layout which was set at > install time? Thanks to xkb/ibus, this can be different from the currently used > layout in X (ie the one you set from the "country and language" GNOME capplet, > which can be dynamically changed at runtime) AFAIK it is more like the system-wide layout and is not static. GNOME not touching that file doesn't mean it cant or shouldn't.
Here is how things currently work in gnome: the per-user keyboard settings are stored in gsettings: org.gnome.libgnomekbd.keyboard.model org.gnome.libgnomekbd.keyboard.layouts org.gnome.libgnomekbd.keyboard.options the system-wide keyboard settings are saved using systemd's localed, which in turn writes /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf
okay a few points: 1) comment 0 talks about en-GB which is just weird. en_GB is a locale, and has nothing to do with keyboards 2) cz is a valid console keymap (just run loadkeys cz if you don't believe me) 3) system-config-keyboard seems to have a hard coded list of keymaps: /usr/lib/python2.7/site-packages/system_config_keyboard/keyboard_models.py The point of that list is to map console keymaps to X keymaps I guess, but it's missing "cz" 4) /etc/sysconfig/keyboard contains the system configured keymap as configured by system-config-keyboard. It's updated any time the user runs system-config-keyboard to change their keymap 5) since system-config-keyboard is the thing that normally writes that file, and system-config-keyboards hardcoded list lacks "cz", it's unclear to me how "cz" (or en-GB !) got put in that file. My assumption is users are editing it manually and putting values system-config-keyboard doesn't know about in it. 6) There's a program called system-setup-keyboard (not to be confused with system-config-keyboard) that gets run before X starts to write /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf. It reads /etc/sysconfig/keyboard and translates the keymap to an X keymap much in the same way as 3) above.
It very well could be intentional, btw, that keyboard_models.py is missing cz. I don't think when asking the user what keyboard they want, it would make sense to have 3 choices for czech
(In reply to comment #22) > okay a few points: Thanks for the info! > 4) /etc/sysconfig/keyboard contains the system configured keymap as configured > by system-config-keyboard. It's updated any time the user runs > system-config-keyboard to change their keymap > 5) since system-config-keyboard is the thing that normally writes that file, > and system-config-keyboards hardcoded list lacks "cz", it's unclear to me how > "cz" (or en-GB !) got put in that file. My assumption is users are editing it > manually and putting values system-config-keyboard doesn't know about in it. No! Boxes put those strings in the kickstart file, fetching them from the user's config (in case of kbd layout, thats the org.gnome.libgnomekbd.keyboard.layouts gsetting mentioned above). The question now is whether boxes should get layout (to put in the anaconda kickstart) from /etc/sysconfig/keyboard or that Anaconda should allow all valid choices of layouts without presenting it to the user (in case of non-kickstart installation). i-e work-around vs solution.
https://www.redhat.com/archives/virt-tools-list/2012-February/msg00244.html hints at a better solution imo...
I don't believe Anaconda is really wrong here. The problem is that Boxes is making bad assumptions about guest OS keyboard map names. As Christophe points out ultimately we will use libosinfo to solve this. As a temporary workaround until then, Boxes could just keep a mapping table for Anaconda in its code.
(In reply to comment #26) > I don't believe Anaconda is really wrong here. The problem is that Boxes is > making bad assumptions about guest OS keyboard map names. I think you need some arguments to back that claim after comment#22 (keeping in mind that this is about Fedora guest on a Fedora host/client). > As Christophe points > out ultimately we will use libosinfo to solve this. As a temporary workaround > until then, Boxes could just keep a mapping table for Anaconda in its code. And how do we find out which value from the table we pick-up? No, we are *not* going to ask the user since this information really should be auto-detectable. The temporary work-around (if needed) would be to just use the layout from /etc/sysconfig/keyboard.
anaconda-17.26-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.26-1.fc17
org.gnome.libgnomekbd.keyboard.layouts lists X layouts, not console keymaps. They aren't interchangeable. That's what /usr/lib/python2.7/site-packages/system_config_keyboard/keyboard_models.py maps (in the other direction)
(In reply to comment #29) > org.gnome.libgnomekbd.keyboard.layouts lists X layouts, not console keymaps. > They aren't interchangeable. > > That's what > /usr/lib/python2.7/site-packages/system_config_keyboard/keyboard_models.py maps > (in the other direction) Thanks for this important clarification. I cooked-up a patch last night: https://bugzilla.gnome.org/show_bug.cgi?id=675813 But thats Fedora-specific AFAICT. Is there any generic linux way to fetch console keymap?
Should be able to use org.freedesktop.locale1 interface to get the console keymap. If possible, though, you probably want to put MODEL/LAYOUT/VARIANT/OPTIONS in /etc/sysconfig/keyboard based on the gnome settings, not based on localed, since VMs are per user. Just get KEYTABLE from localed
lennart has been pushing for /etc/vconsole-setup as a replacement - localed will write that if you ask it the right way.
Package anaconda-17.26-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-17.26-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7623/anaconda-17.26-1.fc17 then log in and leave karma (feedback).
anaconda-17.26-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.