Re: Kdump Automation Mechanism

Re: Kdump Automation Mechanism

[Bernhard Walle]

* 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?

> > [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.

Having that said, for testing one must do:

 - install packages
   SUSE:
   o kexec-tools
   o kdump
   o makedumpfile
   RH: ?

 - set crashkernel parameter
   => can be done with GRUB configuration manually with editing
      /boot/grub/menu.lst, should be the same on RH and SUSE

 - enable kdump (that would be “chkconfig kdump on”)
   => should be the same on RH and SUSE

 - 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

 - trigger kdump
   => echo c > /proc/sysrq-trigger

Most other stuff is “nice to have” but not “mandatory” I think?



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

Kdump Automation Mechanism

[Cai Qian]

Hi,

I am wondering if this is the right project to accept Kdump automation files. For example, Kdump
daemon init script, mkdumprd (read from Kdump configuration file and generate Kdump initramfs for
the system), default Kdump configuration file, tools to compress vmcore etc.

The problem I am having right now is that, I am trying to write a Kdump test suite, but I could
not 
find a easy way to write a general enough suite for every distro to use. Red Hat and SUSE have
slightly different setting up. Debian and Ubuntu don't have Kdump automation mechanism as the time
I was checking. Also, It make things much easier for different distros and users to pick it up and
contribute to those efforts.

Thanks,
CaiQian

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

Re: Kdump Automation Mechanism

[Bernhard Walle]

* Cai Qian [2008-08-14 01:03]:
> 
> I am wondering if this is the right project to accept Kdump automation files. For example, Kdump
> daemon init script, mkdumprd (read from Kdump configuration file and generate Kdump initramfs for
> the system), default Kdump configuration file, tools to compress vmcore etc.
> 
> The problem I am having right now is that, I am trying to write a Kdump test suite, but I could
> not 
> find a easy way to write a general enough suite for every distro to use. Red Hat and SUSE have
> slightly different setting up. Debian and Ubuntu don't have Kdump automation mechanism as the time
> I was checking. Also, It make things much easier for different distros and users to pick it up and
> contribute to those efforts.

SLES 11 / openSUSE 11.1 (and later) scripts and tools are at
http://freehg.org/u/bwalle/kdump if you want to take a look at.

The problem is that kdump needs to be integrated into the distribution,
i.e. YaST configuration (vs. RedHat's configuration utilities),
mkinitrd from SUSE (vs. mkdumprd from RedHat [1]), BusyBox vs. GNU
tools.

For example, the reason why SUSE does not use Busybox in initramfs is
that we didn't want to provide additional support for Busybox.
That was a business decision, not because Busybox is not suited or
buggy (i.e. not strictly technical decision).

What I want to say: It's not always *that* easy to share everything
across distributions although I consider that in general as a good idea.


Bernhard

[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
-- 
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

Re: Kdump Automation Mechanism

[Neil Horman]

On Thu, Aug 14, 2008 at 10:17:20AM +0200, Bernhard Walle wrote:
> * Cai Qian [2008-08-14 01:03]:
> > 
> > I am wondering if this is the right project to accept Kdump automation files. For example, Kdump
> > daemon init script, mkdumprd (read from Kdump configuration file and generate Kdump initramfs for
> > the system), default Kdump configuration file, tools to compress vmcore etc.
> > 
> > The problem I am having right now is that, I am trying to write a Kdump test suite, but I could
> > not 
> > find a easy way to write a general enough suite for every distro to use. Red Hat and SUSE have
> > slightly different setting up. Debian and Ubuntu don't have Kdump automation mechanism as the time
> > I was checking. Also, It make things much easier for different distros and users to pick it up and
> > contribute to those efforts.
> 
> SLES 11 / openSUSE 11.1 (and later) scripts and tools are at
> http://freehg.org/u/bwalle/kdump if you want to take a look at.
> 
> The problem is that kdump needs to be integrated into the distribution,
> i.e. YaST configuration (vs. RedHat's configuration utilities),
> mkinitrd from SUSE (vs. mkdumprd from RedHat [1]), BusyBox vs. GNU
> tools.
> 
> For example, the reason why SUSE does not use Busybox in initramfs is
> that we didn't want to provide additional support for Busybox.
> That was a business decision, not because Busybox is not suited or
> buggy (i.e. not strictly technical decision).
> 
> What I want to say: It's not always *that* easy to share everything
> across distributions although I consider that in general as a good idea.
> 

Agreed.  It would be great if we could get some common testing infrastructure,
but currently the the implementation of kdump functionality is completely
non-standard.  Theres just too many things the people want kdump to be able to
do, and too many ways to get there.

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?

> 
> Bernhard
> 
> [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?

Neil

> -- 
> 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 list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump Automation Mechanism

[Vivek Goyal]

On Thu, Aug 14, 2008 at 01:03:48AM -0700, Cai Qian wrote:
> Hi,
> 
> I am wondering if this is the right project to accept Kdump automation files. For example, Kdump
> daemon init script, mkdumprd (read from Kdump configuration file and generate Kdump initramfs for
> the system), default Kdump configuration file, tools to compress vmcore etc.
> 
> The problem I am having right now is that, I am trying to write a Kdump test suite, but I could
> not 
> find a easy way to write a general enough suite for every distro to use. Red Hat and SUSE have
> slightly different setting up. Debian and Ubuntu don't have Kdump automation mechanism as the time
> I was checking. Also, It make things much easier for different distros and users to pick it up and
> contribute to those efforts.
> 

Couln't agree more. Distributions tend to diverge when it comes to user
space implementation of things and that makes testing and community
contribution very difficult (Apart from normal user being confused).

We need to put some effort in making sure we diverge as less as possible.
How to do that? I can think of two things.

- Development of user space utilities/applications takes place while
  interacting with community. For example, filtering utility, makedumpfile
  development took place while taking feedback from community on kexec
  mailing list.

- Willingness on the user space developers to come to a common platform
  and put a concious effort to keep things similar.  (Of course good
  things similar).

Thanks
Vivek

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

Re: Kdump Automation Mechanism

[Neil Horman]

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 would
like to move to using a url style syntax for specifying dump targets like you
have, but there are series of other options that I need to take into
consideration (see
http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/kexec-tools-1.102pre-15.fc10.src.rpm


> > > [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 of
the 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 spanning
tree, 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 list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Kdump Automation Mechanism

[Jay Lan]

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

Re: Kdump Automation Mechanism

[Neil Horman]

On Thu, Aug 14, 2008 at 10:23:01AM -0700, Jay Lan wrote:
> 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!!!
> 
This is 90% there.  installation is the same, both for kexec and debuginfo rpms,
initrd creation is automated based on configs (which do need to find a way to
merge).  Likewise core capture format is the same (subject to config options of
course)

> If you can put vmcore at the same location... Ahh, asking too much? ;)
> 
This is really on you.  both systems let you configure where to store cores

> 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
> 

-- 
/***************************************************
 *Neil Horman
 *Senior Software Engineer
 *Red Hat, Inc.
 *nhorman@redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/

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

Re: Kdump Automation Mechanism

[Bernhard Walle]

* Jay Lan [2008-08-14 10:23]:
>
> If you can put vmcore at the same location... Ahh, asking too much? ;)

Will change that to /var/crash since that's FHS 2.3 anyway. :)
[And I personally never liked “/var/log/dump” since it's not a logfile.]



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

Re: Kdump Automation Mechanism

[Cai Qian]

Hi Bernhard and Neil,

--- Bernhard Walle <bwalle@suse.de> wrote:

> * Jay Lan [2008-08-14 10:23]:
> >
> > If you can put vmcore at the same location... Ahh, asking too much? ;)
> 
> Will change that to /var/crash since that's FHS 2.3 anyway. :)
> [And I personally never liked “/var/log/dump” since it's not a logfile.]
>

That's a good. Do you have any consideration for standard Kdump options? I have created a Kdump
test suite but it originally written and tested on RHEL and Fedora.

http://sourceforge.net/mailarchive/message.php?msg_name=20080815.210735.450985660335275199.qcai%40redhat.com

I hope it could also work for SLES, OpenSUSE and other distros. However, I have no environment to
test it yet, and I found it is kind of difficult to port it to other distros for so many different
options.

I'd appreciate if you guys could have a look, and come out a standard Kdump options. I'd also be
happy to modify the suite accordingly.

Thanks,
CaiQian

> 
> 
> 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
> 


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

Re: Kdump Automation Mechanism

[Bernhard Walle]

* Cai Qian <caiqian@cclom.cn> [2008-08-20 09:22]:
> --- Bernhard Walle <bwalle@suse.de> wrote:
> 
> > * Jay Lan [2008-08-14 10:23]:
> > >
> > > If you can put vmcore at the same location... Ahh, asking too much? ;)
> > 
> > Will change that to /var/crash since that's FHS 2.3 anyway. :)
> > [And I personally never liked “/var/log/dump” since it's not a logfile.]
> >
> 
> That's a good. Do you have any consideration for standard Kdump options? I have created a Kdump
> test suite but it originally written and tested on RHEL and Fedora.
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=20080815.210735.450985660335275199.qcai%40redhat.com

Thanks for that effort and for letting me that know.

I'll take definitively a look at this, but currently I'm a bit short in
time because of feature development for the next enterprise
distribution.

I put that on my TODO list, and I'll give you feedback, in the next
weeks. :-)



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

Kdump Automation Mechanism

[Jay Lan]

Cai Qian wrote:
> Hi Bernhard and Neil,
> 
> --- Bernhard Walle <bwalle@suse.de> wrote:
> 
>> * Jay Lan [2008-08-14 10:23]:
>>> If you can put vmcore at the same location... Ahh, asking too much? ;)
>> Will change that to /var/crash since that's FHS 2.3 anyway. :)
>> [And I personally never liked ???/var/log/dump??? since it's not a logfile.]
>>
> 
> That's a good. Do you have any consideration for standard Kdump options? I have created a Kdump
> test suite but it originally written and tested on RHEL and Fedora.
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=20080815.210735.450985660335275199.qcai%40redhat.com

Hi Cai,

I clicked on the attachment of the page above, it failed with:
   File not found on server.

Regards,
 - jay

> 
> I hope it could also work for SLES, OpenSUSE and other distros. However, I have no environment to
> test it yet, and I found it is kind of difficult to port it to other distros for so many different
> options.
> 
> I'd appreciate if you guys could have a look, and come out a standard Kdump options. I'd also be
> happy to modify the suite accordingly.
> 
> Thanks,
> CaiQian
> 
>>
>> Bernhard
>> -- 
>> Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
>>
>> ???Make everything as simple as possible, but not simpler.???
>>        -- Albert Einstein
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: Kdump Automation Mechanism

[Cai Qian]

Hi Jay,

From: Jay Lan <jlan@sgi.com>
Subject: Re: Kdump Automation Mechanism
Date: Wed, 20 Aug 2008 13:07:53 -0700

> Cai Qian wrote:
> > Hi Bernhard and Neil,
> > 
> > --- Bernhard Walle <bwalle@suse.de> wrote:
> > 
> >> * Jay Lan [2008-08-14 10:23]:
> >>> If you can put vmcore at the same location... Ahh, asking too much? ;)
> >> Will change that to /var/crash since that's FHS 2.3 anyway. :)
> >> [And I personally never liked “/var/log/dump” since it's not a logfile.]
> >>
> > 
> > That's a good. Do you have any consideration for standard Kdump options? I have created a Kdump
> > test suite but it originally written and tested on RHEL and Fedora.
> > 
> > http://sourceforge.net/mailarchive/message.php?msg_name=20080815.210735.450985660335275199.qcai%40redhat.com
> 
> Hi Cai,
> 
> I clicked on the attachment of the page above, it failed with:
>    File not found on server.
> 

Then, please find it at,

http://people.redhat.com/qcai/kdump-ng-1.0.tar.gz

Thanks,
CaiQian

> Regards,
>  - jay
> 
> > 
> > I hope it could also work for SLES, OpenSUSE and other distros. However, I have no environment to
> > test it yet, and I found it is kind of difficult to port it to other distros for so many different
> > options.
> > 
> > I'd appreciate if you guys could have a look, and come out a standard Kdump options. I'd also be
> > happy to modify the suite accordingly.
> > 
> > Thanks,
> > CaiQian
> > 
> >>
> >> 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
> >>
> > 
> > 
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> > 
> 
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec