Kill the kill switch - "ST - yy" - Shield Tablet General

< include generic disclaimer here >
TL;DR
Since update 3.1, Nvidia can force updates (such as the one that bricks your tablet) to be downloaded and installed silently. No guarantees, but:
If you're on stock, delete TegraOTA (/system/app/TegraOTA or /system/priv-app/TegraOTA if you're on 5.0 or newer, or /system/app/TegraOTA.apk if you're still on 4.4) before booting into Android (the attached ZIP file does this for you, but please check with the file manager in recovery before rebooting and let me know if it didn't work), then reboot
Note: you also will need to delete TegraOTA again if you ever install an OTA from Nvidia or a recovery image
If you're not on stock, you're probably safe
EDIT: The urgent OTA is currently not getting sent out to any devices anymore, not even to those who have been getting it before.
EDIT 2: The urgent OTA is now being delivered again, this time named "ST - yy"!
What if my tablet is already deactivated?
Unless you can still boot into fastboot mode (in which case your tablet isn't really deactivated yet), your tablet is probably gone for good. The only way to fix this would be through nvflash, and using it requires the SBK that is unique to each device and that only Nvidia knows, so it's pretty unlikely that we'll ever be able to fix these deactivated tablets.
What/why/how?
In the last OTA (Update 3.1), Nvidia has made some changes to their TegraOTA application. The most important/interesting/suspicious of which is the ability for them to mark OTAs as "urgent". What this means is that these updates will be downloaded without ever notifying the user, and they will be installed without asking the user for permission first. If this is how the kill switch is delivered, all users will see is the tablet randomly rebooting and installing an update, then the tablet would never boot again. As some of you might notice, this would match what has been happening to a few users already, both here and on reddit.
But that's not all. I've been connecting to the OTA servers using various serial numbers (both found and provided to me by a few people) in hopes of actually finding the update that bricks the device. The first serial number I've tried that wasn't mine was the serial number from the screenshot on the recall page. It revealed an interesting "urgent" OTA, named "SHIELD Tablet xx - LTE", which does nothing but flash a blob (which, among other things, contains the bootloader). Many more questions appear now, but the main one is: if this is nothing but a routine bootloader update, why is it marked urgent? And why is it not attached to any Android update? But this by itself is not enough to prove anything, as I could only obtain it with one serial number, so as far as I could have known, it might had just been an internal update or something similar. (update is linked and analysed in the second post below)
Today, however, one of the serial numbers I've been given by some of the people here (thanks for the help guys!) turned out to have the same update waiting for it the next time it connected to the Internet. This rules out the possibility of an internal update, so the next somewhat obvious possibility is that this is the kill switch. Mind you, I still have no direct way of proving this without flashing the ZIP to see what happens (which I'm not planning to do myself), but I will keep checking on the other serial numbers I've gotten to see if this update turns up for them too.
The same person who has given me this serial number has also tested running the old tablet on the latest stock Android version but with TegraOTA removed, and, as expected, the tablet is still working perfectly fine now. Your mileage may vary.
How can I know if the kill switch has been triggered for my tablet?
Go to http://shield.bogdacutu.me/ and enter the full serial number of your old tablet. If the next OTA returned is "SHIELD Tablet xx" "ST - yy", the kill switch has been triggered for your tablet.
Warning: the serial number from the box of the tablet and the one etched on the side of the tablet are not complete, as they only contain the first 13 characters of the full (20 characters) serial number. You can get the full serial number from Android (Settings -> About -> Status), from the bootloader (it will be on the screen when you boot into bootloader mode), or from your computer if the tablet is or (in some cases) if it was previously connected, using various tools such as USBDeview. Example: 0413714803249000a4cf (you can try this on the page and it will return that the kill switch is activated).
Why would I want to also do the fix on my new tablet too?
The update is signed by Nvidia, and communication with the OTA server does not use HTTPS, so, for example, a malicious WiFi network could MITM your connection and cause this update (as well as any other signed update) to be flashed to your new tablet without your permission, thus permanently disabling it too. If you have the stock recovery, only updates signed by Nvidia can run. The story might be slightly different if your recovery doesn't enforce signature verification (such as TWRP and CWM by default).
Can I still get updates from Nvidia after doing this?
Not directly, but people will post OTA download links here on xda when new updates get released. I'd personally recommend that you wait before flashing though until someone here checks the new update to confirm that there's no new way for Nvidia to kill your tablet.
Many hours of work have gone into investigating this. Even if it doesn't help your specific scenario, consider hitting that Thanks button, so that I can at least know it wasn't for nothing.
I'd also like to thank the people who have given me their serial numbers to use for testing again, this wouldn't have been possible without their help: @Beauenheim, @Jackill, and @runandhide05 (who has even volunteered to test removing TegraOTA with the latest update on his old tablet :highfive

Fragments of code from TegraOTA.apk
< screenshots temporarily removed >
Also, from what I've seen so far, the update isn't delivered instantly after activating the new tablet. I don't know exactly what the rule is, but out of the 4 serial numbers that I have, only 2 have this update waiting for them.
EDIT: One more serial number from the ones I have has gotten the xx update. Only one left...
EDIT 2: All the serial numbers I have have the urgent OTA waiting for them now.

"SHIELD Tablet xx" - Update Analysis
OTA URL: http://ota.nvidia.com/ota/data/post...wf-full_ota-32256_554.0168.20150624152335.zip
yy OTA URL: http://ota.nvidia.com/ota/data/posted-roms/uploaded/st---yy--092704233775---7294.20150819152732.zip (if you don't know what you're doing, DO NOT DOWNLOAD THIS, it's very likely that this will permanently brick your device upon flashing it!!!) - also attached to this post in case this link becomes invalid
updater-script is the first file we check:
Code:
getprop("ro.product.device") == "shieldtablet" || abort("This package is for \"shieldtablet\" devices; this is a \"" + getprop("ro.product.device") + "\".");
nv_copy_blob_file("blob", "/staging");
reboot_now("/dev/block/platform/sdhci-tegra.3/by-name/MSC", "");
Suspiciously enough, this only flashes a blob to the staging partition. But what exactly does this blob do, you might ask? Well, the blob actually contains data for 9 partitions, which are automatically replaced during the next boot (before the bootloader does anything else at all, so once you've rebooted, there's no going back) with the contents present in this blob. The 9 partitions are as follows (also detailing comparison with files from update 3.1):
BCT (Boot Configuration Table) - stores some information that is needed for the device to find the bootloader stored on the other partitions, initialize the RAM and some other stuff
Status after update: probably corrupted - the previous OTAs have binary BCTs, but this update replaces it with a text file (which, while it does contain somewhat relevant information, is likely not a valid format). If this is corrupted, it's enough for the device not to be able to boot anymore.
BMP (boot logo) - intact
DTB - intact
EBT (part of the bootloader) - has a zeroed out region
NVC (part of the bootloader) - intact
RBL (part of the bootloader) - has a zeroed out region
RP4 (landscape boot logo) - intact
TOS (Trusted OS - probably part of the bootloader too) - has a zeroed out region
WB0 (related to the boot process, source file is named "nvbootwb0.bin") - has a zeroed out region
The update also contains a few other files, but those are not used at all (probably leftovers from the 5.1 AOSP update template that they are using).
DO NOT DOWNLOAD THE ATTACHMENT IF YOU DON'T KNOW WHAT YOU'RE DOING. THIS IS THE XX OTA, NOT THE ZIP THAT REMOVES TEGRAOTA!

Just as I suspected!!

Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.

tecnoworld said:
Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.
Click to expand...
Click to collapse
CWM and TWRP are both compatible with OTAs, so yes, it can. If you completely erase the recovery (fastboot erase recovery), the update can't get flashed, but the tablet will still reboot (which is at least annoying).
You can flash the provided ZIP through CWM or TWRP (but please check through the file manager if /system/app/TegraOTA still exists after installing it, the ZIP hasn't gone through a lot of testing so it might not work properly in all cases)

tecnoworld said:
Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.
Click to expand...
Click to collapse
This was to be my question too... Normal ota updates will not flash if you have a custom recovery, so how would this silent ota update?

bluegizmo83 said:
This was to be my question too... Normal ota updates will not flash if you have a custom recovery, so how would this silent ota update?
Click to expand...
Click to collapse
Normal OTAs don't work through custom recoveries because they do various checks that usually fail when you have a custom recovery (such as if the system partition is modified, by rooting for example), this urgent OTA has none of those checks

Bogdacutu said:
Normal OTAs don't work through custom recoveries because they do various checks that usually fail when you have a custom recovery (such as if the system partition is modified, by rooting for example), this urgent OTA has none of those checks
Click to expand...
Click to collapse
Oh ok! Great explaination. Thanks for all your hard work on this! I'm flashing the zip now, i'll report back if it removes the file
Edit: Ok I flashed the zip, and TegraOTA is gone. Now I will finally turn on my new tablet and set it up!

So out of interest, what do you think the chances are that thisll work?
How did you find out if the update is waiting? FYI I flashed the ZIP... All is good and it booted fine on LTE 32Gb...
Plus the deleting of the TegraOTA File has gone through... So you really think the TegraOTA removal has stopped it?
How do i check if i have downloaded randomly that update?

Great post. Hopefully that's as far as Nvidia is going to go. I flashed a custom rom on my old tablet. I'm keeping my new one stock but deleting the system app per your post. Just in case Nvidia is spiteful when I don't return the old tablet. I don't want to leave them any option of nuking the new one.

fkofilee said:
So out of interest, what do you think the chances are that thisll work?
How did you find out if the update is waiting? FYI I flashed the ZIP... All is good and it booted fine on LTE 32Gb...
Click to expand...
Click to collapse
Decompiled the OTA application. Using information from there I can connect to the OTA server directly from my PC, and request updates for any given serial number and Android version combination.
I wouldn't have posted this if I weren't relatively confident in my findings

Bogdacutu said:
Decompiled the OTA application. Using information from there I can connect to the OTA server directly from my PC, and request updates for any given serial number and Android version combination.
I wouldn't have posted this if I weren't relatively confident in my findings
Click to expand...
Click to collapse
I know fella I appreciate it. Could you check my second point? 2 x Nvidia Shields would be awesome! One for Work, One For Home

fkofilee said:
Plus the deleting of the TegraOTA File has gone through... So you really think the TegraOTA removal has stopped it?
How do i check if i have downloaded randomly that update?
Click to expand...
Click to collapse
Yes, I think it did. If that update was downloaded on your device, it would have been too late (as it reboots instantly after the update is downloaded), so I wouldn't worry about that.

Bogdacutu said:
Yes, I think it did. If that update was downloaded on your device, it would have been too late (as it reboots instantly after the update is downloaded), so I wouldn't worry about that.
Click to expand...
Click to collapse
So heres an interesting one for you, using a logical mindset, if you receive your new tablet, activate it, the next time that the old one connects to the network, it downloads this update and bricks it? But it wont technically do this until the new tablet is turned on?

fkofilee said:
So heres an interesting one for you, using a logical mindset, if you receive your new tablet, activate it, the next time that the old one connects to the network, it downloads this update and bricks it? But it wont technically do this until the new tablet is turned on?
Click to expand...
Click to collapse
As mentioned in the OP, the update doesn't get delivered immediately after you activate the new tablet. But yes, the old tablet shouldn't get the update before the new one is activated.

Bogdacutu said:
As mentioned in the first post, the update doesn't get delivered immediately after you activate the new tablet. But yes, the old tablet shouldn't get the update before the new one is activated.
Click to expand...
Click to collapse
Sorry fella missed that part, I will be donating some funds when i get paid later this month Mucho Gracias!

Totally not related to this thread, but I just went to setup my new tablet and it's not letting me restore apps & settings from my old Shield Tablet... It doesn't show my old tablet as a restore option. I doubt checked and the old tablet is setup to backup all settings and apps though. Anyone else have this issue when setting up they're new tablet?

bluegizmo83 said:
Totally not related to this thread, but I just went to setup my new tablet and it's not letting me restore apps & settings from my old Shield Tablet... It doesn't show my old tablet as a restore option. I doubt checked and the old tablet is setup to backup all settings and apps though. Anyone else have this issue when setting up they're new tablet?
Click to expand...
Click to collapse
Upgrade to 5.1 on the new tablet without restoring any data, then do a factory reset and you should get the option to restore

Bogdacutu said:
Upgrade to 5.1 on the new tablet without restoring any data, then do a factory reset and you should get the option to restore
Click to expand...
Click to collapse
AWESOME man, thank you!!

Related

Help! Can't update with OTA or manually to 4.2.1

Today i decided to finally update to 4.2.1 and there after 4.2.2, but when i tried to update with OTA, it stopped 1/3 into the updateting process. Then showed a red exclamation thingy. I tried several times, but all with the same result.
Then i tried to update manually to 4.2 with adb sideload, but that did not work. It stopped after displaying "Verifying system" and then it displayed the following:
assert failed: apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0")
Installation aborted
I am sure if have done anything right, but still can't make it work. The device is completely stock. Please help me D:
You didn't mention the starting condition of the tablet, and that is incredibly important information.
Additionally, you didn't really say whether the first upgrade succeeded. Please be specific and detailed.
The OTAs are patching kits - not full replacements - and thus they:
- must each be applied to a SPECIFIC starting condition, and
- can not be "skipped over"; they need to be performed in sequence.
You should be able to avoid OTAs altogether and flash a full factory image (at least up to JOP40D/4.2.1), but only if you are willing to wipe away all your data (factory reset)
So, say what your current version is - use the "J" release version (e.g. JOP40D, etc) , don't say four-point-whatever.
bftb0 said:
You didn't mention the starting condition of the tablet, and that is incredibly important information.
Additionally, you didn't really say whether the first upgrade succeeded. Please be specific and detailed.
The OTAs are patching kits - not full replacements - and thus they:
- must each be applied to a SPECIFIC starting condition, and
- can not be "skipped over"; they need to be performed in sequence.
You should be able to avoid OTAs altogether and flash a full factory image (at least up to JOP40D/4.2.1), but only if you are willing to wipe away all your data (factory reset)
So, say what your current version is - use the "J" release version (e.g. JOP40D, etc) , don't say four-point-whatever.
Click to expand...
Click to collapse
I am running Build JZO54K and tried to update OTA to JOP40D. All of my attempts of updating have failed. Both OTA and manual.
What do you mean by starting condition?
It would help to know if you have a wi-fi only model or 3g. They take different update files. You have to have the update specific to your model (wi-fi v. 3g). The amount of memory doesn't matter.
Groid said:
It would help to know if you have a wi-fi only model or 3g. They take different update files. You have to have the update specific to your model (wi-fi v. 3g). The amount of memory doesn't matter.
Click to expand...
Click to collapse
It is a 32gb wifi
henrikpw said:
I am running Build JZO54K and tried to update OTA to JOP40D.
Click to expand...
Click to collapse
Thanks, much better info.
henrikpw said:
What do you mean by starting condition?
Click to expand...
Click to collapse
Exactly what you stated above - thanks. In your OP, it wasn't clear whether it was the first OTA or the second OTA that was failing.
The assert fail message you provided revolves around the boot image (LNX partition). It implies a modified boot partition ... but I believe you when you say unmodified stock. (A different user reported a similar case a few days ago, but with a different stock ROM installed... and therefore a different OTA file)
Is it correct to assume this failure occurs when attempting to apply the JZO54K -> JOP40D OTA update?
Let me poke around a little bit, I will respond back. You may have to do a full factory flash - in the meantime have a look at the Carbon app video on Koush's (ClockworkMod) site to see if you are comfortable with doing that process.
bftb0 said:
Is it correct to assume this failure occurs when attempting to apply the JZO54K -> JOP40D OTA update?.
Click to expand...
Click to collapse
Yes.
bftb0 said:
Let me poke around a little bit, I will respond back. You may have to do a full factory flash - in the meantime have a look at the Carbon app video on Koush's (ClockworkMod) site to see if you are comfortable with doing that process.
Click to expand...
Click to collapse
I do not want to do anything that voids my warrenty
henrikpw said:
I do not want to do anything that voids my warrenty
Click to expand...
Click to collapse
Well, if you consider unlocking your bootloader, installing stock software, and then re-locking your bootloader to be a warranty-voiding situation, then there is really only one path available to you: back up all your market apps & data using Carbon, install the (full) factory software**, perform the 4.2.2 OTA, and then restore apps & data with Carbon.
**actually, I'm not completely sure if the factory (full-install) software bundle requires bootloader unlocking or not - I suspect that it might require an unlocked bootloader.
If you have never been through any of this before, I can see that it appears intimidating, esp. because of the number of newbs showing up every day asking "did I just brick my device?"
But using custom recoveries - even temporarily - provides some flexibility even when you want to run pure stock.
For instance, in your case, I believe that boot image check is the very last thing which is checked in your OTA prior to starting. That suggests that removing that check - AND the corresponding boot image patching - would allow everything else in the OTA patch to succeed; after that the complete boot.img file from the JOP40D distro could be manually flashed; and from there you would no doubt be able to proceed to an additional OTA install to get to 4.2.2
But because a modified/re-zipped OTA bundle could not be flashed by the stock recovery due to lack of signing, this flashing would have to be performed by a custom recovery (that has signature checking supressed).
Lastly, I will say this - I doubt that Google made a mistake with their assert() checks in their OTA update package. That suggests that either
- your boot image actually did get mysteriously modified somehow, or
- your device developed a media flaw in it's boot partition, so the checksum validation fails because of this problem.
In the latter instance, that portends a small risk involving future flashing or booting from that partition.
Well, this post has gotten long; maybe you should say something about what risks you *are* willing to take...
Here are some people who have the same problem: http://code.google.com/p/android/issues/detail?id=41819
henrikpw said:
Here are some people who have the same problem: http://code.google.com/p/android/issues/detail?id=41819
Click to expand...
Click to collapse
That's a lot of reports.
The thing that strikes me about this is that the check which fails (boot partition) is the very last item checked before the patching begins. In the case of folks trying the patch manually, it is hard to believe they simply picked the wrong OTA file (corresponding to the wrong release version) - because in that case a whole bunch of files would be mismatched: they would get a very early error in the list of things checked.
It's almost as if a bunch of units escaped Asus with a variation in the boot image.
There might be something more subtle going on too - here's someone on xda who reported the very same syndrome, but was trying to update a completely different OTA - the starting point was JRO03S
Well, as I said, the problem can be overcome manually. But you would probably need to unlock the bootloader, even if you planned on staying with a full stock setup.

Problem getting 4.2.2 update: "Verification failed"

Hey everyone,
I'm having trouble getting my Nexus 7 to update to 4.2.2. My device is rooted, I recently performed a factory reset.
The update has never appeared in my "System updates" menu, so I looked around and saw that if you force stop "Google Services Framework" and clear its data, the update will appear in "System updates."
It did, but when it finishes downloading, it says "Verification failed."
I tried another factory reset, and I had to again force stop and clear data on "Google Services Framework" to get the update to appear, but again it downloads and say "Verification failed."
I'm stumped now. Do I have to unroot and reroot? Do I have to keep waiting for this update? Do anything with the bootloader? (I really hope not...)
Thanks everyone!
If some files in your system got changed for whatever reason, then you wont be able to update. You can flash the 4.2.1 stock rom and try ota update again.
Leonhan said:
If some files in your system got changed for whatever reason, then you wont be able to update. You can flash the 4.2.1 stock rom and try ota update again.
Click to expand...
Click to collapse
Is flashing the stock 4.2.1 rom the same thing as doing a factory reset to 4.2.1?
If it isn't, would flashing the 4.2.1 rom wipe my tablet?
Leonhan said:
If some files in your system got changed for whatever reason, then you wont be able to update. You can flash the 4.2.1 stock rom and try ota update again.
Click to expand...
Click to collapse
If he is trying to do an OTA to 4.2.2, would it not be more straightforward to just flash the 4.2.2 factory image? The OP has already done a factory reset, so it doesn't look like he/she is particularly attached to his current setup.
Also - the language he used was vague - it sort of sounded like the OP observed "verification failed" in the main OS rather than in the recovery. Not sure.
But it doesn't matter - newbs should not be trying to use OTAs on modified /system images or tabs with altered boot images. It's just too detailed a process to describe compactly.
@Horadrius
Before you do anything further, you should back up everything on the "SD Card" to your PC. Yes, all of it. You can throw it away later if you find you didn't need it. But if you follow the instructions for the Google (factory) images install, everything gets wiped off of /data including your pseudo - SD card.
At a minimum, that will allow you to follow the SBS instructions for installing the 4.2.2 factory images, or - you can simply install a 4.2.2 Stock ROM from over in the dev forum.
Whatever you do, start getting in the habit of making backups - and at least occasionally also getting copies of those off of the tablet.
Oh boy, lot of information to digest here....and a lot of questions
it sort of sounded like the OP observed "verification failed" in the main OS rather than in the recovery. Not sure.
Click to expand...
Click to collapse
Yes, it was the main OS - Settings -> About Tablet -> System Update.
After force stopping Google Services Framework, the update showed up there, and when the download bar reached 100%, it said "verification failed." I did a factory reset, and now when I go to System Update it simply says that my system is up to date.
This makes me think I'm not "supposed" to have the update yet, and that it will arrive, eventually. Yes?
newbs should not be trying to use OTAs on modified /system images or tabs with altered boot images.
Click to expand...
Click to collapse
So, no updating the device from System Menu because I'm rooted/unlocked bootloader? I'll have to flash everything as it comes out?
@Horadrius
Before you do anything further, you should back up everything on the "SD Card" to your PC.
Click to expand...
Click to collapse
Would Titanium Backup held in this regard? Or simply copy/paste the sdcard folder to my PC?
This whole process has been very frustrating. Is this the price you pay for rooting your device? Making simple system updates into a maze?
Horadrius said:
Oh boy, lot of information to digest here....and a lot of questions
Yes, it was the main OS - Settings -> About Tablet -> System Update.
After force stopping Google Services Framework, the update showed up there, and when the download bar reached 100%, it said "verification failed." I did a factory reset, and now when I go to System Update it simply says that my system is up to date.
This makes me think I'm not "supposed" to have the update yet, and that it will arrive, eventually. Yes?
So, no updating the device from System Menu because I'm rooted/unlocked bootloader? I'll have to flash everything as it comes out?
Would Titanium Backup held in this regard? Or simply copy/paste the sdcard folder to my PC?
This whole process has been very frustrating. Is this the price you pay for rooting your device? Making simple system updates into a maze?
Click to expand...
Click to collapse
Sounds like your download is bad if it fails at this stage. I believe it is saying the checksum of the download file doesn't match whatever is downloaded.
PS. not related to N7, why XDA use the re-captcha which I need to refresh several times to get something I can read
Horadrius said:
Yes, it was the main OS - Settings -> About Tablet -> System Update.
After force stopping Google Services Framework, the update showed up there, and when the download bar reached 100%, it said "verification failed." I did a factory reset, and now when I go to System Update it simply says that my system is up to date.
This makes me think I'm not "supposed" to have the update yet, and that it will arrive, eventually. Yes?
Click to expand...
Click to collapse
No. It means that for some strange reason, running a checksum program on the downloaded OTA file failed to produce the expected checksum. The most likely way this can happen is that the file is truncated - the download stopped short of the full file. Don't know why this is happening, but there you go. There could be other failure causes that are more rare, but it doesn't mean you are not "supposed" to have the OTA. It means that the download process is failing.
The *stock* recovery does a number of even more sophisticated checking than this; but it appears from your description that the recovery never even gets booted.
Horadrius said:
So, no updating the device from System Menu because I'm rooted/unlocked bootloader?
Click to expand...
Click to collapse
Yes and No. An unlocked bootloader causes no problems at all. ANY of the following CAN or WILL cause problems:
- attempting to run an OTA with a custom recovery installed instead of the stock recovery.
- having a modified boot partition (e.g. non-stock kernel, or slightly modified boot partition)
- having altered (or removed!) files in the /system partition that are targeted for patching.
- permissions changes performed by the installer script can cause root functionality to disappear
Horadrius said:
I'll have to flash everything as it comes out?
Click to expand...
Click to collapse
Not sure what you are asking here, but the basic answer is that if you stay on stock you can certainly apply OTAs easily. If you start altering things, you might or might not be able to apply an OTA; there are simply no guarantees.
[size=+1]OTAs are meant for stock installations - including a stock recovery. PERIOD. While it is possible that an OTA could succeed, it is unreasonable to have the expectation that it will do so.[/size]
Horadrius said:
Would Titanium Backup held in this regard? Or simply copy/paste the sdcard folder to my PC?
Click to expand...
Click to collapse
I presume you are talking about the future here, as you said that you already did a factory reset at least twice. If you have subsequently added stuff back in, then I suppose you might be talking about the present tense.
But, yes - either TiBu or the Carbon app can be used along with a strategy where you simply back up the apps & data you are interested in, (plus any "flashable zips" that you used to customize your device in the first place), and you simply start from scratch with a factory install followed by re-rooting, and then restore your apps & data (using TiBu or Carbon).
One other thing you can do which is EASY is this: simply wait until a developer/ROM cook publishes a "Stock" flashable ROM based on the release that the OTA is upgrading to. Don't worry about the OTA, just wait a little bit. (These ROMs are already out for the WiFi-only model, BTW).
1) Take a backup as the first thing you do. It's easy and gives you some insurance.
2) Don't wipe (no "factory reset") - just install the Stock ROM over the top of your existing ROM.
that's it. If you were using a custom kernel, re-install it.
Horadrius said:
This whole process has been very frustrating. Is this the price you pay for rooting your device? Making simple system updates into a maze?
Click to expand...
Click to collapse
[size=+1]OTAs are meant for stock installations - including a stock recovery. PERIOD.[/size]
Interpret that as you desire. It is unreasonable for you to expect that you can diddle with your phone any way you please, and a patch install upgrade methodology will be robust in the faces of arbitrary changes on your part. You are the person creating the maze, not Google.
Moreover, it is your choice to take an upgrade - it's not mandatory. My guess is your tablet was quite pleasing to you before any OTAs started rolling out. Nobody is forcing you to do anything.
OK, one last thing. It is still possible that a manual OTA can succeed on your phone if it is lightly rooted - but there are no guarantees. The procedure does not require you to wait around until an OTA arrives on your phone, but it is not for the faint-hearted:
1) Download the appropriate Stock OTA File.
2) Re-install the stock recovery onto your tablet. You will have to dig it out of the Google full factory image for the version of the OS you are currently running. (available here)
Code:
fastboot flash recovery factory-4.2.1-recovery.img
3) Soft-boot into a custom recovery, e.g.
Code:
fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
5) Using the command line and adb to communicate with the soft-booted recovery, create a recovery command file:
Code:
C:\myPCsux> adb push 6ece895ecb23.signed-nakasi-JDQ39-from-JOP40D.6ece895e.zip /cache/update.zip
C:\myPCsux> adb shell
# cd /cache/recovery
# cat > command
--update_package=/cache/update.zip
^D # ( that is a Control-D character )
# sync
# reboot recovery
This will either succeed or fail. Based on your comments though, you might just want to overflash a Stock-derived ROM over the top of your existing ROM (a "no-wipe" install).
[ROM][Factory Image][4.2.2] Nakasi -::- Odex, Deodex, Rooted -::- teshxx (02/14/13) <-- NOTE for WiFi (nakasi/grouper) ONLY
good luck with your tab.
Someone once said "Rooting is a lifestyle". There's some truth to that; it eats up your time. Perhaps it is not for you.
Thanks, bftb0.
Looking through your list of reasons for why my OTA might not work, none of them applied to me.
I didn't install any custom recovery (didn't install Clockwork Mod recovery specifically to avoid dealing with flashing roms) or kernels or modify any partitions, nor to my knowledge changed any files in the /system section.
I think I'm going to give this update a week or so to pop up on my update menu before I start tinkering again.
Don't get me wrong - I enjoy this kind of tinkering, and all the perks of rooting, but my knowledge is extremely limited, which is what makes it frustrating trying to find information. The only thing I've done before this is install Cyanogen on my HP Touchpad.
Anyway, do I need to install CWM recovery to flash (overflash?) that 4.2.2 rom you linked?
if you haven't done anything other than rooting(i.e. copying a file su to it), OTA would go through. Your problem is about the download process. It can go wrong for many reasons from the download is bad to what saved to the temp area(where the download is) is bad(rare but still possible).
chimpanzeexda said:
if you haven't done anything other than rooting(i.e. copying a file su to it), OTA would go through. Your problem is about the download process. It can go wrong for many reasons from the download is bad to what saved to the temp area(where the download is) is bad(rare but still possible).
Click to expand...
Click to collapse
That's all I've done, root and unlock bootloader. The download only showed up when I cleared data and force stopped the "Google Services Framework" process. I reboot the system, and check for the update and nothing is there.
well, sounds like you have to flash it manually using fastboot then.
That said, I myself have no intention of doing the update any time soon as I don't find any specific problem with 4.2.1 and there isn't any specific feature i want in 4.2.2
Horadrius said:
Anyway, do I need to install CWM recovery to flash (overflash?) that 4.2.2 rom you linked?
Click to expand...
Click to collapse
TL;DR Yes and No.
People that use toolkits seem to use hard-flashed installs of custom recoveries, as they don't really understand what goes on under the hood, even if the toolkit offers them a means to soft-boot any image the toolkit operator downloads. (I assume that the toolkits probably allow this; as I don't use them I don't know for sure.)
What I am saying is that the answer depends on your knowledge. So long as you have an unlocked bootloader, you can soft-boot any boot image you like - including custom recoveries.. (This also pre-supposes correctly-functioning device drivers, but that is a Windows/user training issue, it has nothing to do with Android).
When I say soft-boot, I mean that the image is transferred to the tablet, which then hands over control and starts executing that image - but it is not "flashed" to Flash memory, so the next time a boot occurs, the same boot images are still stored in either "boot" or "recovery".
In this configuration, the phone should be much more likely to complete an OTA as it will have the stock recovery present most of the time, and only temporarily present when you attach to your PC and kick things off with a custom recovery.
The OTA could still fail, but it probably would succeed for a very lightly rooted stock configuration (other than problems with losing root).
The only downside to this arrangement is that you can't be flashing roms or making nandroid backups or other forms of rooter activities when you are away from the PC.
For the IT-OCD or obsessive ROM hopper, that could be a good thing.
good luck... the rest is up to you.
Ok, I installed Clockwork Mod from a toolkit because going into fastboot and choosing "Recovery mode" led me to a picture of the Android guy with a red triangle on his back saying "No Command."
I'm just going to install 4.2.2 myself now. Question regarding that link - odex/deodexed - I looked up the difference but can't tell which one is appropriate for me - I'm guessing it's odex because that seems to be closer to stock.
Edit: It worked! Thanks for your assistance, everyone!
IMO, google should not ship odex image now that we have fast enough hardware. odex is just a form of 'pre-compilation' which only benefit first time load(or when the cache is cleared). Too little gain for such a complicated setup.

4.1.2 > 4.2.x

Ok. So here's the deal. I'm trying to update to 4.2.2 from 4.1.2, but in recovery I get assert failed, emmc this that and the other.
I'm currently on JZ054K trying to update to JOP40C. I am also fully stock. It's hurting my head using everything I learned from other devices.
*I don't want to do anything with the Nexus into the rooting process. I want to stay fully stock for once.
Please and thank you.
Curiousn00b said:
Ok. So here's the deal. I'm trying to update to 4.2.2 from 4.1.2, but in recovery I get assert failed, emmc this that and the other.
I'm currently on JZ054K trying to update to JOP40C. I am also fully stock. It's hurting my head using everything I learned from other devices.
*I don't want to do anything with the Nexus into the rooting process. I want to stay fully stock for once.
Please and thank you.
Click to expand...
Click to collapse
The "this that and the other" is the only thing which is relevant.
Post the exact error message. If you don't remember what it was, re-attempt the OTA and post a screen shot.
I'll take a photo today. I've been slacking. Away from the forums a bit.
Re: 4.1.2 > 4.2.x
That's the assert failed error. Fully stock neXus.
Sent from my HTC One V using Tapatalk 2
Curiousn00b said:
That's the assert failed error. Fully stock neXus.
Click to expand...
Click to collapse
OK, thanks for that.
Time to come clean though - when you say "fully stock", do you mean
(a) The device has never been rooted ever, or
(b) The device was rooted at one time and then (believed to be) returned to stock.
The assert error that is occurring is a complaint that the boot partition ("LNX") fails a checksum.
This would really only happen under two or three circumstances:
(1) Somehow the boot partition got modded by a root user - eg replacement of the entire boot image such as a "new kernel" or even something tiny like a change to /default.prop, OR
(2) You developed a media (eMMC flash chip) error in your boot partition after the device left the factory, OR
(3) Google/Asus somehow screwed up either the checksum calculation or your N7 slipped out of Asus's factory with a non-standard flash of the boot partition.
Now (3) seems a little bit unlikely. There was a previous user in these forums that reported exactly this same thing happening with a stock (never rooted) device; iirc though, he had a different factory ROM than what you are reporting. So, both his case and yours could be condition (2).
The things which is strange about this possibility (2) is that if a media error occurred randomly in the boot partition, it would be in most cases be fatal to the booting of the device, and neither you nor that other user reported booting troubles. The media error would have to be in a non-critical location such as in the slack space after the end of the boot image but before the end of the partition.
The reason I mention this is because of the way that apply_patch_check() assert seems to work: note that there are 5 parameters total:
filename,length1,sha1val1,length2,sha1val2
This suggests that a successful apply_patch_check() checks the SHA1 signature of the starting file - over an exact byte count, and if that succeeds it actually performs a trial patching operation so that it can compute the SHA1 signature of the output (patched) file and verify that the patch-trial-file has the correct length. This means that partition slack space is probably not included in the first checksum.
This is an extremely conservative and excellent approach to patching things in the field. Note also that the OTA does not touch/modify a single file on your tablet unless everyone of these checks goes to completion.
Also, the stock recovery performs a signature check on the entire zip file that is downloaded by the OTA before any of these other checks begin - which means, that when a stock recovery is used it is impossible to have a bad download being responsible for the errors that you observe.
If your device was never rooted then it seems to me that the odds point towards a hardware error that occurs during the patching-test operation.
If your device is still in Warranty and truly was never rooted, I would encourage you to try and get a new replacement or RMA repair (not a refurb). You are going to have to haggle with Google and show them that assert failure image.
good luck
Re: 4.1.2 > 4.2.x
It bears mentioning that, since the OTA is a patch, it's going to error out if the system is as the OP describes it. I'm unaware of any update zip that patches 4.1.2 to 4.2.2 directly. Since he's skipped a couple updates, he's going to have to do some sideloading to catch up and get to an upgradable state.
Sent from my Nexus 7 using Tapatalk HD
najaboy said:
It bears mentioning that, since the OTA is a patch, it's going to error out if the system is as the OP describes it. I'm unaware of any update zip that patches 4.1.2 to 4.2.2 directly. Since he's skipped a couple updates, he's going to have to do some sideloading to catch up and get to an upgradable state.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
Good catch najaboy
I didn't catch that (JZO54K -> JOP40C) reference, but oldblue910's OTA thread does list such an OTA as having been available in the past.
Plus, iirc the boot image check occurs late in the OTA installer script, possibly even the very last assert() before patching actually starts - so it is hard to imagine that all other checks would have succeeded had a mis-matched OTA been applied.
However, it is indeed odd for "back dated" OTAs to get downloaded automatically esp when more recent upgrades are available, i.e. JZO54K->JDQ39. And nowhere did the OP mention side-loading.
Looks like the OP's got some 'splainin to do...
Ok. So yes.
A. The Device is FULLY STOCK. Never touched anything on it. Brand new on Christmas day.
I've been watching QBking's videos about upgrading it, and yes. I thought the same thing. Going from 4.1.2 to 4.2.2 directly, I noticed that seemed a bit off. I've seen more than just me with this issue. A few on XDA, and few on other websites.
I have tried downloading the 4.2.1 update. I tried sideloading it once. It failed. Atleast I believe it did. I don't know if I had the right download though.
All help is appreciated. I thank you guys as well. This 4.2.2 update is just what the OTA checker keeps throwing at me. I've tried clearing the data/cache of Google Services Framework(I believe this made me redownload the update).
Curiousn00b,
I'm 99.99% positive that you were applying a valid OTA file.
For instance if you have JZO54K on your tablet, and you were going to apply a sideloaded OTA you could choose any of 3 OTAs
JDQ39 (4.2.2) from JZO54K
JOP40D (4.2.1) from JZO54K
JOP40C (4.2) from JZO54K
My comment in the prior post was only that the automatic download always seem to download the OTA update to the most recent (in this case JDQ39) release, so your mention of JOP40C ota seemed slightly off; but if there was some reason to pick an older update, sideloading should still allow that to work correctly.
Bottom line is that a fully stock, never unlocked, never rooted tablet should be capable of accepting a factory OTA, and I would thus consider your tablet to have some unknown defect.
Just to be clear (I recall that the previous person reporting your symptoms was on JRO03S), you are currently on JZO54K, correct?
I found multiple people with it via Google. Couldn't really find a fix for it.
And yes. I'm on JZ054K.
Tomorrow I'll try going to 4.2 from 4.1.2. I'm pretty sure I've tried it already. I remember seeing the C/D parts at the end of these 2 files.
Curiousn00b said:
Tomorrow I'll try going to 4.2 from 4.1.2. I'm pretty sure I've tried it already. I remember seeing the C/D parts at the end of these 2 files.
Click to expand...
Click to collapse
If the problem occurs during the initial checksum of the (currently installed) boot image, then none of the three OTAs (starting from the same JZO54K base) will succeed. If there is something very strange - say a read/write error during the trial patching operation, I suppose it is feasible that one could succeed and another not. But they all should start out looking for the identical bootloader SHA1 checksum as they should be expecting the same (jzo54k) starting condition.
Anyway, post your results.
Re: 4.1.2 > 4.2.x
This is after trying 2 of the updates.
One to 4.2 and other to 4.2.2.
The first on is 4.2.2
Sent from my HTC One V using Tapatalk 2
Curiousn00b said:
This is after trying 2 of the updates.
One to 4.2 and other to 4.2.2.
The first on is 4.2.2
Click to expand...
Click to collapse
As I said, I didn't really expect any of them to succeed.
Where to proceed from here? You really only have 3 choices:
- Use your tablet on 4.1.2 and never upgrade
- RMA for repair/refurb replacement
- Root it, fix the problem, and relock it (so that it is 100% stock again). No guarantess that some trouble won't develop down the road.
As I said before, neither you nor I have any explantion for why a never-rooted tablet would not be able to accept a valid factory OTA. Your tablet either:
(a) slipped out of the factory with an unknown bootloader variant, OR
(b) the boot partition managed to develop bit-rot that does not affect the tablet's ability to boot, OR
(c) there is some other unidentified hardware fault that occurs during the apply_patch_check() process
I would call Asus and see what they will do for you before you make a final decision. (Their warranty has a lot of weasel-words in it; they might tell you that it's not their problem.) If you want an RMA and they push back, I think you should keep repeating that the tablet is less than 3 months old.
good luck
I also noticed that I can't boot into recovery normally. I use ADB or the OTA way to reboot into recovery.
If I get into Bootloader and plug the USB in, the Nexus 7 will freeze at whatever selection I am currently on. Bootloader, Restart, Recovery, etc and nothing will happen.
When I click Recovery, I get a black screen with Google, nothing happens, plug the USB in, and still. Nothing happens. I don't know what's wrong with it.
Thanks for the help.
bftb0 said:
As I said, I didn't really expect any of them to succeed.
Where to proceed from here? You really only have 3 choices:
- Use your tablet on 4.1.2 and never upgrade
- RMA for repair/refurb replacement
- Root it, fix the problem, and relock it (so that it is 100% stock again). No guarantess that some trouble won't develop down the road.
Click to expand...
Click to collapse
My N7 has the same error about the boot partition. It's rooted, unlocked, and has CWM installed. I'm running 4.1.2 (JZO54K). I downloaded the JZO54K to JDQ39 zip file, and got the failure
script aborted: assert failed: apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5062656:af83f09e77a64ed7ede2adad2a16bd0c12d5d7fd")
when I tried to install it via CWM.
How would I fix this - I assume I need to get a copy of the 4.1.2 boot.img and flash it, but I'm not sure how to flash it. I can do it in Windows if I have to, but I'd rather use Linux if I can. I have the adb tools installed on Linux.
mvi57 said:
How would I fix this - I assume I need to get a copy of the 4.1.2 boot.img and flash it, but I'm not sure how to flash it.
Click to expand...
Click to collapse
Yes, that's right. It is easiest is to flash it with fastboot
Code:
fastboot flash boot boot.img
It can also be flashed to the block device
/dev/block/platform/sdhci-tegra.3/by-name/LNX
from a root shell (say in a terminal emulator) using the "dd" utility if you are familiar with that.
A custom kernel or even a trivial re-packing of the boot image (say for a small /default.prop file change) probably is what caused the boot image to be changed from stock.
bftb0 said:
A custom kernel or even a trivial re-packing of the boot image (say for a small /default.prop file change) probably is what caused the boot image to be changed from stock.
Click to expand...
Click to collapse
I didn't install a custom kernel, and as far as I know I didn't change default.prop either.
I reflashed the boot image, it went ok, but I still get the error trying to do the update. I guess I'll have to wipe and flash the whole 4.2.2 image to get it installed.
mvi57 said:
I didn't install a custom kernel, and as far as I know I didn't change default.prop either.
I reflashed the boot image, it went ok, but I still get the error trying to do the update. I guess I'll have to wipe and flash the whole 4.2.2 image to get it installed.
Click to expand...
Click to collapse
Never mind, I flashed the bootloader-grouper-3.41.img instead of pulling boot.img from the .zip. It's working now.
mvi57 said:
Never mind, I flashed the bootloader-grouper-3.41.img instead of pulling boot.img from the .zip. It's working now.
Click to expand...
Click to collapse
That observation is extremely counter-intuitive.
While the bootloader is responsible for booting the recovery, it is certainly not "running" after the recovery starts booting, so it's hard to understand why or how it could have any effect at all on the OTA processing.
Is it possible that the error which occurred after you re-flashed the boot image (LNX) was something different than the original error concerning the checksum on the boot partition?
You might want to consider flashing the v4.18 bootloader to the tablet if you plan on using any dev kernels.
bftb0 said:
That observation is extremely counter-intuitive.
Click to expand...
Click to collapse
Poorly worded, sorry. After I flashed the boot.img I extracted from the zip file, the update ran fine. I looked at the error message again and noticed that one of the numbers matched the size of boot.img, and then realized I flashed the wrong file. I shouldn't do this stuff when I'm tired.
Thank you for all your help!

[SOLVED] Error installing recent OTA update, anyone help or provide insight?

Went to update "YB1-X90L_170420" and as I have been normally doing I removed root, ran the update, and all was well. It installed fine and worked no problem.
I was then prompted for update "YB1-X90F_USR_S000408_1704201342_WW06_BP_ROW_TO_YB1_X90F_USR_S000426_1705080316_WW06_BP_ROW" So I started the download and when the device reboots it then fails with this string, note the error about the "build fingerprint"
Supported API: 3
Finding update package...
Opening update package...
Verifying update package...
Installing update...
Package expects build fingerprint of Lenovo/yeti_10_row_wifi/yeti:6.0.1/MMB29M/LenovoYB1-X90F_S000408_170420:user/release-keys or Lenovo/yeti_10_row_wifi/yeti:6.0.1/MMB29M/LenovoYB1-X90F_S000426_170508:user/release-keys; this device has Lenovo/yeti_10_row
E:Error in @/cache/recovery/block.map
(Status 7)
Installation aborted.
I foolishly after some googling and not finding enough info opened a chat with Lenovo. The rep asked what the error was and once I showed it said that was just related to my fingerprint scanner .... really?!?!? I knew the chat was a dead spot at this point but tried to state this device has no fingerprint reader, etc.. and so on. Hope they could really tell me what the error was. Anyway the rep told me to 'ignore' the update and just carry on since my device is actually working. They then went on to state they are hardware only on the chat session, which the Lenovo site says nothing about that. They then also told me to take this up with Google as they make Android not Lenovo. So much for warranty helping anything but possibly replacing a physically broken device. Their techs are useless, seriously.
So anywho, as you see in the error the update is trying to apply but looks for "Lenovo/yeti_10_row_wifi" and is finding somewhere (in the update or my device?) "Lenovo/yeti_10_row", notice the missing "wifi" on the end of that. My 'build.prop' and other system files are untouched. I even tried resetting the device. Which after the reset I was able to once again install the "YB1-X90L_170420" update but this next update "YB1-X90F_USR_S000408_1704201342_WW06_BP_ROW_TO_YB1_X90F_USR_S000426_1705080316_WW06_BP_ROW" fails again on that same fingerprint mismatch.
Any clue what I should be looking for here? Has anyone else installed that update successfully?
Will anyone here supply me with the original (or as close as original) clean stock ROM without paying for it? I know I should have backed up with TWRP before I started doing updates, and this may well be my issue, but I didn't and not I can only restore back to an already rooted backup. Though I assume doing a reset of that rooted restore is considered clean (no root or 3rd party anything)?
thanks for any help or ideas!
MarkAllen said:
Went to update "YB1-X90L_170420" and as I have been normally doing I removed root, ran the update, and all was well. It installed fine and worked no problem.
I was then prompted for update "YB1-X90F_USR_S000408_1704201342_WW06_BP_ROW_TO_YB1_X90F_USR_S000426_1705080316_WW06_BP_ROW" So I started the download and it the device reboots then fails with this string, note the error about the "build fingerprint"
Supported API: 3
Finding update package...
Opening update package...
Verifying update package...
Installing update...
Package expects build fingerprint of Lenovo/yeti_10_row_wifi/yeti:6.0.1/MMB29M/LenovoYB1-X90F_S000408_170420:user/release-keys or Lenovo/yeti_10_row_wifi/yeti:6.0.1/MMB29M/LenovoYB1-X90F_S000426_170508:user/release-keys; this device has Lenovo/yeti_10_row
E:Error in @/cache/recovery/block.map
(Status 7)
Installation aborted.
I foolishly after some googling and not finding enough info opened a chat with Lenovo. The rep asked what the error was and once I showed it said that was just related to my fingerprint scanner .... really?!?!? I knew the chat was a dead spot at this point but tried to state this device has no fingerprint reader, etc.. and so on. Hope they could really tell me what the error was. Anyway the rep told me to 'ignore' the update and just carry on since my device is actually working. They then went on to state they are hardware only on the chat session, which the Lenovo site says nothing about that. They then also told me to take this up with Google as they make Android not Lenovo. So much for warranty helping anything but possibly replacing a physically broken device. Their techs are useless, seriously.
So anywho, as you see in the error the update is trying to apply but looks for "Lenovo/yeti_10_row_wifi" and is finding somewhere (in the update or my device?) "Lenovo/yeti_10_row", notice the missing "wifi" on the end of that. My 'build.prop' and other system files are untouched. I even tried resetting the device. Which after the reset I was able to once again install the "YB1-X90L_170420" update but this next update "YB1-X90F_USR_S000408_1704201342_WW06_BP_ROW_TO_YB1_X90F_USR_S000426_1705080316_WW06_BP_ROW" fails again on that same fingerprint mismatch.
Any clue what I should be looking for here? Has anyone else installed that update successfully?
Will anyone here supply me with the original (or as close as original) clean stock ROM without paying for it? I know I should have backed up with TWRP before I started doing updates, and this may well be my issue, but I didn't and not I can only restore back to an already rooted backup. Though I assume doing a reset of that rooted restore is considered clean (no root or 3rd party anything)?
thanks for any help or ideas!
Click to expand...
Click to collapse
From what i recall the fingerprint is what is shown in the buildprop. You could try editing this but i would tread carefully if its just a minor update as it may justmess up your system if there are other mismatches during the update process.
Lenovo technical support is a complete joke, you get much better help here. Lol
Sent from my F5121 using Tapatalk
Nope every line of my build.prop, where listed, has the proper "Lenovo/yeti_10_row_wifi" that the update claims is wrong. I personally think it is this update itself but no confirmation from other users if the update
"YB1-X90F_USR_S000408_1704201342_WW06_BP_ROW_TO_YB1_X90 F_USR_S000426_1705080316_WW06_BP_ROW"
has installed for them yet.
And I certainly knew how far I was *not* going to get with Lenovo but figured it couldn't hurt. I was really trying to get a stock ROM download from them or anywhere. I would love to just revert this to how it was out of the box and start over.
Well for reference I think I finally realize what is causing this (unconfirmed, but sounds feasible).
I did at one time try the "YB1-X90L_USR_S000155_1609272258_WW06_BP_ROW" noted in another thread here from Easy firmware. I figured since it was a free download and others have done it, what could it hurt? lol (I think I know now). Anyway I forget what it was at the time but something with that rom just wasn't right for me and I decided to restore back to my TWRP backup I had made. I'm assuming my backup doesn't overwrite something that "L" version rom did and leaves some residue that reports itself as the "L" model now?
Anyway that is the only thing to me that makes sense to me that could be happening. Of course I have no original stock rom with IMG files to flash again to fix this. :/
Can anyone here confirm Easy Firmware is safe to use? Can anyone confirm their YB1-X90F rom is really that models rom?
MarkAllen said:
Well for reference I think I finally realize what is causing this (unconfirmed, but sounds feasible).
I did at one time try the "YB1-X90L_USR_S000155_1609272258_WW06_BP_ROW" noted in another thread here from Easy firmware. I figured since it was a free download and others have done it, what could it hurt? lol (I think I know now). Anyway I forget what it was at the time but something with that rom just wasn't right for me and I decided to restore back to my TWRP backup I had made. I'm assuming my backup doesn't overwrite something that "L" version rom did and leaves some residue that reports itself as the "L" model now?
Anyway that is the only thing to me that makes sense to me that could be happening. Of course I have no original stock rom with IMG files to flash again to fix this. :/
Can anyone here confirm Easy Firmware is safe to use? Can anyone confirm their YB1-X90F rom is really that models rom?
Click to expand...
Click to collapse
Hi,
I registered for the free account. Had to email there support team to get it activate as there were problems their end. The 90F firmwares were not in the free tier so I paid the $15 through paypal to be safe, and got the 90F firmware fine. It was old and I had to run a lot of updates to get it up to date. But it got everything back to how it should be.
I blame Lenovo that we have to jump through theese hoops, but the files are legit.
Broomfundel said:
Hi,
I registered for the free account. Had to email there support team to get it activate as there were problems their end. The 90F firmwares were not in the free tier so I paid the $15 through paypal to be safe, and got the 90F firmware fine. It was old and I had to run a lot of updates to get it up to date. But it got everything back to how it should be.
I blame Lenovo that we have to jump through theese hoops, but the files are legit.
Click to expand...
Click to collapse
Thanks for that confirmation! I did end up getting a registered account ($15) used Paypal and all looked good. I ended up downloading two versions of firmware. Initially I thought I would start with the oldest knowing many updates awaited but really wanted to be sure in erasing all my previous steps just in case it didn't work or the same thing happened again.
Used "YB1-X90F_USR_S000036_1607280616_WW6_BP_ROW-flashfiles.zip" from Easy Firmware. I opted to follow the included "installer.cmd" but did not do the "unlock" or "lock" as I already was unlocked of course and did not want to lock it again. When it completed I first noted my Halo keyboard not working and things were in Chinese here and there. This post resolved both items (thanks vimalbhimani!). Pretty sure that was because I formatted all the various partitions including "country", duh. Sadly however this version was showing no further OTA updates were available at all. Maybe Lenovo has deleted some of the really old OTA downloads and they are no longer available? Not sure.
I then installed the most recent rom "YB1-X90F_USR_S000196_1611040312_WW06_BP_ROW-flashfiles.zip". This time I did not format and only flashed this newer roms boot, bootloader, factory, recovery, and system images. After the system was backup everything was in great shape and updates were available. I made a TWRP backup straight away. Then I let the first and second updates listed below download and install via OTA and had no issues. The final two I opted to save time and installed using the standard recovery from my SD card after I downloaded them from my PC. Here are direct links to those if anyone wants them and they are in order of install (descending) based on already having "YB1-X90F_USR_S000196_161104"
http://tabdl.ota.lenovomm.com/dls/v...S000239_1612091428_WW06_BP_ROW_WCAC703BC6.zip
http://tabdl.ota.lenovomm.com/dls/v...S000340_1702251540_WW06_BP_ROW_WC365253B3.zip
http://tabdl.ota.lenovomm.com/dls/v6/YB1-X90F_170420_WC76FD00EF.zip
http://tabdl.ota.lenovomm.com/dls/v...S000426_1705080316_WW06_BP_ROW_WC80C2A0F2.zip (this is the failed update that incited this thread)
All updates went great and all is well at this point. Made another TWRP backup and I plan to root again now and see if any upcoming updates later have some issue?
I just wanted to report back here if anyone was interested that I unrooted, updated the June OTA update, and was able to root again without issue.
i got the same error message and now i'm stuck. I cant install any updates and so i bought a account from easy-firmware to get the firmware ... the firmware: YB1-X90F_USR_S000036_1607280616_WW6_BP_ROW-flashfiles.zip
doesnt not work with twrp or the stock recovery... it tells me "zip file is corupt"
@MarkAllen: Can you provide a guide how you got back to the stock rom? just flashing the zips doesnt work....
i really need help...
FreddeHamm said:
i got the same error message and now i'm stuck. I cant install any updates and so i bought a account from easy-firmware to get the firmware ... the firmware: YB1-X90F_USR_S000036_1607280616_WW6_BP_ROW-flashfiles.zip
doesnt not work with twrp or the stock recovery... it tells me "zip file is corupt"
@MarkAllen: Can you provide a guide how you got back to the stock rom? just flashing the zips doesnt work....
i really need help...
Click to expand...
Click to collapse
You cannot flash the ZIP file with TWRP or stock recovery. You have to unzip the file and then flash each IMG file that you need manually while in fastboot mode (there are seven of them).
**** IF YOU FOLLOW THESE DIRECTIONS IT IS NO ONES FAULT BUT YOUR OWN IF IT SCREWS UP SOMETHING!!! ****
**** WILL TRY TO HELP PROVIDE INFO IF I CAN BUT CANNOT GUARANTEE ANYTHING. ALSO THIS ERASE ALL YOUR DATA ****
First be aware as noted in the previous post above that I tried using "YB1-X90F_USR_S000036_1607280616_WW6_BP_ROW-flashfiles.zip" intially and it worked fine to get me back up and running but once I was done no new OTA updates were showing at all. No clue why so I ended up doing it again but used the ROM named "YB1-X90F_USR_S000196_1611040312_WW06_BP_ROW-flashfiles.zip". Also note I had erased my "country" partition and flashed "country.img" which requires the info posted by vimalbhimani again linked above in my previous post. It has to be used to correct for your country, no biggie at all and worked fine for myself.
1) Unzip the ROM you downloaded to a folder on your PC
2) From command prompt go to that folder
3) Make sure from the command prompt that ADB and fastboot commands are working properly
4) Put your tablet in fastboot mode ("adb reboot bootloader")
(these next commands are directly from the "install.cmd" included with the ROM from EasyFW, I just opted to run them manually one at a time in order and I omitted the unlock and lock commands)
fastboot flash gpt gpt.bin
fastboot erase misc
fastboot erase persistent
fastboot erase frp
fastboot erase metadata
fastboot format config
fastboot format country
fastboot format cache
fastboot format data
fastboot format factory
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash config config.img
fastboot flash country country.img
fastboot flash system system.img
fastboot flash bootloader bootloader
fastboot flash oemvars bootloader_policy-oemvars.txt
fastboot continue
That's it. Minus the Intel error code 03 for being unlocked, it should be a normal out of the box setup when it boots back up into Android.
good luck!
People that are looking for the YB1-X90F_USR_S000196_1611040312_WW06_BP_ROW-flashfiles.zip may want to take a look at this post.
In contrast to my experiences with devices made by other OEMs, it seems like the files can directly be used for downgrading the Yoga Book if you're currently using a newer version.
Moved...

Patched 11.0.12.12.KB05AA ROM for rooted users - install from Fastbootd!!!

[UPDATE]:
**********
I got sick of my phone telling me I needed to update but I couldn't because I'm rooted. So finally got around to patching the last full ROM today w/ the incremental.
This is the fastbootd w/ flash_all.bat script to update to 11.0.12.12.KB05AA. The package for KB05AA (Global/US) is not yet available, hence I'm still making it available here. Be sure to alter the flash script (remove the "rem" before boot.img and recovery.img if you DO NOT want to keep your custom kernel + TWRP) ****************
3.14 GB file on MEGA
mega.nz
THIS IS ONLY FOR 11.0.9.9.KB05AA, BUT READ IT ANYWAY!!!!: ***************
I think this is the first time anyone has actually made a working incremental update for a rooted OOS device, or any with a payload.bin update method that I know of. This method doesn't require any wiping and TWRP / rooted boot.img / custom OOS kernel can be installed right after the script finishes (or left on the device), and you don't even change your active slot (usually, incremental updates will flash to the inactive slot).
I won't get into that many specifics except it was EXTREMELY DIFFICULT, but it works now. Read here if you want to do it yourself in the future, or on another phone. Should work on just about any phone that uses payload.bin files https://forum.xda-developers.com/t/...11-0-9-9-kb05aa-posted.4314677/#post-85425949
You may have to edit the .bat file to pick your RAM type (the lp5 ones are for devices with LPDDR5; it is preset for most of the phones using the LPDDR4 RAM). On the Op8T at least you can do this from adb shell:
adb shell getprop ro.boot.ddr_type; where a 0 is LPDDR4 and 1 is LPDDR5 ram. If it's 1 returned, you need to flash the lp5 files instead of the same named otherwise files in the .bat file (so edit it).
That weird -cow stuff is temp files that prevented the update from working. Not documented anywhere I could find (well, minimally explained by Google), took hours to figure out they were filling the super partition up. I had to re-engineer a Linux project (linked above) to get this working, and have officially updated from 11.0.8.13 to 11.0.9.9 COMPLETELY now. While rooted, without switching slots, and TWRP installed.
You just have to ensure you're on the latest ADB and Fastboot tools and an adb reboot bootloader, followed by a fastboot reboot fastboot should get you there. You can check with: fastboot getvar is-userspace
If it says yes, you're in fastbootd. It actually will work with TWRP installed, I found out later, as long as you reboot in TWRP to fastboot and confirm with the command above you're in fastbootd.
https://github.com/fawazahmed0/Latest-adb-fastboot-installer-for-windows/releases/tag/v1.7 has a script that will get you the Latest ADB and Fastboot and put it in a folder for you.
I uploaded it to Mega. Just use some common sense and look at the flash_all.bat file before flashing. I'd write more but I'm tired as hell from getting this working. Now we'll never have to wait for an incremental update while rooted again, at least in the foreseeable future.
I'm just going to leave this here
https://forum.xda-developers.com/t/...1-kb2003-kb2005.4178675/page-25#post-85386145
g96818 said:
I'm just going to leave this here
https://forum.xda-developers.com/t/...1-kb2003-kb2005.4178675/page-25#post-85386145
Click to expand...
Click to collapse
That never worked for me and others, Always resulted in either bootloop or booting back to previous build
nujackk said:
That never worked for me and others, Always resulted in either bootloop or booting back to previous build
Click to expand...
Click to collapse
I've mentioned it multiple times for people having issues. They need to use the unbrick tool cause there is something wrong with the original rom install from OnePlus.
g96818 said:
I've mentioned it multiple times for people having issues. They need to use the unbrick tool cause there is something wrong with the original rom install from OnePlus.
Click to expand...
Click to collapse
This Devs solution works and i appreciate his work. And appreciate your attempts but didn't work for me So ....
nujackk said:
This Devs solution works and i appreciate his work. And appreciate your attempts but didn't work for me So ....
Click to expand...
Click to collapse
It's good that you found a band-aid fix.
nujackk said:
That never worked for me and others, Always resulted in either bootloop or booting back to previous build
Click to expand...
Click to collapse
Of course I tried that solution first, it didn't work on my device.
I'm glad it did on others' devices, kudos to you for posting it (and I DO appreciate your work), but this is the only one that worked on mine. Why? Who knows. I also followed another guide that didn't work. Or else I wouldn't have wasted all my time making this (it took many, many hours to assemble). I'm not saying it's the best solution (I really hope someone just uses what I put in the other thread and assembles it into an easier format for others to use), but I have a full time job (2 actually) so I can't work on it anymore. But it works, no data loss, and TWRP can be installed. Until the next incremental update comes out, then I'll post another version using the tools I used for this, if your build doesn't work on my device. But only when I have the time...
g96818 said:
It's good that you found a band-aid fix.
Click to expand...
Click to collapse
LoL band-aid fix... Call it whatever you want, it works.
It's actually a patched 11.0.8.3.KB05AA with the incremental update applied to it for 11.0.9.9.KB05AA. So it flashes to the active slot and TWRP / rooted custom kernel can all be installed at the same time, even while you are still rooted with Magisk, and even if TWRP is installed. No data loss. I never claimed perfection on this project, just that it works for me.
Keep doing what you're doing, I'll keep doing what I'm doing. We both just aim to help others anyway. I just couldn't get any other method to work so I came up with this one, extending on the incomplete / abandoned work of others. I didn't come up with Payload extraction. Never claimed to. I didn't come up with fastbootd flashing either.
All the forked and modified code is at my GitHub repo. The fork goes back to several other devs' forks (mine is the 3rd modified fork).
Someone want to point me to the right download for the incremental update to 11.0.9.9.KB05AA? I got a download link but if it's not for this exact ROM, it would be dangerous (I don't know what would break) if I applied it and patched the incremental 11.0.9.9 (which is like a full ROM in the way I distribute it here). I believe the update is 11.0.10.10.KB05AA. I tried downloading as illustrated in the linked thread and it halfway installed (Op8T's don't seem to like the "remove Magisk images" and then install the update method, it totally jacked up my system (like long boot time, alarms didn't work, numbers wouldn't always appear to login to the phone after reboot, etc.), luckily I had backed up Super in TWRP and that fixed it (upon a restore). The one someone told me was the official link to the incremental update did not work with the Linux program I hacked, so it's either incapable of patching an incremental 2x, or I got the wrong file downloaded. My life is so crazy at the moment I don't have time to screw up my phone just to get the incremental update downloaded on my phone and extract it, so if anyone has already done that, please let me know.
mslezak said:
Someone want to point me to the right download for the incremental update to 11.0.9.9.KB05AA? I got a download link but if it's not for this exact ROM, it would be dangerous (I don't know what would break) if I applied it and patched the incremental 11.0.9.9 (which is like a full ROM in the way I distribute it here). I believe the update is 11.0.10.10.KB05AA. I tried downloading as illustrated in the linked thread and it halfway installed (Op8T's don't seem to like the "remove Magisk images" and then install the update method, it totally jacked up my system (like long boot time, alarms didn't work, numbers wouldn't always appear to login to the phone after reboot, etc.), luckily I had backed up Super in TWRP and that fixed it (upon a restore). The one someone told me was the official link to the incremental update did not work with the Linux program I hacked, so it's either incapable of patching an incremental 2x, or I got the wrong file downloaded. My life is so crazy at the moment I don't have time to screw up my phone just to get the incremental update downloaded on my phone and extract it, so if anyone has already done that, please let me know.
Click to expand...
Click to collapse
Better to install the full ROM
Download Oxygen Updater in app store and select your device AA for global and Ba for European device.
Go to settings, system update wait til 100% and Don't reboot yet if you want to keep Root
Go to Magisk and install ota in inactive slot
5star02707 said:
Better to install the full ROM
Download Oxygen Updater in app store and select your device AA for global and Ba for European device.
Go to settings, system update wait til 100% and Don't reboot yet if you want to keep Root
Go to Magisk and install ota in inactive slot
Click to expand...
Click to collapse
I think maybe you misunderstood what I did in this thread. I patched a full ROM with the incremental update of 11.0.9.9.KB05AA. So while OnePlus does not have a full ROM available for download (yet), it is available for download here.
Yeah the method you propose is the "normal" rooted way, but if you're rooted already it forces you to full ROMs not OTAs. You'll be on 11.0.8.3.KB05AA. The goal here is to get on 11.0.10.10.KB05AA (someone NOT ROOTED could download the OTA update using Oxygen Updater and upload it here so I could make a patched version for those that want to keep their root / custom kernel / TWRP / etc and avoid the hassle of unrooting first, which wipes your data partition). At least my Oxygen Updater won't let me download incremental updates even with Magisk Images removed (don't try this unless you're on Op8 / Op8 Pro; some people are having big system update issues on Op8T incremental hence why this thread exists.) It jacked up my system pretty bad (Magisk images removed, Settings / System / System Updates method) until after a boot.img and super restore from TWRP. Not all devices were setup the same (mine is a US carrier converted to US KB05AA). To my knowledge, no direct download has been posted for KB05AA incremental update. Here or on TG. If you have found one, please post a link here. The only one out I've seen works on European ROMs. OnePlus always does KB05AA last for whatever reason.
11.0.10.10.KB05AA posted with caveats - please back up your data as suggested in case the Phone Services APK doesn't fix your SIM after a flash, and you end up formatting the data partition. You may want to try some other methods or just plan on restoring (not with TWRP Alpha in my experience).
mslezak said:
Guys, bad news. So 11.0.10.10.KB05AA incremental does something to the data partition and kills your SIM access.
...
Click to expand...
Click to collapse
I successfully update from 9.9 to 10.10 including keeping root. I have no issues with my Sim card. So, for me, the update is fine.
However, I believe that the 10.10 update includes a key change. This results in the data partition being unreadable if you swap back to the previous slot after the update. I found this out by doing just that using TWRP.
But syncing the 10.10 firmware to the inactive slot fixes this. It might be possible (I haven't tried it) to just sync the keymaster partition to the inactive slot and then restore 9.9 (excluding keymaster).
BillGoss said:
I successfully update from 9.9 to 10.10 including keeping root. I have no issues with my Sim card. So, for me, the update is fine.
However, I believe that the 10.10 update includes a key change. This results in the data partition being unreadable if you swap back to the previous slot after the update. I found this out by doing just that using TWRP.
But syncing the 10.10 firmware to the inactive slot fixes this. It might be possible (I haven't tried it) to just sync the keymaster partition to the inactive slot and then restore 9.9 (excluding keymaster).
Click to expand...
Click to collapse
Can you explain how you managed to update it? I'm screwed at this point anyhow, would like to hear how you did it. Are you just saying when you update flash to both slots and the data is still readable? Instead of flashing to active only? I still have the extracted / patched ROM, not going to try it out now (or for a while) unless I know someone has figured out a way to make it not break the system data. (Note: I'm on a very hacked phone; it's a carrier T-mobile originally fastbootd converted to Global, then updated on Global since then). I realize most people probably don't have a phone that's been altered this much. Then the easier methods are more likely to work. I'm also running a custom fork (mine) of RadioActive kernel (just tweaked how I like it, wakelocks blocked to save idle battery, some GPU frequencies added, etc). I tried running just the patched boot.img with Magisk but still Phone Services was busted.
@mslezak, When I get an update I:
- use a terminal session (you could also use ADB) to restore the stock boot and recovery (this way I don't lose root yet)
- install the update but don't reboot
- copy the new boot image and patch it
- turn on airplane mode (to avoid SafetyNet and certification issues in the next step)
- reboot the phone and the updated system comes up
- flash the patched boot image and TWRP in fastboot/bootloader
- reboot and disable airplane mode
This is basically @osm0sis' process from https://forum.xda-developers.com/t/...ices-platforms.2239421/page-149#post-84764713
No, I'm not saying flash to both slots, because that will make it impossible to fall back to the current system if the update fails (though this is meaningless if you're manually flashing partitions).
I've got into the habit of syncing active to inactive (after I'm happy with the update) simply because it's required when going from OOS to a custom ROM (I use a shell script based on the LineageOS sync zip). And, after the sync, I can now access the data partition from the inactive slot (which wasn't the case just after the update due to the different keys).
mslezak said:
Can you explain how you managed to update it? I'm screwed at this point anyhow, would like to hear how you did it. Are you just saying when you update flash to both slots and the data is still readable? Instead of flashing to active only? I still have the extracted / patched ROM, not going to try it out now (or for a while) unless I know someone has figured out a way to make it not break the system data. (Note: I'm on a very hacked phone; it's a carrier T-mobile originally fastbootd converted to Global, then updated on Global since then). I realize most people probably don't have a phone that's been altered this much. Then the easier methods are more likely to work. I'm also running a custom fork (mine) of RadioActive kernel (just tweaked how I like it, wakelocks blocked to save idle battery, some GPU frequencies added, etc). I tried running just the patched boot.img with Magisk but still Phone Services was busted.
Click to expand...
Click to collapse
Thats not very hacked/hacked at all, and quite a few use that setup
xstefen said:
Thats not very hacked/hacked at all, and quite a few use that setup
Click to expand...
Click to collapse
LoL I gave up fastbootd flashed to 11.0.10.10.KB05AA and formatted data, let Google download everything it backed up, and am back in business. Just have a lot of apps to login to / Magisk modules to add / etc.
So yeah my patched 11.0.10.10.KB05AA works but the data must be formatted or the SIM doesn't work (at least for me; I don't know if anyone else has tried it since I just posted it a few hours ago; it could be that it works for some without causing issues, I don't have any idea). The goal was to not have to mess up the data partition.... but I can't control what OnePlus does in their updates... Try what worked for others posted here first I'd suggest, or just make solid backups of everything knowing you're going to likely need to reinstall / re-login to everything and format the data partition. New pin, new fingerprint, etc. Re-login to your wifi blah blah.
It's still a full unreleased ROM so I posted it for those that don't mind taking backups (outside of TWRP) if they want to keep root & TWRP on the new release... Yeah a pain to setup if you aren't warned to use another backup method (maybe there is a better backup method, maybe Migrate (app store early access) is developed enough for easy transfer now, I know many people said it worked well in the past but haven't been following the updates. Still free).
It dawned on me later that since the only thing that didn't work using this method going from 11.0.9.9.KB05AA to 11.0.10.10.KB05AA was phone services, that I should just include the working version in this post. Since I already did it the hard way and restored everything back to normal. AS I SAID ABOVE, IF PHONE SERVICES ISN'T ENOUGH TO FIX THE ISSUE, PM ME AND I CAN EXTRACT MORE RELATED FILES UNTIL IT WORKS AGAIN. Unfortunately, I can't just downgrade to 11.0.9.9.KB05AA and keep trying fastbootd over and over again as I don't have the time.
g96818 said:
I've mentioned it multiple times for people having issues. They need to use the unbrick tool cause there is something wrong with the original rom install from OnePlus.
Click to expand...
Click to collapse
The whole point of this is to AVOID the unbrick tool, reinstalling an outdated version, updating each new ROM build since the brick tool was made, and starting over clean. I think... Have a hunch at least we're almost there on 11.0.10.10.KB05AA with an APK install... Although just backing up everything first will always work (if you don't mind formatting your data partition) just as it's posted here already. Always an issue for us rooted users (especially on Global) since we're always last in line to get a full ROM. This IS a full ROM, payload extracted and patched with incremental updates. Still not available from OnePlus Global (KB05AA) as I checked today, so still relevant.
Ladies and Gents,
I have removed some off topic posts from this thread because I believe we could express the same meaning in more civil words. Please try to do that from now on.
Thanks.
Jerry
FSM

Categories

Resources