Root Kit Kat OTA "bricked" me, how can I get it back?

[Eris1981]

My bootloader is unlocked, it always has been and I had root access so I could use Titanium Backup.

I was on the latest OTA JB build

After the update pushed through it had an error, and now I just get an Android on its back and a 'no command' error.

I can get into the stock (if I recall) recovery, but it has been so long since I messed with anything I do not know what to do to get it back to a working OS. - Mostly because my computer does not 'seem' to be seeing it.

Google has been no help, and I am already familiar with how useless ASUS would be, well that and my unlocked bootloader voids any warranties.

Any help would be awesome at this point. I have already downloaded the factory image file.

 

[jhawkkw]

Check this guide out.

http://androidforums.com/showthread.php?p=5702530

 

[Eris1981]

Check this guide out.

[Guide]How to flash a Nexus Factory Image manually. - Android Forums

Thanks, Wugs toolkit ended up fixing it for me. This blows though as I lost everything. It was set up just the way I liked it.

 

[scary alien]

Hey Eris1981! :wavey:

Sorry for the delayed participation here, but if I can ask, had you previously saved rooted with OTA RootKeeper or SuperSU (root survival mode) or with my app?

Lemme know if you can, please .

Thanks and great to see you again!

 

[Eris1981]

Hey Eris1981! :wavey:

Sorry for the delayed participation here, but if I can ask, had you previously saved rooted with OTA RootKeeper or SuperSU (root survival mode) or with my app?

Lemme know if you can, please .

Thanks and great to see you again!

I had OTA Rootkeeper installed, and was protected. I have not re-rooted 4.4 though yet, been working too much to mess with it, sucks when work gets in the way!

The problem with the computer not seeing the N7 was the cable I was using turned out to be bad, once I switched it the computer could see the tablet, and so could the toolkit.

 

[scary alien]

I had OTA Rootkeeper installed, and was protected. I have not re-rooted 4.4 though yet, been working too much to mess with it, sucks when work gets in the way!

The problem with the computer not seeing the N7 was the cable I was using turned out to be bad, once I switched it the computer could see the tablet, and so could the toolkit.

Ah, many thanks for that confirmation! :thumbup:

Yeah, I ran into the soft-brick thing, too--but I was sort-of prepared for it because I was testing Pau Oliva's 4.3 OTA root keeper (keeproot.sh) script. I have replicated this 4.3+ save root feature in the latest (2.6) release of my Android Root Toolkit app.

I also have OTA RootKeeper installed as well as the saved root from my Android Root Toolkit app and was unable to boot after the OTA failed after it encountered the saved root file (it barfs because the updater-script has a recursive set permissions on the /system partition that fails when it sees the immutable saved su file (immutable = can't delete or alter, etc., which is why the save root function worked (past tense) so well)).

I even soft-booted a custom recovery and removed the bad file, but there's no getting the OTA to restart or complete it's installation. About 95% of the installation (patching, etc.) is already done by the time the recursive permission setting fails, but there are key/vital things that are left not yet completed that keeps you from rebooting or even easily recovering.

[I suppose I could have created a new .zip file out of the failed and unfinished commands and flashed that in custom recovery, but I already knew what the dealio was so I didn't both to do this (I still might, just for grins)].

Anyway, lesson learned is that you need to make sure you do not have any immutable files (i.e., pre-4.3 saved su root binaries) left on your /system partition before taking the 4.4 KitKat (or higher, I believe) OTA since the OTA will likely fail when encountering these files.

Simply uninstalling OTA RootKeeper or my app does not remove the saved root. My Android Root Toolkit app kept his in /system/su-backup-atr and provides a function for removing that file. OTA RootKeeper, I believe, currently stores his saved su binary in /usr/we-need-root/su-backup. I'm not sure where SuperSU's root survival mode saves his, but I believe Chainfire's 4.3 root install will nuke or remove the immutable bit on the proper file, but don't quote me on that.

Sorry I didn't catch these threads before, but, LOL, I was busy debugging and discovering all of this wonderful stuff myself .

Thank you again, Eris1981--very good to see you again!

 

[Eris1981]

Outstanding explanation for what happened!

In other words I should have just done what I would have done in the past and installed a custom leaked Kit Kat a month or two ago, trying to run OTA stuff just mucks me up when I have root LOL

My Eris and Thunderbolt had me requiring root to be happy, I would OC and delete all the bloat.

My DNA and the N7 had always run pretty flawlessly and the only reason to root was for Titanium Backup, deleting bloat, and micro-usb mounting. The stock OS I was pretty happy with so I had not been around as much.

 

[John Bean]

Anyway, lesson learned is that you need to make sure you do not have any immutable files (i.e., pre-4.3 saved su root binaries) left on your /system partition before taking the 4.4 KitKat (or higher, I believe) OTA since the OTA will likely fail when encountering these files.

At last an explanation of what broke my N4.

My N7 had been fine - I had flashed the KK factory image rather than waiting for the OTA - but my N4 was taken down big time by the OTA. I couldn't communicate with it at all except in adb sideload mode, fastboot simply didn't work. In the end I contacted Google and they sent me a replacement next day, even though I had told them it was unlocked and rooted. Good service

Re-rooting is so easy I'm a bit puzzled by why anyone bothers to attempt a "rootkeeper" strategy, especially if it can (and does) sometimes cause more problems than it fixes. Unfortunately I obviously had legacy OTA Rootkeeper files lurking after I had long since removed the app after previous OTAs had shown it to be ineffective.

That said the behaviour of the update script shows very bad coding practice from Google; they ought to be ashamed of themselves for leaving a system in that state after a failed update.