* Kdump Automation Mechanism @ 2008-08-14 8:03 Cai Qian 2008-08-14 8:17 ` Bernhard Walle 2008-08-14 13:34 ` Vivek Goyal 0 siblings, 2 replies; 13+ messages in thread From: Cai Qian @ 2008-08-14 8:03 UTC (permalink / raw) To: kexec; +Cc: caiqian 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 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-08-14 13:34 ` Vivek Goyal 1 sibling, 1 reply; 13+ messages in thread From: Bernhard Walle @ 2008-08-14 8:17 UTC (permalink / raw) To: kexec * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 8:17 ` Bernhard Walle @ 2008-08-14 12:18 ` Neil Horman 2008-07-18 0:43 ` Bernhard Walle 0 siblings, 1 reply; 13+ messages in thread From: Neil Horman @ 2008-08-14 12:18 UTC (permalink / raw) To: Bernhard Walle; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 12:18 ` Neil Horman @ 2008-07-18 0:43 ` Bernhard Walle 2008-08-14 15:11 ` Neil Horman 0 siblings, 1 reply; 13+ messages in thread From: Bernhard Walle @ 2008-07-18 0:43 UTC (permalink / raw) To: kexec * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-07-18 0:43 ` Bernhard Walle @ 2008-08-14 15:11 ` Neil Horman 2008-08-14 17:23 ` Jay Lan 0 siblings, 1 reply; 13+ messages in thread From: Neil Horman @ 2008-08-14 15:11 UTC (permalink / raw) To: Bernhard Walle; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 15:11 ` Neil Horman @ 2008-08-14 17:23 ` Jay Lan 2008-08-14 18:52 ` Neil Horman 2008-08-18 15:02 ` Bernhard Walle 0 siblings, 2 replies; 13+ messages in thread From: Jay Lan @ 2008-08-14 17:23 UTC (permalink / raw) To: Neil Horman; +Cc: Bernhard Walle, kexec 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 17:23 ` Jay Lan @ 2008-08-14 18:52 ` Neil Horman 2008-08-18 15:02 ` Bernhard Walle 1 sibling, 0 replies; 13+ messages in thread From: Neil Horman @ 2008-08-14 18:52 UTC (permalink / raw) To: Jay Lan; +Cc: Neil Horman, kexec, Bernhard Walle 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 17:23 ` Jay Lan 2008-08-14 18:52 ` Neil Horman @ 2008-08-18 15:02 ` Bernhard Walle 2008-08-20 16:22 ` Cai Qian 1 sibling, 1 reply; 13+ messages in thread From: Bernhard Walle @ 2008-08-18 15:02 UTC (permalink / raw) To: Jay Lan; +Cc: Neil Horman, kexec * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 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 0 siblings, 2 replies; 13+ messages in thread From: Cai Qian @ 2008-08-20 16:22 UTC (permalink / raw) To: Bernhard Walle, Neil Horman; +Cc: qcai, kexec 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-20 16:22 ` Cai Qian @ 2008-08-20 19:54 ` Bernhard Walle 2008-08-20 20:07 ` Jay Lan 1 sibling, 0 replies; 13+ messages in thread From: Bernhard Walle @ 2008-08-20 19:54 UTC (permalink / raw) To: Cai Qian; +Cc: qcai, Neil Horman, kexec * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kdump Automation Mechanism 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 1 sibling, 1 reply; 13+ messages in thread From: Jay Lan @ 2008-08-20 20:07 UTC (permalink / raw) To: kexec 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-20 20:07 ` Jay Lan @ 2008-08-21 3:03 ` Cai Qian 0 siblings, 0 replies; 13+ messages in thread From: Cai Qian @ 2008-08-21 3:03 UTC (permalink / raw) To: jlan; +Cc: qcai, bwalle, kexec, nhorman 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kdump Automation Mechanism 2008-08-14 8:03 Kdump Automation Mechanism Cai Qian 2008-08-14 8:17 ` Bernhard Walle @ 2008-08-14 13:34 ` Vivek Goyal 1 sibling, 0 replies; 13+ messages in thread From: Vivek Goyal @ 2008-08-14 13:34 UTC (permalink / raw) To: Cai Qian; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-08-21 3:03 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.