Hide Forgot
Description of problem: While the password is queried kernel output is still written to the console. This is very confusing. In my case it happens to be USB related information about my mouse being found. Version-Release number of selected component (if applicable): 007, 008 How reproducible: Happens every time
(In reply to comment #0) > Description of problem: > While the password is queried kernel output is still written > to the console. This is very confusing. In my case it happens > to be USB related information about my mouse being found. > > Version-Release number of selected component (if applicable): > 007, 008 > > How reproducible: > Happens every time Well, specify "quiet" or set the kernel "loglevel=" on the kernel command line.
> Well, specify "quiet" or set the kernel "loglevel=" on the kernel command line. With quit it seems I get error output only. If there is no better if solving this with a single console, I guess we can close this bug.
Once again with less errors to be clear: With qui[e]t it seems I get error output only. If there is no better [way o]f solving this with a single console, I guess we can close this bug.
Re-thinking this: Could you drop the log-level to strong-errors-only during password query (and maybe notify the user that you did) and restore it's original value after? It seems this # echo 0 > /proc/sys/kernel/printk is what genkernel has been been doing, despite that file's four-value nature: # cat /proc/sys/kernel/printk 0 5 1 7 Quoting proc(5): The four values in this file are - console_loglevel, - default_message_loglevel, - minimum_console_level, and - default_console_loglevel. In case you dislike such an approach as the default behaviour would you object introducing a boot parameter for it?
OK, I'll try that.
Hm, or not, sorry. We discussed this. Disabling messages for password prompt will eat most of them, so why not disabling them at all? As Harald mentioned, the solution is "quiet" or "loglevel=". Yet another is Plymouth which nicely prompts for password.