Reading kernel logs

To find out what happened during an unsuccessful boot you can check the kernel log files. These can usually be retrieved after rebooting the device into another, working system. Generally, your recovery image will be the “working system”.

Linux kernel <=3.4

Until Kernel 3.4, Android developers created a driver that the Linux kernel may use to store its kernel message buffer in a special persistent location in RAM. This information is preserved over a reboot but not a hard power cycle (such as holding the power button or powering off). This location is preserved to the system in /proc/last_kmsg

To use last_kmsg to debug problems in your port, do the following:

  1. Boot your newly built image
  2. Wait for it to fail
  3. Reboot the device into a working system.
  4. Retrieve the kernel log with adb shell cat /proc/last_kmsg > ~/last_kmsg
  5. Read ~/last_kmsg and find out what went wrong

If you aren’t able to find these files, ensure that the following configs are set in your kernel config:

CONFIG_ANDROID_RAM_CONSOLE=y
CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y

Linux Kernel >3.4

After Kernel 3.4, most Android vendors have used the upstream pstore and ramoops drivers to store kernel logs after a panic.

You can get these logs by following these steps:

  1. Boot your newly built image
  2. Wait for it to fail
  3. Reboot the device into a working system.
  4. Find and retrieve the logs from /sys/fs/pstore/console-ramoops. The file may be named slightly differently, but will be in this directory.

If you aren’t able to find these files, ensure that the following configs are set in your kernel config:

CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_RAM=y

Most devices require that the kernel panics in order to offer these logs. You can cause a kernel panic by running these commands as root:

Warning

Yes, these commands really do cause a kernel panic. Don’t run them on your production machine.

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger