------- Comment From <email address hidden> 2016-01-25 06:32 EDT-------
(In reply to comment #12)
> Hello,
>
> I must admit that I am a bit puzzled by some of your statements :
>
> ---Steps to Reproduce---
> Steps to follow:
> 1. apt-get install linux-crashdump
> 2. apt-get install kdump-tools
>
> Step 2 is not required : kdump-tools is a dependency of linux-crashdump so
> it is installed automatically :
>
> 3. Edit /etc/default/kdump-tools and change the following:
> USE_KDUMP=0 to 1
> This is not required. kdump-tools 1:1.5.9-3 does that automatically during
> installation and you should be prompted to accept it :
>
> ???????????????????????????????????????????????? Configuring kdump-tools
> ????????????????????????????????????????????????
> ?
> ?
> ? If you choose this option, the kdump-tools mechanism will be enabled. A
> reboot is still required in order to enable ?
> ? the crashkernel kernel parameter.
> ?
> ?
> ?
> ? Should kdump-tools be enabled by default?
> ?
> ?
> ?
> ? <Yes>
> <No> ?
> ?
> ?
> ?????????????????????????????????????????????????????????????????????????????
> ????????????????????????????????????????????
>
> 4. Change the size of the crash kernel in /boot/grub/grub.cfg to
> crashkernel=4096M-:4096M
> 5. Load the kdump config file: kdump-config load
>
> This will fail with the following :
>
> # kdump-config load
> * no crashkernel= parameter in the kernel cmdline
>
Hi Louis,
The description should have another step between 4 & 5.
4a. Reboot.
While this step was missing in description, reboot was done as you can see
from the output of "kdump-config show" command.
> Which is normal as a reboot is required in order to have the crashkernel
> parameter taken into account after the reboot.
>
> 6. echo 1 > /proc/sys/kernel/sysrq
> 7. echo c > /proc/sysrq-trigger
>
> The hang following this command is normal : as previously stated, a reboot
> is required otherwise kdump-tools is not loaded.
>
> After the reboot, you should see the following in /var/log/syslog :
>
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: Starting kdump-tools: *
> Missing symlink : /var/lib/kdump/initrd.img
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Creating symlink
> /var/lib/kdump/initrd.img
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Missing symlink :
> /var/lib/kdump/vmlinuz
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Creating symlink
> /var/lib/kdump/vmlinuz
> Jan 25 11:12:26 XenialS-crashdump kdump-tools[523]: * loaded kdump kernel
>
> To verify the status of kdump you can do :
>
> # kdump-config show
> DUMP_MODE: kdump
> USE_KDUMP: 1
> KDUMP_SYSCTL: kernel.panic_on_oops=1
> KDUMP_COREDIR: /var/crash
> crashkernel addr: 0x2c000000
> current state: ready to kdump
>
> kexec command:
> /sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-4.3.0-7-generic
> root=/dev/mapper/VividS--vg-root ro console=ttyS0,115200 irqpoll maxcpus=1
> nousb systemd.unit=kdump-tools.service" --initrd=/var/lib/kdump/initrd.img
> /var/lib/kdump/vmlinuz
>
> Your bug statement shows the following :
>
> /sbin/kexec -p --args-linux
> --command-line="root=UUID=e445a093-4593-4e91-bebb-6968483bf2ea ro quiet
> splash irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service"
> --initrd=/boot/initrd.img-4.3.0-5-generic /boot/vmlinux-4.3.0-5-generic
>
> This : --initrd=/boot/initrd.img-4.3.0-5-generic
> /boot/vmlinux-4.3.0-5-generic indicates that kdump-tools is not properly
> configured and that your /etc/default/kdump-tools file is the one from a
> previous version. I suspect that kdump-tools was improperly configured or
> that installation of the maintainer's version of the file was refused.
>
> Since 15.10 (Wily), /etc/default/kdump-tools has the following :
>
> KDUMP_KERNEL=/var/lib/kdump/vmlinuz
> KDUMP_INITRD=/var/lib/kdump/initrd.img
>
> This was implemented to fix LP: #1496317 which might be the bug that you are
> encountering.
>
Actually, there are two problems here.
1. No vmlinuz on ppc64le which makes the kdump-tools script act weird.
- We tried to workaround this problem by commenting out KDUMP_KERNEL
& KDUMP_INITRD so that the script picks /boot/vmlinux-4.3.0-5-generic and
/boot/initrd.img-4.3.0-5-generic respectively.
2. After triggering crash, we are hanging right after "IPI complete". This could well be
related to kernel or kexec-tools. I am debugging the issue..
We can use this bug to track one of the problems, say vmlinux vs vmlinuz problem (first problem).
Let me raise another bug to track the kernel/kexec-tools problem..
Thanks
Hari
> I suggest that you verify your configuration and run the test again as your
> description does not describe an actual bug but misconfiguration of
> kdump-tools
------- Comment From <email address hidden> 2016-01-25 06:32 EDT------- kdump-tools and change the following: ??????? ??????? ??????? ??????? ??????? ?????? Configuring kdump-tools ??????? ??????? ??????? ??????? ??????? ?????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ??????? ?? 4096M-: 4096M
(In reply to comment #12)
> Hello,
>
> I must admit that I am a bit puzzled by some of your statements :
>
> ---Steps to Reproduce---
> Steps to follow:
> 1. apt-get install linux-crashdump
> 2. apt-get install kdump-tools
>
> Step 2 is not required : kdump-tools is a dependency of linux-crashdump so
> it is installed automatically :
>
> 3. Edit /etc/default/
> USE_KDUMP=0 to 1
> This is not required. kdump-tools 1:1.5.9-3 does that automatically during
> installation and you should be prompted to accept it :
>
> ???????
> ???????
> ?
> ?
> ? If you choose this option, the kdump-tools mechanism will be enabled. A
> reboot is still required in order to enable ?
> ? the crashkernel kernel parameter.
> ?
> ?
> ?
> ? Should kdump-tools be enabled by default?
> ?
> ?
> ?
> ? <Yes>
> <No> ?
> ?
> ?
> ???????
> ???????
>
> 4. Change the size of the crash kernel in /boot/grub/grub.cfg to
> crashkernel=
> 5. Load the kdump config file: kdump-config load
>
> This will fail with the following :
>
> # kdump-config load
> * no crashkernel= parameter in the kernel cmdline
>
Hi Louis,
The description should have another step between 4 & 5.
4a. Reboot.
While this step was missing in description, reboot was done as you can see
from the output of "kdump-config show" command.
> Which is normal as a reboot is required in order to have the crashkernel kernel/ sysrq kdump/initrd. img kdump/initrd. img kdump/vmlinuz kdump/vmlinuz panic_on_ oops=1 line="BOOT_ IMAGE=/ vmlinuz- 4.3.0-7- generic mapper/ VividS- -vg-root ro console= ttyS0,115200 irqpoll maxcpus=1 unit=kdump- tools.service" --initrd= /var/lib/ kdump/initrd. img kdump/vmlinuz line="root= UUID=e445a093- 4593-4e91- bebb-6968483bf2 ea ro quiet unit=kdump- tools.service" /boot/initrd. img-4.3. 0-5-generic /boot/vmlinux- 4.3.0-5- generic /boot/initrd. img-4.3. 0-5-generic 4.3.0-5- generic indicates that kdump-tools is not properly kdump-tools file is the one from a kdump-tools has the following : /var/lib/ kdump/vmlinuz /var/lib/ kdump/initrd. img
> parameter taken into account after the reboot.
>
> 6. echo 1 > /proc/sys/
> 7. echo c > /proc/sysrq-trigger
>
> The hang following this command is normal : as previously stated, a reboot
> is required otherwise kdump-tools is not loaded.
>
> After the reboot, you should see the following in /var/log/syslog :
>
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: Starting kdump-tools: *
> Missing symlink : /var/lib/
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Creating symlink
> /var/lib/
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Missing symlink :
> /var/lib/
> Jan 25 11:12:25 XenialS-crashdump kdump-tools[523]: * Creating symlink
> /var/lib/
> Jan 25 11:12:26 XenialS-crashdump kdump-tools[523]: * loaded kdump kernel
>
> To verify the status of kdump you can do :
>
> # kdump-config show
> DUMP_MODE: kdump
> USE_KDUMP: 1
> KDUMP_SYSCTL: kernel.
> KDUMP_COREDIR: /var/crash
> crashkernel addr: 0x2c000000
> current state: ready to kdump
>
> kexec command:
> /sbin/kexec -p --command-
> root=/dev/
> nousb systemd.
> /var/lib/
>
> Your bug statement shows the following :
>
> /sbin/kexec -p --args-linux
> --command-
> splash irqpoll maxcpus=1 nousb systemd.
> --initrd=
>
> This : --initrd=
> /boot/vmlinux-
> configured and that your /etc/default/
> previous version. I suspect that kdump-tools was improperly configured or
> that installation of the maintainer's version of the file was refused.
>
> Since 15.10 (Wily), /etc/default/
>
> KDUMP_KERNEL=
> KDUMP_INITRD=
>
> This was implemented to fix LP: #1496317 which might be the bug that you are
> encountering.
>
We couldn't use that setting on ppc64le as it has vmlinux. /bugs.launchpad .net/ubuntu/ +source/ makedumpfile/ +bug/1324544
This bug is similar to vmlinuz vs vmlinux problem we had earlier with trusty
https:/
Actually, there are two problems here.
1. No vmlinuz on ppc64le which makes the kdump-tools script act weird.
- We tried to workaround this problem by commenting out KDUMP_KERNEL 4.3.0-5- generic and img-4.3. 0-5-generic respectively.
& KDUMP_INITRD so that the script picks /boot/vmlinux-
/boot/initrd.
2. After triggering crash, we are hanging right after "IPI complete". This could well be
related to kernel or kexec-tools. I am debugging the issue..
We can use this bug to track one of the problems, say vmlinux vs vmlinuz problem (first problem).
Let me raise another bug to track the kernel/kexec-tools problem..
Thanks
Hari
> I suggest that you verify your configuration and run the test again as your
> description does not describe an actual bug but misconfiguration of
> kdump-tools