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? │ │ │ │ │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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 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. 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