See https://bugzilla.redhat.com/show_bug.cgi?id=963103 : apparently, Boxes is passing invalid keyboard= parameters to anaconda in the kickstart it generates when you do an Express install of F19 Beta TC4. Jens' kickstart wound up with this: keyboard 'ja_JP.UTF-8' that's a locale name, not a keyboard layout name. https://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard documents the values that accepted here. In future we might just want Boxes to pass in a locale and let anaconda derive an appropriate keyboard layout; otherwise, if Boxes is going to do it, it should do it properly. Either way, this should probably go through mfabian's new 'langtable' thing, which is intended for this: https://github.com/mike-fabian/langtable . tflink also hit this problem, suggesting it probably happens to en_US as well. We're just confirming that at present. If so, this is probably a Beta blocker, per https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria#Self_hosting_virtualization .
(In reply to comment #0) > See https://bugzilla.redhat.com/show_bug.cgi?id=963103 : apparently, Boxes > is passing invalid keyboard= parameters to anaconda in the kickstart it > generates when you do an Express install of F19 Beta TC4. > > Jens' kickstart wound up with this: > > keyboard 'ja_JP.UTF-8' > > that's a locale name, not a keyboard layout name. > https://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard documents the > values that accepted here. > > In future we might just want Boxes to pass in a locale and let anaconda > derive an appropriate keyboard layout; otherwise, if Boxes is going to do > it, it should do it properly. It does! If this was 'ja_JP.utf8', Boxes will strip the '.utf8' part and pass that as the keyboard and locale setting to libosinfo's kickstart generator. libosinfo will then take care of transforming this into a valid keyboard name: 'jp' in this case. Either I didn't know or care about '.UTF-8' possibility when writing this code so I'll look into that now.
Ah. Yes, it's one of the great mysteries of locales: the ".utf8 / .UTF-8 discrepancy". I have spent many a fruitless afternoon Googling in search of an explanation, but the executive take-home seems to be 'in anything locale-y, deal with both foo.utf8 and foo.UTF-8, they are both used'.
Bug with patch filed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=700415
gnome-boxes-3.8.2-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-boxes-3.8.2-2.fc19
Package gnome-boxes-3.8.2-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.8.2-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8355/gnome-boxes-3.8.2-2.fc19 then log in and leave karma (feedback).
gnome-boxes-3.8.2-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-boxes-3.8.2-3.fc19
gnome-boxes-3.8.2-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-boxes-3.8.2-4.fc19
gnome-boxes-3.8.2-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-boxes-3.8.2-5.fc19
gnome-boxes-3.8.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-boxes-3.8.3-1.fc19
gnome-boxes-3.8.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.