<br><br><div><span class="gmail_quote">On 6/19/07, <b class="gmail_sendername">Peter Jones</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Tony Nelson wrote:<br>> At 4:50 PM -0500 6/18/07, Bruno Wolff III wrote:<br>>> On Mon, Jun 18, 2007 at 16:51:55 -0400,<br>>> Jeremy Katz <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:
<br>>>> On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote:<br>> ...<br>>>>> Heck, for key maps there probably aren't so many that you can't try<br>>>>> multiple possibilities after getting the password.
<br>>>> There are at least 30-40 that we allow in the installer alone at the<br>>>> console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140.<br>>>> I don't think that trying either is really that practical.
<br>>> 40 probably isn't too many to make trying them all impractical. I expect<br>>> that it will take less than a second to try each one even with measures<br>>> to slow down password guessing. That's not nice for suspend resume, but
<br>>> wouldn't be a deal breaker for initial boots.<br>> ...<br>><br>> Couldn't it just start with the one that worked last time?<br><br>Not really. We need to ask for the passphrase during thaw, in the
<br>initrd. At that time, the filesystem containing /boot is in the mounted<br>state, so we can't mount it to write the data anywhere. There's also no<br>mechanism to pass data from the running kernel to the one we're
<br>restoring into memory, which means we can't save the data during the<br>userland thaw sequence, either.</blockquote><div><br>I think we might be putting the cart before the horse. A user would be thawing from hibernation on a machine with an *existing* installation. Therefore language, and keymaps would have been chosen (during installation) prior to the hibernate operation.
<br><br>Could it be possible to store the keyboard map in the initrd. During the install we select all of these. So, adding an option to /etc/sysconfig/mkinitrd for KEYMAP and/or LANGUAGE and saving/loading it in the initrd (by regeneration) after installation should be pretty straightforward. We could switch to the encryption options after keyboard/language has been selected/loaded.
<br><br>Is this even plausible?<br></div></div><br clear="all"><br>-- <br>The early bird may get the worm, but the it's the second mouse that gets the cheese.