Android boot-up messages for debugging? 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!
There's a couple of ways to do this:


cat /proc/last_kmsg &gt; /sdcard/last_kernel_message_log.txt
dmesg &gt; /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!

Edit:

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 [ &lt;option&gt; ] &lt;command&gt;

commands:
  update &lt;filename&gt;                        reflash device from update.zip
  flashall                                 flash boot + recovery + system
  flash &lt;partition&gt; [ &lt;filename&gt; ]         write a file to a flash partition
  erase &lt;partition&gt;                        erase a flash partition
  getvar &lt;variable&gt;                        display a bootloader variable
  boot &lt;kernel&gt; [ &lt;ramdisk&gt; ]              download and boot kernel
  flash:raw boot &lt;kernel&gt; [ &lt;ramdisk&gt; ]    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

options:
  -w                                       erase userdata and cache
  -s &lt;serial number&gt;                       specify device serial number
  -p &lt;product&gt;                             specify product name
  -c &lt;cmdline&gt;                             override kernel commandline
  -i &lt;vendor id&gt;                           specify a custom USB vendor id
  -b &lt;base_addr&gt;                           specify a custom kernel base address
  -n &lt;page size&gt;                           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