Bug 689567

Summary: Dracut 008 writes USB kernel output to console during Luks password query
Product: [Fedora] Fedora Reporter: Sebastian Pipping <sebastian>
Component: dracutAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: aidecoe, harald, jonathan
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-29 09:50:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Sebastian Pipping 2011-03-21 19:30:23 UTC
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

Comment 1 Harald Hoyer 2011-03-23 12:27:27 UTC
(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.

Comment 2 Sebastian Pipping 2011-03-23 15:08:37 UTC
> 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.

Comment 3 Sebastian Pipping 2011-03-23 15:09:48 UTC
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.

Comment 4 Sebastian Pipping 2011-03-25 00:17:43 UTC
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?

Comment 5 Amadeusz Żołnowski 2011-03-29 09:25:43 UTC
OK, I'll try that.

Comment 6 Amadeusz Żołnowski 2011-03-29 09:42:57 UTC
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.