FS#10465 - [cryptsetup] LUKs password field on boot interrupted by USB mouse text

Attached to Project: Arch Linux
Opened by kilo lima (kilolima) - Wednesday, 21 May 2008, 21:05 GMT
Last edited by Thomas Bächler (brain0) - Thursday, 19 May 2011, 07:35 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 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

When booting a system with an encrypted / partition and a USB mouse plugged in, the LUKs enter passphrase dialog prints, but immed. after about 5 or 6 lines of text pertaining to the USB mouse initialization are printed. The result is that the cursor is at the bottom of the screen on a blank line.

The problem is that in the mass of text arch prints during boot it's easy to miss the luks prompt, and might give the user the impression that the boot process has hung.


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Thomas Bächler (brain0)
Thursday, 19 May 2011, 07:35 GMT
Reason for closing:  Fixed
Comment by Aaron Griffin (phrakture) - Wednesday, 21 May 2008, 23:23 GMT
Hmm, I'm not really sure if there's much we can do about this besides add some delay before outputting the prompt. The kernel output is hardware specific, so this may not happen on all machines, or all the time
Comment by Thomas Bächler (brain0) - Thursday, 22 May 2008, 00:49 GMT
We could suppress printing these messages at all using dmesg (as we do in initscripts). But that's all.
Comment by Aaron Griffin (phrakture) - Thursday, 22 May 2008, 01:04 GMT
That's true. But we need dmesg (or equivalent) in early userspace. Or at least, however it supresses those messages.
I guess booting with 'quiet' is always an option. The kernel handles that
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 28 February 2010, 23:54 GMT
status of this issue? Now with current mkinitcpio can do some hacks. This task is 1.75 years old.
Comment by Heiko Baums (cyberpatrol) - Monday, 01 March 2010, 02:11 GMT
It's off topic, but it's interesting that this task is related to itself. ;-)
Comment by Thomas Bächler (brain0) - Monday, 01 March 2010, 08:57 GMT
In fact we can now do something about it. There is a related task, but I can't find it now. The busybox dmesg supports the -n option which would suppress these messages.
Comment by Glenn Matthys (RedShift) - Monday, 15 November 2010, 11:03 GMT
What's the status of this issue?
Comment by Dieter Plaetinck (Dieter_be) - Thursday, 19 May 2011, 07:18 GMT
why would it be better to totally supress these messages? that way you don't even know if your usb devices/keyboard was recognized successfully or not.
(on my hardware, on some boots it happens that my keyboard is just not recognized. not much of an issue, i just reboot when that happens)

the "might give the user the impression that the boot process has hung." argument is invalid imho: the person who knows which password to type during boot obviously knows that a password must be typed during boot of the particular machine.
Comment by Thomas Bächler (brain0) - Thursday, 19 May 2011, 07:35 GMT
This bug was solved months ago, but I didn't close it as it is not marked as a bug in mkinitcpio.

The 'dmesg' hook in mkinitcpio, inserted before the 'encrypt' hook, sets the console log level to 3, supressing any usb-related messages.

Loading...