Ok, I have a phone with unlocked boot loader and FRF50 on it.
I put the original system recovery on (it had another prior to my ownership), but when the OTA update arrives, I get the following error:
Verifying current system...
assert failed: apply_patch_check("/system/framework/am.jar", "efccd3...:, ea...: )
E: Error in /cache/836691a1ca8b.signed-passion-FRF91-from-FRF50.836691a9.zip
(Status 7)
Installation aborted...
Any ideas???
Thanks!!!
have you tried doing the line of updates start from frf50 then do frf83 then frf83b then do frf91
No, but based on the error it looks like it was trying to go from FR50 (installed) to FRF91 based on the update file name....
I'm not doing this manually, I'm letting the OTA update take care of it....
Can you point me to the update images? I'd like to get it to do OTA updates again, but if I have to do manual I guess I'll deal with it...
I wonder if it is a problem with the v 2E recovery?
Hey Pete,
I am getting the exact same issue with my nexus over here in Oz. I jumped on the early release and manually installed and now it wont update from frf50-frf91 OTA with the above error.
Very frustrating. I wondered if a wipe data/factory reset then wait for another OTA might work. I am unsure of exactly how much that will affect the phone though. I would rather not lose pictures and movies on the SD card and apps would be a PITA to get back on with my settings.
Maybe the manual updates might be a good place to start.
What version of the recovery do you have on your phone?
pwkpete said:
What version of the recovery do you have on your phone?
Click to expand...
Click to collapse
I am a bit of a noob Pete when it comes to Android and Nexus. I am not sure on the version or even how to check. Can you give me a hint ??
I have an un-rooted stock phone which I downloaded the FRF 50 update to when it first came out. I have made no other changes to it.
Give me a call centre skills based routing or call recording system and I'm your man, but smart phones are not in my skillset... I am trying to learn though. I just learnt what the ADB is.
you are on stock recovery and rom...and you wont anything in your SD card it doesnt wipe sdcard, only the phone setup, and if you have the backup feature on phoen you wont really lose the apps either
you can always do the #*#CHECKIN#*# on dial pad then go to settings and check for updates to see if you can get the OTA
i did it mainually it i couldnt wait any longer for the OTA.. so its not really hard to do it maunally lol
Even if I do that with my FRF50 phone, it just says success...
It took a week for the OTA update to reattempt an install. (and fail)
I did download a full signed FRF91 which I'm going to try applying soon, I hope after that OTA's will just be automatic...
Fixed at last !!!
I went through this forum.xda-developers.com/showthread.php?t=717870
Which took me back to epe76. I then went to frf85b with a link further in the same thread and got an instant OTA update to frf91.
YAY FIXED !!!!!!!!!!!!!!!!!!!
Forgot to post here, I downloaded the complete FRF91 signed and just installed it. Contains everyting including radio.
I don't have the link anymore, but I recall it contained the words, "FRF91", "signed", "passion"....
That should get you there...
Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
phonic said:
Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
Click to expand...
Click to collapse
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
The two devices differ in more respects than a simple assert check, including having different recovery.fstab files, which are used to make and configure recovery.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
mateorod said:
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
Click to expand...
Click to collapse
Thanks, that's definitely a better solution versus a work around.
Though the safety check bypassed in the OP wouldn't cause any issues since it was redundant and unnecessary. The OTA update already checks build.prop for the model info and all the apks/odexes it updates, so it would be impossible to flash it on a non-compatible device. But you raise a very valid point about incorrect ROMs and other things. The 3G unit probably needs it's own forum.
Did you have to make any real modifications to CWM outside of changing grouper to talapia?
The 3G unit probably needs it's own forum.
Click to expand...
Click to collapse
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Ather said:
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Click to expand...
Click to collapse
Woohoo! Thanks.
I had some issues when I did the update. It gave me some errors, and aborted, but then I found a link that had the update and I got it to update. This happened on my n4 and n73g. Well, for some reason, the recoveries got deleted so I had to reinstall them. I was able to use the goo manager to restore TWRP on my N4, but it wasn't working on my N7 so I had to side load it. After this, I noticed that google now wasn't working on my n4, and the volume rocker on my n7 had some issues. I went in and wiped the cache and dalvik cache and rebooted. Google now works on my N4, and while the volume gets adjusted on my N7, it won't make the beep every time I push up or down on the rocker indicating the volume level. I haven't noticed any other issues, but I haven't really delved into my devices. I may try to do a factory wipe and return everything to stock just to see what went wrong in the first place and to see if I can do anything different I still can't figure out how to get ADB running on my computer, so yes I used one of the tool kits to load everything. I know the OP's position on tool kits, but I just can't figure out how to get ADB running manually, AND it takes so long to download and install everything unless I am installing things I don't even need.
Nexus 7 takju firmware update
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Do you have the Galaxy Nexus or Nexus 7? If Galaxy Nexus, you of course would want to check those forums. As for the updates, you should normally see a notification alerting you of the update, but you can also check for it in settings/about phone/system updates. Otherwise the appropriate forum for your device will have links to the update files. Good luck!
lil help please
I updated to 4.2.1 with the OTA zip file using TWRP and voodoo root keeper installed. It flashed just fine. Rebooted with update. My root access is funky though. SuperSU is still there and I can access root file threw root explorer but I can't mount it as writable and when I install a new app that needs root access it never asks for it. Does superSU need to be updated? There is no update available for it.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
The N73G ships with an interim 4.2 build, which is JVP15S. There are some significant differences between this and JOP40C, which is the first update you will get out of the box. I imagine 4.2 wasn't fully finalized prior to hardware production, and they didn't want to hold it up until they were ready (wise choise!). In my case, within an hour after opening my N73G and turning it on, I had the 40C update notification. I applied this prior to rooting/modding/etc. ONLY after you are on 40C can you get the upgrade to 40D (4.2.1). Google pushes out incremental patch updates, so you can't skip a version.
So you have two options:
1) Apply update #1 and wait for #2 and then root/etc.
2) If you don't want to wait, and your device is still basically brand new and not setup (too much), AND assuming you want to root, customize, etc., just download the 4.2.1 system image from Google and fastboot flash it. You'll need to unlock the bootloader anyway, which will wipe your system, so now's a perfectly good time to do everything at once. Unlock bootloader, flash 4.2.1 stock (40D FULL IMAGE), flash custom recovery, install su zip, install any other mods (which is limited really to basic stuff and a custom kernel right now), enjoy.
Andoid 4.2.1 update
adamhlj said:
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Click to expand...
Click to collapse
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Vlad7777 said:
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Click to expand...
Click to collapse
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
phonic said:
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
Click to expand...
Click to collapse
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Vlad7777 said:
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Click to expand...
Click to collapse
You can place the "su zip" anywhere you like on the internal storage. When you get into custom recovery (CWM or TWRP), you can select "Install ZIP" (or something along those lines) and it will bring up a file system explorer that will let you select the one you want to install.
CWM and TWRP are both custom recoveries. They replace the stock, and very useless, recovery and give you many more advanced features. Things like flashing zip files, making nandroid backups, etc. You need to flash them to your "recovery" partition. It's a very easy process, but will require some specialized software. There are many guides and toolkits (if that's what you want to use) online. Just make sure you use the Talipia recovery (which exists now in the 3G forum).
I recieved the first OTA update for lollipop and it installed correctly. Now I went to download the large 700+mb 2nd OTA update and after the download completes my phone resets. It goes into installing the update, however about 1/4 of the way through the update, i get the dead droid screen flash on my screen and then my phone reboots back to 4.4.4 and tells me that the updated was unsuccessful. I have a moto x XT1060 dev ed, build KXA21.12-L1.26-4 on system version 212.166.4.
I'm stumped on what to try next. I have already returned everything back to stock and downloaded all updates and I get to the same point and get the same results. I've wiped all data, system, cache, and davlik, installed stock recovery and still get the same results. i've removed super user rights to see if that would work but it did not. I'm at a lose at what to try next. Anyone have any other ideas?
[email protected] said:
I recieved the first OTA update for lollipop and it installed correctly. Now I went to download the large 700+mb 2nd OTA update and after the download completes my phone resets. It goes into installing the update, however about 1/4 of the way through the update, i get the dead droid screen flash on my screen and then my phone reboots back to 4.4.4 and tells me that the updated was unsuccessful. I have a moto x XT1060 dev ed, build KXA21.12-L1.26-4 on system version 212.166.4.
I'm stumped on what to try next. I have already returned everything back to stock and downloaded all updates and I get to the same point and get the same results. I've wiped all data, system, cache, and davlik, installed stock recovery and still get the same results. i've removed super user rights to see if that would work but it did not. I'm at a lose at what to try next. Anyone have any other ideas?
Click to expand...
Click to collapse
I was having this same problem, but here is the process I went through to get through the full update to 5.1:
I saw this post this morning and started with it: http://forum.xda-developers.com/moto-x/general/help-lollipop-update-unlocked-bootloader-t3201426 I had previously downloaded the version of 4.4.4 referenced in it.
I don't have RDSLite installed so I moved on to this post: http://forum.xda-developers.com/moto-x/general/faq-how-to-prepare-ota-update-carriers-t3126425 and used Option #5 since I already the Android SDK tools on my computer. After going through all the steps I have successfully stepped through all three updates, rebooting the phone after each whether it helps or not. My phone is currently optimizing apps after the second 5.1 update.
For reference I was on the most current version of 4.4.4, rooted with TWRP with no modifications to any system/bloatware apps. I originally tried Option #6 in the above thread which allowed me to take the first 5.1 update but the second update failed in the same way you described.
Hope this helps, and good luck!
Thanks for the post. I was reading through that post late last night and I was going through option #2. I didn't read further down to option #5, but that worked perfectly. My phone is optimizing apps as we speak.
Hi,
Sorry of this is a bit of a newbie question but:
What is the purpose of each of the 3 different update zip files ?
And do I have to apply them all - and in what order ?
In my case, I am about to update to B389, and I have downloaded 3 files for VIE-L29C636B389 (currently on VIE-L29C636B130), and I have an update.zip, an update_full_VIE-L29_hw_spcseas.zip and an update_data_full_public.zip.
I was planning on doing the first two by the dload method (with reboots in between), but the update_data_full_public.zip doesn't appear to have an update.app, so how do I load that ? (I do have TWRP on my phone, so could probably figure it out - eventually).
Cheers,
SZ
same question
I read somewhere that it should be flashed in that exact order. i'm guessing that is the same procedure as with auto OTA updates, except now we have rooted phones, so bye-bye to auto updates. I am currently on VIE-L29CB636B387 and i received an automatic Huawei notification of a new version (VIE-L29CB636B388) about a week ago. I tried to update to that version in System Update-Quick Update, but that didn't work (surprise!). There was no issue though as when I rebooted it just went back to 387. However, I now have a red "New Version" notification in my System Update. Please tell me how your upgrade went if you went ahead and flashed 389. I have the three files already from filefinder, i also have TWRP and/or I could use adb fastboot to install. Thanks in advance.
Hey,
I am not sure I want to proceed on the basis of something that somebody 'read somewhere' ....
Anyhow - I've not run these updates yet, as I wanted to backup my phone first, but TWRP keeps blowing up with an error in the middle of the backup, so I am not going to try anything until I get to the bottom of that.
Will let you know if/when I ever go ahead!
Cheers,
SZ
Hi,
TWRP blowing up during NAND backups? thats not a good thing. Upon the advice of a forum member (xzanium) I flashed TWRP 3.1.1-1 instead of TWRP-3.2.1-0-vienna. No hitches so far, solid backups and no hiccups in flashing SuperSU, also got xposed to work seamlessly and other stuff. I hope you are able to resolve the issue you mentioned and get around to getting VIE-L29CB636B389 on your phone.
Well good luck to you, and post here any progress if you would.
SZ,
I have an idea on what the purpose of each of the 3 different update zip files are for and whether you have to apply them all - and in what order.
Since I could make a NAND backup using TWRP without issues, and there was an OTA update notice for an upgrade to VIE-L29CB636B388 which I couldn't upgrade to while rooted, I decided to unroot in order to upgrade to that. First i did the requisite steps - uninstalled the xposed framework and proceeded with the full unroot with SuperSU. Then I performed the dload method to flash the update.app that I extracted from the update.zip.
It was here where i hit a snag. What followed was, I found out that Huawei needs a verified stock rom, meaning it has to be a fullOTA-MF-PV in order that the bootloader could be relocked. So I tried my luck and downloaded the stock ROM VIE-L29C636B370 and flashed that. Success! From there, and several auto upgrades later I was back to L29C636B370. Reinstalling my Google account also locked back FRP. At this point i am full stock EMUI 5
Now, to answer your question. When I tried to upgrade to VIE-L29C636B388 via system update quick update. I only saw one file - update.zip therefore this must the only one needed for incremental patches. The same holds true with update_data_full_public.zip as I later learned when I decided to use the proxy upgrade method in MT filefinder . It applied a 2nd patch. The third file, namely, update_full_VIE-L29_hw_spcseas.zip was not required for this incremental update. In fact, the update process was cut short and an error message appeared that the file could not be located, even though i copied that to the HwOUC folder. It appears that this was deleted before the fullOTA update could finish during the incremental update process. Clearly, this last zip is not necessary for incremental updates. So this must be the package which delivers the rest of the ROM, or the parts of it that needs to be changed.
So, obviously what "I read somewhere" was legit. I hope that answers your question.
cheers!
mm
Anyone else having a problem with the OTA update failing to install?
It'll keep trying over and over and a notification of failure occurs.
I have to "FORCE STOP" for the "Motorola Update Service" in order for it to stop trying.
The filesize is 150815511.
Looking at https://mirrors.lolinet.com/firmware/moto/beckham/official/RETUS/ it would seem *1-6 isn't listed, but rather it jumps to *2-3.
I ended up manually doing the "step"s in "flashfile.xml" from "BECKHAM_PPWS29.183_29_1_2_subsidy_DEFAULT_regulatory_DEFAULT_CFC_SVC.xml.zip" I took from LMSA to Slot-A.
I'm thinking the whole magisk thing was the culprit, but I'm still going to reinstall it.
Again, like last time, at some point Magisk seems to lose it's SU abilities. The thing is, there was NO version change for my device (not magisk) this time, so there was no reason for the "boot" partition to be overwritten.
This time, after rewriting boot, I updated the Manager and Magisk itself.
Next time, I might just copy out the boot partition and diff it with the patch to see if the patch that was written into boot was overwritten.
Hmm, for some reason I wasn't getting the update failure notification, but I'm guessing my system HAD been trying to update, because when I would wake up, my battery would be much lower than usual.
Looking at the logcat, it would appear that an update to PPWS29.183-29-1-9 exists and is trying to be installed.
Back to doing what I did before to make it happen <sigh...>.
vindicatorr said:
Hmm, for some reason I wasn't getting the update failure notification, but I'm guessing my system HAD been trying to update, because when I would wake up, my battery would be much lower than usual.
Looking at the logcat, it would appear that an update to PPWS29.183-29-1-9 exists and is trying to be installed.
Back to doing what I did before to make it happen <sigh...>.
Click to expand...
Click to collapse
What did you have to do before? This update that keeps failing to install seems to have broken my Google Pay.
gullzway said:
What did you have to do before? This update that keeps failing to install seems to have broken my Google Pay.
Click to expand...
Click to collapse
Sadly, what I did before does not make the other boot slot boot.
Essentially, I manually used fastboot to flash the partition images for version *1-6 following the steps in the xml file zipped up.
You can find recovery images from links in other threads dedicated to them or use LMSA (there was no *1-9 version when I last checked) to download it and find the file(s) in the ProgramData folder.
My understanding is that if you see the steps flashing some images specifically to the one dedicated to slot_b, then you want everything else flashed to slot_a (fastboot --set-active=a).
After that, I "think" the incremental upgrade process is supposed to download the diff (~100MB) between the 2 versions, then unpack the payload to slot_b and then set the active slot to "b".
But even when I used twrp to erase ALL partitions listed in the xml, then manually flashed *1-6 to slot a, it should have done a complete copy of slot_a and the upgrade diff to slot_b, but for whatever reason, even though it DOES seem to happen (looking at the logcat output), the boot fails to occur and it tells me something along the lines of trying again or wiping everything. So then I just set the active slot back to "a" (*1-6).
I didn't want to bother wiping out all of my programs and stuff, so I'm just going to wait for the *1-9 recovery and manually flash that.
I saw NO reason for the boot to fail given I wiped everything but userdata (wiped cache as well).
In the meantime I just disabled the motorola update service.
As for Google Pay, I don't know if you got it working before using the "dg.db" method (https://medium.com/@raphnguyen/andr...-work-with-magisk-through-tasker-2468e720b566).
That's what I used to get my card scanned into it.
So, I found the 1-9 version now registers as existing in LMSA.
But again, sadly, for some reason, it still doesn't want to boot that version. I went back to 1-6 for now and posted a reply to a thread on the Lenovo forum regarding this. I'm not sure if their issue is like mine or not.
I really don't want to delete my userdata partition and can't think of why an update would require it.