From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; rv:1.7.3) Gecko/20041014 Firefox/0.10.1 Description of problem: I have all my servers' serial consoles connected to one machine with many serial ports, where I can access them via minicom. I also have watchdog modules configured on servers to autoreboot them in case of problems. Every now and then some server goes down with an oops. My idea for this serial console setup was simplified oops capturing, but there's a problem: when watchdog reboots the server, bios actually redraws the whole screen, deleting all the oops info. So I was thinking ... Could it be possible to add a simple loop to the oops printing function that would print a number of newlines after the oops info, where number would be taken as a kernel boot line parameter? So that bios would redraw over already blank screen and I could just scroll minicom buffer up to get the oops. Version-Release number of selected component (if applicable): any kernel How reproducible: Always Steps to Reproduce: 1. set up a server with console on serial port and watchdog timer to reboot it 2. make someting to oops it 3. watch the console in minicom and observe bios overwriting oops data Additional info: I don't know if this can be acomplished with some minicom setting or possibly with using something else than minicom for serial terminal. If it is, I'd like to know how to do it. Afterall, I'd like to see where my machines are oopsing and figure out why.
Internal RFE bug #149115 entered; will be considered for future releases.
Hello, Jure. Could you simply use minicom's "capture" mechanism to log all of the console output into a file? To begin capturing, go into the "Minicom Command Summary" menu with CTRL-A Z, then type L and provide a file name for logging. Please let me know if this satisfies your request. Thanks.
Thanks for the suggestion. I've enabled capturing in my minicoms. Will report back with results when new oops happens.
Closing under the assumption that minicom feature suffices.
*** Bug 149115 has been marked as a duplicate of this bug. ***