I think it would be absolutely fantastic if there was a means to use nvflash/wheelie for bootloader disasters *without* previously generating blobs. (Yes, I understand that isn't possible at this time - and may never be).
Or, if it were possible to generate blobs without first flashing a "hacked" bootloader to the tablet (which - if I am reading this thread correctly - apparently borks the use of fastboot for flashing official bootloaders afterwards, so that you are required to repair this situation by use of yet another use of nvflash)
But seriously, this isn't a case of the cure being worse than the disease, it's a case of the
*prevention* being more risky than the disease itself: "you can prevent an unlikely hard-brick of your tab in the future by certainly risking a hard-brick today!"
I read
this thread - "rats, it's bricked... no, wait, it's not bricked... oh crap I think it's bricked... no, wait, it's not bricked... oh crap I think it's bricked... no, wait, it's not bricked... oh crap it's bricked now for sure." That hardly inspires a sense of confidence wrt repeatability of the procedure for anyone reading.
Don't get me wrong though - props are due to anybody who willingly risks their device trying to figure out rescue methods for others. But that's not the same thing as recommending that newbs use a complicated, risky, and not-well-understand procedure in order to prevent a later act of stupidity.
If they are stupid enough to wreck their bootloader in the future, then they are even more likely to brick it today using this - especially because the procedure is substantially more complicated and less well understood than say using fastboot.
I think OTA Updates are more risky than updating the bootloader with fastboot. OTA updates just flash the bootloader without any checks direct to the block device. Fastboot makes a signature check to be sure that the image is ok. I wasn' t able to flash a broken bootloader via fastboot...
Not so. The OTA update.zip files are cryptographically signed (jarsigner method). The update process can not even begin unless the whole archive passes the (file-by-file) SHA1 MICs. That means not a single byte can be wrong in the OTA payload - it won't even launch if that is the case (I am talking about true OTA delivery - not sideloads with manually downloaded files). And the OTA-delivered bootloader is "staged" for installation by the recovery boot for the pre-existing bootloader
the next time it loads. Since fastboot "talks to" the running bootloader, both methods (fastboot and OTA) install the replacement bootloader via the facilities of the preexisting bootloader. Not obvious why there would be more or fewer checks in either case.
The only people that have problems with OTAs are folks who try applying them with non-stock recoveries and/or customized ROMs. Simply put, they were not designed to be used in that manner.
The reality of the situation is that folks should try to avoid manual flashing of bootloaders at all costs; the safest procedure for doing so is to make a full backup of their current ROM (including recovery),
restore a stock ROM from a backup including its' stock recovery, and take the automated OTA against pure unadulterated stock. After that, flash a custom recovery (unlocked bootloader case) using fastboot and either restore a backup or install a new ROM.
The usual excuse for not doing bootloader updates this way is "I don't have a stock ROM backup or the matching stock recovery", or "yeah but using fastboot is faster" But that's just sloppy behavior leading to even sloppier behavior.
