This is a good suggestion Rich! I've looped Dann and Cascardo, both
maintainers of kdump-tools to also discuss this subject.
We could have a more explicit message when installing the package, maybe
in the same screen that asks if we want to enable kdump by default. I'm
against the idea of _not_ se
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
Oh yeah, it would be awesome to set such message...but I'm not sure how
we can do it! If we know beforehand that the reserved memory amount
won't work for your system, to show the message..why we don't just fix
it?
The problem is that this is a policy, there is no technical mechanism
(currently) t
I suppose I should have made it clear that just changing the amount of
memory reserved was not sufficient.
Perhaps it would be useful to print a message saying "hey, I know we set
something by default, but we don't expect that to actually work, so you
should probably test and adjust it"?
Because
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 proj
** Description changed:
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 t
6 matches
Mail list logo
