console messages and log level

Andy Whitcroft wrote:
> We are now moving into new territory where the kernel is naked in front
> of the user for some seconds before xsplash covers its blushes.  The
> kernel has traditionally been very chatty and although it has a 'quiet'
> mode which we use for normal boots it is still keen to tell us about a
> lot of events and errors.
> 
> During the lifetime of the kernel it is only this very early phase where
> any messages are visible at all.  Once X has started the console is gone,
> even 'emergency' messages are only visible via dmesg.  Until recently
> usplash was also hiding our messages, again hiding every message level.
> Generally in the life the kernel, its idea of importance is ignored, and as
> a result not all of its levels are accurate; leading to the issue at hand.
> 
> Now we can attempt to fix these messages so they come out at lower levels
> (KERN_WARN or lower), indeed we are already seeing requests to quieten
> some of these messages.  Typically we do this by dropping the severity of
> those messages via a patch, a patch which typically upstream is unlikely
> to want and which we will have to carry for the long haul.
> 
> Does it really make sense for us to carry a large number of silencer
> patches?  I am not convinced.  As we are happy for X to hide all messages
> and indeed we added usplash to hide them before X started, perhaps the
> sensible thing to do is simply suppress them completely on a regular boot.
> The kernel already has a log_level indicating which messages are important
> enough to display on the real console and we use this to control verbosity
> on boot.
> 
> When we look at a normal boot we boot with 'quiet' on the command line.
> This lowers the kernels noise level and is also passed to userspace which
> again reacts quieting it init.d script logging levels and the like.  If
> things fail we normally boot without 'quiet' and we get the full glory
> of the kernel output and userspace output too.
> 
> To cut to the chase, rather than patching lots of kernel messages to lower
> their level might it make just as much sense to lower the level at which
> console messages are emitted in the face of the 'queiet' command.  To allow
> the kernel to shield itself more heavily.  We could probabally lower the
> console level from the default 4 to 1 allowing only emergency messages
> to be seen without losing anything in the debug case.  Messages are still
> logged to the dmesg and thus the logs, and if booting is broken removing
> 'quiet' will give us all messages, and indeed log_level=4 will give us
> the current behaviour.
> 
> In short.  We try very hard in normal running to hide the kernel and are
> happy to hide it completly, why is early boot any different.
> 
> If you think this makes sens I can spin a patch for testing.
> 
> -apw
> 

thusly?

> From 1aba8a4352402396a42140b2b177abce44d920b7 Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Thu, 8 Oct 2009 11:42:36 -0600
> Subject: [PATCH] UBUNTU: SAUCE: Raise the default console 'quiet' level to 2
> 
> In the interests of providing a clean boot experience, i.e., a blank screen
> before X starts, supress noisy driver messages.
> 
> See https://lists.ubuntu.com/archives/kernel-team/2009-October/007476.html
> for the original diatribe.
> 
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
>  init/main.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/init/main.c b/init/main.c
> index 11f4f14..a97d0b7 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -233,7 +233,7 @@ static int __init debug_kernel(char *str)
>  
>  static int __init quiet_kernel(char *str)
>  {
> -	console_loglevel = 4;
> +	console_loglevel = 2;
>  	return 0;
>  }

That is indeed the idea.

Acked-by: Andy Whitcroft <apw@canonical.com>

-apw