Related
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.
I described here my failed attempt to update to 4.4.4
I've restored the device back to stock 4.3 JRW66Y, not rooted, and the cache has been cleared.
But the system remembers that it had an OTA to 4.4.2. If I try to install it it hangs 'rebooting now'.
logcat says E/SystemUpdateService( 961): 'OTA package doesn't exist'
Can I, without rooting it, get the system to forget that it had this OTA so that it will download a new one?
Dave_Ro said:
I described here my failed attempt to update to 4.4.4
I've restored the device back to stock 4.3 JRW66Y, not rooted, and the cache has been cleared.
But the system remembers that it had an OTA to 4.4.2. If I try to install it it hangs 'rebooting now'.
logcat says E/SystemUpdateService( 961): 'OTA package doesn't exist'
Can I, without rooting it, get the system to forget that it had this OTA so that it will download a new one?
Click to expand...
Click to collapse
You could do a factory reset then it should be able to download the OTA but the factory reset will completely wipe your device and you need to have the correct bootloader for the OTA to work. What version bootloader do you have?
wantabe said:
You could do a factory reset then it should be able to download the OTA but the factory reset will completely wipe your device and you need to have the correct bootloader for the OTA to work. What version bootloader do you have?
Click to expand...
Click to collapse
I don't want to do a factory reset - I'd rather live with 4.3
The installed bootloader is 4.23. Although the installed system is JRW66Y the bootloader is from JRW66V (see this thread).
I wonder whether deleting Google Services Framework data will do the trick, but this may have undesirable consequences (see this thread).
Maybe I'll wait a bit and have another go at flashing 4.4.4 - see my OP; nobody has suggested yet why that didn't work.
Dave_Ro said:
I don't want to do a factory reset - I'd rather live with 4.3
The installed bootloader is 4.23. Although the installed system is JRW66Y the bootloader is from JRW66V (see this thread).
I wonder whether deleting Google Services Framework data will do the trick, but this may have undesirable consequences (see this thread).
Maybe I'll wait a bit and have another go at flashing 4.4.4 - see my OP; nobody has suggested yet why that didn't work.
Click to expand...
Click to collapse
Sorry! I should have received a notification email that you had responded. For whatever reason, lately, the notification works some of the time but not always. I had no idea the bootloaders had gotten so effing screwed up! I bought my daughter a 2012 N7 for Christmas and no wonder I had to let it do an OTA before it would let me flash a factory image. I vaguely remember getting a bootloader invalid state error. My brothers bone stock 2012 N7 is on 4.4.4 with no issues, he would have called me otherwise. ; )
If you don't want to do a factory reset you CAN flash the factory image without wiping your device, as long as your bootloader is already/still unlocked. If you modify the flash_all.bat, which is inside the factory image the userdata.img which wipes your device won't be flashed. If you open the flash_all.bat with whatever text editor you use (I use editpad lite or notepad) and remove the -w from the text it won't wipe your device. You will keep your settings, installed apps and storage. Extract the factory image into the same folder as your adb.exe and fastboot.exe, you should see these files if you have the 3G version;
bootloader-tilapia-4.23.img
flash-all.bat
flash-all.sh
flash-base.sh
image-nakasig-krt16s.zip
radio-tilapia-1231_0.18.0_0409.img
The 4.4 (krt16s) is the newest factory image that has the exact same bootloader as jwr66v. From there you can let it do some OTA's or flash the 4.4.4 factory image. If you need help getting the sdk installed or have any questions let me know, hopefully the notification will work.
wantabe said:
...I had no idea the bootloaders had gotten so effing screwed up!
Click to expand...
Click to collapse
I'm not sure whether these bootloaders are as screwed up and some posts suggests. A corrupt bootloader in one release - JRW66Y - I can understand, but I'd have thought it would get corrected. But no, and the next version is also suspect. There's something going on that I don't understand. Files with the same name but different MD5s - why is that? I don't understand the 'signatures' that people mention - is there are explanation of that? In the post above mine at the end of this thread (post #98) he refers to a signature mismatch. I got the same error (post #100) but no mention of signatures. And that bootloader failed to flash despite others presumably having been successful and it having the 'correct' MD5 (which the OP has changed in the original post!). All very odd.
]If you don't want to do a factory reset you CAN flash the factory image without wiping your device, as long as your bootloader is already/still unlocked. If you modify the flash_all.bat, which is inside the factory image the userdata.img which wipes your device won't be flashed. If you open the flash_all.bat with whatever text editor...
Click to expand...
Click to collapse
I use Linux and flash the partitions individually rather than using their script, but essentially It's what I did with 4.4.4 KTU84 - at least I'm pretty sure I did.
The 4.4 (krt16s) is the newest factory image that has the exact same bootloader as jwr66v. From there you can let it do some OTA's or flash the 4.4.4 factory image. If you need help getting the sdk installed or have any questions let me know, hopefully the notification will work.
Click to expand...
Click to collapse
I might try KRT16S instead of KTU84P - it's a smaller step. But it would be better to go straight to the latest.
But I'd like to understand what's happening before I try again - and nobody's suggesting anything on that other thread. I guess the world's move on from the Nexus 7 2012! But thanks for your full replies and suggestions.
Going back to the object of this thread, here must be some way to just tell GFS to forget that it once downloaded that OTA! Any suggestions on that?
Dave_Ro said:
I'm not sure whether these bootloaders are as screwed up and some posts suggests. A corrupt bootloader in one release - JRW66Y - I can understand, but I'd have thought it would get corrected. But no, and the next version is also suspect. There's something going on that I don't understand. Files with the same name but different MD5s - why is that? I don't understand the 'signatures' that people mention - is there are explanation of that? In the post above mine at the end of this thread (post #98) he refers to a signature mismatch. I got the same error (post #100) but no mention of signatures. And that bootloader failed to flash despite others presumably having been successful and it having the 'correct' MD5 (which the OP has changed in the original post!). All very odd.
I use Linux and flash the partitions individually rather than using their script, but essentially It's what I did with 4.4.4 KTU84 - at least I'm pretty sure I did.
I might try KRT16S instead of KTU84P - it's a smaller step. But it would be better to go straight to the latest.
But I'd like to understand what's happening before I try again - and nobody's suggesting anything on that other thread. I guess the world's move on from the Nexus 7 2012! But thanks for your full replies and suggestions.
Going back to the object of this thread, here must be some way to just tell GFS to forget that it once downloaded that OTA! Any suggestions on that?
Click to expand...
Click to collapse
Out of curiosity I looked at the bootloaders and even though they say v4.23 a crap load of them are different sizes. Just as an example jwr66v is 2,150,992 bytes and ktu84p is 2,151,068 bytes. Don't have a clue what is going on. I can tell you that the bootloaders on the N5 and 2013 N7 are the exact same size across os versions that state the same bootloader version number.
---------- Post added at 02:19 AM ---------- Previous post was at 02:00 AM ----------
The vast majority of the time I also fastboot flash the images separately, I make a few too may changes in the system files to be able to use an OTA unless it's a very small one. I would flash the images for krt16s, bootloader, boot, system, recovery and radio. Then let it do a couple OTA's. 4.4.2 has a different size bootloader (4,005,632 bytes) and 4.3, 4.4.3 and 4.4.4 have the same size (2,151,068 bytes).
---------- Post added at 02:26 AM ---------- Previous post was at 02:19 AM ----------
Dave_Ro said:
Going back to the object of this thread, here must be some way to just tell GFS to forget that it once downloaded that OTA! Any suggestions on that?
Click to expand...
Click to collapse
I would think flashing the system image would clear it out but I guess not. If you were rooted you could run SDMaid and I think that would clear it. If you were rooted you could sideload the OTA and put it in /cache and see it that works. Sorry, I don't have a lot of experience running OTA updates, I usually have to fastboot flash images.
Well, in the end I successfully reflashed it to 4.4 (KRT16S), erasing user data. It then did 3 OTAs to 4.4.4 in quick succession.
Along the way it said:
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
archive does not contain 'tos.img'
tos? ISTR that was on the Atari ST
Thanks for the suggestion. I don't need half these apps anyway - it's good to have a clearout!
Dave
i have an unlocked rooted but otherwise stock G4P and it has an OTA but fails to install. Is there a full ROM I can apply which won't wipe? Or some other way which is not involving a full wipe?
nigelhealy said:
i have an unlocked rooted but otherwise stock G4P and it has an OTA but fails to install. Is there a full ROM I can apply which won't wipe? Or some other way which is not involving a full wipe?
Click to expand...
Click to collapse
I tried, failed, and eventually gave up. I haven't had the motivation to do a full wipe/flash, but I tried everything else I could think of before giving up.
hp420 said:
I tried, failed, and eventually gave up. I haven't had the motivation to do a full wipe/flash, but I tried everything else I could think of before giving up.
Click to expand...
Click to collapse
Did you tryied reinstall the full stock rom & recovery (through Fastboot) without wipe?
rafaelrgi said:
Did you tryied reinstall the full stock rom & recovery (through Fastboot) without wipe?
Click to expand...
Click to collapse
I had a twrp backup of my system partition, which I restored, then fastboot flashed the stock kernel, and wiped caches. Safetynet passed, but the ota would not flash. It said there was an unexpected change in the system, or something to that affect.
I'm not aware of any true, untouched flashable rom zip available. I suppose it wouldn't take long to make one, I just didn't have one available to me.
hp420 said:
I had a twrp backup of my system partition, which I restored, then fastboot flashed the stock kernel, and wiped caches. Safetynet passed, but the ota would not flash. It said there was an unexpected change in the system, or something to that affect.
I'm not aware of any true, untouched flashable rom zip available. I suppose it wouldn't take long to make one, I just didn't have one available to me.
Click to expand...
Click to collapse
To install the OTA update the stock recovery is required, and Twrp is a custom recovery.... after restore the backup you should reinstall the stock recovery before apply the OTA.
rafaelrgi said:
To install the OTA update the stock recovery is required, and Twrp is a custom recovery.... after restore the backup you should reinstall the stock recovery before apply the OTA.
Click to expand...
Click to collapse
sorry, didn't see you were asking about fastboot. no, I didn't flash the factory image. I didn't want to go that far and didn't really care enough to do a full wipe
Have you tried Magisk? Could potentially work
hp420 said:
I had a twrp backup of my system partition, which I restored, then fastboot flashed the stock kernel, and wiped caches. Safetynet passed, but the ota would not flash. It said there was an unexpected change in the system, or something to that affect.
I'm not aware of any true, untouched flashable rom zip available. I suppose it wouldn't take long to make one, I just didn't have one available to me.
Click to expand...
Click to collapse
A TWRP backup restore doesn't fix the issue. You have to reflash SYSTEM , BOOT(if modified), RECOVERY(if modified), and OEM through fastboot. That is a "block flash," instead of TWRP, which is "file based restore."
apply OTA to rooted phone
Could someone please give me this zip ota moto g4 play I need this file since I thank you.
VR25 said:
A TWRP backup restore doesn't fix the issue. You have to reflash SYSTEM , BOOT(if modified), RECOVERY(if modified), and OEM through fastboot. That is a "block flash," instead of TWRP, which is "file based restore."
Click to expand...
Click to collapse
What about other partitions :
gpt, bootloader, adspso, modem
Must they be restored ?
Just after OTA, is it possible to make a raw image backup with TWRP in R/O mode ?
hamelg said:
What about other partitions :
gpt, bootloader, adspso, modem
Must they be restored ?
Just after OTA, is it possible to make a raw image backup with TWRP in R/O mode ?
Click to expand...
Click to collapse
You only need to restore SYSTEM, OEM, BOOT AND RECOVERY images. That's all you'll ever need. NEVER touch other partitions, unless you are upgrading.
To make RAW image backups of SYSTEM and OEM partitions, use terminal in TWRP
Or "adb shell" from your computer (running as root)
adb shell
ls -al /dev/block/platform/soc/7824900.sdhci/by-name
This command will give you the names of the SYSTEM and OEM partitions of your device, Moto G4 Plus. For example, for Moto Z Play (my device), they are mmcblk0p53 and mmcblk0p51 respectively.
So, the commands would be (again, that's an example for MOTO Z PLAY):
Backup
dd if=/dev/block/mmcblk0p53 of=/sdcard/system.img
dd if=/dev/block/mmcblk0p51 of=/sdcard/oem.img
Restore
dd if=/sdcard/system.img of=/dev/block/mmcblk0p53
dd if=/sdcard/oem.img of=/dev/block/mmcblk0p51
Thanks much VR25.
With your help, I have successfully applied the latest OTA
hamelg said:
Thanks much VR25.
With your help, I have successfully applied the latest OTA
Click to expand...
Click to collapse
Confused. The VR25 guidance is when you had taken a full backup when stock, how to restore back to stock to then apply the OTA. You are describing how to apply the OTA on a rooted device without a pre-rooted backup?
You don't need backups to apply the latest OTA.
Get the stock corresponding to your device.
flash LOGO, SYSTEM, OEM, BOOT AND RECOVERY images.
Apply November OTA
Apply February OTA
I did that without wiping my data.
If you want to avoid reset to stock & apply all OTAs, you must have a binary backup of system partition, not a file based backup (see comment #8).
I asked about this issue here :
https://forum.xda-developers.com/showpost.php?p=72029402&postcount=55
hamelg said:
You don't need backups to apply the latest OTA.
Get the stock corresponding to your device.
flash LOGO, SYSTEM, OEM, BOOT AND RECOVERY images.
Apply November OTA
Apply February OTA
I did that without wiping my data.
If you want to avoid reset to stock & apply all OTAs, you must have a binary backup of system partition, not a file based backup (see comment #8).
I asked about this issue here :
https://forum.xda-developers.com/showpost.php?p=72029402&postcount=55
Click to expand...
Click to collapse
Where is the stock for my device
Where is the OTA for my device
My device is the USA unlocked G4P XT1607
nigelhealy said:
Where is the stock for my device
Where is the OTA for my device
My device is the USA unlocked G4P XT1607
Click to expand...
Click to collapse
Exactly this question, but then the XT1602. Flashed the stock parts, but no message of an OTA and they are nowhere to be found. Or does anyone have latest stock version full ROM?
TheEvilVirus said:
Exactly this question, but then the XT1602. Flashed the stock parts, but no message of an OTA and they are nowhere to be found. Or does anyone have latest stock version full ROM?
Click to expand...
Click to collapse
Yeah, others were just saying too high a level to not actually helpful. As I did this last week I'll tell you now is as step by step as I can to actually try to be helpful.
Firstly you need to know you will wipe data, there's no avoiding it, that I could find so backup everything, that can be a mix of TWRP backup of data to SDCARD external, USB OTG, or Titanium backup to online / SD / OTG. In my case I prefer to simply install everything and configure everything from scratch.
Follow this guide to return to stock.
In my case I'm on Ubuntu Linux desktop, fastboot got a "no permissions" type message so I had to sudo in front.
The stock for your device, well look at your device Status page now before you start, Settings -> About Phone -> it says Software Channel "retus" so when I go to the list of ROMs in the above guide go to mirrors.lolinet.com - firmware - moto - harpia - official - then I went to Retus, you'd go to a different one probably.
Note these are old stock ROMs I think from September so there have been one or two updates since then.
Follow the step by step guide, basically lots of fastboot commands.
The step where it says fastboot oem lock it bawks and say fastboot oem lock begin and that will do another wipe, so given a later fastboot oem unlock would do a 3rd wipe I didn't do the oem lock, I left mine unlocked and that worked fine.
Let it boot, setup, you will then be in an old stock ROM, then if it doesn't offer to do an update, go into Settings, System Updates, and trigger it to look. It will then download and apply a stock OTA ontop of the stock ROM. In my case it was 1 OTA, 1 update, then that that complete. You then are on stock current ROMs.
Then root and whatever you want.
But note, to get to the impending N OTA, you'll probably have to right back to the top here because your rooted Moto G4 Play will likely refuse the future OTA as the system is modified, so you'd have to repeat, return to an old stock ROM and then let it go through the 1 or 2 or 3 OTAs to get to that future release.
Hence you'd be doing the return to stock twice.
If the mirrors could be updated to newer stocks it would bypass the OTA. My other phone - the OnePlus3T they offer mirrors of full ROMs, they are far easier to use because if you are rooted you download the full ROM not just the delta incremental of the change of the OTA, and then you can flash in recovery the full ROM and it ignores the system state, and no wiping of data. The fact the mirror site is out of date is causing the need to wipe so the OTAs work on an unmodified system.
Fortunately I have multiple phones so I can use another for the few hours this all takes.
works great, I just flash it and without wiping data
hamelg said:
You don't need backups to apply the latest OTA.
Get the stock corresponding to your device.
flash LOGO, SYSTEM, OEM, BOOT AND RECOVERY images.
Apply November OTA
Apply February OTA
I did that without wiping my data.
If you want to avoid reset to stock & apply all OTAs, you must have a binary backup of system partition, not a file based backup (see comment #8).
I asked about this issue here :
https://forum.xda-developers.com/showpost.php?p=72029402&postcount=55
Click to expand...
Click to collapse
works great and finally my phone can upgrade the OTA updates:laugh::good:
VR25 said:
To make RAW image backups of SYSTEM and OEM partitions, use terminal in TWRP
Or "adb shell" from your computer (running as root)
...
Restore
dd if=/sdcard/system.img of=/dev/block/mmcblk0p53
dd if=/sdcard/oem.img of=/dev/block/mmcblk0p51
Click to expand...
Click to collapse
Here is time to apply the may OTA MPIS24.241-15.3-21.
I restored the vanilla system.img MPIS24.241-15.3-16 with dd, but it didn't work. The OTA failed with the error "system partition has unexpected content" because the sha1sum was incorrect.
Here is the solution :
Before restoring with dd, you must check "Mount System partition read only" is enable in the MOUNT menu of TWRP.
With TWRP 3.1, you need no more to use dd. Now, the feature "system image backup" is available
Does anyone know about this ?
The last version of the firmware that got OTA'ed to my phone is POTTER_RETAIL_7.0_NPNS25.137-93-8.
The only twrp backup of the firmware I have is while it was on POTTER_RETAIL_7.0_NPNS25.137-93-4.
When I tried to flash the phone with v 93-4 using fastboot, I got denied because of the version being older than that of the bootloader. But the problem is that I was able to erase prior to attempting writing ...
I need to re-install a stock rom in the phone, but POTTER_RETAIL_7.0_NPNS25.137-93-8 cannbot be found anywhere yet.
I though about twrp-flashing the phone with my 93-4 backup, but I am hesitant, I fear bricking the phone.
Is there any alternative to patience while waiting for POTTER_RETAIL_7.0_NPNS25.137-93-8_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip eventually appearing somewhere ?
Or, in other words, knowing that the last OTA to my phone installed v 93-8, is there any way to flash POTTER_RETAIL_7.0_NPNS25.137-35-5_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip for instance ?
CanadianGixxerman said:
I though about twrp-flashing the phone with my 93-4 backup, but I am hesitant, I fear bricking the phone.
Click to expand...
Click to collapse
An older version (your twrp backup) will work with a newer bootloader, however you can't do any OTAs. An OTA will try to apply the same changes to the bootloader that were already made, resulting in a hard brick - though the OTA would fail anyway since you don't have an intact /oem partition. You will have a functional phone, and you can get back on track after 93-8 images or Oreo are released.
I know because I'm in a similar situation. I wanted to update from 93-4 to 93-8, and I had an intact /system image backup, but /oem was mounted before so I had to flash it via fastboot. Little did I know it was from the wrong channel (retus instead of reteu), resulting in the OTA updating everything except for oem and messing stuff up, so I just flashed a 93-4 twrp backup. Everything works, patiently waiting for Oreo.
bazinga137 said:
I just flashed a 93-4 twrp backup.
Click to expand...
Click to collapse
Just curious. Did you have a full system image backup through twrp or just the system partition? I have a twrp backup of 93-8 stock boot, logo, oem, recovery, and system PARTITIONS which I thought would allow me to restore and take ota. However, since doing that I've read that system needs to be the full IMAGE backup through twrp. Confused so I haven't restored to take the 93-10 update which I got notification of yesterday.
craigl14 said:
Just curious. Did you have a full system image backup through twrp or just the system partition? I have a twrp backup of 93-8 stock boot, logo, oem, recovery, and system PARTITIONS which I thought would allow me to restore and take ota. However, since doing that I've read that system needs to be the full IMAGE backup through twrp. Confused so I haven't restored to take the 93-10 update which I got notification of yesterday.
Click to expand...
Click to collapse
Honestly, I am not sure. I did a twrp back up with the default selected partitions. But it turned out that this backup is not reliable. The phone does boot up on it, but suffers from applications crashes all over. Last I discovered is that the phone itself was not working for a phone, meaning making receiving calls is not possible.
craigl14 said:
Just curious. Did you have a full system image backup through twrp or just the system partition? I have a twrp backup of 93-8 stock boot, logo, oem, recovery, and system PARTITIONS which I thought would allow me to restore and take ota. However, since doing that I've read that system needs to be the full IMAGE backup through twrp. Confused so I haven't restored to take the 93-10 update which I got notification of yesterday.
Click to expand...
Click to collapse
It needs to be an image backup for OTAs. Unlike a regular backup, image backups are block-by block pristine copies, and restoring them preserves dm-verity and all /system checks. On the other hand the /oem partition cannot be backed up as an image (I asked GtrCraft, the official maintainer of twrp for some moto devices), and since OTAs also check if /oem has been tampered with, the update fails.
Updates will only pass if /oem has never been mounted, and you have a system image backup.
bazinga137 said:
It needs to be an image backup for OTAs. Unlike a regular backup, image backups are block-by block pristine copies, and restoring them preserves dm-verity and all /system checks. On the other hand the /oem partition cannot be backed up as an image (I asked GtrCraft, the official maintainer of twrp for some moto devices), and since OTAs also check if /oem has been tampered with, the update fails.
Updates will only pass if /oem has never been mounted, and you have a system image backup.
Click to expand...
Click to collapse
Dumb question...How do I know if the oem partition is tampered with or has never been mounted? I am rooted with elementalx kernel and supersu. TWRP partition stock backup made immediately after taking 93-8 update and before flashing twrp, rooting, etc. I know I am hosed without the system IMAGE as far as ota's go, but I'm just trying to learn.
I'm in the same boat. Pretty much stuck on 93-8 forever until a new full image is released somewhere. I might just move onto a custom Oreo rom.
dunderball said:
I'm in the same boat. Pretty much stuck on 93-8 forever until a new full image is released somewhere. I might just move onto a custom Oreo rom.
Click to expand...
Click to collapse
Well, I did that. I have tried a few cutom roms : Pixel Exprerience, Resurection Remix, AOSP extended, AOSiP and Dirty Unicorns. The latter and AOSiP are those I find the most reliable. Avoid PE and RR, too buggy, AOSP-E has issues with SIM/SDcard here.
But I will want to go back to stock moto rom when I can (ie : full 93-8 load fastboot flashable is released).
If moto had been quicker to release Oreo AND fix the wifi bug, I would not have given up on retus.
I guess I have an even more fundamental dumb question than my twrp restore issue and maybe it belongs in another thread. Aside from advanced excel formulas, I have no programming experience of any kind, let alone android. However, it seems to me that if I have a full firmware package for 93-4 (which I do) and a "blur" ota update file that takes it to 93-8 (which I do), I should be able to create a full 93-8 firmware package file myself from those two files without waiting on the file hosting sites. Maybe this is way too advanced a process but it seems to me this is 1+2=3 variety.
craigl14 said:
I guess I have an even more fundamental dumb question than my twrp restore issue and maybe it belongs in another thread. Aside from advanced excel formulas, I have no programming experience of any kind, let alone android. However, it seems to me that if I have a full firmware package for 93-4 (which I do) and a "blur" ota update file that takes it to 93-8 (which I do), I should be able to create a full 93-8 firmware package file myself from those two files without waiting on the file hosting sites. Maybe this is way too advanced a process but it seems to me this is 1+2=3 variety.
Click to expand...
Click to collapse
Your device now being at 93-8 is what's in the way. It seems like you can restore your twrp 93-4 on it, but you won't be able to relock the BL, hence OTA will not work.
CanadianGixxerman said:
Your device now being at 93-8 is what's in the way. It seems like you can restore your twrp 93-4 on it, but you won't be able to relock the BL, hence OTA will not work.
Click to expand...
Click to collapse
Sorry for the confusion. My restore issue is with the fact that I did not make a full system image twrp backup of stock 93-8. If I had, I would be able to restore and take ota's (assuming the oem issue doesn't interfere which I don't know about).
My last question is more fundamental and broader. There are quite a few people waiting on firmware updates. It just seems to me that if I have a full firmware package and an update package for that firmware, I should be able to create a newly updated full firmware package independent of what happens to be on my phone at any one time. Again, maybe really stupid and way beyond my capabilities.
I'm on a slightly same boat as OP, but I don't have my backup since I thought it was on my SD and wiped my phone, with the backup only there. I was on 93-8 when I wiped. Would getting a 93-4 backup work?
This question might of been answered but I did not see it when I read through this thread.
craigl14 said:
Sorry for the confusion. My restore issue is with the fact that I did not make a full system image twrp backup of stock 93-8. If I had, I would be able to restore and take ota's (assuming the oem issue doesn't interfere which I don't know about).
My last question is more fundamental and broader. There are quite a few people waiting on firmware updates. It just seems to me that if I have a full firmware package and an update package for that firmware, I should be able to create a newly updated full firmware package independent of what happens to be on my phone at any one time. Again, maybe really stupid and way beyond my capabilities.
Click to expand...
Click to collapse
I took a full backup of my system image through twrp, and I was on 93-8. I'll upload it when I have time and you can give it a try.
CanadianGixxerman said:
[...] but you won't be able to relock the BL, hence OTA will not work.
Click to expand...
Click to collapse
Why would you need to relock the BL to take an OTA?
craigl14 said:
My last question is more fundamental and broader. There are quite a few people waiting on firmware updates. It just seems to me that if I have a full firmware package and an update package for that firmware, I should be able to create a newly updated full firmware package independent of what happens to be on my phone at any one time. Again, maybe really stupid and way beyond my capabilities.
Click to expand...
Click to collapse
Sadly you can't apply an OTA to the firmware images, if that's what you're thinking. They need to be signed by moto to be flashable through fastboot. And if you'd want to provide someone with a twrp backup of a firmware higher than theirs, their bootloader would need to be updated too, via an OTA.
bazinga137 said:
if that's what you're thinking.
Click to expand...
Click to collapse
Thanks. That's exactly my question. So the answer is that Motorola controls the process. Makes sense. Any thoughts on my oem mounting question?
craigl14 said:
Thanks. That's exactly my question. So the answer is that Motorola controls the process. Makes sense. Any thoughts on my oem mounting question?
Click to expand...
Click to collapse
I really can't think of a way of checking the mount count of Android partitions, and I haven't found anything online.
I discovered the mount counter thingy when sweeping through logs of a failed OTA. I'm really not sure where the OTA script reads it from.
craigl14 said:
Sorry for the confusion. My restore issue is with the fact that I did not make a full system image twrp backup of stock 93-8. If I had, I would be able to restore and take ota's (assuming the oem issue doesn't interfere which I don't know about).
My last question is more fundamental and broader. There are quite a few people waiting on firmware updates. It just seems to me that if I have a full firmware package and an update package for that firmware, I should be able to create a newly updated full firmware package independent of what happens to be on my phone at any one time. Again, maybe really stupid and way beyond my capabilities.
Click to expand...
Click to collapse
I made a full backup of 93-8, but still i can't lock bootloader. We need complete firmware, until then, Lineage OS is the answer.
---------- Post added at 11:55 PM ---------- Previous post was at 11:52 PM ----------
bazinga137 said:
Why would you need to relock the BL to take an OTA?
Click to expand...
Click to collapse
No idea, i saw this first time now on Motorola. On any other manufacturers i could lock bootloader, and even get OTA updates just by flashing stock recovery and having unlocked bootloader was not a problem.
If your device was formally updated to NPNS25.137-93-8 (March 2018 security patch), then you could try to flash the NPNS25.137-93-4 (Jan 2018 security patch) update again as you previously tried (link to the Jan 2018 stock firmware for EU/US and Asia devices: https://mirrors.lolinet.com/firmware/moto/potter/official/RETAIL/ ). You may wish to ignore the security downgrade errors (you cannot downgrade bootloaders anyway, presumably to prevent you opening security vulnerabilities) when you flash, which should just be for GPT and bootloader. You may also see 'image signed with bad key' for recovery and boot as well, but verify those partitions, and the other partitions report [OKAY] after flashing. That way, you should have a NPNS25.137-93-4 system, with a NPNS25.137-93-8 bootloader, and when you boot you should have a device reporting with fully stock NPNS25.137-93-4. The next OTA you should receive is the NPNS25.137-93-8 OTA and then the NPNS25.137-93-10 April 2018 security patch OTA, which should bring you up to the latest stock firmware.
By reflashing the NPNS25.137-93-4 firmware, this should also restore your OEM partition to being untampered (read only status?), as should your system partition (which should be read only, I recall that swiping to allow modifications in TWRP sets your system partition to read-write, which causes the OTA to fail).
Normally, I would advise against downgrading and using OTA updates, as this is a prime way of hard bricking. However, in this case you are downgrading your device firmware to the firmware directly preceding the newest firmware you had (i.e. downgrading to NPNS25.137-93-4 from NPNS25.137-93-8), with the next OTA being NPNS25.137-93-8, which brings you back up to the build you had, this may be safe. To your device, you are flashing the same bootloader from the NPNS25.137-93-8 OTA as currently on your device, which should not hard brick.
If you previously had stock NPNS25.137-93-10, then I cannot recommend this procedure as you'll be downgrading two firmware versions (and you'll have to wait for newer stock firmware to be leaked), else if you try flashing NPNS25.137-93-4 onto the April 2018 firmware and try using OTA updates, you may hard brick and have a pricey paperweight. I also do not know if this will work by cross-flashing from the NPN25.137-92 series of updates either.
Of course, as the NPNS25.137-93-4 firmware is older than your bootloader, you will not be able to re-lock your bootloader (you'll need a newer firmware, probably the April 2018 or newer security patch stock firmware), but being back on full stock, you should be eligible for OTAs provided you only downgraded from NPNS25.137-93-8 (and that March 2018 security patch was the latest stock firmware on your device).
If you are truly concerned about hard bricking, then I would follow other member's suggestions in this thread and stay with TWRP flashables of the stock ROM, as they do not usually affect the bootloader.
Any questions or comments before you perform this procedure, please ask.
bazinga137 said:
I really can't think of a way of checking the mount count of Android partitions, and I haven't found anything online.
I discovered the mount counter thingy when sweeping through logs of a failed OTA. I'm really not sure where the OTA script reads it from.
Click to expand...
Click to collapse
Thanks. Weird. Sorry for hijacking this thread. But if my process were to take OTA after which it reboots, then IMMEDIATELY reboot into bootloader, fastboot BOOT into twrp (not flash it) and take a backup of boot, logo, oem, recovery and system (FULL IMAGE), how would that change oem?
CanadianGixxerman said:
Well, I did that. I have tried a few cutom roms : Pixel Exprerience, Resurection Remix, AOSP extended, AOSiP and Dirty Unicorns. The latter and AOSiP are those I find the most reliable. Avoid PE and RR, too buggy, AOSP-E has issues with SIM/SDcard here.
But I will want to go back to stock moto rom when I can (ie : full 93-8 load fastboot flashable is released).
If moto had been quicker to release Oreo AND fix the wifi bug, I would not have given up on retus.
Click to expand...
Click to collapse
What's buggy about PE? I was just about to try it...
Since these tablets don't have an external online resource for downloading system updates, only a sketchy OTA app (com.adups.fota) I'm collecting a library of OTAs, as well as boot/recovery/system images.
I have access to a 10.1 with keyboard (ONA19TB007) and without (ONA19TB003) that I can pull updates and images from, but I do not have access to the 8" (ONA19TB002) or newer 7" tablet. Any assistance with those two would be welcomed :good:
Onn 10.1" without keyboard - ONA19TB003
OTA
20191015-1827
Stock Images
October 2019
Full (Thanks @CaffeinePizza!)
Boot
Recovery
VbMeta
Vendor
System
May 2019
Full (Thanks @CaffeinePizza!)
Onn 10.1" with keyboard - ONA19TB007
OTA
20191011-1212
20190516-1437
Stock Images
October 2019
Boot
Recovery
Vendor
VbMeta
System
May 2019
Boot
Recovery
Vendor
VbMeta
System
Onn 8" - ONA19TB002
OTA
November 2019 (Thanks @martyfender)
July 2019 (Thanks @tek3195)
Stock Images
November 2019
Full (Thanks @CaffeinePizza!)
May 2019
Full (Thanks @CaffeinePizza!)
Onn 7" Surf - 100005206
OTA
November 2019 (Thanks @tek3195)
Stock Images
October 2019
Full (Thanks @deadman96385!!)
June 2019
Full (Thanks @deadman96385!)
*Reserved
NFSP G35 said:
Since these tablets don't have an external online resource for downloading system updates, only a sketchy OTA app (com.adups.fota) I'm collecting a library of OTAs, as well as boot/recovery/system images.
Click to expand...
Click to collapse
I discovered that running the following command
Code:
pm uninstall -k --user 0 com.adups.fota.sysoper && pm uninstall -k --user 0 com.adups.fota
withing adb shell will disable the over the air updates.
I do not know if there is any truth to this, but Malwarebytes has an article on this, claiming that the software can be used to collect user data so I chose to disable it.
^ yep. I ran across a lot of worrysome information about that software. I figure I can 'take one for the team' and leave it enabled on mine, and collect updates here.
That way, if anyone wants to update while leaving com.adups.fota disabled or uninstalled, now they will have a way to do so
NFSP G35 said:
^ yep. I ran across a lot of worrysome information about that software. I figure I can 'take one for the team' and leave it enabled on mine, and collect updates here.
That way, if anyone wants to update while leaving com.adups.fota disabled or uninstalled, now they will have a way to do so
Click to expand...
Click to collapse
I am repeating some information I previously stated since we now have a section specifically for this:
I am sure @CaffeinePizza would not mind, he posted stock roms in this POST. Maybe a link to this information in the OP will help people looking for a STOCK rom for the 8' and 10' devices. The images he is hosting are patched to April 5, 2019. Anyone wishing to flash these images will need the SP Flash tools.
OTA for 8" ONA19TB002 https://drive.google.com/file/d/10vFETRunJEkyZXGUV05-rmJy60qrnSuy/view?usp=sharing
I can not remember date but somewhere around July 2019.
tek3195 said:
OTA for 8" ONA19TB002 https://drive.google.com/file/d/10vFETRunJEkyZXGUV05-rmJy60qrnSuy/view?usp=sharing
I can not remember date but somewhere around July 2019.
Click to expand...
Click to collapse
Thanks! Added to the OP
I guess this would be the place for the 7" SURF OTA's to reside for now ? Here is ota for Onn 7" Surf Model 100005206 downloaded 11/7/2019 have not installed yet so don't have security patch date.
https://drive.google.com/file/d/1U77dxYgO-ihbO1XP6c8AiEnEtUlJRcfI/view?usp=sharing
tek3195 said:
I guess this would be the place for the 7" SURF OTA's to reside for now ? Here is ota for Onn 7" Surf Model 100005206 downloaded 11/7/2019 have not installed yet so don't have security patch date.
https://drive.google.com/file/d/1U77dxYgO-ihbO1XP6c8AiEnEtUlJRcfI/view?usp=sharing
Click to expand...
Click to collapse
Thanks!
Added to the OP along with a couple of images from the 007.
More to come once I can get them uploaded.
Random OT... I just noticed you're in PC... Hi from Tallahassee!
Maybe we should have a thread on sptools too... I still need to read up on mtk told but there are so many...
You're welcome to reference my thread and post a link to my server with the x003 and x002 stock images. SP Flash Tools is needed.
https://forum.xda-developers.com/showpost.php?p=80574967&postcount=192
https://www.nathanbar.net/files/android
I plan on making a proper thread, perhaps this weekend, on how to backup with Wwr, and flash with SP Tools. I will try to upload updated images from the newest OTA.
I may even make a blog post with photos on my site.
Can the Onn 8 update.zip be flashed in TWRP, or must it only be flashed in spflashtool?
Thanks
UPDATE:
I tried both ways and neither works. How does one apply this update.zip? Do I need to reflash the stock recovery and apply it there?
I copied the update.zip to:
Code:
/storage/emulated/0/Android/data/com.adups.fota/files/fota
When I go to settings,system, about tablet, wireless Update, local updates, I navigate to where the update is and if I choose update.zip,: make sure the file is official, it states it may wipe your data and will reboot to recovery to install. (which I assume needs to be the stock recovery?)
I, of course do not want to do this until I hear from someone who can clarify all of this: @tek3195
Thanks
martyfender said:
Can the Onn 8 update.zip be flashed in TWRP, or must it only be flashed in spflashtool?
Thanks
UPDATE:
I tried both ways and neither works. How does one apply this update.zip? Do I need to reflash the stock recovery and apply it there?
Click to expand...
Click to collapse
To my knowledge, it has to be flashed with the stock recovery
NFSP G35 said:
To my knowledge, it has to be flashed with the stock recovery
Click to expand...
Click to collapse
Yeah, it has to be stock recovery and can be done with adb sideload or update from sdcard. I haven't tried yet but it may be able to be repacked and flashed with TWRP. I know as it sits now the compatibility.zip is of wrong format to be flashed. It's a possibility, but something that would have to be done at each update. Also, regardless of how installed will it re-lock bootloader or erase /data? Some brands do. I don't know mine was already wiped before the update.zip. Just installed it from sdcard and says success although two errors at end. loader1 & loader2 could not read misc-sd, unable to set boot part. Find out in a few if relocked.
Okay,cool. The ota when installed manually did not re-lock the bootloader.
tek3195 said:
Yeah, it has to be stock recovery and can be done with adb sideload or update from sdcard. I haven't tried yet but it may be able to be repacked and flashed with TWRP. I know as it sits now the compatibility.zip is of wrong format to be flashed. It's a possibility, but something that would have to be done at each update. Also, regardless of how installed will it re-lock bootloader or erase /data? Some brands do. I don't know mine was already wiped before the update.zip. Just installed it from sdcard and says success although two errors at end. loader1 & loader2 could not read misc-sd, unable to set boot part. Find out in a few if relocked.
Okay,cool. The ota when installed manually did not re-lock the bootloader.
Click to expand...
Click to collapse
Yes, I re-flashed the stock recovery and booted to it. I attempted to flash the update.zip from there, but there was some error that it was not and official verified file.
Keep in mind that is not what it stated, I am just relaying a very vague, poor memory version of what I saw then.
I tried to restore the just released, twrp version in fastboot in linux, but had errors, so I booted to Windows 7 and reflashed the just released version of twrp in fastboot in Windows 7 WTF? fastboot in Linux Mint Mate, has, until now, worked flawlessly.
To clarify, I could not install the ota with an unlocked bootloader and Magisk installed.
20191015 stock firmware for ONA19TB003 has been uploaded. https://www.nathanbar.net/files/android/ONA19TB003/
CaffeinePizza said:
You're welcome to reference my thread and post a link to my server with the x003 and x002 stock images. SP Flash Tools is needed.
https://forum.xda-developers.com/showpost.php?p=80574967&postcount=192
https://www.nathanbar.net/files/android
I plan on making a proper thread, perhaps this weekend, on how to backup with Wwr, and flash with SP Tools. I will try to upload updated images from the newest OTA.
I may even make a blog post with photos on my site.
Click to expand...
Click to collapse
Thanks a ton BTW, I tried to apply the October OTA on mine, and it failed because the system partition was modified (I'm sure I was doing some silly experiment)
Worse yet, the wifi stopped working for some reason... So I grabbed the backup from your server, dd'd the system image over mine, and the OTA was able to apply without a problem. Wifi started acting right again too.
I'm adding links to the OP now.
Thanks again!
NFSP G35 said:
Thanks a ton BTW, I tried to apply the October OTA on mine, and it failed because the system partition was modified (I'm sure I was doing some silly experiment)
Worse yet, the wifi stopped working for some reason... So I grabbed the backup from your server, dd'd the system image over mine, and the OTA was able to apply without a problem. Wifi started acting right again too.
I'm adding links to the OP now.
Thanks again!
Click to expand...
Click to collapse
MD5 hashes are also uploaded with DOS CRLF since I uploaded them from Windows (in the same directory as the zips on the server). Note: MD5SUM should be used only to verify that a file is not corrupt during transfer.
10"
af2e056b8b929540b3030f7dcbf07c1a stock_20190516_pie.zip
d5c6c4f8f1ea21bf18d2ee0fcb1e6335 stock_ONA19TB003_20191015.zip
8"
2244d235325b22a8a7225a736fbafaf6 stock_ONA19TB002_20190516.zip
Also, I know the 7" tablet exists now, and I have yet to purchase one. I do know, however, that it is not part of the same family. Technically (though I haven't tried it), the stock images between the 8" and 10" are exactly the same besides the ITEMS partition (items.ini).
Just got done adding boot, recovery, vbmeta, vendor and system images for the October updates on both the ONA19TB003 and ONA19TB007