- Before filing any bug reports or support requests, please clean with a can of air, and visually review all the hardware for any failures (ex. expanding or popped capacitors).
Please perform a MemoryTest.
- If the memory test passed, it is vital to capture a log of this crash (kernel call trace, xorg backtrace, etc.) in order to fix the problem. Below are some useful techniques in capturing useful crash information.
If your system crashes when a particular action occurs, and this is repeatable every time, try to reproduce the crash on a text console (Control+Alt+F1) if possible. If the crash occurs during startup, select the recovery mode option to disable the splash screen.
When the crash occurs, press Alt+SysRq+1 (one, not L) followed by Alt+SysRq+t. If using a text console, you should see a trace dumped to the screen. If the system is sufficiently alive, it will also be logged to /var/log/kern.log and visible in the output from dmesg. This information shows where the crash occurred, and should be included in any problem reports. If the output is not saved in any file, or the system is so bad off that you cannot retrieve it, you can either take a digital photo, or hand write the results. Almost all of the output is important (so please don't copy the one line you think is important, because context means everything).
For a full list of Alt+SysRq options, see the kernel documentation.
- If unable to log the full backtrace, supply a digital photo of the screen to capture the crash. It most important to capture the beginning of the kernel oops or panic.
If a kernel crash completely locks the system, take a look at https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe.
If using linux-crashdump (above) is not successful try and see if any backtrace was logged to one of the kern.log files according to their time stamp (ex. /var/log/kern.log). Please attach this file if anything was captured.
Some crashes, in particular those involving the X server, are impossible to reproduce on the text console. The best way is then to use a second computer from which you can log in to the "sick" machine using ssh.
- On the "sick" machine, install openssh-server (make sure you have good passwords on all user accounts if your machine is connected to the Internet).
- On the second machine, install openssh-client. If this is a Windows machine, install Putty, a free SSH client. If it is a MacOSX machine, it already has the ssh client installed.
Find the IP address of the sick machine, for instance by running ip addr. If both machines are running Ubuntu 7.04 or MacOSX, you can use the machine name (e.g. mycomputer.local) instead of the IP address.
Connect to the sick machine, for instance ssh firstname.lastname@example.org
Inside the ssh session, run sudo cat /proc/kmsg
Optionally start a second ssh session to run for instance tail -f /var/log/syslog or other commands. You can emulate the above SysRq key presses, for instance the Alt+SysRq+t combination, by running echo t | sudo tee /proc/sysrq-trigger
- Reproduce the crash
- Watch any error messages in the ssh client window on the second machine, and save them to a file that you attach to the bug report.
If the above doesn't work, one may use Netconsole.
In X window mode
Sometimes crashes occur in X, and so terminal access is not available (to capture the kernel backtrace). When this occurs, the user should try to recreate the crash at the console (Ctrl+Alt+F1). If this is not possible, then annotate the bug as such.
If the X server crashes (you're thrown back to the login screen, or screen goes black or frozen but there is activity "below") see DebuggingXorg. See DebuggingProgramCrash if just a program and not the whole system is crashing.