according to pterjan, the issue seems to be in dracut, colin, any ideas ?

CC: sysadmin-bugs => (none)
Component: Release (media or process) => RPM Packages
Source RPM: (none) => dracut

Confiorming this, I have a decryption password containing "z"s and I needed some time to realize, I had to press "y" instead (quertz/querty).

I did notice the decryption password is asked very early in the boot process since a few days, perhaps it should only be asked after the keyboard setup is loaded, can we force systemd to keep the order of those two things?

CC: (none) => oliver.bgr

Colin maybe you have an idea ? (seems I miss to add you :/)

CC: (none) => mageia

I just did a test install. I used a British as the language but picked a french keyboard layout.

I checked that I got the text azerty on the top row and used that for my password. After install, I was prompted for the password, I used the top row, and it worked.

So I think this is working OK?

So if people still have this problem can they check the vconsole file inside their initrd? Ideally just regenerate your initrd if you've not down so for a while. Like I said i cannot reproduce in my tests, so I'll close, but if there is a problem still, please reopen with more info on how to reproduce in a test VM.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME

*** Bug 5266 has been marked as a duplicate of this bug. ***

CC: (none) => boklm

# qemu-img create -f qcow2 mga2b3.qcow2 4G
# qemu-kvm -m 1024 -serial stdio -hda mga2b3.qcow2 -cdrom Mageia-2-beta3-x86_64-DVD.iso --boot d

- select default (English) Language
- accept License Agreement
- select More -> German (no dead keys)
- select Custom disk partitioning
  + create 'boot' (Linux native)
  + create 'swap' (Linux Swap)
  + create '/' check 'Encrypt partition'
    pass phrase 'tyty'
- continue installation, select:
  + Configuration
  + Documentation
  remove rest (faster install)
- finish without update, reboot

try to unlock the root volume with the passphrase 'tyty'
now try to unlock with 'tztz' instead ...

Priority: Normal => release_blocker
Status: RESOLVED => REOPENED
CC: (none) => herbert
Resolution: WORKSFORME => (none)
Target Milestone: --- => Mageia 2

OK, so please boot this, extract the initramfs (mkdir initrd; cd initrd; zcat /boot/initrd.img | cpio -id) and then attach the etc/vconsole.conf file.

Thanks.

I tried following these exact steps (which are very similar to my own testing in VirtualBox above) but it all worked fine for me. Password was accepted and all was well. (I confirmed that pressing the ty keys produced tz as the output when entering the password).

In the generated initrd I see the /etc/vconsole.conf file contains:
KEYMAP="de-latin1-nodeadkeys.uni"
UNICODE="1"
FONT="lat0-16"

So I still don't see a problem here :s Are you using an up to date installer and stage2 image? If you are using urpmi-proxy you might need to delete the stage2 image manually before installing.

Ping reporter, we need feedbacks as soon as possible

CC: (none) => ennael1

Was resolved here some days ago with a systemd update. I thought it was done by Colin on purpose.

I have to test it again, but i think it was broken for me too. Typo in passphrase was a bad idea as backspace didn't delete the last dot but added on more. So the only way was to hit enter and start from beginning.

CC: (none) => sander.lepik

@Oliver I really don't think it's anything to do with systemd. This is something happening very early on in dracut, before systemd even comes into the picture.

However, I have thought of one problem, but it's not as described here.

If another filesystem, not needed for boot (e.g. /home) is encrypted then it's not in the dracut environment that this decryption occurs, but in the running system. As I'm not sure we've fully converted to vconsole.conf yet, this *could* potentially ask for the passphrase in the wrong locale. I'll test this scenario when I can.

Well, all I can say, it's working again. Perhaps new systemd and new dracut came in the same update, I'm not sure about that.
In my case, I have a partition /mnt/data that is encrypted by the way.
Since it's working correctly again here, I'm not sure, I can be of any help.

@Oliver. Yeah if you have /mnt/data encrypted then it could very well be a systemd related issue. Do you have a /etc/vconsole.conf file on your system? If not, then I'm not convinced any previous fix to make it work for you is a real fix, more just correctly aligned planets :p

Nope, no /etc/vconsole.conf file here.

OK, so I tried a non-initrd mounted encrypted partition both with and without the vconsole.conf and it also worked fine for me too. It could still be a timing thing but as myself and Oliver cannot reproduce this and I have tried several times to reproduce the error actually reported (which is about dracut asking for the password, not systemd during later boot) and cannot, I'd suggest we should close this ticket as WFM/Fixed if Herbert agrees. Might be best to wait for tests after the RC however.

agreed! will do some more testing after the final RC is there and if I cannot recreate the issue, I'll close it as resolved.

@Herbert The final RC is out. If you can retest that would be great.

Without any answer within 2 days we will decrease priority of this bug

problem still exists with:

md5sum Mageia-2-rc-x86_64-DVD.iso
480253baa22607c3fe5133f0436e36f6  Mageia-2-rc-x86_64-DVD.iso

I tried the exact steps from comment 7 with "tyty" (tztz) and ";';'" (umlaut o/a) and it failed.
it might be related to the package selection though, will do some more tests.

even reproduceable with full gnome install, with ";';'" encryption passphrase.

# md5sum Mageia-2-rc-x86_64-DVD.iso
480253baa22607c3fe5133f0436e36f6  Mageia-2-rc-x86_64-DVD.iso

# qemu-img create -f qcow2 mga2rc.qcow2 8G
# qemu-kvm -m 1024 -serial stdio -hda mga2rc.qcow2 -cdrom Mageia-2-rc-x86_64-DVD.iso

boot (ext2), swap and encrypted root (ext4) for the rest.

from the initramfs:

# cat etc/vconsole.conf 
KEYMAP="de-latin1-nodeadkeys.uni"
UNICODE="1"
FONT="lat0-16"

could it be that the de-latin1-nodeadkeys.uni file just isn't there (or accessible?)

ping

CC: (none) => alien

I don't understand why I cannot reproduce this problem. I've followed the exact steps posted previously without problem, so there must be something more convoluted.

I guess the de-lating1-nodeadkeys.uni file is present in the initrd?

Actually could you post the initrd somewhere (too big to attach here) so I can poke at it? Maybe a link to dropbox or some other space?

here you go:
http://vserver.13thfloor.at/Stuff/MAGEIA/BUGS/initrd-3.3.4-desktop-1.mga2.img 

if you still cannot reproduce the issue, just let me know and I make a vnc capture.

ping... release_critical

Hmm, OK, so this could be in some way to be tied to plymouth support.

It would seem that loadkeys is only run via lib/udev/console_init. This is all present in the initrd.

It would seem that running:
lib/udev/console_init /dev/tty0

Should properly initialise the keys.


This happens in two potential ways:
 1. etc/udev/rules.d/10-console.rules
 2. lib/dracut/hooks/pre-trigger/10plymouth-pretrigger.sh

Now the latter might not happen if plymouth support is disabled on the kernel command line.

etc/udev/rules.d/10-console.rules:KERNEL=="tty0",		RUN+="/lib/udev/console_init $root/$name"

I wonder if the $root/$name bit is just wrong... I wonder if it should be %k... I'll try and do some tests.

OK, so I'm using your initrd. I'm not 100% sure why it's failing (well I know why it's failing to mount the crypto uuid obviously, but that's not what I mean).

If I do a rd.break=pre-udev then the keymap is english (tyty), but if do rd.break=initqueue then it's properly set to german (tztz).


So, can you do some tests for me:
 1. Boot with rd.break=pre-udev
 2. Run: /lib/udev/console_init /dev/tty0
 3. Type exit (and do so whenever dracut drops to a shell.

Can you now enter the password as needed?

Also I've created a modified initrd that should do the necessary automatically http://colin.guthr.ie/herbert-initrd-5192-2.img

Can you check to see if that one fixes your problem?

The only modification to the initrd you supplied is what the following patch to dracut should do:

commit 2f2709edd35399f938eb9c3ff9177221858de2a4 (HEAD, mga-017)
Author: Colin Guthrie <colin@mageia.org>
Date:   Sat May 19 12:31:08 2012 +0100

    i18n: Run console_init prior to udev startup.
    
    In some cases udev will initialised the encrypted disks and
    ask for a password before it initialises the console.
    
    This can result in the password for encrypted partitions
    being asked for with the wrong keymap loaded.

diff --git a/modules.d/10i18n/i18n-pre-udev.sh b/modules.d/10i18n/i18n-pre-udev.sh
new file mode 100755
index 0000000..2033948
--- /dev/null
+++ b/modules.d/10i18n/i18n-pre-udev.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
+# ex: ts=8 sw=4 sts=4 et filetype=sh
+
+if [ -x /lib/udev/console_init -a -e /dev/tty0 ]; then
+    /lib/udev/console_init /dev/tty0
+fi
diff --git a/modules.d/10i18n/module-setup.sh b/modules.d/10i18n/module-setup.sh
index a5a3388..fa12ab7 100755
--- a/modules.d/10i18n/module-setup.sh
+++ b/modules.d/10i18n/module-setup.sh
@@ -87,6 +87,7 @@ install() {
         inst ${moddir}/console_init.sh /lib/udev/console_init
         inst_rules ${moddir}/10-console.rules
         inst_hook cmdline 20 "${moddir}/parse-i18n.sh"
+        inst_hook pre-udev 10 "$moddir/i18n-pre-udev.sh"
     }
 
     install_all_kbd() {

FYI, this fix is now included in dracut. Hopefully it fixes your problem, but a test would be very much appreciated ASAP :)

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

I had the same problem when upgrading Mageia 1 -> Mageia 2. I Upgraded on 2012-05-29, dracut is dracut-017-16.mga2, build at 20 Mai 2012 14:19:23. So this should be the version as reported comment #30.

CC: (none) => h.goebel

Damn :(

The fix we put in set the console language really early before any pass phrases should be asked for...

Can I ask how did you upgrade? Via urpmi or via the installer? If the former, can you do "ls -l /boot" and check how larger your initrd is? If it's very large (i.e. > 10megs) you should try regenerating it after booting up (move the large initrd to a short, but convenient name (e.g. "/boot/initrd-mga2.img") for backup purposes and then regenerate a nice new initrd with "dracut -f"). This newly generate file should be relatively small (5-8megs). The next boots will then hopefully work as expected with the correct keymap. (if, for whatever reason, the boot fails, you can edit the grub prompt on boot and use the backup initrd).

If the above does not work, can I ask if this reproducable on every boot? If so, can you do a quick (and easy test)? At the grub command prompt, just remove the resume= option and try booting? Does the keymap work correctly now?

Hopefully answering all your questions :-)

- I Upgraded using `urpmi --replacefiles --auto-update --auto` as recommended.
- As described in the release notes, the initrd generated while upgrading is qute large (17MB).
- Using this initrd, the keymap is wrong.
- This is reproducible.
- This initrd generated by `dracut -f` works without any problem, esp. the keymap is set correctly.

Anything I can help analysing?

Addendum to my comment #34:

Looking into the largeinitrd generated while upgrading I found:
- etc/vconsole.conf is missing
- etc/sysconfig/console/default.kmap is missing

Nope, that's perfect, thanks very much for the tests.

I guess this is just a generic issue with a non-hostonly initrd - it's kinda designed to be quite generic (to the extent that it will not try and set your keymap).

I suppose the solution here is to make non-hostonly initrds ask the user for their preferred keymap if they are going to need to ask for input - and to make sure it includes all keymaps too! (not sure if it does already).

As this should only affect urpmi upgrades (well maybe live too?) it's likely something we can actually fix later, but I'm not sure it's necessarily worth it overall - i.e. it'll take a fair bit of development, QA and for quite a corner case that can (most of the time at least) be fixed in a few steps... in extreme cases it might be quite tricky to get the password right on that first boot if special accented chars are used, but if the initrd does contain the keymaps even this could be made to work with a strategic rd.break=pre-udev on the command line and a call to loadkeys...

I'll liaise with upstream about the general problem and see what the official approach should be.

(In reply to comment #35)
> Addendum to my comment #34:
> 
> Looking into the largeinitrd generated while upgrading I found:
> - etc/vconsole.conf is missing
> - etc/sysconfig/console/default.kmap is missing

Yeah, this is kinda expected... in theory the non-hostonly initrd is meant to be generic and thus doesn't include anything specificially related to the system (I wonder if vconsole.conf should be the exception here tho'...)

Can you check and see if it contains keymaps (I don't have one handy right now)? (i.e. a usr/lib/kbd/keymaps folder with lots of subfolders for different layouts)

usr/lib/kbd/keymaps exists

(In reply to comment #36)

> I guess this is just a generic issue with a non-hostonly initrd - it's kinda
> designed to be quite generic (to the extent that it will not try and set your
> keymap).

But it should be able to fetch the keymap setting from the running system.

Otherwise some guys may have no chance to enter their LUKS password using the english keymap just because the characters are not available there.

Anyway: Who is in charge of adding an entry to the errata web-page?

(In reply to comment #38)
> usr/lib/kbd/keymaps exists

does it contain lots of subfolders too (like azerty, qwerty etc.)?

(In reply to comment #39)
> (In reply to comment #36)
> 
> > I guess this is just a generic issue with a non-hostonly initrd - it's kinda
> > designed to be quite generic (to the extent that it will not try and set your
> > keymap).
> 
> But it should be able to fetch the keymap setting from the running system.

Well it can only do that at install/generation time and this is exactly what a hostonly initrd does. We are forced to use a non-hostonly initrd on urpmi upgrades to work around a problem that dracut needs an accurate udev database to query and the pre-mga2 boot (using mkinitrd) could not guarentee that for all configurations as e.g. it started lvm and such before udev and thus 
important metadata was missing from udev).

So the non-hostonly initrd gives enough to boot at which point you can regenerate the initrd. In theory this works nicely in most cases, but when user input is needed (such as the case for LUKS stuff) it trips up and fails.

So we could inject the vconsole.conf into the initrd but this wouldn't be a true non-hostonly initrd as it would contain some details about the running systems which is kinda wrong - being pragmatic however I do agree it would solve this particular problem and thus might be a viable solution even if it means the initrd is not as generic as it should be in such circumstances.

> Otherwise some guys may have no chance to enter their LUKS password using the
> english keymap just because the characters are not available there.

If the keymaps folder above is fully populated (i.e. contains all keymaps) it should be possible to boot with a rd.break=pre-udev (or some other suitible breakpoint) and run "loadkeys /usr/lib/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.uni.map.gz" then type "exit" (maybe a few times) in order to complete their first boot and generate the more friendly hostonly initrd.

> Anyway: Who is in charge of adding an entry to the errata web-page?

Anyone can, but I can add this one. If you can confirm the existence of all the keymap files that would be great as this will affect the instructions.

Again, thanks for the investigations and I'm sure we can work something out :)

(In reply to comment #40)
> (In reply to comment #38)
> > usr/lib/kbd/keymaps exists
> 
> does it contain lots of subfolders too (like azerty, qwerty etc.)?

> If you can confirm the existence of all the
> keymap files that would be great as this will affect the instructions.

Actually forget this. I was being lazy. I've looked at the code and it does include them all.

Also it seems you can pass: "vconsole.keymap=de-latin1-nodeadkeys.uni" on the kernel command line to get the right keymap in this mode.

If you feel like playing maybe you could test this out with your old initrd just do double check it all works OK?

(In reply to comment #41)

> Also it seems you can pass: "vconsole.keymap=de-latin1-nodeadkeys.uni" on the
> kernel command line to get the right keymap in this mode.

Adding this works.

For the errata-page: The keymap is named in /etc/sysconfig/keyboard, variable KEYTABLE.

OK, I've added a note on the Errata:

https://wiki.mageia.org/en/Mageia_2_Errata#Base_system

There is no perfect resolution for this bug in this circumstance, so let's go with "Fixed" :)

Thanks again for your help!

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED