This bug was fixed in the package kdump-tools - 1:1.10.2ubuntu1
---------------
kdump-tools (1:1.10.2ubuntu1) noble; urgency=medium
* Merge from Debian unstable. Remaining changes:
- Update default s390x crashkernel.
- Install the updated zipl.conf with ucf, so users will be able to
decide whether to pick any crashkernel changes.
- Bump grub default (x86 amd64) crashkernel params to those used on
arm64, ppc64le, s390x.
- Add riscv64 build
kdump-tools (1:1.10.2) unstable; urgency=medium
* debian/tests/crash: Support makedumpfile's flattened format,
which file(1) reports as "Flattened kdump compressed dump" instead
of the "Kdump compressed dump" string we were looking for.
kdump-tools (1:1.10.1) unstable; urgency=medium
* Delete the temporary sysctl files on kernel removal. Thanks to
Guilherme G. Piccoli.
-- dann frazier <da...@ubuntu.com> Thu, 22 Feb 2024 15:39:13 -0700
** Changed in: kdump-tools (Ubuntu Noble)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kdump-tools in Ubuntu.
Matching subscriptions: Maintainer
https://bugs.launchpad.net/bugs/1908090
Title:
kdump-gaps: Default 192MB crashkernel reservation is never enough
(kdump fails on 20.04)
Status in kdump-tools package in Ubuntu:
Fix Released
Status in kdump-tools source package in Focal:
New
Status in kdump-tools source package in Jammy:
New
Status in kdump-tools source package in Mantic:
New
Status in kdump-tools source package in Noble:
Fix Released
Bug description:
When linux-crashdump (5.4.0.58.61) is enabled on Ubuntu 20.04 LTS,
everything appears to be in good working order, according to
"systemctl status kdump-tools" and "kdump-config status". However,
upon an actual crash, the system hangs, and no crash files are
produced. I've investigated and have learned that the capture kernel
does indeed start, but it is unable to unpack the rootfs/initrd, and
thus fails and hangs.
[ 1.070469] Trying to unpack rootfs image as initramfs...
[ 1.333182] swapper/0 invoked oom-killer: gfp_mask=0x100cc2(GFP_HIGHUSER),
order=0, oom_score_adj=0
[ 1.335074] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-26-generic
#30-Ubuntu
[ 1.336396] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 1.336396] Call Trace:
[ 1.336396] dump_stack+0x6d/0x9a
[ 1.336396] dump_header+0x4f/0x1eb
[ 1.336396] out_of_memory.part.0.cold+0x39/0x83
[ 1.336396] out_of_memory+0x6d/0xd0
...
[ 1.413202] ---[ end Kernel panic - not syncing: System is deadlocked on
memory ]---
On this system with 8G of memory, the crash memory as specified on the kernel
command line is "crashkernel=512M-:192M". I changed the 192M to 256M, and now
kdump works.
Not sure how the 192M value is chosen, but it does not work. I think
this used value used to work for 16.04 and maybe 18.04 (I didn't try),
but is no longer useful for 20.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1908090/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
