Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is made dump capture capable breaking fadump's able to capture dump properly. Fix this by sticking with the debug variant in case of fadump.
Fixes: c5bdd2d8f195 ("kdump-lib: use non-debug kernels first") Signed-off-by: Hari Bathini hbathini@linux.ibm.com --- kdump-lib.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index f7b659e..6d081a8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -680,7 +680,13 @@ prepare_kdump_bootinfo()
if [[ -z $KDUMP_KERNELVER ]]; then KDUMP_KERNELVER=$(uname -r) - nondebug_kernelver=$(sed -n -e 's/(.*)+debug$/\1/p' <<< "$KDUMP_KERNELVER") + + # Fadump uses the regular bootloader, unlike kdump. So, use the same version + # for default kernel and capture kernel unless specified explicitly with + # KDUMP_KERNELVER option. + if ! is_fadump_capable; then + nondebug_kernelver=$(sed -n -e 's/(.*)+debug$/\1/p' <<< "$KDUMP_KERNELVER") + fi fi
# Use nondebug kernel if possible, because debug kernel will consume more memory and may oom.
On 16/09/22 7:07 pm, Hari Bathini wrote:
Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is
made dump capture capable breaking fadump's able to capture dump
It should have read:
"dump capture capable, breaking fadump's ability"
instead of
"dump capture capable breaking fadump's able".
properly. Fix this by sticking with the debug variant in case of fadump.
Fixes: c5bdd2d8f195 ("kdump-lib: use non-debug kernels first") Signed-off-by: Hari Bathini hbathini@linux.ibm.com
kdump-lib.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index f7b659e..6d081a8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -680,7 +680,13 @@ prepare_kdump_bootinfo()
if [[ -z $KDUMP_KERNELVER ]]; then KDUMP_KERNELVER=$(uname -r)
nondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")
# Fadump uses the regular bootloader, unlike kdump. So, use the same version# for default kernel and capture kernel unless specified explicitly with# KDUMP_KERNELVER option.if ! is_fadump_capable; thennondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")fifi
# Use nondebug kernel if possible, because debug kernel will consume more memory and may oom.
Acked-by: Lichen Liu lichliu@redhat.com
On Fri, Sep 16, 2022 at 9:37 PM Hari Bathini hbathini@linux.ibm.com wrote:
Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is made dump capture capable breaking fadump's able to capture dump properly. Fix this by sticking with the debug variant in case of fadump.
Fixes: c5bdd2d8f195 ("kdump-lib: use non-debug kernels first") Signed-off-by: Hari Bathini hbathini@linux.ibm.com
kdump-lib.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index f7b659e..6d081a8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -680,7 +680,13 @@ prepare_kdump_bootinfo()
if [[ -z $KDUMP_KERNELVER ]]; then KDUMP_KERNELVER=$(uname -r)
nondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")
# Fadump uses the regular bootloader, unlike kdump. So, use the same version# for default kernel and capture kernel unless specified explicitly with# KDUMP_KERNELVER option.if ! is_fadump_capable; thennondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")fi fi # Use nondebug kernel if possible, because debug kernel will consume more memory and may oom.-- 2.37.3 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi Hari,
On Fri, Sep 16, 2022 at 07:07:24PM +0530, Hari Bathini wrote:
Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is made dump capture capable breaking fadump's able to capture dump properly. Fix this by sticking with the debug variant in case of fadump.
If I understand the commit message correctly, the problem is for fadump, the dump capture kernel is a debug kernel but the initrd matches a normal kernel.
My only concern if the default crashkernel value for fadump i.e. 4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G works for debug kernel on POWER machines especially the virtual machines that may have smaller system memory. If there is OOM issue, we need to fix this mismatch between fadump kernel and initrd in a different way, for example, instructs fadump to load the normal kernel instead.
Fixes: c5bdd2d8f195 ("kdump-lib: use non-debug kernels first") Signed-off-by: Hari Bathini hbathini@linux.ibm.com
kdump-lib.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh index f7b659e..6d081a8 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -680,7 +680,13 @@ prepare_kdump_bootinfo()
if [[ -z $KDUMP_KERNELVER ]]; then KDUMP_KERNELVER=$(uname -r)
nondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")
# Fadump uses the regular bootloader, unlike kdump. So, use the same version# for default kernel and capture kernel unless specified explicitly with# KDUMP_KERNELVER option.if ! is_fadump_capable; thennondebug_kernelver=$(sed -n -e 's/\(.*\)+debug$/\1/p' <<< "$KDUMP_KERNELVER")fifi
# Use nondebug kernel if possible, because debug kernel will consume more memory and may oom.
-- 2.37.3 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 21/09/22 10:09 am, Coiby Xu wrote:
Hi Hari,
On Fri, Sep 16, 2022 at 07:07:24PM +0530, Hari Bathini wrote:
Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is made dump capture capable breaking fadump's able to capture dump properly. Fix this by sticking with the debug variant in case of fadump.
If I understand the commit message correctly, the problem is for fadump, the dump capture kernel is a debug kernel but the initrd matches a normal kernel. My only concern if the default crashkernel value for fadump i.e. 4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G works for debug kernel on POWER machines especially the virtual machines that may have smaller system memory. If there is OOM issue, we need to fix this mismatch between fadump kernel and initrd in a different way, for example, instructs fadump to load the normal kernel instead.
Unlike kdump, there is no such thing as loading the kernel for fadump. On crash, system goes through the grub bootloader. So, the kernel that is the default boot entry in the grub bootloader is booted. So, fadump works with the assumption that the default boot entry is configured with fadump (be it debug variant or the regular one). As for the OOM issues, the existing warning ("Using debug kernel, you may need to set a larger crashkernel than the default value.") in kdumpctl should be sufficient?
Thanks Hari
On Wed, Sep 21, 2022 at 12:45:15PM +0530, Hari Bathini wrote:
On 21/09/22 10:09 am, Coiby Xu wrote:
Hi Hari,
On Fri, Sep 16, 2022 at 07:07:24PM +0530, Hari Bathini wrote:
Since commit c5bdd2d8f195 ("kdump-lib: use non-debug kernels first"), non-debug kernel is preferred, over the debug variant, as dump capture kernel to reduce memory consumption. This works alright for kdump as the capture kernel is loaded using kexec.
In case of fadump, regular boot loader is used to load the capture kernel. So, the default kernel needs to be used as capture kernel as well. But with commit c5bdd2d8f195, initrd of a different kernel is made dump capture capable breaking fadump's able to capture dump properly. Fix this by sticking with the debug variant in case of fadump.
If I understand the commit message correctly, the problem is for fadump, the dump capture kernel is a debug kernel but the initrd matches a normal kernel. My only concern if the default crashkernel value for fadump i.e. 4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G works for debug kernel on POWER machines especially the virtual machines that may have smaller system memory. If there is OOM issue, we need to fix this mismatch between fadump kernel and initrd in a different way, for example, instructs fadump to load the normal kernel instead.
Unlike kdump, there is no such thing as loading the kernel for fadump. On crash, system goes through the grub bootloader. So, the kernel that is the default boot entry in the grub bootloader is booted. So, fadump works with the assumption that the default boot entry is configured with fadump (be it debug variant or the regular one).
Thanks for the explanation!
As for the OOM issues, the existing warning ("Using debug kernel, you may need to set a larger crashkernel than the default value.") in kdumpctl should be sufficient?
Thanks to Xiaoying who have confirmed no OOM issue is observed for crashkernel=768M for debug kernel. So my concern is not a valid one.
I've merged the patch. Thanks!
Thanks Hari
-
Coiby Xu -
Hari Bathini -
Lichen Liu