Re: [PATCH 1/4] update kexec-kdump-howto

Hi Coiby, On Tue, 1 Mar 2022 17:39:57 +0800 Coiby Xu <coxu(a)redhat.com&gt; wrote: > 1. yum is deprecated so use dnf instead > 2. use the "kdumpctl reset-crashkernel" API > > Signed-off-by: Coiby Xu <coxu(a)redhat.com&gt; > --- > kexec-kdump-howto.txt | 23 ++++++++++++----------- > 1 file changed, 12 insertions(+), 11 deletions(-) > > diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt > index 1aeffc7..0121d0e 100644 > --- a/kexec-kdump-howto.txt > +++ b/kexec-kdump-howto.txt > @@ -44,7 +44,7 @@ ia64 and ppc64. > If you're reading this document, you should already have kexec-tools > installed. If not, you install it via the following command: > > - # yum install kexec-tools > + # dnf install kexec-tools > > Now load a kernel with kexec: > > @@ -66,23 +66,24 @@ How to configure kdump > Again, we assume if you're reading this document, you should already have > kexec-tools installed. If not, you install it via the following command: > > - # yum install kexec-tools > + # dnf install kexec-tools > > To be able to do much of anything interesting in the way of debug analysis, > you'll also need to install the kernel-debuginfo package, of the same arch > as your running kernel, and the crash utility: > > - # yum --enablerepo=\*debuginfo install kernel-debuginfo.$(uname -m) crash > + # dnf --enablerepo=\*debuginfo install kernel-debuginfo.$(uname -m) crash personally I would remove the whole paragraph. IMHO this how-to should be on how to setup kdump to create a dump. Not how to analyze one.

> > -Next up, we need to modify some boot parameters to reserve a chunk of memory for > -the capture kernel. With the help of grubby, it's very easy to append > -"crashkernel=128M" to the end of your kernel boot parameters. Note that the X > -values are such that X = the amount of memory to reserve for the capture kernel. > -And based on arch and system configuration, one might require more than 128M to > -be reserved for kdump. One need to experiment and test kdump, if 128M is not > -sufficient, try reserving more memory. > +Next up, we need to reserve a chunk of memory for the capture kernel. To use > +the default crashkernel value, you can kdumpctl: > > - # grubby --args="crashkernel=128M" --update-kernel=/boot/vmlinuz-`uname -r` > + # kdumpctl reset-crashkernel --kernel=/boot/vmlinuz-`uname -r` can't you drop the --kernel option? IIRC reset-crashkernel uses it automatically when no argument is given (and no KDUMP_KERNELVER is set).

> + > +If based on arch and system configuration, the default crashkernel isn't > +sufficent, you can specify a larger value e.g crashkernel=256M after > +experimenting and testing kdump with the help of grubby: > + > + # grubby --args="crashkernel=256M" --update-kernel=/boot/vmlinuz-`uname -r` the grubby command above doesn't update the GRUB_CMDLINE_LINUX in /etc/default/grub. So after an kernel update the crashkernel will be back on the old value. Same for kdumpctl reset-chrashkernel above. Shall we mention it here?

Furthermore I think it makes sense to mention kdumpctl estimate here.

How about --- Next up, we need to reserve a chunk of memory for the capture kernel. For most users using the default value is sufficient. You can set the default value with: # kdumpctl reset-crashkernel If the default value does not work for your setup you can use # grubby --args="crashkernel=256M" --update-kernel=/boot/vmlinuz-`uname -r` to specify a larger value, in this case 256M. You need to experiment to find the best value that works for your setup. To begin with # kdumpctl estimate gives you an estimation for the crashkernel value based on the currently running kernel. --- Thanks Philipp > > Note that there is an alternative form in which to specify a crashkernel > memory reservation, in the event that more control is needed over the size and