[Nexus 7 Q&A, Help & Troubleshooting] bftb0:
[MENTION=1691355]Punchlinegott[/MENTION]

The fact that /dev/block/mmcblk0p9 (/data) is not mounted is not normal for TWRP 2.5.0.0. Typically it does that automatically when it boots. This *might* mean that /data was corrupted, but the "read tests" you performed are extremely unusual; there is no reason that (under normal circumstances) that your tablet should spontaneously shut down while doing only reads from the flash chip.

(BTW, TWRP shows the battery charge percentage right on the top of the screen - your battery is well charged, is it not?)

First, I should note that TWRP 2.5.0.0 does screen blanking with a timeout of about 60 seconds; you just touch the screen to get it to unblank. That is not what you meant by

is it?

(You can get the screen to wake up in TWRP simply by touching it; it will display a lock image and tell you "swipe to unlock"). Please clarify this point to be sure: was your tablet really powering off, or did you mistake the blank screen for a powered-off condition?

In any event, the partition read ("dd") operations that I recommended as a test shouldn't take very long for the smaller partitions - fractions of a second for everything but APP, CAC, and UDA For example, here's mine (I soft-booted TWRP 2.5.0.0)

APP: 681574400 bytes (650.0MB) copied, 19.229674 seconds, 33.8MB/s
CAC 464519168 bytes (443.0MB) copied, 13.088077 seconds, 33.8MB/s
LNX 8388608 bytes (8.0MB) copied, 0.251189 seconds, 31.8MB/s
MDA 524288 bytes (512.0KB) copied, 0.019751 seconds, 25.3MB/s
MSC 524288 bytes (512.0KB) copied, 0.020908 seconds, 23.9MB/s
PER 5242880 bytes (5.0MB) copied, 0.156823 seconds, 31.9MB/s
SOS 12582912 bytes (12.0MB) copied, 0.350451 seconds, 34.2MB/s
USP 10485760 bytes (10.0MB) copied, 0.391506 seconds, 25.5MB/s
UDA 30734811136 bytes (28.6GB) copied, 842.577451 seconds, 34.8MB/s

Only the huge userdata partition (I have a 32 GB model) takes more than 60 seconds.

again, more weirdness.

The above error message generally only happens if /data is mounted. But wait a minute, the output of "cat /proc/mounts" you showed earlier indicated that it (/dev/block/mmcblk0p9) was not mounted - is it possible that sometimes it mounts and sometimes it does not? (After all, it seems from your reply that you rebooted your tab several times)

"... option to run TWRP without flashing ..." uses fastboot underneath the hood of the Toolkit to perform a boot of an arbitrary image - in this case some version of TWRP or another. But it does not flash anything, so if you were to powercycle your strangely-behaving tablet, it would boot again from whatever is stored on the tablet. The "without flashing" image is only in RAM, and disappears whenever you reboot.

Perhaps you should say a few words about:

(a) Exactly what you were doing when you got into this mess in the first place, and

(b) you mention above "... I can flash my backup..." - did you actually attempt this? If so, what exactly was "your backup", and did you see any errors occur during this process?

If the only thing you still have running on the tab (the partially-functioning recovery boot) is not capable of reading data from the eMMC flash memory chip, I'm not sure that there is any reason to believe that writing to any partition will be any more successful than reading.

There was an outside chance that - by virtue of the fact that you could still run root-privileged shell commands in your crippled recovery - that you could just use "dd" to "flash" a recovery image (to the SOS partition) and perhaps a boot image to your boot (LNX) partition.

But at this point, what you have reported is so strange that I don't have much confidence in trying much more.

To gather more information without performing any write operations, you could do two more things which might shed some light on what your tablet is doing:

- reboot it and then immediately perform a

adb shell dmesg > dmesg_right_after_boot.txt

and then cut-n-paste the dmesg output file "dmesg_right_after_boot.txt" to a pastebin so that we can have a look at it. Provide a link to the pastebin for us.

Also, you could open a second terminal window on your PC, and perform the command

adb shell cat /proc/kmsg

The above command will show you every new command being spit out into the kernel log file. If your tablet is really rebooting when you perform a simple read operation (one of the previous "dd" commands), then perhaps you should try one of those partition read ("dd") commands in the first command window, and see if the kernel issues any warning/error messages that might hint at where the problem is coming from

.