On Tue, Apr 05, 2022 at 01:44:14PM +0200, Philipp Rudo wrote:
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 ;-)
Yes, it could also mean a burden. I'll bring up this topic in the team
meeting:)
> >
> >>
> >> -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.
Now I understand why I feel the need to add a note. One difference
between "kdumpctl reset-crashkernel" and "grubby" is with no kernel
specified, "kdumpctl reset-crashkernel" operates on the currently
running kernel whereas grubby operates on the default kernel.
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.
Thanks for raising this concern! No, if we manually setting the
crashkernel value for current running kernel, the new kernel will inherit
the new value. You may have misunderstood how new kernel's crashkernel
is set. And editing GRUB_CMDLINE_LINUX doesn't prevent this issue because
new kernel simply inherit the crashkernel value of current running kernel.
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.
--
Best regards,
Coiby