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 firmware
> 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
"fadump"?
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
emergency.service.
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.
Thanks
WANG Chao
You and chao will have to discuss how to cater to needs of fadump also.
Thanks
Vivek
> exec &> /dev/console
> . /lib/dracut-lib.sh
> . /lib/kdump-lib.sh
> diff --git a/kdumpctl b/kdumpctl
> index ff09b9a..98de747 100755
> --- a/kdumpctl
> +++ b/kdumpctl
> @@ -151,8 +151,12 @@ rebuild_fadump_initrd()
> # backup fadump initrd for reference before replacing it
> backup_initrd
>
> + # this file tells the initrd is fadump enabled
> + touch /tmp/fadump.initramfs
> target_initrd_tmp="$TARGET_INITRD.tmp"
> - $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver
> + $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver \
> + -i /tmp/fadump.initramfs /etc/fadump.initramfs
> + rm -f /tmp/fadump.initramfs
> if [ $? != 0 ]; then
> echo "mkdumprd: failed to rebuild initrd with fadump support"
>&2
> return 1