[Nexus 7 Q&A, Help & Troubleshooting] bftb0:
hi aha27,

Sorry about your problem. You are to be commended though, for the preparation and detail you provided in describing your situation - too bad most are not that thorough.

That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.

I looked briefly through one of your dmesg boot logs, and didn't spot anything unusual. The facts that:

(a) you can successfully re-flash stock roms, including file system re-creation

(b) you can run adb shell commands interactively

is evidence that the kernel has no difficulty booting and that perhaps the flash filesystems are all OK too.

What sticks out is your report that the recoveries also do not proceed completely to show their touchscreen interfaces.

Here is something to try

(1) perform soft-boots of the recovery with fastboot, for example:

fastboot boot openrecovery-twrp-2.3.3.0-grouper.img

As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)

Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing

C:\fubar> adb shell logcat > logcat_output.txt

and

C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt

[ If you are using cygwin or linux you can spice this up a little, e.g.

$ adb shell logcat 2>&1 | tee logcat_output.txt

$ adb shell cat /proc/kmsg 2>&1 | tee kernel_log_output.txt

... as both of these block waiting for more output, in the latter case you get to see things happening in real time as well as capturing the output for later analysis ]

(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of

adb shell cat /proc/last_kmsg

(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via

adb shell cat /proc/kmsg

or

adb logcat -v threadtime

Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and

# mkdir /data/property

# chmod 700 /data/property

# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config

# chmod 600 /data/property/persist.sys.usb.config

(4) I also noted your comment about "freezing if I mount /system". Note that when you flash the factory image, /data and /cache are handled differently than /system, even though all 3 are ext4 filesystems. For the first two, the process is "erase, mkfs, write", whereas for /system all you get is a "erase, write". So here is the deal - if a mke2fs filesystem is created, that means for /data and /cache that the bootloader is actually mounting those partitions (as ext4 filesystems) and restoring into them file by file. Otherwise, a "blob"-type write would just overwrite the newly created ext4 filesystem metadata.

/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.

So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.

mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3

If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.

The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.

Whew that was a lot of typing. I think I am done for the day.

bftb0