From: Bernhard Walle <bwalle@suse.de>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Determine version of kernel that produced vmcore
Date: Tue, 10 Jul 2007 15:20:31 +0200 [thread overview]
Message-ID: <20070710132031.GE22862@suse.de> (raw)
In-Reply-To: <20070710044546.GA2240@localdomain>
Hello,
* Dan Aloni <da-x@monatomic.org> [2007-07-10 06:45]:
> > >
> > > Not exactly. Let me describe the procedure in greater detail.
> > > Basically, it would go like this:
> > >
> > > 1. <normal bootloader boot>
> > > 2. <normal initramfs>
> > > 3. embed_configfile /proc/kcore.info /vmlinux-kdump
> > > 4. kexec -l vmlinux-kdump <....>
> > > 5. <boot continues>
> > > 6. <crash>
> > > 7. <kdump kernel boot>
> > > 8. <kdump initramfs runs>
> > > 9. makedumpfile -i /proc/vmcore.info <....>
> >
> > I don't see why an additional tool would be needed here. kexec already
> > modifies symbols, so why not adding the functionality into kexec? The
> > advantage would be that there's no on-disk modification necessary.
>
> Actually, 'embed_configfile /proc/kcore.info /vmlinux-kdump' makes
> no on-disk modification, since it is all contained in initramfs (we
> step out of initramfs in stage 5).
Well, that assumes that you load the kdump kernel in the initrd of the
normal kernel. That's not always the case. For example, in SUSE the
kdump kernel is loaded as init script in the normal boot process.
Also, e.g. when testing, you may load the kdump kernel again. So you
would always need to copy the kdump kernel, modify it with
embed_configfile and then run kexec.
I think extending kexec to perform this task is more user friendly.
> BTW another option would be containing the whole CONFIGFILE as a
> vmlinux-specific ELF note, to be easily read from /proc/vmcore.
> You'd still need some util like embed_configfile at build time
> in order to integrate it, and you'd also need to modify
> makedumpfile so it can use it. Actually this sounds quite better
> to me. I'll try to prepare patches both for makedumpfile and the
> kernel and see how easy it is.
Well, in our kernel RPMs there's also a CONFIGFILE which can be
located on disk based on the version. (If a user builds the kernel
manually, then he probably builds it with -g anyway because if he
doesn't, he cannot run makedumpfile.)
The inclusion of the CONFIGFILE can be done by kexec when loading the
kdump kernel, either from a file or from the compiled-in
/proc/kcore.info file. I don't see a reason why a tool should modify
the vmlinux file for kdump on-disk. Actually, I like the idea of
including a ELF note that contains CONFIGFILE.
Currently, we still have another problem: On x86_64, if the kernel is
relocatable, we only can use bzImage, not vmlinux kexec because of a
GDB bug that doesn't get attention by the GDB developers although I
found out the patch that broke GDB in that way ... But: That would
require that embed_configfile must also be able to modify bzImage
which is very problematic. Adding a ELF in kexec that could be read in
the /proc/vmcore hasn't that problem.
Thanks,
Bernhard
next prev parent reply other threads:[~2007-07-10 13:20 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 13:28 Determine version of kernel that produced vmcore Bernhard Walle
2007-07-06 14:58 ` Dan Aloni
2007-07-09 9:21 ` Bernhard Walle
2007-07-09 11:41 ` Dan Aloni
2007-07-09 20:49 ` Bernhard Walle
2007-07-10 4:45 ` Dan Aloni
2007-07-10 13:20 ` Bernhard Walle [this message]
2007-07-10 15:00 ` Vivek Goyal
2007-07-10 17:17 ` Neil Horman
2007-07-10 17:35 ` Dan Aloni
2007-07-10 18:26 ` Dan Aloni
2007-07-10 19:00 ` Neil Horman
2007-07-10 20:36 ` Dan Aloni
2007-07-11 11:57 ` Neil Horman
2007-07-10 6:48 ` Vivek Goyal
2007-07-10 8:14 ` Dan Aloni
2007-07-10 12:12 ` Neil Horman
2007-07-10 13:05 ` Bernhard Walle
2007-07-10 12:09 ` Neil Horman
2007-07-10 16:52 ` Dan Aloni
2007-07-11 6:07 ` Vivek Goyal
2007-07-11 7:32 ` Dan Aloni
2007-07-11 13:43 ` Ken'ichi Ohmichi
2007-07-13 3:58 ` Vivek Goyal
2007-07-13 7:49 ` Bernhard Walle
2007-07-13 3:43 ` Vivek Goyal
2007-07-11 8:58 ` Bernhard Walle
2007-07-10 3:13 ` Ken'ichi Ohmichi
2007-07-10 12:02 ` Neil Horman
2007-07-13 11:05 ` Ken'ichi Ohmichi
2007-07-13 13:15 ` Bernhard Walle
2007-07-16 4:19 ` Vivek Goyal
2007-07-16 11:57 ` Bernhard Walle
2007-07-16 12:25 ` Vivek Goyal
2007-07-16 12:27 ` Bernhard Walle
2007-07-16 12:28 ` Bernhard Walle
2007-07-16 12:36 ` Vivek Goyal
2007-07-18 14:07 ` Ken'ichi Ohmichi
2007-07-18 23:10 ` Bernhard Walle
2007-07-24 6:49 ` Ken'ichi Ohmichi
2007-07-19 14:12 ` Vivek Goyal
2007-07-19 16:39 ` Don Zickus
2007-07-19 16:49 ` Bernhard Walle
2007-07-19 16:59 ` Don Zickus
2007-07-23 5:01 ` Vivek Goyal
2007-07-23 11:47 ` Ken'ichi Ohmichi
2007-07-23 13:02 ` Dan Aloni
2007-07-23 15:58 ` Vivek Goyal
2007-07-24 6:40 ` Ken'ichi Ohmichi
2007-07-17 3:50 ` Vivek Goyal
2007-07-17 8:17 ` Bernhard Walle
2007-07-10 12:52 ` Bernhard Walle
2007-07-10 6:36 ` Vivek Goyal
2007-07-10 12:59 ` Bernhard Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070710132031.GE22862@suse.de \
--to=bwalle@suse.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox