cool feature of dmesg.boot file

[Jeremy Chadwick]

On Fri, Feb 22, 2008 at 09:28:35AM +0100, Oliver Fromme wrote:
> Bartosz Giza wrote:
>  > I have found quite interesting feature on one of router that lately i have 
>  > taken to administer.
>  > What i knew was that file /var/run/dmesg.boot holds data from kernel buffer 
>  > that is taken right after file system(s) are mounted.
>  > Lately i have found that one router writes to this file data from kernel 
>  > buffer when system is going to reeboot. Below are few lines from this file.
>  > What you can see are lines from kernel right before reeboot. I have never seen 
>  > before such lines in this file. And this is quite interesting. Could anyone 
>  > tell me how can i achieve such funcionality on other systems ? I have tried 
>  > to find on google about this but i couldn't find anything similar to this.
> 
> Upon a reboot, the kernel is usually loaded to the same
> physical addresses in RAM where it was before, so the
> dmesg buffer will be at the same location, too (unless
> you built a new kernel, of course).  So all the contents
> from before reboot are still there -- *IF* the system
> BIOS didn't clear the RAM.  Then the old contents will
> end up in /var/run/dmesg.boot, too.
> 
> You could try looking at your BIOS setup.  Some have an
> option called "Quick POST" or similar.  If you enable
> it, the BIOS will skip the RAM test (which is rather
> useless anyway) which clears the RAM.  It might help,
> but it depends very much on your mainboard and BIOS.

There is also kern.msgbuf_clear.  However, this is a sysctl, which
means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output
after the OS had started.  Bummer.

It would be useful if there was a loader.conf variable which was the
equivalent of msgbuf_clear.  In fact, I'm wondering why the message
buffer isn't cleared on shutdown/immediately prior to reboot...

Interesting tidbit: We have one production machine which when booted
into single-user via serial console for a world install, retains all of
the output from that single-user session even once rebooted and brought
back into multi-user mode.  This poses a substantial security risk,
especially during the mergemaster phase (we can discuss why if anyone is
curious).

-- 
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |