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

Reply via email to