[olug] Kernel Building

[William E. Kempf]

Phil Brutsche said:
> William E. Kempf wrote:
>
>> I started down this path in the very early days, and genkernel (for
>> those not running Gentoo, this is a script that automates kernel
>> building for Gentoo) was in flux and not really usable for 2.6.  So,
>> I managed to get a kernel that mostly worked by doing things by hand.
>> By mostly work, I mean that all my programs/servers appear to run
>> with out issue, but there are errors at boot time (mostly, I believe,
>> issues with devfs).
>
> devfs is considered depreciated in kernel 2.6.x by the kernel
> developers.  It's not well maintained and has crashing issues on 64-bit
> architectures.
>
> The replacement is a combination of the /sys file system and the udev
> program.  The system should mount /sys by default, and udev should be in
> the Portage someplace.
>
> Incidentally, Gentoo was the only "major" distribution to enable devfs
> by default.

Thanks, I'm already aware of this, and am working on switching to Udev. 
That's part of the reason I'm posting this query.

>> I want to learn how to handle this, but there are a few things
>> standing in my way, so I'm hoping someone can help me out.  First, is
>> there any way to read all of the messages sent to the terminal during
>> a boot?
>
> You already know that one...

IOW, /var/log/messages and dmesg?  That sucks, in that case.

> A serial console with a large scrollback buffer will help.

And how would you accomplish something like that?

>> I'm aware of both /var/log/messages and dmesg, but neither of these
>> seem to be complete, and are certainly not the exact same output seen
>> during boot. This is making it difficult to diagnose issues for me.
>
> You can also increate the size of the buffer the kernel stores messages
> in.  Look for CONFIG_LOG_BUF_SHIFT, aka "Kernel log buffer size" under
> "General setup".

I don't believe my problem is one of the log size.  There's messages in
the middle that are not seen when running dmesg, though messages before
and after are.

>> Second, is there any way to test a kernel remotely?  It's not always
>> possible for me to be at the physical terminal when I'm administering
>> the box, for numerous reasons.  I do most everything remotely via
>> ssh, but testing the kernel this way is problematic.  Rebooting, if
>> the kernel doesn't boot properly, renders it impossible to recover
>> remotely.  Seems there should be a way to test this remotely, even if
>> it's in an emulated environment.
>
> Serial console.  Provided the kernel doesn't completely hard lock you
> should be able to do almost anything through the serial port that you
> can through the console.  Oh, and make sure you enable "Magic SysRq"
> support.

Any info/docs on this topic?  I don't even have a clue what you mean by
"serial console", considering how you seem to be using the term here, and
I don't understand how it would help me to do remote testing?

-- 
William E. Kempf
wekempf at cox.net