7 thoughts on - How To Specify Kernel Version When Restart Kdump

• Hi, Ben

  I think your response doesn’t answered my question. I’m not asking how to trigger kernel crash and see whether the kdump is works, but asking how to specifying kernel version when start kdump service.

  Thanks.

• What do you mean? Wouldn’t the kernel version always be the actual running version of the kernel that was booted?

  Ben

• Suppose the running kernel is 2.6.32, and then I installed kernel 3.10.0. The files under /boot includes (exclude some unimportant files):
  initramfs-2.6.32.img
  initramfs-3.10.0.img
  vmlinuz-2.6.32
  vmlinuz-3.10.0
  initrd-2.6.32kdump.img We can see that there is no initrd-3.10.0kdump.img for newly installed kernel 3.10.0, and kdump will generate initrd-3.10.0kdump.img only when booted as kernel 3.10.0. However, I want kdump to generate initrd-3.10.0kdump.img now (the current running kernel is 2.6.32).

• Your particolar versions seem quite strange because 2.6.32 lets me think about CentOS 6 and 3.10.0 lets me think about CentOS 7. Any way see below for some discussion, not tried by me, so in case please use on test system before.

  1) In CentOS 6 we have the classical SysV service file: /etc/rc.d/init.d/kdump

  Supposing you have just installed 2.6.32-642.13.1.el6.x86_64 kernel

  Analyzing what it runs we have

  DUMP_KERNELVER=””
  MKDUMPRD_ARGS=””

  . /etc/sysconfig/kdump In my case:
  KDUMP_BOOTDIR=”/boot”

  local running_kernel=`uname -r`
  kdump_kver=`echo $running_kernel | sed ‘s/smp//g’`
  MKDUMPRD=”/sbin/mkdumprd -d -f $MKDUMPRD_ARGS”

  kdump_initrd=”${KDUMP_BOOTDIR}/initrd-${kdump_kver}kdump.img”

  and at the end it runs this command if it doesn’t find one:
  $MKDUMPRD $kdump_initrd $kdump_kver

  that tipically will translate in:

  /sbin/mkdumprd -d -f “/boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img”

  2) In CentOS 7 we have systemd unit files and for kdump: /usr/lib/systemd/system/kdump.service

  Supposing you have just installed 3.10.0-693.21.1.el7.x86_64

  The script called actually it is /usr/bin/kdumpctl

  See also fadump (firmware assisted dump) concepts in RHEL 7 / CentOS 7:
  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/kernel_administration_guide/kernel_crash_dump_guide

  But I think you are x86_64 so kdump sttill applies In kdumpctl we have something like this:

  MKDUMPRD=”/sbin/mkdumprd -f”
  TARGET_INITRD=””

  . /lib/kdump/kdump-lib.sh

  . /etc/sysconfig/kdump

  eval $(cat /proc/cmdline| grep “BOOT_IMAGE” | cut -d’ ‘ -f1)
  KDUMP_BOOTDIR=”/boot”$(dirname $BOOT_IMAGE)

  kdump_kver=`uname -r`
  TARGET_INITRD=”${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img”

  rebuild_kdump_initrd()
  {
  $MKDUMPRD $TARGET_INITRD $kdump_kver
  if [ $? != 0 ]; then
  echo “mkdumprd: failed to make kdump initrd” >&2
  return 1
  fi

  return 0
  }

  So at the end the command will be:

  $MKDUMPRD $TARGET_INITRD $kdump_kver

  that in general should be something like this if you want to compile for kernel 3.10.0-693.21.1.el7.x86_64 :

  /sbin/mkdumprd -f /boot/initramfs-3.10.0-693.21.1.el7.x86_64kdump.img
  3.10.0-693.21.1.el7.x86_64

  HIH trying, Gianluca

• The command line fo CentOS 6 clearly misses the kernel version to build initrd file for, so the correct command should be:

  /sbin/mkdumprd -d -f
  “/boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img” 2.6.32-642.13.1.el6.x86_64

  On a test system of mine with version 6.8:
  # /sbin/mkdumprd -d -f “/boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img”
  2.6.32-642.13.1.el6.x86_64
  Warning: There might not be enough space to save a vmcore.
  The size of UUID59ce627-f3b1-49a3-a9b9-f607435a40d9 should be greater than 132250104 kilo bytes.
  #

  # ll /boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img
  -rw——- 1 root root 7515358 Mar 28 09:52
  /boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img

• I test it and it works for me, although prints some harmless warnings.

  Thanks

• Unfortunately, I encountered a new issue when mkdumprd for a kernel different from running. The phenomenon is mkdumprd cannot break following loop in function depsolve_modlist(), in /sbin/mkdumprd:

  348 while [ -n “$TMPINMODS” ]
  349 do
  350 for i in $TMPINMODS
  351 do
  352 mname=`basename $i | sed -e’s/\.ko//’`
  […]
  407 TMPINMODS=$TMPTMPMODS
  408 done
  409 done
  410 MODULES=$TMPOUTMODS

  and $TMPINMODS is vhost_net.ko when issue occurs. The reason is mkdumprd set
  $TMPINMODS by lsmod in running kernel. But there is a new depends of vhost_net in newer kernel and $TMPINMODS doesn’t include it, so mkdumprd stuck in previous while loop.

  Is there a solution exists?