firstboot's frontend.py contains these three lines: kbd = keyboard.Keyboard() kbd.read() kbd.activate() these were added way back in the mists of time because at the time they somehow fixed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=446345 I think this was back when s-c-k actually got run _as part of firstboot_ to write out the keyboard config, so what I'm guessing happened is that firstboot didn't then pick up the config it had just written, or something. Anyway. As of right now those lines are 100% useless because s-c-k is trying to read from /etc/sysconfig/keyboard , which doesn't exist: https://bugzilla.redhat.com/show_bug.cgi?id=882159 I am pretty sure we can get correct behaviour simply by dropping them and using the keyboard config that's written out by anaconda. Given anaconda's current behaviour it's _possible_ we'd still have a problem with some Cyrillic layouts, but I'm testing and that doesn't seem to be the case, and even if it's true, those lines aren't really going to help. What they result in right now is, quite simply, firstboot always uses a U.S. English layout. Whatever /etc/vconsole.conf or the cmdline says, whatever anaconda wrote out, firstboot always runs in U.S. English. As of Final TC1. This broke between Beta and Final TC1 as anaconda stopped writing out /etc/sysconfig/keyboard between those two. Nominating as an F18 blocker. I have a fixed build ready to go.
Sigh. So this works, but there's a problem. It *does* resurrect https://bugzilla.redhat.com/show_bug.cgi?id=446345 , basically. We need to fix something else. If we leave things as they are, Cyrillic layouts 'work' (in that you get U.S. English at firstboot because of this bug), but it's bad for French and U.K. English and any other layout where the user will naturally expect to use their layout, not U.S. English, at firstboot. If we fix this bug, then it works right for French, U.K. etc, but it's bad for Cyrillic-type layouts - cases where the 'native' layout cannot type ASCII characters, and you have to switch layouts to type ASCII - because they get their 'native' layout and no keyboard switch shortcut configured. There are two bugs in anaconda related to this which I'll file. But I do think we should make this change in firstboot. Links to anaconda bugs coming.
http://koji.fedoraproject.org/koji/taskinfo?taskID=4842376 is a scratch build which fixes this. It has been tested, it does work. We need to discuss the trade-offs between this and https://bugzilla.redhat.com/show_bug.cgi?id=892110 and plan a route forward. I'm planning to request an RC1 compose without this fix, for now, as that's one _plausible_ option (though not one I'd support). The options are: 1) Don't fix this bug, but document it in CommonBugs - all users have to use a U.S. layout to create username / password 2) Fix this bug, and document 892110 in CommonBugs - Russian-type layout users have to be careful to configure their layouts correctly in anaconda 3) Fix this bug, and try to improve 892110 somewhat also, as described in https://bugzilla.redhat.com/show_bug.cgi?id=892110#c3 If everyone could contribute thoughts, that'd be great. I would favour 2) or 3).
So IMO - 2 seems like ... a reasonable option, mostly because (AIUI) the problem will be more immediately obvious to this specific group of users (vs. a "my name typed in fine, thus I didn't notice that my password was borked"). If we go this route, I think it would be incredibly nice if we could sync up quickly with someone appropriate who could ensure that this commonbug, if nothing else, was made available to see in their language. Option 3 sounds nice (though there seem to be 2 options presented in that bz) but it's not entirely clear to me how invasive it could be.
I'd favor option 2 as well.
I'm gonna go ahead and submit an update with the fix for this, since it is clearly, in absolute terms, correct. There is no valid reason for firstboot to try and read in keyboard configuration itself in this way, and taking it out makes firstboot do what is in any reasonable terms 'the right thing': read the X keyboard config written out by anaconda. If we somehow decide to go with option 1) we can always just not pull the fix into any composes.
firstboot-18.6-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firstboot-18.6-2.fc18
Package firstboot-18.6-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firstboot-18.6-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0292/firstboot-18.6-2.fc18 then log in and leave karma (feedback).
So we have three votes for plan 2). I also have another reason to go for that: if you get hit by the 'only configure native keyboard layout' problem, you probably won't be able to enter a valid root password in anaconda anyway, so you'd never make it to firstboot. So yeah, we really should just go ahead and fix firstboot. I'll mark this bug as AcceptedBlocker and the other as RejectedBlocker for now, and I've asked dgilmore to pull the fixed firstboot into RC1, as he's composing it now and we want to get out ahead and start testing. We can of course review all this on Monday and change tack if necessary, we're not doing anything irreversible.
*** Bug 890343 has been marked as a duplicate of this bug. ***
firstboot-18.6-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Some success in testing RC3. The Spanish Latam keyboard is in vconsole. (tty1...) worked with live image. I am retesting today with DVD iso.
firstboot-18.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firstboot-18.7-1.fc18
firstboot-18.7-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.