Hi Coiby,
On Sat, 2 Apr 2022 18:07:09 +0800
Coiby Xu <coxu(a)redhat.com> wrote:
Hi Philipp,
Thanks for reviewing this patch set!
On Fri, Mar 25, 2022 at 06:16:13PM +0100, Philipp Rudo wrote:
>Hi Coiby,
>
>On Tue, 1 Mar 2022 17:39:57 +0800
>Coiby Xu <coxu(a)redhat.com> 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>
>> ---
>> 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.
I'd like to keep it for two reasons,
ok, no problem it was only a suggestion.
- This info is useful and I don't find a file like
crash-howto.
- This paragraph dated to 2006 according to commit 9ac14dd ("fixing bz
206861"). There could be another unknown reason why it has such a
long history.
Hmm.. no clue what the bug and the commit fit together...
Nevertheless only because it has been this way for a long time doesn't
automatically mean that it made sense in the first place ;-)
>
>>
>> -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 I drop the --kernel option, it feels I need to add a note that this
applies to current running kernel. So maybe it's better to make the
command self-explanatory.
The question is, how can we make it more self-explanatory? As an
alternative we could also switch to use --kernel=ALL through out the
document. That would also...
>> +
>> +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?
No, only running grub2-mkconfig would reset all kernels with the old
value if /etc/default/grub. grubby only updates /etc/defaut/grub when
called with --update-kernel=ALL and I intentionally made "kdumpctl
reset-crashkernel" has the same behaviour.
... partially solve this problem. Nevertheless, I would mention here
that if you manually set the crashkernel value only for a specific
kernel you need to repeat this after every update for the newly
installed kernel (or edit GRUB_CMDLINE_LINUX manually). Otherwise it
most likely won't work.
BTW, I think that it's good that kdumpctl reset-crashkernel and grubby
behave the same. The only thing I don't like is that if you update the
kernel commandline for a specific kernel the change won't carry over
when you install/update to a new kernel. At least I expect that if you
need to increase the crashkernel for the an old kernel you most likely
need to increase it for the new kernel as well.
>
>Furthermore I think it makes sense to mention kdumpctl estimate here.
Thanks for this good suggestion! crashkernel-howto.txt already has a
section about "kdumpctl estimate" maybe we can simply refer the users to
it?
Sounds good!
Thanks
Philipp
>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
>