Subject: bug#25453: Inconsistent keyboard layout affecting encrypted root

From: ng0 <[email-masked]>
Date: Wed, 17 Jan 2018 08:29:20 +0000

Ludovic Courtès transcribed 1.1K bytes:
> Hi!
> 
> Christopher Baines <[email-masked]> skribis:
> 
> > I'm using a UK keyboard layout with a computer that I recently installed
> > GuixSD on with a encrypted root parition. Immediately after installation
> > when I attempted to boot in to the new system for the first time I had
> > to enter the passphrase twice, and in doing this, first I had to use the
> > keyboard layout under which I carried out the installation (the layout
> > which I had intended to use), and then during the early boot stage of
> > the system I had to enter the passphrase using a different keyboard
> > layout.
> 
> Currently installing a keymap is something done by the ‘console-keymap’
> Shepherd service, which invokes ‘loadkeys’.  That happens after
> “cryptsetup --open” has opened your encrypted root device, hence the
> problem.
> 
> Should we install the keymap right in the initrd, before we’ve mounted
> the root partition?  That would require copying the right keymap(s) and
> probably ‘loadkeys’ to the initrd, which might make it quite big.
> 
> Suggestions?  How do others handle it?

Yes, this has been annoying me to the point of simply taking it for
granted for now, and replacing it in my own set of defaults.

To answer your question: Others handle it in the initrd aswell.

For example in Gentoo with OpenRC, you set the keyboardlayout for
the initrd. In Archlinux iirc before and after adoption of systemd
you set the keymap for it. In Debian if memory serves me right you
set the keyboard layout. I think I don't need to go on...

What's the size difference for the initrd then in numbers?
I don't think we have to wory about size as we'll never run
on devices smaller than router devices (at least that's my
current assumption looking at the size of a typical minimal
GuixSD, it's possible but requires lots of customization).

> Thanks for your report,
> Ludo’.

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/