LWN: Comments on "Crash dumps with kexec" https://lwn.net/Articles/108595/ This is a special feed containing comments posted to the individual LWN article titled "Crash dumps with kexec". en-us Sun, 05 Oct 2025 20:52:08 +0000 Sun, 05 Oct 2025 20:52:08 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Crash dumps with kexec https://lwn.net/Articles/109056/ https://lwn.net/Articles/109056/ brouhaha <blockquote> I don't think crach dump to net is much better than any other kind: a corrupt kernel can still corrupt your data. </blockquote> I strongly disagree. If the crashdump code doesn't even TRY to access your disk drives, it's not very likely to corrupt the filesystems thereon. Of course, the crash that lead to the invocation of the crashdump might already have done that, but you can't blame that on the crashdump code. Sun, 31 Oct 2004 00:33:48 +0000 Crash dumps with kexec https://lwn.net/Articles/108935/ https://lwn.net/Articles/108935/ amh I don't think crach dump to net is much better than any other kind: a corrupt kernel can still corrupt your data.<br> <p> You might try a watchdog timer (even a card) to help with your system problem. There are various drivers for them. And I guess a kernel dump could well help afterwards.<br> Fri, 29 Oct 2004 16:48:06 +0000 FC2 already has netdump (and netconsole) functionality https://lwn.net/Articles/108896/ https://lwn.net/Articles/108896/ mcatkins Ah. That's the touble with good ideas - someone else has<br> usually had them first!<br> <p> Thanks for letting me know!<br> <p> Martin<br> Fri, 29 Oct 2004 11:41:46 +0000 FC2 already has netdump (and netconsole) functionality https://lwn.net/Articles/108793/ https://lwn.net/Articles/108793/ epithumia Fedora Core 2 includes network crash dumping and a network console. See /etc/sysconfig/netdump and "service netdump".<br> Thu, 28 Oct 2004 18:46:00 +0000 Crash dumps with kexec https://lwn.net/Articles/108654/ https://lwn.net/Articles/108654/ NRArnot Crash dump to net is a good idea - much safer than writing with what might be corrupt software onto what might be a failing disk with valuable and retrievable data on it. Absolute worst it could do is a DoS on your network, and a faulty network card can do that anyway. <br> <p> You don't need a full IP network stack to dump over the network. You need just enough to accomplish reliable 2-way communication with a crash dump receiver across a LAN - a "packet driver" for the network hardware plus a minimal protocol for handshaking with the receiver.<br> <p> This wouldn't be much baggage to carry with a crash-dump kernel, though it would have to be configured for a particular network card (by the normal kernel at normal kernel boot time? )<br> <p> BTW - I'm currently trying to work out what is wrong with a system that wedges hard at rare intervals, with an MTBF of about a fortnight. Crash dump would help only if there was a way to get a crash dump out of a system that appears to be responsive only to the reset switch (though maybe it's still doing something with keyboard interrupts, no way I can tell). Yes, it's probably a hardware fault (the same kernel doesn't do this on other very similar systems) - but a dump might point at what hardware. Nothing else does.<br> Thu, 28 Oct 2004 11:45:39 +0000 Crash dumps with kexec https://lwn.net/Articles/108646/ https://lwn.net/Articles/108646/ mcatkins I'd never thought much about this issue before reading this article, but<br> a thought occured when I did: rather than trying to save a crash dump<br> to a disk file, why not send it over a network to a crash dump server<br> on another (i.e., not currently not crashing!) machine?<br> <p> Thus the local disks need not be touched - one would need to have a<br> working network stack though (doesn't the console logging over-the-network<br> stuff have some useful stuff for this purpose?).<br> <p> The result might be small/safe enough to be in the main kernel, and hence<br> not require all that crash-kernel memory!<br> <p> Just a thought!<br> <p> Martin<br> Thu, 28 Oct 2004 09:51:04 +0000