On Fri, Jul 25, 2014 at 02:53:49PM +0800, WANG Chao wrote:
On 07/24/14 at 02:51pm, Vivek Goyal wrote:
> On Fri, Jul 25, 2014 at 12:09:22AM +0530, Hari Bathini wrote:
> > The script dracut-kdump.sh is responsible for capturing vmcore during
> > second kernel boot. Currently this script gets installed into kdump
> > initrd as part of kdumpbase dracut module.
> > With fadump support, 'dracut-kdump.sh' script also gets installed into
> > default initrd to capture vmcore generated by firmware assisted dump.
> > Thus in fadump case, the same initrd is going to be used for normal
> > boot as well as boot after system crash. Hence a check is required to
> > see if it is a normal boot or boot after crash.
> > A new node "ibm,kernel-dump" is added, to the device tree, by
> > to notify kernel if it is booting after crash. The below patch adds a
> > check for this node before executing steps to capture vmcore. This
> > check will help bypassing the vmcore capture steps during normal boot
> > process.
> > Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
> > Signed-off-by: Hari Bathini <hbathini(a)linux.vnet.ibm.com>
> > ---
> > dracut-kdump.sh | 5 +++++
> > kdumpctl | 6 +++++-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> > diff --git a/dracut-kdump.sh b/dracut-kdump.sh
> > index cb13d92..9958317 100755
> > --- a/dracut-kdump.sh
> > +++ b/dracut-kdump.sh
> > @@ -1,5 +1,10 @@
> > #!/bin/sh
> > +# continue here only if we have to save dump.
> > +if [ -f /etc/fadump.initramfs ] && [ ! -f
/proc/device-tree/rtas/ibm,kernel-dump ]; then
> > + return
> > +fi
> > +
> This is much better.
> What about the failure case. Say saving vmcore fails. Current default
> is to "reboot" the system. What are you expecting in case of
> I don't think you will like to reboot the system. You probably will
> want to continue the boot after giving error message.
> If yes, then this area is going to need some work. Currently chao
> is making changes where if an error occurs, then we will be isolated
> to kdump error handler which will reboot the system.
Yes, we will replace the default emergency.service of systemd with our own
I think in case of fadump, we can simply find a way to propagate fadump
flag from mkdumprd to dracut-module-setup, then we can skip the
replacement and leave the default one still.
W/o the replacement of emergency.service, fadump could work as expected.
If saving vmcore failed (after kdump service was started), will that
not invoke error handler. I am not sure if that will be kdump one or
default one. But that might not be required in fadump case.
Secondly, right now after successful dump , we reboot the machine and
fadump will not like that.
I am not sure how is it working for Hari right now. Did I miss something.