Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: Neil Horman <nhorman@redhat.com>
Cc: Bernhard Walle <bwalle@suse.de>, kexec@lists.infradead.org
Subject: Re: Kdump Automation Mechanism
Date: Thu, 14 Aug 2008 10:23:01 -0700	[thread overview]
Message-ID: <48A469F5.3010608@sgi.com> (raw)
In-Reply-To: <20080814151150.GC14625@hmsendeavour.rdu.redhat.com>

Neil Horman wrote:
> On Fri, Jul 18, 2008 at 02:43:11AM +0200, Bernhard Walle wrote:> * Neil Horman [2008-08-14 08:18]:> > > > That being said, Bernhard, I suppose it would be worthwhile standardizing some> > configuration settings, seeing as despite our implementation differences, we> > seem to largely support the same feature set.  Have you given any consideration> > to defining a standard kdump feature set and configuration syntax?> > I have nothing against consideration in that area.> > SUSE does configuration in /etc/sysconfig/kdump. I think sysconfig is> also on RedHat, so that is the same?> Its close, /etc/sysconfig/kdump is used to apply options to the kexec utility,while /etc/kdump.conf directs how the initrd should be constructed.  I wouldlike to move to using a url style syntax for specifying dump targets like youhave, but there are series of other options that I need to take intoconsideration (seehttp://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/kexec-tools
-1.102pre-15.fc10.src.rpm

Hi Neil and Bernhard,

Yes, please! Please at least agree between RedHat and SuSE how users
can install (rpms that contains necessary bits, such as debuginfo data),
create initrd, configure (kdump config files), and analyze (what to
take to run crash) core files! That would be great!!!

If you can put vmcore at the same location... Ahh, asking too much? ;)

Cheers,
 - jay

> 
>>>> [1] mkdumprd on SUSE is only a script that calls mkinitrd with right> > >     parameters while the mkdumprd on RedHat builds a initramfs for> > >     kdump itself with busybox> > I was looking at this, I assume that your initramfs then acts very simmilar to> > your default initramfs, which mounts the rootfs and runs init, and your kdump> > capture operations are then implemented in the kdump init script.  Is that> > correct?> > For kdump, an own initramfs is built. That does the copy stuff in> initramfs, so that works without rootfs and reboots before init is> executed.> > So the 'copy' script is not the init script but “init/boot-kdump.sh”> script if you “hg clone http://freehg.org/u/bwalle/kdump/”.> Unfortunately, freehg has no tree view in its web interface.> Ahh, so you do all your dump manipulation with your kdumptool binary, I see now.I handle all of that with various shell scripts in the initramfs.
>> Having that said, for testing one must do:> >  - install packages>    SUSE:>    o kexec-tools>    o kdump>    o makedumpfile>    RH: ?> Same here.
>>  - set crashkernel parameter>    => can be done with GRUB configuration manually with editing>       /boot/grub/menu.lst, should be the same on RH and SUSE> Agreed.
>>  - enable kdump (that would be “chkconfig kdump on”)>    => should be the same on RH and SUSE> Agreed.
>>  - tweak some configuration settings like the place where it should be>    saved>    => KDUMP_SAVEDIR in /etc/sysconfig/kdump>    => KDUMP_DUMPLEVEL for makedumpfile in /etc/sysconfig/kdump>    => KDUMP_DUMPFORMAT (“compressed” / “ELF” / “”)>       in /etc/sysconfig/kdump> Agreed.  I think this is where we diverge though.  We seem to support much ofthe same dump targets but our configuaration directives are different.  For me,I would need to configure:<dump type> <type data><core_collector> <cp|makedumpfile> [options]
>>  - trigger kdump>    => echo c > /proc/sysrq-trigger> > Most other stuff is “nice to have” but not “mandatory” I think?> Actually, you're right.  Looking over it, I do have a set of additional options,but none are central to dump collection (link delay specification for spanningtree, kdump pre/post scripts, etc).
>>>> Bernhard> -- > Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development> > “Make everything as simple as possible, but not simpler.”>        -- Albert Einstein> > _______________________________________________> kexec mailing list> kexec@lists.infradead.org> http://lists.infradead.org/mailman/listinfo/kexec
> -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/
> _______________________________________________kexec mailing listkexec@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/kexec


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2008-08-14 17:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-14  8:03 Kdump Automation Mechanism Cai Qian
2008-08-14  8:17 ` Bernhard Walle
2008-08-14 12:18   ` Neil Horman
2008-07-18  0:43     ` Bernhard Walle
2008-08-14 15:11       ` Neil Horman
2008-08-14 17:23         ` Jay Lan [this message]
2008-08-14 18:52           ` Neil Horman
2008-08-18 15:02           ` Bernhard Walle
2008-08-20 16:22             ` Cai Qian
2008-08-20 19:54               ` Bernhard Walle
2008-08-20 20:07               ` Jay Lan
2008-08-21  3:03                 ` Cai Qian
2008-08-14 13:34 ` Vivek Goyal

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=48A469F5.3010608@sgi.com \
    --to=jlan@sgi.com \
    --cc=bwalle@suse.de \
    --cc=kexec@lists.infradead.org \
    --cc=nhorman@redhat.com \
    /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