console messages and log level
Jim Lieb
jim.lieb at canonical.com
Thu Oct 8 17:13:27 UTC 2009
On Thursday 08 October 2009 09:44:40 am Andy Whitcroft wrote:
> 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.
>
Agreed. Hacking the individual printk levels will be a long lasting pain.
I had a similar issue a while back on an appliance product. Simply
silencing the console however is one quick way to create a silicon brick.
What I did was silence the console as you suggest, actually completely
but add code to the initramfs init that detected errors and then dd'd
dmesg to the console. The end result was normal boot was silent but
if there was an error early on, before the LCD display manager or anything
else could preserve logs and report, the initramfs env would dump the log
to the console. The only failure window was early boot prior to lighting off
initramfs which was a catastrophic error. The result saves a lot of RMAs
and agitated users who don't mind busted systems, just silently busted systems.
We could also have a small window between the chroot+upstart and X starting.
--
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.
More information about the kernel-team
mailing list