Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"Ahmed S. Darwish" <darwish.07-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Wed, Jan 26, 2011 at 08:44:14PM -0800, H. Peter Anvin wrote:
>> On 01/26/2011 06:13 PM, Vivek Goyal wrote:
>>>>
>>>> - Use kexec/kdump. I wonder though, can kexec work on early panics? The
>>>>    kind where the disk itself might not yet be initialized?
>>>
>>> As of today kexec/kdump does not work with early panics as kdump kernel
>>> needs to be loaded in reserved memory and that action happens once the
>>> first kernel has booted.
>>>
>>> There is so much to it that I really don't think that modifying bootloaders to
>>> do all that might not trivial and more importantly I think it probably is not
>>> worth the effort.
>>>
>>
>> It's really not all that hard, actually.
>>
>
> Nice, I'll try prototyping this using syslinux and kexec: this seems the
> safest path so far. Further details are in my first reply to Vivek.

Given the inertia of boot loaders it might make sense to compile in the
crash recovery code.

Regardless the way I would organize this is simply to have a chunk of
memory that you place the crash reporting kernel and initrd in, and
simply tell the linux about it, at boot time.  Then kexec on panic can
be pointed at it and that is the end of the matter.  That is very simple.

It might be a bit tricky to get all of the context information the crash
kernel needs, but it should not be too bad.  I am with Vivek in being a
bit dubious if this will do better in practice than having a crash
kernel that we load from the initramfs, simply because the maintenance
difficulty of a specialized component.  But I see no reason to not add
the basic mechanism, to the kernel and bootloaders.  The basic mechanism
is simple and easy to maintain, and ultimately should work across platforms.

Eric