1. yum is deprecated so use dnf instead 2. use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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
-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` + +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`
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
1. yum is deprecated so use dnf instead 2. use the "kdumpctl reset-crashkernel --fadump=on" API
Signed-off-by: Coiby Xu coxu@redhat.com --- fadump-howto.txt | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/fadump-howto.txt b/fadump-howto.txt index bc87644..bef73cb 100644 --- a/fadump-howto.txt +++ b/fadump-howto.txt @@ -39,7 +39,7 @@ kernel are one and the same on 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
Fadump Operational Flow:
@@ -82,7 +82,7 @@ How to configure fadump: 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
Make the kernel to be configured with FADump as the default boot entry, if it isn't already: @@ -94,20 +94,24 @@ 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
-Next up, we need to modify some boot parameters to enable firmware assisted -dump. With the help of grubby, it's very easy to append "fadump=on" to the end -of your kernel boot parameters. To reserve the appropriate amount of memory -for boot memory preservation, pass 'crashkernel=X' kernel cmdline parameter. -For the recommended value of X, see 'FADump Memory Requirements' section. +Next up, we can enable firmware assisted dump and reserve the memory for boot +memory preservation as specified in in the table of 'FADump Memory Requirements' +section: + + # kdumpctl reset-crashkernel --fadump=on + +Alternatively, you can use grubby to reserve custom amount of memory:
# grubby --args="fadump=on crashkernel=6G" --update-kernel=/boot/vmlinuz-`uname -r`
+ By default, FADump reserved memory will be initialized as CMA area to make the memory available through CMA allocator on the production kernel. We can opt out of this, making reserved memory unavailable to production kernel, by booting the -linux kernel with 'fadump=nocma' instead of 'fadump=on'. +linux kernel with 'fadump=nocma' instead of 'fadump=on': + # kdumpctl reset-crashkernel --fadump=nocma
The term 'boot memory' means size of the low memory chunk that is required for a kernel to boot successfully when booted with restricted memory. By default, @@ -350,6 +354,6 @@ Remove "crashkernel=" from kernel cmdline parameters:
If KDump is to be used as the dump capturing mechanism, reset the crashkernel parameter:
- # kdumpctl reset-crashkernel `uname -r` + # kdumpctl reset-crashkernel --fadump=off
Reboot the system for the settings to take effect.
Hi Coiby,
all in all looks good, two small comments below. Nevertheless
Reviewed-by: Philipp Rudo prudo@redhat.com
On Tue, 1 Mar 2022 17:39:58 +0800 Coiby Xu coxu@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel --fadump=on" API
Signed-off-by: Coiby Xu coxu@redhat.com
fadump-howto.txt | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/fadump-howto.txt b/fadump-howto.txt index bc87644..bef73cb 100644 --- a/fadump-howto.txt +++ b/fadump-howto.txt @@ -39,7 +39,7 @@ kernel are one and the same on 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
Fadump Operational Flow:
@@ -82,7 +82,7 @@ How to configure fadump: 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
Make the kernel to be configured with FADump as the default boot entry, if it isn't already: @@ -94,20 +94,24 @@ 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
-Next up, we need to modify some boot parameters to enable firmware assisted -dump. With the help of grubby, it's very easy to append "fadump=on" to the end -of your kernel boot parameters. To reserve the appropriate amount of memory -for boot memory preservation, pass 'crashkernel=X' kernel cmdline parameter. -For the recommended value of X, see 'FADump Memory Requirements' section. +Next up, we can enable firmware assisted dump and reserve the memory for boot +memory preservation as specified in in the table of 'FADump Memory Requirements' +section:
- # kdumpctl reset-crashkernel --fadump=on
+Alternatively, you can use grubby to reserve custom amount of memory:
# grubby --args="fadump=on crashkernel=6G" --update-kernel=/boot/vmlinuz-`uname -r`
I would stick with only one blank line here ...
By default, FADump reserved memory will be initialized as CMA area to make the memory available through CMA allocator on the production kernel. We can opt out of this, making reserved memory unavailable to production kernel, by booting the -linux kernel with 'fadump=nocma' instead of 'fadump=on'. +linux kernel with 'fadump=nocma' instead of 'fadump=on':
- # kdumpctl reset-crashkernel --fadump=nocma
... and add one above the example.
Thanks Philipp
The term 'boot memory' means size of the low memory chunk that is required for a kernel to boot successfully when booted with restricted memory. By default, @@ -350,6 +354,6 @@ Remove "crashkernel=" from kernel cmdline parameters:
If KDump is to be used as the dump capturing mechanism, reset the crashkernel parameter:
- # kdumpctl reset-crashkernel `uname -r`
- # kdumpctl reset-crashkernel --fadump=off
Reboot the system for the settings to take effect.
Hi Philipp,
On Mon, Mar 28, 2022 at 01:35:31PM +0200, Philipp Rudo wrote:
Hi Coiby,
all in all looks good, two small comments below. Nevertheless
Thanks for catching the two issues! I have fixed them in v2.
Reviewed-by: Philipp Rudo prudo@redhat.com
Thanks for reviewing the patch!
On Tue, 1 Mar 2022 17:39:58 +0800 Coiby Xu coxu@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel --fadump=on" API
Signed-off-by: Coiby Xu coxu@redhat.com
fadump-howto.txt | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/fadump-howto.txt b/fadump-howto.txt index bc87644..bef73cb 100644 --- a/fadump-howto.txt +++ b/fadump-howto.txt @@ -39,7 +39,7 @@ kernel are one and the same on 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
Fadump Operational Flow:
@@ -82,7 +82,7 @@ How to configure fadump: 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
Make the kernel to be configured with FADump as the default boot entry, if it isn't already: @@ -94,20 +94,24 @@ 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
-Next up, we need to modify some boot parameters to enable firmware assisted -dump. With the help of grubby, it's very easy to append "fadump=on" to the end -of your kernel boot parameters. To reserve the appropriate amount of memory -for boot memory preservation, pass 'crashkernel=X' kernel cmdline parameter. -For the recommended value of X, see 'FADump Memory Requirements' section. +Next up, we can enable firmware assisted dump and reserve the memory for boot +memory preservation as specified in in the table of 'FADump Memory Requirements' +section:
- # kdumpctl reset-crashkernel --fadump=on
+Alternatively, you can use grubby to reserve custom amount of memory:
# grubby --args="fadump=on crashkernel=6G" --update-kernel=/boot/vmlinuz-`uname -r`
I would stick with only one blank line here ...
By default, FADump reserved memory will be initialized as CMA area to make the memory available through CMA allocator on the production kernel. We can opt out of this, making reserved memory unavailable to production kernel, by booting the -linux kernel with 'fadump=nocma' instead of 'fadump=on'. +linux kernel with 'fadump=nocma' instead of 'fadump=on':
- # kdumpctl reset-crashkernel --fadump=nocma
... and add one above the example.
Thanks Philipp
The term 'boot memory' means size of the low memory chunk that is required for a kernel to boot successfully when booted with restricted memory. By default, @@ -350,6 +354,6 @@ Remove "crashkernel=" from kernel cmdline parameters:
If KDump is to be used as the dump capturing mechanism, reset the crashkernel parameter:
- # kdumpctl reset-crashkernel `uname -r`
- # kdumpctl reset-crashkernel --fadump=off
Reboot the system for the settings to take effect.
Signed-off-by: Coiby Xu coxu@redhat.com --- crashkernel-howto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crashkernel-howto.txt b/crashkernel-howto.txt index 1ba79ab..ed5660c 100644 --- a/crashkernel-howto.txt +++ b/crashkernel-howto.txt @@ -17,7 +17,7 @@ Latest kexec-tools provides "kdumpctl get-default-crashkernel" to retrieve the default crashkernel value,
$ echo $(kdumpctl get-default-crashkernel) - 1G-4G:192M,4G-64G:256M,64G-102400T:512M + 1G-4G:192M,4G-64G:256M,64G-:512M
It will be taken as the default value of 'crashkernel=', you can use this value as a reference for setting crashkernel value manually.
Hi Coiby,
On Tue, 1 Mar 2022 17:39:59 +0800 Coiby Xu coxu@redhat.com wrote:
Signed-off-by: Coiby Xu coxu@redhat.com
Reviewed-by: Philipp Rudo prudo@redhat.com
crashkernel-howto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crashkernel-howto.txt b/crashkernel-howto.txt index 1ba79ab..ed5660c 100644 --- a/crashkernel-howto.txt +++ b/crashkernel-howto.txt @@ -17,7 +17,7 @@ Latest kexec-tools provides "kdumpctl get-default-crashkernel" to retrieve the default crashkernel value,
$ echo $(kdumpctl get-default-crashkernel)
- 1G-4G:192M,4G-64G:256M,64G-102400T:512M
- 1G-4G:192M,4G-64G:256M,64G-:512M
It will be taken as the default value of 'crashkernel=', you can use this value as a reference for setting crashkernel value manually.
Signed-off-by: Coiby Xu coxu@redhat.com --- kdumpctl.8 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kdumpctl.8 b/kdumpctl.8 index 067117b..1a2ae8f 100644 --- a/kdumpctl.8 +++ b/kdumpctl.8 @@ -50,6 +50,9 @@ Estimate a suitable crashkernel value for current machine. This is a best-effort estimate. It will print a recommanded crashkernel value based on current kdump setup, and list some details of memory usage. .TP +.I get-default-crashkernel +Return the default crashkernel value provided by kexec-tools. +.TP .I reset-crashkernel [--kernel=path_to_kernel] [--reboot] Reset crashkernel to default value recommended by kexec-tools. If no kernel is specified, will reset KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
Hi Coiby,
On Tue, 1 Mar 2022 17:40:00 +0800 Coiby Xu coxu@redhat.com wrote:
Signed-off-by: Coiby Xu coxu@redhat.com
kdumpctl.8 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kdumpctl.8 b/kdumpctl.8 index 067117b..1a2ae8f 100644 --- a/kdumpctl.8 +++ b/kdumpctl.8 @@ -50,6 +50,9 @@ Estimate a suitable crashkernel value for current machine. This is a best-effort estimate. It will print a recommanded crashkernel value
while you are at it ;)
s/recommanded/recommended/
based on current kdump setup, and list some details of memory usage. .TP +.I get-default-crashkernel +Return the default crashkernel value provided by kexec-tools.
How about:
Print the default crashkernel value used by kexec-tools. Useful when setting the crashkernel value manually, e.g. via grubby.
Thanks Philipp
+.TP .I reset-crashkernel [--kernel=path_to_kernel] [--reboot] Reset crashkernel to default value recommended by kexec-tools. If no kernel is specified, will reset KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
Hi Philipp,
On Mon, Mar 28, 2022 at 01:59:40PM +0200, Philipp Rudo wrote:
Hi Coiby,
On Tue, 1 Mar 2022 17:40:00 +0800 Coiby Xu coxu@redhat.com wrote:
Signed-off-by: Coiby Xu coxu@redhat.com
kdumpctl.8 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kdumpctl.8 b/kdumpctl.8 index 067117b..1a2ae8f 100644 --- a/kdumpctl.8 +++ b/kdumpctl.8 @@ -50,6 +50,9 @@ Estimate a suitable crashkernel value for current machine. This is a best-effort estimate. It will print a recommanded crashkernel value
while you are at it ;)
s/recommanded/recommended/
Thanks for catching the typo!
based on current kdump setup, and list some details of memory usage. .TP +.I get-default-crashkernel +Return the default crashkernel value provided by kexec-tools.
How about:
Print the default crashkernel value used by kexec-tools. Useful when setting the crashkernel value manually, e.g. via grubby.
Thanks for the suggestion! I'd like to suggest a small change. How about:
Print the default crashkernel value used by kexec-tools. Useful as a reference when setting the crashkernel value manually, e.g. via grubby.
Thanks Philipp
+.TP .I reset-crashkernel [--kernel=path_to_kernel] [--reboot] Reset crashkernel to default value recommended by kexec-tools. If no kernel is specified, will reset KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
Hi Coiby,
On Sat, 2 Apr 2022 18:14:24 +0800 Coiby Xu coxu@redhat.com wrote:
Hi Philipp,
On Mon, Mar 28, 2022 at 01:59:40PM +0200, Philipp Rudo wrote:
Hi Coiby,
On Tue, 1 Mar 2022 17:40:00 +0800 Coiby Xu coxu@redhat.com wrote:
Signed-off-by: Coiby Xu coxu@redhat.com
kdumpctl.8 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kdumpctl.8 b/kdumpctl.8 index 067117b..1a2ae8f 100644 --- a/kdumpctl.8 +++ b/kdumpctl.8 @@ -50,6 +50,9 @@ Estimate a suitable crashkernel value for current machine. This is a best-effort estimate. It will print a recommanded crashkernel value
while you are at it ;)
s/recommanded/recommended/
Thanks for catching the typo!
based on current kdump setup, and list some details of memory usage. .TP +.I get-default-crashkernel +Return the default crashkernel value provided by kexec-tools.
How about:
Print the default crashkernel value used by kexec-tools. Useful when setting the crashkernel value manually, e.g. via grubby.
Thanks for the suggestion! I'd like to suggest a small change. How about:
Print the default crashkernel value used by kexec-tools. Useful as a reference when setting the crashkernel value manually, e.g. via grubby.
When I made this suggestion I had mind that in crashkernel-howto.txt under "Reset manually" there is the suggestion to run
grubby --update-kernel ALL --args "crashkernel=$(kdumpctl get-default-crashkernel)"
But your suggestion is fine, too.
Thanks Philipp
Thanks Philipp
+.TP .I reset-crashkernel [--kernel=path_to_kernel] [--reboot] Reset crashkernel to default value recommended by kexec-tools. If no kernel is specified, will reset KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
Hi Coiby,
On Tue, 1 Mar 2022 17:39:57 +0800 Coiby Xu coxu@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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.
-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
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@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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, - 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.
-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.
+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.
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?
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
Hi Coiby,
On Sat, 2 Apr 2022 18:07:09 +0800 Coiby Xu coxu@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@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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
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@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@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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.
Hi Coiby,
On Wed, 6 Apr 2022 09:37:05 +0800 Coiby Xu coxu@redhat.com wrote:
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@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@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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:)
Thanks!
-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.
Yes, It's probably better to add a short comment...
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.
Right... I now see where my problem was. Simply cloned the repo and ran kdumpctl from there to set the new value. But when updating the kernel the old 92-crashkernel.install was called...
Sorry for the noise...
Thanks Philipp
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.
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@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@redhat.com wrote:
- yum is deprecated so use dnf instead
- use the "kdumpctl reset-crashkernel" API
Signed-off-by: Coiby Xu coxu@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 ;-)
I just notice this file has the following paragraphs in the later section,
Once back to your normal kernel, you can use the previously installed crash kernel in conjunction with the previously installed kernel-debuginfo to perform postmortem analysis:
# crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux /var/crash/2006-08-23-15:34/vmcore
crash> bt
So I guess we need to keep the info of installing kernel-debuginfo.
-
Coiby Xu -
Philipp Rudo