Take the 2-minute tour ×
Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. It's 100% free, no registration required.

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!

share|improve this question
    
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). –  Ryan Conrad Jul 19 '12 at 19:26
    
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). –  9exceptionThrower9 Jul 20 '12 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. –  Ryan Conrad Jul 20 '12 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... –  9exceptionThrower9 Jul 20 '12 at 15:36
add comment

1 Answer

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!

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 [ <option> ] <command>

commands:
  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

options:
  -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!)

As always, proceed with caution and double check on the switches used on the command line, very easy to mess up the boot-loader as in sudo fastboot flash boot recovery.img, then that's your boot-loader hosed.

So 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

share|improve this answer
    
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? –  9exceptionThrower9 Jul 20 '12 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 Jul 20 '12 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 Jul 20 '12 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 Jul 20 '12 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... –  9exceptionThrower9 Jul 20 '12 at 15:33
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.