Database Users

Can't update to 4.1.1. Please Help!!!

Let me start off by saying that I have tried everything I can find. I have tried the ADB sideload method. I have tried to go to the firmware it's trying to upgrade from. I've tried both stock recovery and CWM. I'm not a n00b when it comes to unlocking, rooting, flashing etc. Anyway, here's the story. My dad bought a Nexus 7 32GB and it kept asking him to update to 4.1.1 for the landscape rotation. The first time he tried it, it failed because it was trying to update from a specific firmware that he didn't have. He has JRO03S. It was trying to update from JRO03D to the new 4.1.1 update. It fails every time no matter what. Like I stated earlier, I've tried both stock recovery and CWM, but they both error out. I've included some pictures of the error in CWM and the about device screen, but nothing from stock recovery. I was too lazy to put the stock recovery back on there to take a picture, but if it's necessary for a solution then I will. Yes, I have searched here and google. Every solution that I have found has not worked. If anyone can help me then you would be a lifesaver. Thanks for taking the time to read through all this. If I'm not being specific enough then please let me know what else you need to know.

The assert() failure you see in the custom recovery is to be expected - it is the installer script checking to make sure that someone is attempting to apply the update to an exact version of the factory software. In this case, exact also means the version of the recovery boot in use which is trying to process the update.
In general, you can not use a custom recovery with an unmodified OTA installer file because of that first assert.
The OTA updates are NOT complete re-installs; they use a patching tool to fix up existing files on the device. That allows their size to be quite a bit smaller than a full new install. Read that again - existing files!.
It is my impression (someone correct me if I am wrong) that the installer scripts also do checksums on each individual target files that are intended to be patched, and if a single one of them fails, the install will spontaneously abort - part way through the process.
That has serious consequences, as now a failed partial install will block a subsequent attempt - if any of the target files get successfully patched, they will no longer have the checksum expected by the update script - they will no longer have the (old file) checksum. [ note I might be fuzzy on whether the individual file checks cause a wholesale abort of the installation session, or they cause a per-file abort ]
In general, you can only use an OTA patch kit on a modified phone if you have not altered any of the files involved in the patching process, and you are using the stock recovery. If you want to use a custom recovery, for certain you need to diddle the update .zip file at a minimum to remove that initial assert(), and also verify that you have not removed or fooled with any of the files from the original distro that are involved in the patching process.
Given where you are, I suggest you make backups (possibly including using Titanium Backup), and start over with the phone (flash a stock 4.1.x or 4.2.x installation or a custom ROM). OR, if you happen to have a near bone-stock backup (meaning the only thing you have done is install the Superuser.apk and su binary), you could restore that, restore the stock recovery, and then proceed with the update from there.
good luck

bftb0 said:
The assert() failure you see in the custom recovery is to be expected - it is the installer script checking to make sure that someone is attempting to apply the update to an exact version of the factory software. In this case, exact also means the version of the recovery boot in use which is trying to process the update.
In general, you can not use a custom recovery with an unmodified OTA installer file because of that first assert.
The OTA updates are NOT complete re-installs; they use a patching tool to fix up existing files on the device. That allows their size to be quite a bit smaller than a full new install. Read that again - existing files!.
It is my impression (someone correct me if I am wrong) that the installer scripts also do checksums on each individual target files that are intended to be patched, and if a single one of them fails, the install will spontaneously abort - part way through the process.
That has serious consequences, as now a failed partial install will block a subsequent attempt - if any of the target files get successfully patched, they will no longer have the checksum expected by the update script - they will no longer have the (old file) checksum. [ note I might be fuzzy on whether the individual file checks cause a wholesale abort of the installation session, or they cause a per-file abort ]
In general, you can only use an OTA patch kit on a modified phone if you have not altered any of the files involved in the patching process, and you are using the stock recovery. If you want to use a custom recovery, for certain you need to diddle the update .zip file at a minimum to remove that initial assert(), and also verify that you have not removed or fooled with any of the files from the original distro that are involved in the patching process.
Given where you are, I suggest you make backups (possibly including using Titanium Backup), and start over with the phone (flash a stock 4.1.x or 4.2.x installation or a custom ROM). OR, if you happen to have a near bone-stock backup (meaning the only thing you have done is install the Superuser.apk and su binary), you could restore that, restore the stock recovery, and then proceed with the update from there.
good luck
Click to expand...
Click to collapse
I appreciate your response. I think I may have left some things out. I am not rooted. I have only flashed the custom recovery and unlocked the bootloader. That's it. If I have to start completely over then I will. I have already tried that though. I'm willing to try any solutions that anyone has. Thanks again for your response.

Evo4eva said:
I appreciate your response. I think I may have left some things out. I am not rooted. I have only flashed the custom recovery and unlocked the bootloader. That's it. If I have to start completely over then I will. I have already tried that though. I'm willing to try any solutions that anyone has. Thanks again for your response.
Click to expand...
Click to collapse
OK. I saw the "ClockworkMod Recovery v6.0.1.0" banner and assumed rooting.
Well, let's look at the assert that you show failing (first image)
assert failed: apply_patch_check("EMMC: /dev/block/platform/sdhci-tegra.3/by-name/LNX:5007....)
Click to expand...
Click to collapse
The "LNX" partition is the "boot.img" area of the device - the kernel and ramdisk for your regular OS boot.
The fact that the assert fails means one of two things:
- that your boot partition has been modified from "stock", or
- the update .zip file is intended for some other version of a factory rom.
One of those two things. Would be sort of surprising if the OTA process mis-judged which factory release was currently on the phone. From the first image, it sure looks like the update package is intended for a from/to migration of:
JRO03S -> JZ054K
and your status screen does show JRO03S. Are you sure don't have a slightly modified boot partition?
I'm not sure what the four parameters in the assert statement are - I would think that at least one of them has to be a checksum. As the LNX (boot) partition is just a binary blob there is no filesystem present; perhaps the shorter numbers are byte lengths within the partition.
If you want to download the same OTA and fool with it (for instance to omit that first assert in META-INF/com/google/android/updater-script, re-zip it & try with TWRP), this link seems to be working:
http://android.clients.google.com/p...signed-nakasi-JZO54K-from-JRO03S.d41da8f6.zip
That's the same place the OTA process gets it from (and stuffs it into /cache along with a recovery-command file).
good luck
---------- Post added at 02:22 PM ---------- Previous post was at 02:04 PM ----------
Update -
On a lark I downloaded the OTA (referenced in the URL above) and took a look at
META-INF/com/google/android/updater-script
the assert that you see failing is the very last check before it actually begins the patching process!
That means that all the other checks (things in the /system partition) passed before that last check failed.
That certainly seems to imply a boot image that has been diddled with. Since you still show JRO03S (I'm not sure about the kernel string - I don't know what it is supposed to be), most likely this would have been a flashable zip that modified something only in the ramdisk. Does that sound familiar?

bftb0 said:
OK. I saw the "ClockworkMod Recovery v6.0.1.0" banner and assumed rooting.
Well, let's look at the assert that you show failing (first image)
The "LNX" partition is the "boot.img" area of the device - the kernel and ramdisk for your regular OS boot.
The fact that the assert fails means one of two things:
- that your boot partition has been modified from "stock", or
- the update .zip file is intended for some other version of a factory rom.
One of those two things. Would be sort of surprising if the OTA process mis-judged which factory release was currently on the phone. From the first image, it sure looks like the update package is intended for a from/to migration of:
JRO03S -> JZ054K
and your status screen does show JRO03S. Are you sure don't have a slightly modified boot partition?
I'm not sure what the four parameters in the assert statement are - I would think that at least one of them has to be a checksum. As the LNX (boot) partition is just a binary blob there is no filesystem present; perhaps the shorter numbers are byte lengths within the partition.
If you want to download the same OTA and fool with it (for instance to omit that first assert in META-INF/com/google/android/updater-script, re-zip it & try with TWRP), this link seems to be working:
http://android.clients.google.com/p...signed-nakasi-JZO54K-from-JRO03S.d41da8f6.zip
That's the same place the OTA process gets it from (and stuffs it into /cache along with a recovery-command file).
good luck
---------- Post added at 02:22 PM ---------- Previous post was at 02:04 PM ----------
Update -
On a lark I downloaded the OTA (referenced in the URL above) and took a look at
META-INF/com/google/android/updater-script
the assert that you see failing is the very last check before it actually begins the patching process!
That means that all the other checks (things in the /system partition) passed before that last check failed.
That certainly seems to imply a boot image that has been diddled with. Since you still show JRO03S (I'm not sure about the kernel string - I don't know what it is supposed to be), most likely this would have been a flashable zip that modified something only in the ramdisk. Does that sound familiar?
Click to expand...
Click to collapse
All I did was use the nexus 7 toolkit to unlock the bootloader and flash CWM touch. Yes, I do think CWM was a zip file. I'm not sure though. It's been a while since I did all that. I didn't flash anything else though.

Evo4eva said:
All I did was use the nexus 7 toolkit to unlock the bootloader and flash CWM touch. Yes, I do think CWM was a zip file. I'm not sure though. It's been a while since I did all that. I didn't flash anything else though.
Click to expand...
Click to collapse
Well, I don't know what to tell you then. Everything looks kosher except for the fact the installer is complaining about the existing boot partition not matching what it is looking for. If you took that check out, and let the patcher-thingy do its work, it could easily bork your boot image and render your tablet OS unbootable.
At this point, if you are intent on staying on 4.1.x, I suggest you install Titanium Backup, back up all your User apps & data (not the system apps), and install the full factory image for JZO54K from here
To be on the safe side, make a backup of everything on your "SD card" - after you have done the Titanium Backup.

bftb0 said:
Well, I don't know what to tell you then. Everything looks kosher except for the fact the installer is complaining about the existing boot partition not matching what it is looking for. If you took that check out, and let the patcher-thingy do its work, it could easily bork your boot image and render your tablet OS unbootable.
At this point, if you are intent on staying on 4.1.x, I suggest you install Titanium Backup, back up all your User apps & data (not the system apps), and install the full factory image for JZO54K from here
To be on the safe side, make a backup of everything on your "SD card" - after you have done the Titanium Backup.
Click to expand...
Click to collapse
Well, unfortunately I have already tried that factory image on stock recovery and through ADB. It failed also. I appreciate all the help so far, but it looks like my dad has a bunk tablet. I'll just flash the stock recovery and have him get an exchange. I don't see another option. Thanks again!

Evo4eva said:
Well, unfortunately I have already tried that factory image on stock recovery and through ADB. It failed also. I appreciate all the help so far, but it looks like my dad has a bunk tablet. I'll just flash the stock recovery and have him get an exchange. I don't see another option. Thanks again!
Click to expand...
Click to collapse
Well I would think that is a failure with a different root cause as the factory installs don't really care about what is on the tablet - well, except maybe for a version check of the bootloader, and I do see that JZO54K did have the older v3.41 bootloader. That's a possibility.
What error occurs when you try to flash that factory image?
FWIW, oldblue910 mantains an archive of Nexus 7 factory images. You didn't mention whether or not you were on the WiFi only version (nakasi) or 3G version (nakasig), but he has both on his site.
good luck
PS I note that I never checked if there was a different OTA depending on whether or not the unit in question was 3G vs. WiFi-only, although TBH it would be weird if the wrong one got delivered over the air to the tablet. It does seem quite odd though, that the only thing which doesn't pass the initial OTA assert checks (checksums) is the boot image.

bftb0 said:
Well I would think that is a failure with a different root cause as the factory installs don't really care about what is on the tablet - well, except maybe for a version check of the bootloader, and I do see that JZO54K did have the older v3.41 bootloader. That's a possibility.
What error occurs when you try to flash that factory image?
FWIW, oldblue910 mantains an archive of Nexus 7 factory images. You didn't mention whether or not you were on the WiFi only version (nakasi) or 3G version (nakasig), but he has both on his site.
good luck
PS I note that I never checked if there was a different OTA depending on whether or not the unit in question was 3G vs. WiFi-only, although TBH it would be weird if the wrong one got delivered over the air to the tablet. It does seem quite odd though, that the only thing which doesn't pass the initial OTA assert checks (checksums) is the boot image.
Click to expand...
Click to collapse
It's the WiFi only version. I know this whole situation is weird. I've been rooting and flashing since the G1 and have never encountered anything like this. I did make sure I tried the one that was for the WiFi version and it still didn't work though. Thanks again for all your help.

Phone not booting after attempt to update 4.4

So I got the OTA update to 4.4 on my Nexus 4 4.3. I clicked it and it rebooted, took a few minutes to run some files via dos prompt...Afterwards I ended up at my TWRP screen. I selected "reboot" at the main screen then "system" thinking that the stuff happening at the beginning was the install update to 4.4. Afterwards my phone is no longer booting, like it has no OS. Hindsight, I think I should have done some research before continuing. Need some help? What are my options? Download fresh 4.4 and reinstall or ?

bankmaggot said:
So I got the OTA update to 4.4 on my Nexus 4 4.3. I clicked it and it rebooted, took a few minutes to run some files via dos prompt...Afterwards I ended up at my TWRP screen. I selected "reboot" at the main screen then "system" thinking that the stuff happening at the beginning was the install update to 4.4. Afterwards my phone is no longer booting, like it has no OS. Hindsight, I think I should have done some research before continuing. Need some help? What are my options? Download fresh 4.4 and reinstall or ?
Click to expand...
Click to collapse
Update: I was able to get to the recovery mode hitting down+power. I'm kind of lost at this point. Just give me 4.3 anything at this point.:crying:

I am in the same boat!! Any ideas, i have tried to do a sideload but i get an error installing //sideload.zip
checking for md5 file
skipping md5 check : no md5 file found
warning no file_contexts
file_getprop: failed to stat "/system/build.prop": No such file or directory
e:error executing updater binary in zip '//sideloader.zip'

download factory image and flash it via fastboot..for instructions -->Click Me!

anto.danny said:
download factory image and flash it via fastboot..for instructions -->Click Me!
Click to expand...
Click to collapse
Brilliant, that fixed. Thank you :good:

[Q] OmniRom flashing question

I apologize for the Noob question(s), but does anyone know if the **.zip.md5sum** file as listed below needs to be flashed in conjunction with the actual Rom? If so, do they need to be flashed in a particular order? I haven't been doing so since it appears to be a blank file based on the size. I only ask because ever since switching to OmniRom from GummyRom, my phone seems to get stuck at the Samsung logo screen. About half the time it requires a battery pull because my phone seems to just be stuck at boot. I'm using the latest version of CWM and have read in the Omni thread that switching to the latest version of TWRP resolved the problem. I am just curious if others are or have experienced this problem and what they did to resolve it?
Lastly, I know this is more like a three part question and if I have to post it in another thread I will. But I did try to install TWRP from the Goo Manager app and when the download page loads it doesn't install anything. The page just says it's preparing my download, but doesn't download anything. Any thoughts or suggestions would be greatly appreciated...
I am using a Verizon Galaxy S4
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip 2013-12-08 18:40 193587 KB
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum 2013-12-08 18:40 0 KB

droidzen10 said:
I apologize for the Noob question(s), but does anyone know if the **.zip.md5sum** file as listed below needs to be flashed in conjunction with the actual Rom? If so, do they need to be flashed in a particular order? I haven't been doing so since it appears to be a blank file based on the size. I only ask because ever since switching to OmniRom from GummyRom, my phone seems to get stuck at the Samsung logo screen. About half the time it requires a battery pull because my phone seems to just be stuck at boot. I'm using the latest version of CWM and have read in the Omni thread that switching to the latest version of TWRP resolved the problem. I am just curious if others are or have experienced this problem and what they did to resolve it?
Lastly, I know this is more like a three part question and if I have to post it in another thread I will. But I did try to install TWRP from the Goo Manager app and when the download page loads it doesn't install anything. The page just says it's preparing my download, but doesn't download anything. Any thoughts or suggestions would be greatly appreciated...
I am using a Verizon Galaxy S4
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip 2013-12-08 18:40 193587 KB
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum 2013-12-08 18:40 0 KB
Click to expand...
Click to collapse
First things first, the MD5sum is the checksum of the ROM at buildtime, all you need to do is have this in the same folder as the ROM when flashing and TWRP will verify the checksum of the ROM before installing, so if it is a mismatch it stops you right there.
It should not be flashed.
Its been a while since I used the twrp check-sum someone correct me if wrong.....I verify the MD5 before i put the rom on phone to ensure its a good download.
GooManager has always been flaky on my Skyrocket and on my buddies S3, but that is just me talking, nothing against goomanager. That being said I have always preferred to flash recoveries from the recovery, or odin this ensures (me) that the flash went well.
You can almost always find a zip of the latest recovery for your phone in one of the development threads or you can ask on the S4 Q&A thread if someone has one or if they can get you one. I haven't been to your forum but i'm sure there is a TWRP thread to follow.

OmniRom flashing question
Tweakecho said:
First things first, the MD5sum is the checksum of the ROM at buildtime, all you need to do is have this in the same folder as the ROM when flashing and TWRP will verify the checksum of the ROM before installing, so if it is a mismatch it stops you right there.
It should not be flashed.
Its been a while since I used the twrp check-sum someone correct me if wrong.....I verify the MD5 before i put the rom on phone to ensure its a good download.
GooManager has always been flaky on my Skyrocket and on my buddies S3, but that is just me talking, nothing against goomanager. That being said I have always preferred to flash recoveries from the recovery, or odin this ensures (me) that the flash went well.
You can almost always find a zip of the latest recovery for your phone in one of the development threads or you can ask on the S4 Q&A thread if someone has one or if they can get you one. I haven't been to your forum but i'm sure there is a TWRP thread to follow.
Click to expand...
Click to collapse
Thanks for your answer and suggestion regarding flashing a recovery. I've been doing a lot of reading here on XDA and quite a few have suggested using Flashify to flash recoveries....

Tweakecho said:
First things first, the MD5sum is the checksum of the ROM at buildtime, all you need to do is have this in the same folder as the ROM when flashing and TWRP will verify the checksum of the ROM before installing, so if it is a mismatch it stops you right there.
Click to expand...
Click to collapse
It doesn't work that way for me. I always put the files in the same folder but TWRP 2.6.3.3 always says that there is no md5 file to be found.

Riiquiem said:
It doesn't work that way for me. I always put the files in the same folder but TWRP 2.6.3.3 always says that there is no md5 file to be found.
Click to expand...
Click to collapse
It's because the file extension is wrong.
Zip md5 Verification (looks for file with zipname.zip.md5)
So, if you downloaded these files :
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum
You need to rename "omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum" to "omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5".

AngryHapposai said:
It's because the file extension is wrong.
Zip md5 Verification (looks for file with zipname.zip.md5)
So, if you downloaded these files :
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip
omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum
You need to rename "omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5sum" to "omni-4.4.1-20131208-jfltevzw-NIGHTLY.zip.md5".
Click to expand...
Click to collapse
That explains why mine always reports an error as well. *fixes all future build md5's

Having the same problem MD5 not found while flashing ROM. lemme try renaming. Will say again, if its work

Flashing ROM Fail HELP!!!

So I decided I'm tired of all the bugs in Android 4.4 and wanted to flash the PACMan ROM onto my 2012 Wifi only Nexus 7. So I have my nexus unlocked and rooted but when I go to install the ROM via TWRP V2.6.3.1 I get this error message:
Installing '/sdcard/pac_grouper-nightly-20140121.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found.
assert failed: getprop("ro.product.device") == "grouper" II getprop("ro.build.pr
E:Error executing updater binary in zip '/sdcard/pac_grouper-nightly-20140121.zip
Updating partition files..
Can anyone tell me whats going wrong? I'm terrible at the whole computer thing, unlocking and rooting was tough enough even with the Nexus Root Toolkit.
Thanks

ST2014 said:
So I decided I'm tired of all the bugs in Android 4.4 and wanted to flash the PACMan ROM onto my 2012 Wifi only Nexus 7. So I have my nexus unlocked and rooted but when I go to install the ROM via TWRP V2.6.3.1 I get this error message:
Installing '/sdcard/pac_grouper-nightly-20140121.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found.
assert failed: getprop("ro.product.device") == "grouper" II getprop("ro.build.pr
E:Error executing updater binary in zip '/sdcard/pac_grouper-nightly-20140121.zip
Updating partition files..
Can anyone tell me whats going wrong? I'm terrible at the whole computer thing, unlocking and rooting was tough enough even with the Nexus Root Toolkit.
Thanks
Click to expand...
Click to collapse
Transfer zip to a pc Open up the zip file with winrar or 7zip there is a meta inf folder find the updater script file open with notepad erase the first line it will say something like asset get prop ect...... save the file transfer back to tablet it will now flash. Or use cwm to flash. I can do it for you if u send me the updater script file.

Even I have the same problem and if you flash a modded zip, TWRP and CWM give an error with no specified status number. I even tried signing the zip
EDIT: Install CWM and toggle signature verification. Simple right?
Press thanks if I helped.?

b3ltazar said:
Transfer zip to a pc Open up the zip file with winrar or 7zip there is a meta inf folder find the updater script file open with notepad erase the first line it will say something like asset get prop ect...... save the file transfer back to tablet it will now flash. Or use cwm to flash. I can do it for you if u send me the updater script file.
Click to expand...
Click to collapse
Thanks for the help. Unfortunately I got a tad frustrated and accidentally deleted EVERYTHING!!! So I have blank tablet now. I'm trying to download the Google Factory Images from their site but it only downloads this .tgz file instead of a zip with 4 files. I even tried extracting the .tgz and it give me a single file. Anyone have any ideas as to why this is?
I'm trying to restore this tablet based on following this page (can't post outside links on this site until after 10 posts?.......really?)
But as you can imagine I'm stuck because I can't download the aforementioned zip file.
My tablet is soon becoming destined to be a rifle target.

BAM!!! Never mind got it all squared away. Now if we can get that ROM set up so that it will work properly.

Androlover98 said:
Even I have the same problem and if you flash a modded zip, TWRP and CWM give an error with no specified status number. I even tried signing the zip
EDIT: Install CWM and toggle signature verification. Simple right?
Press thanks if I helped.?
Click to expand...
Click to collapse
I used CWM to load the ROM no problem. Thanks for the heads up.
So far I''m loving this PACMan ROM, smooth and tons of options. For me KitKat ruined my tablet, completely breaking the auto-rotate (making is stick in portrait mode), chrome crashed all the time and it was just generally laggy and slow.
Thanks to all that replied.

ST2014 said:
I used CWM to load the ROM no problem. Thanks for the heads up.
So far I''m loving this PACMan ROM, smooth and tons of options. For me KitKat ruined my tablet, completely breaking the auto-rotate (making is stick in portrait mode), chrome crashed all the time and it was just generally laggy and slow.
Thanks to all that replied.
Click to expand...
Click to collapse
Kitkat should work with no issues. i use slimkat 4.4.2 and i love it. Just make sure you wipe before the kitkat install and your tablet will fly.

b3ltazar said:
Kitkat should work with no issues. i use slimkat 4.4.2 and i love it. Just make sure you wipe before the kitkat install and your tablet will fly.
Click to expand...
Click to collapse
Exactly. Nothing beats KitKat. PERIOD
Sent from my Nexus 7 using Tapatalk

Easily Apply OTA Update To Rooted Nexus 6

I had a hard time finding this information, so thought I would post a new thread!
After you root your phone, even if using standard recovery, the OTA updates will no longer install. You may get the notifications, but after it reboots to install, you will get a failed notification. Even if you uninstall root. This is because if there is any change to the system image at all, the OTA update will fail.
To install it is actually easy, just requires some legwork. I assume you understand what the bootloader is, and what adb and fastboot tools are since your phone is already rooted. If you used a toolkit, there are plenty of guides on XDA on how to install these tools manually.
Step 1 - Collect Needed Files:
Visit the Google System Images page and download the image for your existing ROM. Check your About Device page to get the exact ID, it should say something like LVY48E.
Extract the system.img file so you can flash it later.
Download the OTA image. All OTA images are listed on the Nexus 6 OTA Images thread. Find the file which upgrades "From" your current ROM id. It will only work if from matches your current image version. It will be named something like 2bef78c4a5ec8dbaa3df9d94e78af8622cd2a394.signed-shamu-LVY48F-from-LVY48E.2bef78c4.zip, and this file in particular flashes to the new LVY48F version from LVY48E version.
Step 2 - Flash Stock System Image:
This step replaces your system image with the stock system image. This will not delete your apps or other personal data, only the information stored on the system partition. The only exception is if you rooted and stored any data on this partition. Plug your phone into your computer. There is no way to do this without a PC.
Reboot into bootloader mode either from booting with POWER+VOLDOWN or via adb:
Code:
adb reboot bootloader
and flash the image
Code:
fastboot erase system
fastboot flash system system.img
At this point your system is stock again (unrooted).
Step 3 - Flash Update Image:
Enter the recovery mode. You can also do this via TWRP but I will cover with stock recovery. Press Volume Up/Down until you see RECOVERY and press power to choose. You are now in recovery.
Press and hold Power and tap Volume Up once to get the recovery menu. Then use Volume Up/Down to select "apply update from ADB" and then Power to select
I had to unplug and plug my phone back in at this point to get it to show up to adb. You can confirm it is visible with the command adb devices.
Apply the OTA update file using the following command, replacing the file name with your own:
Code:
adb sideload 2bef78c4a5ec8dbaa3df9d94e78af8622cd2a394.signed-shamu-LVY48F-from-LVY48E.2bef78c4.zip
After a few minutes the sideload will complete, the phone will reboot and optimize apps, and you can verify the update worked by checking your about system page again.
To root your device again, re-install SuperSU and you're good to go.

I actually just asked about this in the T-Mobile thread, but thanks for making this. My question is, when installing system.img is there anything else you NEED to flash as well, specifically boot and/or cache?
Google has the latest stock image for T-Mobile so I was planning on flashing system and radio, but I wasn't sure if there was anything else required when flashing system.img.
I know I don't want recovery or userdata as that would replace TWRP and all my data, so I'd of course leave those out.

hayzooos said:
I actually just asked about this in the T-Mobile thread, but thanks for making this. My question is, when installing system.img is there anything else you NEED to flash as well, specifically boot and/or cache?
Google has the latest stock image for T-Mobile so I was planning on flashing system and radio, but I wasn't sure if there was anything else required when flashing system.img.
I know I don't want recovery or userdata as that would replace TWRP and all my data, so I'd of course leave those out.
Click to expand...
Click to collapse
Nope, system.img was all that I flashed, verified it worked fine with just that.

So you just have to re-root after right?

JTheAppMerchant said:
So you just have to re-root after right?
Click to expand...
Click to collapse
Correct

Thanks for this guide. I've been trying to figure out how to do this exact thing. When I do the command:
adb sideload 4458964f84d2e44ecd2c1c31c301d47eec4b080e.signed-shamu-LMY48M-from-LMY48I.4458964f
Click to expand...
Click to collapse
it gets to about 50%, then gives a Error message,
E:Error in /sideload/package.zip (Status 7) Installation aborted.
Click to expand...
Click to collapse
Any suggestions?

falconfox said:
Thanks for this guide. I've been trying to figure out how to do this exact thing. When I do the command:
it gets to about 50%, then gives a Error message,
Any suggestions?
Click to expand...
Click to collapse
First try a different USB cable and port.

Thanks for the guide. Does it wipe all the data and files in internal storage?

I did this successfully
torecdude said:
Thanks for the guide. Does it wipe all the data and files in internal storage?
Click to expand...
Click to collapse
I wanted to say thanks first of all for putting this up. It helps those rooted users out there that do actually want security patches applied to the system image. To answer the question above, No it does not wipe data or storage if you follow the instructions to only modify /system partition.
A note about the LMY48M update file and the above comments in the OP : This update changes the kernel (in other words), the boot.img file as well. So if you have flashed a non-stock kernel, you will need to go back to stock during the update (and I suggest just leaving it). That is the partition called boot where boot.img lives. It mainly is the kernel. The way to go back to stock (say if you flashed franco with the FKupdate tool and did not do it manually) is to simply do like above and flash it from the factory image he mentions above for 48I file.
You reboot to the bootloader (*I assume you know how*) with power and vol down button. And then the following command after flashing system.img:
fastboot flash boot boot.img
This takes you to stock LMY48I and should allow you to update now to 48M. I learned this by watching the update failure messages as well as noticed it has boot.img changed in the zip file. Hope this helps others. :good:

bitpushr said:
First try a different USB cable and port.
Click to expand...
Click to collapse
I'm having the exact same issue/error. Already tried new USB ports and cables.

falconfox said:
When I do the command:
it gets to about 50%, then gives a Error message, Any suggestions?
Click to expand...
Click to collapse
confused2much said:
I'm having the exact same issue/error. Already tried new USB ports and cables.
Click to expand...
Click to collapse
Open the update .zip file and go to META_INF > COM > GOOGLE > ANDROID. You will find the "updater-script" file.
Open that file using a text editor like notepad or notepad++ and delete the following text; starting from "assert ....... till the semicolon of the last getprop command.
Place that file back into the update .zip file and reflash. This should remove the status 7 error.

jase33 said:
Open the update .zip file and go to META_INF > COM > GOOGLE > ANDROID. You will find the "updater-script" file.
Open that file using a text editor like notepad or notepad++ and delete the following text; starting from "assert ....... till the semicolon of the last getprop command.
Place that file back into the update .zip file and reflash. This should remove the status 7 error.
Click to expand...
Click to collapse
I'll try this now, thanks for the response!

Honest question: why would you flash a system image and an ota when you could just flash the new system image?

jhotmann said:
Honest question: why would you flash a system image and an ota when you could just flash the new system image?
Click to expand...
Click to collapse
By flashing just the current system image your data stays in tact. Then you can take the OTA, it will see the system image unmodified, and it will update everything for that new version without wiping data.

jase33 said:
Open the update .zip file and go to META_INF > COM > GOOGLE > ANDROID. You will find the "updater-script" file.
Open that file using a text editor like notepad or notepad++ and delete the following text; starting from "assert ....... till the semicolon of the last getprop command.
Place that file back into the update .zip file and reflash. This should remove the status 7 error.
Click to expand...
Click to collapse
I do not have the text "assert" anywhere in that file....

jase33 said:
By flashing just the current system image your data stays in tact. Then you can take the OTA, it will see the system image unmodified, and it will update everything for that new version without wiping data.
Click to expand...
Click to collapse
Easier to just flash the new system image that gets you to the same place as the OTA.

jhotmann said:
Honest question: why would you flash a system image and an ota when you could just flash the new system image?
Click to expand...
Click to collapse
I was wondering this same exact thing, but I was assuming it was because the OTA was hitting people before that matching Google Factory Image was available. This would bring you almost back a version (to being stock) so you could take the OTA.
If the OTA is to match the same Factory Image you can get from Google, I have no idea why you'd do both steps.

Hi, I have the LNX07M, and I don't find it in the google page. Can you help me? please!

hayzooos said:
I was wondering this same exact thing, but I was assuming it was because the OTA was hitting people before that matching Google Factory Image was available. This would bring you almost back a version (to being stock) so you could take the OTA.
If the OTA is to match the same Factory Image you can get from Google, I have no idea why you'd do both steps.
Click to expand...
Click to collapse
I think the only reason to do both steps is to apply the update ASAP. If you are ok waiting, then only flash the new system.img. That's definitely what I always do. I don't mind waiting. I have Google Play Services notifications hidden now anyway, so those update notifications don't show up and bug me.
Thanks for the walk through though, @bitpushr, I'm sure many can make use of it.

confused2much said:
I do not have the text "assert" anywhere in that file....
Click to expand...
Click to collapse
Honestly, you shouldn't edit those files as that can be dangerous, and disabling the filesystem check can be dangerous, and it probably won't work because then the zip would fail signing verification.
If you followed all of the instructions in OP and still get error 7, try, on top of erasing and flashing the stock system.img, also extract and erase then flash boot.img and recovery.img. You will get error 7 if your recovery and kernel (boot.img) aren't stock.