[Nexus 7 Q&A, Help & Troubleshooting] bftb0:
Well, I have a couple of hypotheses.

I guess I should ask one more question - is it correct that in TWRP you see none of your backups in /sdcard (TWRP mounts /sdcard on when it starts up) ?

If you have anything left on the SD card you want saved, get it backed up to your PC with "adb pull" before proceeding any further. (All suggestions below assume you have nothing left to save anywhere in /data.)

Also, I note that my N7 discharges slowly when plugged into my computer but sitting at the TWRP screen - so get your nexus fully charged before going any further.

The fact that you can boot TWRP means that the bootloader can find your recovery image, so at a minimum that means the bootloader can still understand some of the partitioning information it has available.

It is possible that the initial problem you had was something as simple as a corruption of a ext4 file system involving /cache, /system, or /data - as they need to be mounted after the early boot (ramdisk) initialization has more or less finished up. If they can not be mounted, the late boot processes never occur. Looking at your subsequent problems with unlocking the bootloader indicate a problem with the /cache partition - maybe?

[ The re-locking of the bootloader is odd, though. It suggests something got erased or mangled in a partition of the flash RAM that normally does not get mounted or touched by any of the usual kernel boots (whether we are talking about a recovery boot or any other android kernel boot). That means something other than /system, /cache, or /data - probably misc1, misc2, mfg, or possibly somewhere else (like slack space at the ends of either the boot or recovery partitions, or even in hard-coded location. ]

What happens if you try to rebuild the ext4 filesystems on /cache, /system, and /data?

[ note the partitions below are for the grouper N7 device; do a "adb shell cat /etc/fstab" to see if there are differences if you are on tilapia (3G version of the Nexus 7) ]

C:\foo> adb shell

# umount /data

# umount /cache

# umount /sdcard

# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p4

# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p3

# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p9

Does this succeed or fail? If it fails, what about first trying

# /sbin/erase_image /dev/block/mmcblk0p??? ( substitute correct # for ???)

prior to the mke2fs operation?

If you can get them to succeed, you might try restoring a backup (adb push to your "SD card"), and then doing a restore from TWRP and see if you can get it to boot.

You may also want to get your misc1 and misc2 partitions backed up - they contain the partitioning information (and usually the android "boot communication block), and they are generally identical (down to the last byte):

C:\foo> adb shell

# mount /sdcard (if this fails then you can't do this obviously)

# dd if=/dev/block/mmcblk0p5 of=/sdcard/part5.img bs=4096

# dd if=/dev/block/mmcblk0p8 of=/sdcard/part8.img bs=4096

# exit

C:\foo> adb pull /sdcard/part5.img

C:\foo> adb pull /sdcard/part8.img

If one of misc1 or misc2 got corrupted - and that is what is confusing the bootloader - it should be possible to flash the bad one with the good spare - but let's leave that alone until we see if /cache, /data, and /system can be re-initialized.

I'll come back to this thread in 8 hours or so - time for bed for me.