I am trying to figure out if Android (i.e. Galaxy Nexus, Nexus S, and/or Motorola Xoom) come with some sort of capability to produce a "boot-up" log. (kind of like Linux boot-up screen) It would be immensely helpful in figuring out how far one's phone gets in the boot stages before it crashes (such as first-stage bootloader, main bootloader, then kernel loading, etc.). Does anyone know how to enable the phone to spit out this log file or enable a "verbose" boot-up mode (and print actual messages to the terminal of the Linux computer you have the phone connected to)?

My phone gets stuck in a "boot-loop" with my current modified build and I would like to debug it if possible.

Alternatively, anyone know of any useful resources or tutorials that explain how to easily "hack" the phone to do this (no messing with the hardware)? Or of any forums where my question may have been asked but in a more obscure form?

This has been a frustrating problem of recent, so any help would be greatly appreciated!

  • i know it starts writing to the logcat very early on, but that is cleared once it reboots. it should start writing as soon as it shows the "boot animation" (or maybe even a little sooner). Commented Jul 19, 2012 at 19:26
  • 3
    how would you access logcat without "adb"? Adb only works when the phone is in a stable state, which contradicts the whole point I guess as to why logcat exists (who cares if the phone successfully boots, not much need for the tool). Commented Jul 20, 2012 at 14:34
  • adb is one of the first services that start. if you see the boot animation, adb is already running. adb is even available when you are in recovery mode. Commented Jul 20, 2012 at 14:58
  • Well, I'm not sure I'm seeing the boot animation you're talking about. After the battery "charge" symbol, the phone hangs at the splashscreen with "Google" in white on it before it crashes. No "Android" splashscreen after that, or any boot animation. So I don't think ADB works yet... Commented Jul 20, 2012 at 15:36

3 Answers 3


There's a couple of ways to do this:

  • cat /proc/last_kmsg > /sdcard/last_kernel_message_log.txt
  • dmesg > /sdcard/kernel_boot_log.txt
  • plug in the usb cable with the smart-phone switched off. Then issue the command adb logcat from your Windows cmd or Linux terminal, it will hang waiting for the device to come on-line, now power up the smart-phone. The logcat should start scrolling off then.

Since you expressed interest in figuring out how far one's phone gets in the boot stages before it crashes, those methods should help. The thing is you need to be pretty quick to grab the kernel's log (the first two methods shown above).

What I would do is this, on my Arch Linux box, two terminal windows, one for the adb logcat, the other, to grab the log the minute logcat starts scrolling off!


BE aware, there are differences with using adb and fastboot!

fastboot works differently, it is only used for flashing images into specified partitions, and is more tied in with the boot-loader process, i.e, it can understand the boot-loader mechanism. It also requires that:

  • under Windows, 'Administrator' privilege to execute it
  • under Linux, 'root' privilege

The reason it requires it is because it bypasses certain input/output of the hardware, and thus, does not "talk" in adb protocol, rather, it is to "talk" directly to the boot-loader. Something that cannot be done as a normal user. Here is the help for the usage of fastboot.

$ sudo fastboot
usage: fastboot [ <option> ] <command>

  update <filename>                        reflash device from update.zip
  flashall                                 flash boot + recovery + system
  flash <partition> [ <filename> ]         write a file to a flash partition
  erase <partition>                        erase a flash partition
  getvar <variable>                        display a bootloader variable
  boot <kernel> [ <ramdisk> ]              download and boot kernel
  flash:raw boot <kernel> [ <ramdisk> ]    create bootimage and flash it
  devices                                  list all connected devices
  continue                                 continue with autoboot
  reboot                                   reboot device normally
  reboot-bootloader                        reboot device into bootloader
  help                                     show this help message

  -w                                       erase userdata and cache
  -s <serial number>                       specify device serial number
  -p <product>                             specify product name
  -c <cmdline>                             override kernel commandline
  -i <vendor id>                           specify a custom USB vendor id
  -b <base_addr>                           specify a custom kernel base address
  -n <page size>                           specify the nand page size. default: 2048

A well known-usage of fastboot is for flashing for example, to flash a recovery image: sudo fastboot flash recovery recovery.img, another is to directly flash a raw image, sudo fastboot flash system system.img. For more of for the case of kernel development, using this fastboot boot new_kernel, this temporarily downloads a new kernel and boot using that without touching the boot-loader's own boot.

There is also a limitation on the size of a raw image that requires to be flashed, when I say raw image, I am referring to a file that has a .img extension, the image must not exceed 128Mb. (I found out this when developing ics4blade, after the build completed, the system.img was 162Mb, and I tried to flash it but fastboot refused! To circumvent the limitation, had to create a CWM flashable zip file to do that and get around it!)

Practice caution and ensure the partition is correct and double-check and double-check again, if necessary, walk away from the computer, take a break, come back again, and double-check again, this is where it can go horribly wrong, flash the wrong file into the wrong partition... well shrugs

  • 4
    This is a great idea, but one problem....adb only works if the adb daemon can detect the device. If the phone hasn't booted up successfully, adb doesn't work. So a "boot-loop", when you would need logcat the most wouldn't work, and it isn't at the moment as I try it. The only thing you have access to command-wise that doesn't care if the phone has booted successfully is "fastboot". What's an alternative in this case then? Commented Jul 20, 2012 at 14:28
  • @9exceptionThrower9 have edited my answer to include the concept of fastboot and to answer in your comment, fastboot won't work :)
    – t0mm13b
    Commented Jul 20, 2012 at 14:48
  • The only alternative that I can think of is, to fastboot erase the cache and data partition - I am not responsible for anything untoward if you proceed! And try flashing the ROM again through CWM. Even better, forget about fastboot and use CWM to wipe both cache and data, it sounds like the bootloop is due to a borked cache or data...
    – t0mm13b
    Commented Jul 20, 2012 at 14:50
  • As matter of interest, what exactly did you do to get it to bootloop - that is a crucial question and would like to know what steps you took?
    – t0mm13b
    Commented Jul 20, 2012 at 14:55
  • I modified the Android kernel (maguro) for Galaxy Nexus, particularly the "socket.h" file to override INET registration with my team's research project FINS (which pulls out internet protocols into userspace for network researchers). After modifying this file (only few lines), I recompiled the kernel successfully, inserted this kernel into the Android maguro build tree, rebuilt the Android system image, and then flashed the new recovery, boot, system, and userdata.img files into the phone... Commented Jul 20, 2012 at 15:33

You can use LiveBoot. It's in the Google Play Store. It will do just what you are asking.


You can go into recovery on that screen it allows you to access a few log files which you cant access once the phone boots. What your trying to troubleshoot will be in these pre boot logs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .