cutting down on boot messages

cutting down on boot messages

[Jurriaan]

If I boot my system, there are copious messages. 

For example:

md: Autodetecting RAID arrays.
md: autorun ...
md: considering hdc6 ...
md:  adding hdc6 ...
md: hdc5 has different UUID to hdc6
md: hdc3 has different UUID to hdc6
md: hdc1 has different UUID to hdc6
md:  adding hda6 ...
md: hda5 has different UUID to hdc6
md: hda3 has different UUID to hdc6
md: hda1 has different UUID to hdc6
md: hdi2 has different UUID to hdc6
md: hdi1 has different UUID to hdc6
md: hde2 has different UUID to hdc6
md: hde1 has different UUID to hdc6
md: created md5
md: bind<hda6>
md: bind<hdc6>
md: running: <hdc6><hda6>
md5: setting max_sectors to 128, segment boundary to 32767
raid1: raid set md5 active with 2 out of 2 mirrors

Now these messages are often uninteresting - but sometimes they are.
So just deleting them, or requiring a recompile or reboot is not good
enough.
Also, I noted that these messages were almost always grouped together.

Suppose these messages were removed from the normal output, but instead
stored in a buffer in the kernel.

Then, you could do

dmesg.raid

to get at the raid-messages,

and 

dmesg.raid --clear 

to clear the buffer.

The same goes for other groups of messages, like the whole APIC/IRQ
routing block, ide messages, usb messages etc.

Would this keep the interesting information, but cut down on the amount
of messages? I'm now at 22k of dmesg, including raid, usb, apic etc, for
a single CPU system.

I'd be interested in everyone's opinion on this!

Jurriaan
-- 
REAL LIFE MANAGEMENT 'DILBERT QUOTATIONS':
11: One day my Boss asked me to submit a status report to him concerning a
    project I was working on. I asked him if tomorrow would be soon
    enough. He said "If I wanted it tomorrow, I would have waited until
    tomorrow to ask for it!" (New business manager, Hallmark Greeting
    Cards.)
Debian (Unstable) GNU/Linux 2.6.0-test1-ac2 4112 bogomips load av: 1.00 1.00 1.00

Re: cutting down on boot messages

[Mike Fedyk]

On Fri, Jul 25, 2003 at 09:57:52PM +0200, Jurriaan wrote:
> of messages? I'm now at 22k of dmesg, including raid, usb, apic etc, for
> a single CPU system.

And you want more static buffers to store that in than now?  Many people
won't like that.

You'd do better to have a boot time command line option to limit printk
messages to err, or above.  Most of the printk messages have been given a
severity already, so this shouldn't be a problem, and it will probably
uncover some errors in the severity of certain messages.

Anyway, there are other ways to peel this union, including having the
messages to to tty2 instead of console (I've seen patches for this posted
before).

Re: cutting down on boot messages

[Krzysztof Halasa]

Mike Fedyk <mfedyk@matchmail.com> writes:

> You'd do better to have a boot time command line option to limit printk
> messages to err, or above.  Most of the printk messages have been given a
> severity already, so this shouldn't be a problem, and it will probably
> uncover some errors in the severity of certain messages.

Right.
In fact I'd rather leave the console printing KERN_INFO and make sure
the (debug) messages are really KERN_DEBUG. This way we wouldn't have
much noise with normal boot, but we could see KERN_DEBUG when something
goes wrong (and the kernel is being told to print everything).
-- 
Krzysztof Halasa
Network Administrator

Re: cutting down on boot messages

[Kurt Wall]

Quoth Jurriaan:
> If I boot my system, there are copious messages. 
> 

[...]

> Now these messages are often uninteresting - but sometimes they are.
> So just deleting them, or requiring a recompile or reboot is not good
> enough.
> Also, I noted that these messages were almost always grouped together.
> 
> Suppose these messages were removed from the normal output, but instead
> stored in a buffer in the kernel.

How about the "quiet" kernel command line parameter, which quiets
down the boot process but still stores the messages in the ring
buffer?

Kurt
-- 
Support bacteria -- it's the only culture some people have!