Custom recovery results in non-working N7

I'm not really sure what question you are asking. Also, I think you might be leaving something out which ought to be clarified, the way you describe things seems to have some pieces missing. (And, you really should not be starting yet another thread on this)

You shouldn't be able to flash custom ROMs with a stock recovery; so, are you saying that you:

- flash a ROM with a custom recovery
- try and boot it -- but it fails with the "enter password" prompt (you mention "won't let me enter the homescreen")
- flash the stock recovery into place
- perform a factory reset with the stock recovery
- now the ROM boots?

Also, do you get the same result with TWRP?

UnlockedNand said:

It's a help/troubleshooting post. I know it wasn't good to start another thread, but I felt that people that had already browsed my thread the first time wouldn't come back and now I found the reason behind my issue. I didn't flash a custom rom with stock recovery; I used fastboot on my pc to issue commands. My phone has the factory stock rom on it - then if I flash clockworkmod recovery, the next time I reboot, there's a screen that says I need to type a password to decrypt storage and I'm not able to access anything. If I go back into the bootloader and erase and write the stock recovery, I'm able to boot into the homescreen without the issue. Everything I've flashed to the tablet is done through my pc via fastboot. I never tried TWRP, but I don't like that recovery anyways.

Click to expand...

Click to collapse

OK, read and understood. Very bizzare, however. Almost sounds more like something caused by the bootloader (during the fastboot write) rather than it mattering which custom recovery is sitting there (it's not clear from the above, but it almost sounds like it is not even necessary to have ever booted the custom recovery from the device's recovery partition for the problem to appear)

Are you also saying that you can not flash a custom ROM from the custom recovery without this "enter password" phenomenon happening, or is it only this combo of pure stock ROM + recovery flashed via fastboot that exhibits the problem?

I have a lightly-rooted JDQ39 Stock (4.2.2) ROM with a custom recovery - no such troubles. But mine was installed by using factory-via-fastboot of 4.2.1, followed by a manually-triggered OTA to JDQ39, and then followed in turn by a fastboot flash of the recovery partition (TWRP 2.4.1.0). That last flash was certainly performed by the 4.18 bootloader.

No troubles, but that is certainly a different installation path.

Two more small questions for clarification purposes: when you installed the factory 4.2.2 ROM via fastboot, did you follow the exact sequence of the install-all.sh script:



... or did you omit anything (e.g. one or more of the erases, the bootloader flashing, etc)?

UnlockedNand said:

Yeah, it's like the bootloader writes bad information to the userdata partition if the recovery isn't stock. I haven't flashed a custom rom from the custom recovery, but I'm assuming the type your password issue would appear again. Yes, it's a combo of pure stock rom + custom recovery when this problem occurs. No, when I installed the 4.2.2 factory stock rom, I unzipped all the image files and typed these commands.

Code:

fastboot oem lock
fastboot oem unlock
fastboot flash bootloader <bootloader name>.img
fastboot flash boot <boot name>.img
fastboot flash system <system name>.img
fastboot flash userdata <userdata name>.img
fastboot reboot-bootloader
fastboot erase cache
fastboot reboot

I've also gone back and manually erased, formatted, and wrote the userdata partition again. Maybe I should try downgrading the bootloader to 4.2.1, reflash userdata, and flash the custom recovery?

Click to expand...

Click to collapse

Hmmm. Well, I can't say for sure, but I am willing to gamble that the bootloader relocates itself into a load-offset address so that it runs out of RAM rather than running directly out of Flash Memory. Much quicker that way. The implication of that is that once it is fully loaded into RAM and operational, you could actually erase the bootloader and suffer no ill effects - until you powered off the device. Then you would be in real trouble.

The point is, in the Google factory sequence, all of the partition flashing is done by the new bootloader (4.18), whereas in your case none of it is done that way - except for the custom recovery flash. Here's the Google sequence:

- erase all partitions using currently installed bootloader (4.13)
- flash new bootloader and boot into it ( 4.13 -> 4.18 )
- flash all 4.2.2 ROM partitions using new bootloader

whereas your sequence looks like:

- (no explicit erasures)
- flash partitions with old bootloader (4.13)
- reboot into new bootloader ( 4.13 -> 4.18 )
- erase cache
- flash recovery with new bootloader ( 4.18 )

very different!

Also, the "-w" switch used in the google sequence causes partition erasure and re-formatting (depending on partition type) prior to each partition's flashing.

Without going through the lock/unlock procedure, I suppose it would be possible to reflash all the partitions with 4.18 to see if the problem disappears. But, now that I said that, I realize my tab - which had an OTA upgrade - is sort of similar in that the partitions & files patched by the OTA were all initially flashed by 4.13 (by me), patched by the OTA, and then finally I flashed only the custom recovery with the 4.18 bootloader.

Doing further experimentation might mean attempting a bootloader rollback flash. I can't say that I've seen reports here of anybody trying it. And I can't say I blame them - there could be dragons hiding in that process.