Reasinable time for a kernel crash dump?

Ask Fedora
,
1

Running F39 6.10.3-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC on a 16GB system. I’ve tried triggering a kernel crash by echoing “c” to //proc/sysrq-triggers. This immediately crashes the kernel, but after waiting 20 min and then doing a power cycle all I get is the dmesg file in /var/crash. I don’t remember “real” kernel dumps taking quite so long the last time I tried to debug something; they would get written out in 2 or 3 min or less. Do I just need to wait longer?

The dmesg file is probably sufficient - I have a Ryzen based Beelink and it has started to spontaneously reboot right at the “start malfunctioning the week after warrantly expires” time. OTOH there have been a lot of issues lately with google chrome (my reboots generally happen when I am using it) and with amdgpu.

FWIW the results of a google search with “enable fedora kernel crash dump” return results for CoreOS, using ignotion, ostree, etc, which is fine for a CoreOS container but probably not what a desktop user is looking for. The doc “How to use kdump to debug kernel crashes” (How to use kdump to debug kernel crashes - Fedora Project Wiki) by ust enabling the kdump service and using kdumpctl is somewhat hard to find, you can locate it at the bottom of the CoreOS link.

2

I’ve never used it, but I see that /etc/kdump.conf has an option to write the core dump to a “raw” device. I might try pointing that at a USB drive with a flashing LED activity indicator so that I could get a visual indication when the dump has started and when it is finished.

1 Like
3

I still have not managed to get a “manual” crash to produce more than a dmesg file, even when waiting more than 20 minutes. So the lack of a dump file is something else.

The actual bug hanging my system was an issue with Google Chrome. I switched to Edge for Linux and the problem went away. Firefox was probably an option as well.