Bugzilla – Bug 113664
Keyboard layout in YaST changed too late while installation
Last modified: 2008-06-25 09:52:29 UTC
When doing a screenshot of the "mount encrypted partition" dialog while installation, I noted that the keyboard layout was still english. (I had chosen german in the bootloader.) I guess the password dialog also had the wrong keyboard layout (didn't test since my password does not contain y or z ;-) which would be *very* bad.
Please provide YaST2 logs of installation, see: http://www.opensuse.org/index.php/Bug_Reporting_FAQ#YaST
Created attachment 48265 [details] y2logs These are "newly generated" y2logs - means: the problem is reproduceable. (Keyboard layout checked using the PrintScreen dialog since the password dialog itsself shows stars only.)
Hmm, this sounds like the problem of the concept "skip language dialog if selected in bootloader". I'm afraid we will have to change it for 10.1. Jiri, what do you think?
How is the language set if the langauge dialog is skipped? It should be possible to set the keyboard at the same place...
The keyboard is set correctly in proposal, so the only time when you don't have german keyboard although you selected german as language in bootloader meny is before the installation proposal. This is really a minor issue, let's solve it later properly.
I just tested with an encrypted partition with a passphrase containing "y" and "z" (which are arranged different in de/en keyboard layout). The wrong keyboard layout leads to a wrong-entered passphrase (which the user won't see since the passphrase dialog shows only stars). This causes the encrypted partition not to be mounted which isn't minor definitely. Just imagine what happens if someone has /var encrypted...
From the comment it is not clear to me if something actually failed. Di you really have wrong keyboard in the time of passphrase requirement? When are you asked for password for encrypted partition? It looks like the only place of this problem could be during update, before the proposal is generated (which means before the keyboard for selected langauge is set) and only when you selected you language in the boot menu (e.g. in bootloader). Anyway - if you misspel the password because you have US keyaboard, you are able to repeat it, am I right? (I'm not sure; I've never seen handling of encrypted partitions in YaST). If this is a problem, we could solve it by some changes in langauge/keyboard configuration. Andreas, could you please comment?
> When are you asked for password for encrypted partition? Thomas, could you answer this? Is it done before the proposal is generated? And how is such question trigered?
Arvin, please comment.
For installation the password is asked long after the proposal buildup since the user first has to create/specify the crypted partitions. During the update this happens when all the other partitions are also mounted (in RootPart.ycp). As I see it this happens during buildup of the proposal. The "Keyboard Layout" entry is run after mounting since it's the last entry in the proposal. Maybe changing the execution order fixes that, Jiri Srain should know for sure.
Jiri doesn't want to change these issues now in RC phase. It should be possible to set the keayboard in Keyboard constructor (which is loaded far earlier). It doesn't look so ugly as I expected before; however, currently it looks like it breaks console keyboard in some cases. Maybe there could be only a call to set X keyboard, because the console one is already set - Steffen, what is done regarding to keyboard when a language is set in the boot menu?
linuxrc sets the consoles up and passes the language info to yast.
Could you please write more? Where do you get the information which keyboard to load for console? It looks like loadkyes (called from YaST) command breaks the console keyboard during installation, but the one coming from linuxrc is correct. How do you set it exactly?
It has a fixed table and just runs loadkeys. What is your problem exactly? Difficulties with Unicode?
It does exactly this: kbd_unimode(); *enc = 0; if((s = keymap_encoding(config.keymap))) { sprintf(enc, " -c %s", s); } sprintf(cmd, "loadkeys -q %s.map ; dumpkeys%s >/tmp/dk ; loadkeys -q --unicode </tmp/dk", keymap, enc ); if(!config.test) { if(config.debug) fprintf(stderr, "%s\n", cmd); system(cmd); }
Yes, I think so. yast2-country used for a long time the call "/bin/loadkeys " + keymap + " ; dumpkeys | loadkeys -u" which may be wrong but was used probably because 'loadkeys -u' didn't work correctly (bug #suse44223) So what do you call in linuxrc? 'loadkeys -u <keymap>'?
OK, so we have 2 issues here: 1. setting the keyboard when language was set outside (esp. X11 keyboard) to have the correct one before the proposal (usable for the getting to crypted partition ;the question stay if users want this - I'm personaly lucky with using US keyboard for all passwords and not the national one). 2. incorrect call of loadkeys in YaST: there should be either "-c" parameter for dumpkeys or "loadkeys -u" call. Currently YaST does not have the data necesary for -c, so I would vote for "loadkeys -u". If it works correctly now (in bug #59223 it was stated that no, but it is quite time ago). Andreas, do you want to have these fixes in RC2? Looks like point 1 is easy to implement while for point 2 I would like to talk with Juergen before fixing (but it seems 2 is quite important to fix).
(some more comments, also for Steffen)
Note, you must use the sequence 'dumpkeys -c xxx | loadkeys -u'. Just 'loadkeys -u some_map' does not work. BTW, linuxrc does not use a pipe only because the simple shell does not support it - just in case you wondered.
I don't have that 'xxx' for 'dumpkeys -c xxx | loadkeys -u' And according to Jurgen's comments in bug #59223 I though 'loadkeys -u some_map' should (someday) work - actually it worked when I tested it.
I would not bet on it. ;-) # loadkeys -u de-latin1-nodeadkeys Loading /usr/share/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz unknown keysym 'Meta_acute' /usr/share/kbd/keymaps/i386/qwertz/de-latin1.map.gz:34: syntax error syntax error in map file key bindings not changed
You're right, I just tested it with german keyboard also. My assumption came from my previous tests with czech maps - it works for them :-) I'm moving this discussion to the bug #116143.
BTW, the normal 'kbd' init script leaves out '-c' for dumpkeys, too. I always wondered how this works for czech.
fixed in svn, submited as yast2-country-2.12.15 setting as LATER to find better solution after 10.0
reply to comment #7: > From the comment it is not clear to me if something actually failed. Di you > really have wrong keyboard in the time of passphrase requirement? Yes, I really tested this. > Anyway - if you misspel the password because you have US keyaboard, you are > able to repeat it, am I right? No, there isn't even an error message -> bug 116082 And: yes: this happens on update - I tested this case. Maybe it also happens if you do a fresh installation and let it mount an existing encrypted partition - I didn't test this case.
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(