FS#16806 - [mkinitcpio] issue with encrypt password (visibility)

Attached to Project: Arch Linux
Opened by Karol Babioch (johnpatcher) - Friday, 23 October 2009, 16:55 GMT
Last edited by Thomas Bächler (brain0) - Saturday, 08 May 2010, 18:36 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
First of all i'm not quite sure whether this is a bug or not, but at least it seems to be really annoying and I don't know how to solve it.

I've set up an encryption for my whole system, so I have to enter a password during the boot process. Therefore I need some hooks to be added in "/etc/mkinicpio.conf". I've added usbinput as well as encrypt, and recreated the image. The problem is that the usbinput hook is much too slow, it takes a few seconds before all usb devices get recognized, but the encrypt hook is executed beforehand, so while I can see the message "Enter LUKS password" I also see a lot of messages regarding some usb devices, which makes the display quite confusing and makes it impossible to type in the luks password, as it is visible whenever I try to type it in before.

Additional info:
* You'll find my mkinitcpio.conf in the attachment.

Steps to reproduce:
* Add usbinput as well as encrypt to your hooks array
* Recreate your image
* Reboot
   mkinitcpio.conf (2.7 KiB)
This task depends upon

Closed by  Thomas Bächler (brain0)
Saturday, 08 May 2010, 18:36 GMT
Reason for closing:  Fixed
Additional comments about closing:  The next mkinitcpio version includes the sleep and dmesg hooks that can be used to work around the problem.
Comment by Thomas Bächler (brain0) - Friday, 23 October 2009, 20:32 GMT
This is known and probably can't be worked around. The keyboard is detected by the kernel after the "Enter LUKS passphrase:" prompt, so you don't exactly see the prompt - you should still be able to type the password and the characters shouldn't be echoed. We have no way of "waiting" for a keyboard other than sleeping an arbitrary number of seconds.

We could however set the console log level to a lower value, so that the messages about usb/keyboard won't be printed to the console - but that will make debugging much more difficult (we do that when initscript are launched, right at the beginning). What would you like to happen here?
Comment by Karol Babioch (johnpatcher) - Saturday, 24 October 2009, 09:28 GMT
Maybe you could provide a varialbe in mkinitcpio.conf for the loglevel, so the user can decide which loglevel to choose. Furthermore I'm wondering how I can add such a delay, as the kernel parameter rootdelay doesn't change anything at all. First it asks me for my password, then it prints out some information about my usb devices.
I can't type in my password before all of my usb devices are detected, as everything I type in is visible, and therefore it makes not much sense to type in an encryption passphrase, which everyone around me could read right then.

So, a delay before the encryption hook is loaded would be fine for me, is this possible? If so, how? Do I need to write my own hook?
Comment by Thomas Bächler (brain0) - Saturday, 24 October 2009, 11:31 GMT
I'm confused - how can what you type be visible? As soon as cryptsetup asks for a passphrase, it disables echoing of characters, regardless of any (not) detected keyboard. Can you clarify this please?

The rootdelay parameter has changed recently: If you set rootdelay=10 (the default) it will wait _at most_ 10 seconds, but will stop waiting as soon as the device you are waiting for is created. So on any normal SATA or IDE system, it will actually not wait at all - only on systems with USB (or with incorrect settings) it will wait longer.

About adding a delay: A custom hook would be the way to go.
Comment by Karol Babioch (johnpatcher) - Sunday, 25 October 2009, 23:22 GMT
Ok, just forgot about the problem with the visibility, it now is working as described, which doesn't mean that it good at all. I still can see all of these messages, but the echoing of the input is disabled.

So now I just need to change the loglevel. Could you tell me where to change it, or at least where to read something about it ;)?
Comment by Thomas Bächler (brain0) - Sunday, 25 October 2009, 23:34 GMT
In the normal system, you'd use "dmesg -n 3" or so, but klibc/initramfs has no -n option in dmesg. I have no idea right now how to change it manually.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 12 February 2010, 18:43 GMT
what is the status of this issue with latest mkinitcpio-0.6?
Comment by Thomas Bächler (brain0) - Friday, 19 February 2010, 17:30 GMT
I guess we can now decrease the log level with dmesg -n 3 or so during initramfs (busybox's dmesg has the option). I am still unsure if that is a good idea - it is helpful to see the kernel messages during early boot.
Comment by Karol Babioch (johnpatcher) - Thursday, 15 April 2010, 12:43 GMT
What would be the easiest way to do that? I would like to compare both possibilites :).

Maybe it would also be an option to add a little delay before asking for the passphrase ...

Because it seems that the problem is that it asks to early for the passphrase, then some usb devices get recognized and the line asking for the passphrase gets displaced. So when the passphrase hook would get executed a few seconds later, it could actually solve the problem. On the other hand it is hard to say how long it should be delayed.

Would it be possible to add such a delay for me personally? I would like to try that also. What do you think about that?
Comment by Thomas Bächler (brain0) - Thursday, 15 April 2010, 13:59 GMT
Create the following files:

/lib/initcpio/install/dmesg:
install ()
{
MODULES=""
BINARIES=""
FILES=""
SCRIPT="dmesg"
}

help ()
{
:
}

/lib/initcpio/hooks/dmesg:
run_hook ()
{
dmesg -n 3
}

Add "dmesg" as a hook before "encrypt", but preferably after "udev", run mkinitcpio -p kernel26. This should do it. If it works, we can add it to mkinitcpio.


Alternatively, sleeping before adding the passphrase is possible with the "sleep" hook which has been added in mkinitcpio.git, but not yet in a release: http://projects.archlinux.org/mkinitcpio.git/commit/?id=d5625e4bd28a9b3066777c539b05aef3fc551b8f
Comment by Karol Babioch (johnpatcher) - Thursday, 15 April 2010, 14:29 GMT
Thanks for this fast and competent reply!

I have tried both ways, and chosen to go with the second one (sleep hook), because I don't like the idea to possibly miss kernel messages, although the dmesg hook works just great as well and is probably the better way to go, as the needed sleeptime is different on each system :(.

Loading...