kdump operates by booting a fresh kernel to capture the context of a crashed kernel, and so the only way for kdump to dump a kernel is to crash it and cause kdump to invoke its post-crash kernel.
You can manually force a running kernel to panic (and invoke a correctly-configured kdump) with the following command sequence:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
Cheers, Ben
On 3/25/19 7:19 PM, wuzhouhui wrote:
Hi,
Is there a way to specify kernel version when (re)start kdump service? Suppose I have install a new kernel and kdump will generate kdump.img for new kernel in next boot. But I want kdump to generate kdump.img for new kernel immediately, is it possible?
Thanks. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-----Original Messages----- From: "Benjamin Hauger" hauger@noao.edu Sent Time: 2019-03-27 00:15:21 (Wednesday) To: centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
kdump operates by booting a fresh kernel to capture the context of a crashed kernel, and so the only way for kdump to dump a kernel is to crash it and cause kdump to invoke its post-crash kernel.
You can manually force a running kernel to panic (and invoke a correctly-configured kdump) with the following command sequence:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
Cheers, Ben
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.
On 3/25/19 7:19 PM, wuzhouhui wrote: CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
What do you mean? Wouldn't the kernel version always be the actual running version of the kernel that was booted?
Ben
On 3/26/19 6:16 PM, wuzhouhui wrote:
-----Original Messages----- From: "Benjamin Hauger" hauger@noao.edu Sent Time: 2019-03-27 00:15:21 (Wednesday) To: centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
kdump operates by booting a fresh kernel to capture the context of a crashed kernel, and so the only way for kdump to dump a kernel is to crash it and cause kdump to invoke its post-crash kernel.
You can manually force a running kernel to panic (and invoke a correctly-configured kdump) with the following command sequence:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
Cheers, Ben
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.
On 3/25/19 7:19 PM, wuzhouhui wrote: CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-----Original Messages----- From: "Benjamin Hauger" hauger@noao.edu Sent Time: 2019-03-28 01:31:40 (Thursday) To: wuzhouhui wuzhouhui14@mails.ucas.ac.cn, centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
What do you mean? Wouldn't the kernel version always be the actual running version of the kernel that was booted?
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).
Ben
On 3/26/19 6:16 PM, wuzhouhui wrote:
-----Original Messages----- From: "Benjamin Hauger" hauger@noao.edu Sent Time: 2019-03-27 00:15:21 (Wednesday) To: centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
kdump operates by booting a fresh kernel to capture the context of a crashed kernel, and so the only way for kdump to dump a kernel is to crash it and cause kdump to invoke its post-crash kernel.
You can manually force a running kernel to panic (and invoke a correctly-configured kdump) with the following command sequence:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
Cheers, Ben
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.
On 3/25/19 7:19 PM, wuzhouhui wrote: CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
Benjamin Hauger SysAdmin/CSDC-DMO Rm. 94 x8371
On Thu, Mar 28, 2019 at 6:55 AM wuzhouhui wuzhouhui14@mails.ucas.ac.cn wrote:
-----Original Messages----- From: "Benjamin Hauger" hauger@noao.edu Sent Time: 2019-03-28 01:31:40 (Thursday) To: wuzhouhui wuzhouhui14@mails.ucas.ac.cn, centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
What do you mean? Wouldn't the kernel version always be the actual running version of the kernel that was booted?
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/htm...
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
On Thu, Mar 28, 2019 at 9:24 AM Gianluca Cecchi gianluca.cecchi@gmail.com wrote:
- 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
[snip]
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"
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 UUID=359ce627-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
-----Original Messages----- From: "Gianluca Cecchi" gianluca.cecchi@gmail.com Sent Time: 2019-03-28 16:59:19 (Thursday) [...] 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
I test it and it works for me, although prints some harmless warnings.
Thanks
-----Original Messages----- From: wuzhouhui wuzhouhui14@mails.ucas.ac.cn Sent Time: 2019-03-29 10:06:06 (Friday) To: "centos mailing list" centos@centos.org Cc: Subject: Re: [CentOS] How to specify kernel version when restart kdump
-----Original Messages----- From: "Gianluca Cecchi" gianluca.cecchi@gmail.com Sent Time: 2019-03-28 16:59:19 (Thursday) [...] 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
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?
I test it and it works for me, although prints some harmless warnings.
Thanks _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos