1 |
On Sat, Oct 19, 2013 at 6:01 PM, Mark Knecht <markknecht@×××××.com> wrote: |
2 |
> No magic sys request keys, keyboard and |
3 |
> mouse are dead, cannot shell in or even ping from another machine on |
4 |
> the network. |
5 |
|
6 |
These types of situations are really annoying to debug. Do you get |
7 |
anything on the console? Try leaving at a text console with no screen |
8 |
saver so that you have a chance to see any panic message/etc that |
9 |
might be left there. If you have something set to put your monitor to |
10 |
sleep then after the panic your system will not wake up. |
11 |
|
12 |
Serial console is another option, albeit not exactly convenient. |
13 |
|
14 |
I have on my blog somewhere instructions for setting up kdump, but to |
15 |
be honest with recent kernel versions it hasn't been working (that |
16 |
could have changed). You can configure your kernel to auto-reboot to |
17 |
a panic kernel which you can then use to dump core to disk, then you |
18 |
can reboot back into your normal system to examine it at your leisure. |
19 |
That should tell you what was going on when it crashed, but only if |
20 |
the kernel actually detected a panic (usually it does). |
21 |
|
22 |
Note that logs are useless in a panic (unless you're using kdump) as |
23 |
the kernel will not write anything to disk following a panic. If you |
24 |
get an oops/bug you might or might not get anything in your logs |
25 |
depending on whether it affected the filesystem/disk/etc subsystems. |
26 |
If the kernel knows its internals are scrambled the last thing you |
27 |
want it doing is trying to write to your filesystems. With kdump it |
28 |
does a reboot into a new kernel which fully re-initializes everything |
29 |
and then dumps ram safely to disk. |
30 |
|
31 |
Rich |