console messages and log level

Colin Ian King colin.king at
Thu Oct 8 17:26:50 UTC 2009

On Thu, 2009-10-08 at 17:44 +0100, 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?  

Nope. It's madness. Too many patches, and a maintenance nightmare.

> 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.

I agree. Crank it down. It's tweakable at boot and run time too, so we
can put it back up to the normal level to debug if need be.
> 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.

..and I'm happy to try it out.

> -apw

More information about the kernel-team mailing list