My suggestion would be to print a warning unconditionally on first install that you should test it and not assume it will just work, and/or to not set crashkernel=... with the default in the first place so people have to go explicitly set it (and, implicitly, read about the fact that one size does not fit all when finding out how). (I would even do the former if your very next commit landed the heuristic estimator to improve this, until you were confident it worked in the majority of cases.)
I know it's not readily programmatically possible to tell "will this work" short of actually doing it, because haha hardware, my lament is that in my experience, the default has _never_ worked, on my VMs or real hardware, and I would not expect something to configure itself with defaults, resulting in e.g. kdump-config status reporting "ready to kdump" when asked, and then...not. -- 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
