Description of problem: I have installed F15 Alpha RC2 using Czech language and Czech (QWERTZ) layout. I encrypted filesystem with passphrase "šampónek". Installation finished ok. After reboot, I'm asked for passphrase, but the input field freezes as soon as I hit letter š. I have tried several times. Ascii letters are entered ok, but as soon as I hit š letter, the whole input freezes and I have to reboot. Version-Release number of selected component (if applicable): plymouth-0.8.4-0.20110209.2.fc15.i686 (I guess, can't boot the system) How reproducible: always Steps to Reproduce: 1. follow description
if you boot with plymouth.debug on the kernel command line and remove rhgb from the kernel command line, does anything interesting get printed to the console when you hit š ?
Nothing interesting gets printed out, it just freezes. You should be able to easily reproduce it by booting with "KEYTABLE=cz-us-qwertz" option on kernel cmdline and then hitting "3" in the password field. Most of special czech characters (ěščřžýáíé) are located on US-layout keys 2..0 (I don't mean numpad). Some other characters apart from 'š' do work (they print out a star), although a little weirdly - you have to press them twice. 'š' kills it.
I report the same issue when testing this on real HW[1] (previously this bug occurred on KVM machine). Used the same very same steps, layout and password "šampónek" as kparal before. [1] http://www.smolts.org/client/show/pub_a64408ed-c828-4305-95f5-bfbae42dce11
Confirmed that the problem occurs with slovak(querty) layout as well, where the "š" character can by typed properly, however the "ó" character cannot be typed as that is typed by pressing the "´" key first and followed by "o" afterwards. However "´" key does register on its own, thus ending up with two separate characters. I am not sure whether English layout isn't active instead, as that would explain this behavior well. KEYTABLE=sk-querty is passed to kernel on boot though.
vita: is it just characters which have to be composed with dead keys that fail? or is it more complex than that?
Discussed at the go/no-go meeting of 2011-03-02. Agreed this is not a blocker; the criteria do not cover keymap issues well, we will address that, but the group generally agreed the impact of this is too limited and the workarounds are sufficient. we will document this and the workarounds.
I agree that this is not an Alpha blocker. I don't think that too many use national characters in disk encryption password. However there is also an issue also when people use non-alphanumeric ASCII characters ('#', '$', etc.) on non-english layouts, there was a problem with such a password reported by my cubicle neighbour. Also likely not an Alpha blocker, but I'll investigate this as this would likely be an unpleasant bug in later releases.
Does this update fix your issues? https://admin.fedoraproject.org/updates/dracut-008-7.fc15 You have to issue: # dracut -f after installation
(In reply to comment #8) > Does this update fix your issues? > https://admin.fedoraproject.org/updates/dracut-008-7.fc15 It really does! The problem seems to be fixed completely - czech characters work in password, as single letters (š) or as dead keys combos (ó). Vitezslav, if you can still reproduce this bug after the update, please reopen the bug. It works for me now.
Kparal and vhumpa, can you add bodhi karma to https://admin.fedoraproject.org/updates/dracut-008-7.fc15 ?
(In reply to comment #10) > Kparal and vhumpa, can you add bodhi karma to > https://admin.fedoraproject.org/updates/dracut-008-7.fc15 ? Apologies, scratch that, the update is already in stable.