Thank you for the report! I think the problem was memory then, you nailed it - by reserving more memory, you were able to make it work. This is a policy and currently, the default is a bit conservative in order to not waste memory. It works in most of the systems...
We have a memory estimator project [0] that (hopefully) will help users to determine the proper amount of reserved memory for their systems. For now, I guess we can consider this bug fixed (by the reporter!). Cheers, Guilherme [0] https://salsa.debian.org/debian/kdump-tools/-/merge_requests/13 ** Changed in: makedumpfile (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1931779 Title: kdump just hung out of the box Status in makedumpfile package in Ubuntu: Fix Released Bug description: I tried installing kdump-tools (1.6.7-1ubuntu2.2) on my up to date 20.04 system, installed specifically to try reproducing a bug. But when I tried, after kdump-config status reported "ready to dump" on reboot, echo 'c' | sudo tee /proc/sysrq-trigger, it printed the panic to console and then just hung forever. After some blind guessing and twiddling both variables, I found that crashkernel=512M-:256M works on this particular setup. (MS7850 motherboard, i5-4670 CPU, 5.4.0-42-generic kernel) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1931779/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp