Description of problem: kdump console trace preserved with dump. The console trace contains info (such as script output) useful for debugging problems that may occur during kdump processing. This info is not kept with the vmcore and is lost with the reboot. Version-Release number of selected component (if applicable): kexec-tools-1.102pre-21.el5_2.2 How reproducible: Trigger a kdump. Actual results: Dump directory created containing only vmcore. Desired results: Dump directory created containing: - vmcore - console trace of the dump process. Additional info: dmesg can be used in a pre/post script to optain a partial trace. Probably an enhancement. Avoidance: Use kernel command line to echo console to aserial port and use an external device to capture the trace.
(In reply to comment #0) > Description of problem: > kdump console trace preserved with dump. The console trace contains info [...snip...] Of course that should be: kdump console trace *not* preserved with dump...
kdump captures the vmcore, not the log of the capture session. Given that recording of the log is most usefull for debugging of kdump setups, you will nominally have access to a serial console which can log the session independently. If you do want to grab the log from within a kdump session, this can be easily implemented using kdump_post and dmesg.
Unfortunately, it's not quite so easy. A dmesg in the kdump_post doesn't capture everything that's been sent to the console--e.g. command output from the scripts. This could be captured separately but you'd lose the timing interplay with the kernel messages. Also, dmesg gives only the current ring buffer contents. It does not provide the full session. My concern is more with forensic analysis of a failure at a customer site where the serial output is not necessarily collected.