linux-kernel - Re: [Fastboot] Stupid kexec/kdump question...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1u02toi2g.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 27 Sep 2006 02:00:07 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Horms <horms@...ge.net.au>
Cc:	Andrew Morton <akpm@...l.org>, fastboot@...ts.osdl.org,
	Valdis.Kletnieks@...edu, linux-kernel@...r.kernel.org
Subject: Re: [Fastboot] Stupid kexec/kdump question...

Horms <horms@...ge.net.au> writes:

> On Tue, Sep 26, 2006 at 10:10:29PM -0700, Andrew Morton wrote:
>> On Tue, 26 Sep 2006 11:25:06 -0400
>> Valdis.Kletnieks@...edu wrote:
>> 
>> > OK, I'm running a Fedora Core 6 (rawhide actually) box with -18-mm1 kernel.
>> > I've installed kexec-tools and similar, and am trying to get the kernels
>> > built following the hints in Documentation/kdump/kdump.txt, but a few
>> > questions arise:
>> > 
>> > 1) Other than the fact that the Fedora userspace looks for a
>> > ${kernelvers}kdump kernel, is there any reason the kdump kernel has
>> > to match the running one, or can an older kernel be used?
>
> The post-crash kernel is not realy dependant on the pre-crash kernel.
> What is important is that either the kernel is relocatable
> (which is being worked on for x86 and i386), or it is compiled to
> run at a non-default address and that address corresponds
> to the region reserved by the crashkernel command line parameter
> passed to the pre-crash kernel.
>
> The post-crash kernel will also need CONFIG_CRASH_DUMP 
> and likely CONFIG_PROC_VMCORE

hip hip horray!  Getting mismatched kernels to be supported was a long
discussion.

I suspect the reason for the matching kernel from the distros is just
that everything is quite new so they don't want to wonder if you old
kernel has all of the appropriate support, and by that point they can
probably assume the shipped kernel works.

>> > 2) I'm presuming that a massively stripped down kernel (no sound support,
>> > no netfilter, no etc) that just has what's needed to mount the dump location
>> > is sufficient?
>
> Yes
>
>> > 3) The docs recommend 'crashkernel=64M@...', but that's 8% of my memory.
>> > What will happen if I try '16M@...' instead?  Just slower copying due to
>> > a smaller buffer cache space, or something more evil?
>
> There is a lower bound to how small you can make the space, which
> is basically how little memory space your post-crash kernel needs.
> 16M is probably pushing it, but 32M should be more than possible.
> Experimentation is really the order of the day here.

At that level I would say that below 32M is where you start dealing with
custom built programs, instead of slapping a bunch of utilities inside
a ramdisk.  I suspect with a little care you could get a few K user
space executable and fit everything inside of 4M.  But I don't know if anyone
is that ambitious yet.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/