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.
Related
Rooting and updating your MotoActv is about to get significantly easier! No more waiting games for developers to update their ROMs or tools when Motorola pushes a new OTA; now you can do it yourself! I honestly have not seen these types of files ANYWHERE else, so I had to create these myself (with quite a bit of help from [mbm]). But enough blabbing, here are the files and how to use them:
(Note: all these methods assume we have full fastboot access! -- Which we still have at this point)
- Stock Images:
These are not just mere update.zips that you might be accustomed to elsewhere in Android. Nor are these mere fxzs that you might be accustomed to elsewhere with newer Motorola devices. They are in fact both and more. There are 3 main ways to flash these files onto your device, giving you options based on what OS you run and how comfortable you are flashing files to your device.
1) FXZ:
- Operating System: Windows
- Requires: RSD Lite with FXZ Support
- Instructions: Simply load up the file as any standard fxz (it is very straight-forward)
2) Recovery:
- Operating System: Anything that can mount your device
- Requires: The ability to get into recovery
- Instructions: Place the file on the sdcard, boot into recovery, flash as normal
- Note: Recovery does not wipe your device, it is suggested that you do so before flashing stock images
3) Fastboot:
- Operating System: Windows/Linux/Mac
- Instructions (Windows): Unpack the zip, run flash-all.bat (if it fails, run as administrator)
- Instructions (Linux/Mac): Unpack the zip, run flash-all.sh (it should already have proper permissions)
Miscellaneous Images:
These miscellaneous images are nothing you haven't seen before at this point, but their purposes are new, so they too require explanation.
1) AnyRoot:
AnyRoot is based on koush's AnyKernel in the sense that it unpacks and repacks the boot.img on the fly. However, as the name suggests, AnyKernel is meant for kernels, while AnyRoot, actually roots the device on the fly. This will work on any MotoActv device. It is flashed as a normal update.zip and everything is done in the background so you won't noticed much. However, for ease of access, the stock and rooted boot.img is exported to your sdcard in /sdcard/recovery/. Also note, that if you happen to flash AnyRoot over an already rooted device, nothing will happen as it has built-in error checking.
2) rebootRecovery:
rebootRecovery is another fxz type zip, the same as the stock and rooted images, except it can't be flashed in recovery (would be a little redundant don't you think?). This flashes a specially made misc.img by [mbm] that tells the device to reboot into recovery from boot. This means you can flash AnyRoot on any stock device.
How Tos / FAQs:
Now that you know what the files do, I can explain in short steps how to use these files to get what you want:
1) How to Return the Device to Stock?
- flash a stock image using any of the 3 methods
- you can now update via Motocast if you so wish
2) How to Root a Stock Device?
- update your device via Motocast to the latest version (suggested)
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
3) How do I update my Rooted Device?
- flash a stock image using any of the 3 methods
- update your device via Motocast to the latest version
- place AnyRoot on your sdcard
- boot into fastboot, and flash rebootRecovery using either of the 2 methods
- flash AnyRoot in recovery
- reboot
Q: After using rebootRecovery I can't get out of recovery!?
A: You are using an old recovery that doesn't clear the 'reboot-recovery' command; use the newer recovery: https://dl.dropbox.com/u/5849675/android/f100/CWMR5x_F100_recoveryB2.img
Q: What do these ROM offer over other custom ROMs?
A: Nothing, they are simply stock images, but you can upgrade with them.
Q: How much battery should I have when I flash?
A: Performing any kind of these flashes will drain at least 10% of your battery, I wouldn't suggest you flash below 60% ESPECIALLY IF YOU FLASH rebootRecovery!
Q: What happens if I flash a 16gb zip on my 8gb or visa-versa?
A: Don't freak, it will still boot, but it's not the best thing in the world to do, just go back and flash the correct model zip.
Q: Can I extract the images from your zips and flash them my own way?
A: yep (couldn't really think of anything else to say)
Q: I manually flashed the stock-boot.img from AnyRoot, and now I can't update. Why?!
A: The boot.imgs need to be truncated before they can be flashed to correctly work with Motorola's updates, just use the stock images.
Q: What's next?
A: HyprActv -- What's this?
Stock Images (w/ md5sums):
8gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_NA.zip (5e228bf56a67aced012c8cbb2d7f7c76)
16gb-NA: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_16GB_NA.zip (21b067dc629f7ccd18b43799d8d5fb17)
8gb-EU: https://dl.dropbox.com/u/5849675/android/f100/MA_1710_8GB_EU.zip (5b79a46d87728303fc2c920eec71c2e8)
Miscellaneous Images (w/ md5sums:
AnyRoot: https://dl.dropbox.com/u/5849675/android/f100/MA_AnyRoot.zip (2f867b006da42865ef861094db0eb6e6)
Reboot Recovery: https://dl.dropbox.com/u/5849675/android/f100/MA_RebootRecovery.zip (1623c9c61462db9bb20b55bc8f1144aa)
Mirror (thanks Iownox!): http://www.androtransfer.com/?developer=lownox&folder=MotoACTV
This is Reserved.
I rooted and flashed in recovery (the stock 4.55.97 and the the rooted version 4.55.97) and I stay on 4.55.78 no matter what! The flashes go through successfully... But nothing has changed and the System version still says 4.55.78... But like I said, the flashes both completed! I did a factory reset... and the updater-script wipes system, so what could be my issue?
Moose8106 said:
I rooted and flashed in recovery (the stock 4.55.97 and the the rooted version 4.55.97) and I stay on 4.55.78 no matter what! The flashes go through successfully... But nothing has changed and the System version still says 4.55.78... But like I said, the flashes both completed! I did a factory reset... and the updater-script wipes system, so what could be my issue?
Click to expand...
Click to collapse
It sounds like you flashed that old boot.img. Do you have the battery percentage in the status bar? According to TheEndGame7 that is another surefire way to tell if you are on 4.55.97, if you used any of the root tools, it's possible that they automatically flash the old boot.img.
CEnnis91 said:
It sounds like you flashed that old boot.img. Do you have the battery percentage in the status bar? According to TheEndGame7 that is another surefire way to tell if you are on 4.55.97, if you used any of the root tools, it's possible that they automatically flash the old boot.img.
Click to expand...
Click to collapse
I think I did flash the old boot.img (root tools :O ). I'll try flashing the modified boot img again. Thanks! I had no idea the root tool took me back to the old boot img
Moose8106 said:
I think I did flash the old boot.img (root tools :O ). I'll try flashing the modified boot img again. Thanks! I had no idea the root tool took me back to the old boot img
Click to expand...
Click to collapse
Yes, any and all tools that exist so far will need to be updated.
I wiped data / cache and used recovery (b) to install the rooted-4.55.97 zip and didn't have any luck either. I did not use the root tools to flash. Also wiped dalvik cache after and fastboot -w for fun.
innovatelife said:
I wiped data / cache and used recovery (b) to install the rooted-4.55.97 zip and didn't have any luck either. I did not use the root tools to flash. Also wiped dalvik cache after and fastboot -w for fun.
Click to expand...
Click to collapse
Did you end up doing any restore of some kind after you flashed?
Update
There are "new" instructions that might fix the issue where the rooted 4.55.97 appears to not flash. Simply wipe the boot.img image before you flash. And don't use the root tools until they are updated.
Also, if you have success, please post it. Usually "Thanks, it works" is annoying, but in this case where I don't have the device, I need to make sure this is working on some level.
I formated everything from recovery, now I got stuck with Moto logo with no animation when it starts, how to get out of this?
NA
Is there any mirrors for the download of these roms? the dropbox links are down
NORCALkID said:
Is there any mirrors for the download of these roms? the dropbox links are down
Click to expand...
Click to collapse
They were pulled, they're not working. There has been some form of mis-communication when I did my testing. I am not working on these until I can get the device from utkanos. Check Update 2, in the initial post.
Success
CEnnis91
I was lucky the second time, first time I succeeded to upgrade to rooted 4.55.97 but for some reason I didn't get the battery percentage on the status bar but all other issues are OK and status indicated version number 4.55.97, I repeated flash from recovery but after wiping and remounting all folders, this time for stock 4.55.97
Now I'm on stock 4.55.97 with battery percent on status bar and syncing from my mac.
thanks CEnnis91
NA
I went into recovery>mounts, and didn't see any wipe for boot. I took a shot at system since I had already wiped cache and data. Didn't seem to help either. Tried 'fastboot erase boot" and re-flashed. No go. Couldn't start back up the device at all. Tried flashing the latest rooted image using "fastboot flash boot boot.img". No go.
I messed around trying to get the device to boot back up for a while, but it won't even charge right. Only charges long enough to kick off the Motorola 'M', and that is it. On attempts at loading fastboot, I just keep getting an error saying that the battery is low. I know I can only blame myself for this. No fastboot access and no adb access. All attempts at resetting the device have failed.
Before I attempted all of this, my battery was full. Unfortunately, wouldn't charge anymore even plugged into the wall. Any ideas?
Hopefully nobody else makes my mistake.
Man I can't wait till this is perfect, you guys are fricken awesome. I raped your thanks buttons op lol
MoPhoACTV Initiative
Will be working on this tonight. I just found out how to make the flash script clear cache and dalvik for you, pre-install. That'll probably save some headache, but it works only in edify format. Not sure what the stock recovery uses...
Anyways, I'm home!
ClearD said:
Will be working on this tonight. I just found out how to make the flash script clear cache and dalvik for you, pre-install. That'll probably save some headache, but it works only in edify format. Not sure what the stock recovery uses...
Anyways, I'm home!
Click to expand...
Click to collapse
All recoveries will now use edify, amend is old and depreciated, you will only find that on old devices.
Corrupt Kernel...
innovatelife said:
I went into recovery>mounts, and didn't see any wipe for boot. I took a shot at system since I had already wiped cache and data. Didn't seem to help either. Tried 'fastboot erase boot" and re-flashed. No go. Couldn't start back up the device at all. Tried flashing the latest rooted image using "fastboot flash boot boot.img". No go.
I messed around trying to get the device to boot back up for a while, but it won't even charge right. Only charges long enough to kick off the Motorola 'M', and that is it. On attempts at loading fastboot, I just keep getting an error saying that the battery is low. I know I can only blame myself for this. No fastboot access and no adb access. All attempts at resetting the device have failed.
Before I attempted all of this, my battery was full. Unfortunately, wouldn't charge anymore even plugged into the wall. Any ideas?
Hopefully nobody else makes my mistake.
Click to expand...
Click to collapse
This is a classical case of a corrupt Kernel. Not that the images are corrupt, but somewhere along your update, your boot.img did not install the kernel properly and now you have a broken power manager within kernel.
What I would do is the following:
Hook your watch to the charger and let the M sign show up.
Even if it hangs on the M, leave your watch hooked over night.
Try downloading an older image and use fastboot to erase everything and then flash everything back again. This should return your watch to a working state again.
You may then choose to customize it as you see fit.
Root tool > "return to stock"
Sent from my HTC Inspire 4G using XDA-funded carrier pigeons
simx said:
CEnnis91
I was lucky the second time, first time I succeeded to upgrade to rooted 4.55.97 but for some reason I didn't get the battery percentage on the status bar but all other issues are OK and status indicated version number 4.55.97, I repeated flash from recovery but after wiping and remounting all folders, this time for stock 4.55.97
Now I'm on stock 4.55.97 with battery percent on status bar and syncing from my mac.
thanks CEnnis91
NA
Click to expand...
Click to collapse
I'm about to try this.. but it's making me think... Do you think the updater-script doesn't correctly format system? Think about it... our devices say 4.55.97 (mine changed to that after a reboot or two), and we only had partial features... sounds like something isn't wiping correctly.
I am having problems installing the 4.4.2 update via OTA. I am on rooted 4.4 android KRT16S build.
I have rooted.
I have installed xposed framework.
I have installed twrp recovery.
OTA update stucks on twrp and nothing happens.
I have tried the following things :
1) Uninstalled xposed framework and tried installing 4.4.2
2) flashed the zip instead of OTA, twrp says failed.
3) enabled survival mode in superuser app.
4) I have also tried flashing KRT16S first which installs successfully on twrp and then 4.4.2 which again fails.
My point is starting this thread is to know exactly what to do when an OTA updates comes so that you can successfully update to the latest android version and also retain your data back.
Sent from my Nexus 7 using Tapatalk
OTAs are meant only for 100% stock.
The fact that they can occasionally be installed on a non-stock ROM (or when using a non-stock recovery) is purely happenstance - not evidence that anyone should have an expectation of a similar success on a device with arbitrary modifications.
It really is just that simple.
Which means, no matter what, I'll have to start from scratch again? Install 4.4 images with data wipe and then install 4.4.2 via OTA or flashable zip, followed by all customization and data restore by TB??
Only solution?
Sent from my Nexus 7 using Tapatalk
There is no need for a wipe, you can also install boot.img and system.img by fastboot and root your device again afterwards. In that case you will keep your data.
Sent from my Nexus 7 using xda app-developers app
neo1691 said:
Which means, no matter what, I'll have to start from scratch again? Install 4.4 images with data wipe and then install 4.4.2 via OTA or flashable zip, followed by all customization and data restore by TB??
Only solution?
Click to expand...
Click to collapse
There are possibly 8 or 10 different ways to go about this:
[A] Don't worry about minor OTA updates - recently they don't seem to be very compelling.
Dirty-restore only the system and boot images from a Nandroid backup of the near-factory ROM corresponding to the same base ROM you are using. You DO make nandroid backups before you start modifying things, don't you?
[C] Use a well-supported dev ROM and wait for the dev to update the ROM to the new release base. Then, just dirty-flash the ROM (if the dev says that is OK). (Obviously, dirty-flashing is not a good idea between ROMs that are wildly different in origin.)
[D]* Treat it like you would any other ROM install. Launcher configuration backup, TiBu Backup, Nandroid Backup, (custom recovery) "factory reset", new ROM install, (root kit install if needed), TiBu restore, Launcher configuration restore.
[E] Attempt OTA install, inspect failures in /cache/recovery/recovery.log, hand-revert files back to factory**. Rinse and repeat.
[F] Pick apart the OTA installer and repackage your own version of the OTA zip to remove the parts that cause failure - both the individual checks and the corresponding file patch operations.
[G] Find a "flashable stock" ROM that matches the same base version as your current ROM and dirty-flash it. Obviously this nukes any of your customizations. Also note that if that the dev did something like "zipalign" or odexing/deodexing of the stock ROM, it is unlikely that the OTA will succeed - even though the ROM is close to identical in function to the factory ROM, the files have been diddled and so the OTA will fail.
[H] If you think the near-stock mods you have made are "minor", you could attempt a "dirty flash" of just the "system.img" and "boot.img" files from the factory images. This would mean avoiding the use of "fastboot erase" of anything and attempting a "fastboot -w update my-custom-image-nakasi-XXXX.zip" where your custom .zip file only has the boot.img and system.img files in it (remove recovery.img, userdata.img from the .zip archive and also check the "android-info.txt" file to see that it is consistent). I have not personally tried this; if you are going to try it, I would back up your entire device as a safety precaution.
* The Google factory image install instructions show a complete wipe of the userdata partition; this is fundamentally different than most ROM installs (potentially requiring hours of waiting on backup/restores of the "sdcard" area).
** Obviously, you need a source of factory original files. Yet another reason to make nandroid backups before beginning ANY customizations. You can dig them out of nandroid backups - for instance, TWRP ".win" files are just tarballs. Or get familiar with simg2img (or here), loopback mounts, and so forth. You can find older versions of Google factory images on oldblue910's site http://www.randomphantasmagoria.com/
OTA Installation Notes:
[size=+1]1 - OTA installation is a PATCHING process.[/size]
[size=+1]2 - OTA preliminary checks are STOP-ON-FIRST-FAIL.[/size]
[size=+1]3 - OTA installs are ALL OR NOTHING.[/size]
1) The patching process for any individual file that will be updated is like this:
[prior factory file] + [OTA patch file] ===>>> [replacement file]
From the above diagram, it is apparent that "replacement file" needs both the original (factory) file plus the OTA-delivered patching file. The patching process cannot succeed unless an exact version of the original file - down to the very last byte - is present on on the device and in it's original location. The reason things are done this way is that the patch (.p) files are typically much smaller than the originals - so it saves the carriers bandwidth to roll out updates this way to lots of customers. The OTAs do not contain replacement files! They only contain patching (.p) files! Even "blob" files such as boot images are updated this way (so, generally, having a custom kernel will also cause an OTA fail).
2 & 3) The OTAs are quite conservative in their checking; they don't do something like this:
check file1... patch file1... check file2... patch file2... ...
but rather do this:
check file1... check file2... ... check fileN... patch file1... patch file2... ... patch fileN
If any of the checks fail, the process stops immediately without running any further checks This is a good thing - if it didn't happen this way, the OTA could get partially through and then fail - and then it would be impossible to repeat the OTA because all the successfully patched files would no longer be the original versions; and you would have a ROM in a screwed up (inconsistent) state.
So, in light of those above observations, it is apparent that:
- usually it is safe to attempt an OTA install on a modified ROM. If any file (to be modified) is missing or altered, a preliminary file check (SHA-1 hash computation) will fail and nothing will be modified. It is a good thing that the OTA install process is conservative this way.
- this explains why sometimes OTAs succeed on lightly modified stock ROMs: it just happens that whatever files the device owner/user fooled with are not in the group of files to be patched by the OTA. But that's no guarantee for the next OTA that comes down the pike, nor the one after that....
- if there are several file checks that are going to fail as a result of user modification, when the OTA runs, you will only be shown the error for the first file that fails - instead of a list of all files which are screwed up. That means that if you thought you were going to hand-patch things, you might have to iterate the process (OTA-fail... hand-patch... OTA-fail... hand-patch...) several times. If you were going to go down that road, the amount of effort needed to get things back to an OTA-friendly state might be quite significant. The only alternative to avoiding this is to inspect the "updater-script" that the OTA uses, and manually go through every file mentioned in the OTA and compute the SHA1 hashes yourself (using the program "sha1sum"). At least then you would know ahead of time which files/blobs are going to cause a failure.
- Note that the the SHA-1 checksums require that the files be identical to the factory originals down to the very last bit and byte. If you used a "flashable factory image" where the dev decided to do something like "zipalign" the .apk files, or add or remove .odex files, an OTA isn't going to work correctly. The files don't just need to be identical in function, they need to be identical down to the last bit and byte.
So now you can see why you observe lazy rooters perpetually returning to this forum asking, "can anybody get me a copy of file such-and-such from version XYZ of the stock ROM?". They are trying to hand-revert their existing ROM so that an OTA will succeed. And the fact that they are asking that question means that they failed to make a (nandroid) backup of their near-factory ROM. If they had done that, they would have the file(s) in question, and -morover- they would also have the option of running a TiBu backup & nandroid backup, restoring the original (factory/near-factory) ROM, taking the OTA, repairing root, and restoring TiBu backups... and then re-applying their customizations. But failing to take a nandroid backup means that they have NEITHER
Well, hand-reverting a ROM so an OTA will succeed may not be "starting from scratch", but it could be quite a bit of effort, yes? You have to undo things by hand to get back to "close enough" to factory state so that you can get the OTA to work. And usually the OTA stomps on permissions of /system/{x}bin/su so that re-rooting is necessary (or else you involve yourself with some dumb "root saver app" ahead of time). And then re-apply the customizations that intersected the OTA causing its' failure(s). All of that takes time. Less time than biting the bullet and just making backups? Hard to say. But one approach paints you into a corner, and the other provides maximum repair/restore flexibility.
I get it that backups take time, and performing TiBu backup/restores takes time too. And if you don't use a launcher that allows configuration saves/restores, even more time wasted there re-configuring things to "the way they were". But really, there's no excuse for not making Nandroid backups - and copying them off the tablet for safe keeping. You can always delete them later if you don't use them.
whew. i'm done.
bftb0 said:
There are possibly 8 or 10 different ways to go about this:
Dirty-restore only the system and boot images from a Nandroid backup of the near-factory ROM corresponding to the same base ROM you are using. You DO make nandroid backups before you start modifying things, don't you?
[/0QUOTE]
Thanks for the awesome reply. I appreciate the time you spent in giving me such a concise and precise reply to my question.
So I have the nandroid backup ->
1) I will flash 4.4, with full wipe and update to 4.4.2
2) Flash twrp and root.
3) Restore my data from my old nandroid backup.
Click to expand...
Click to collapse
neo1691 said:
So I have the nandroid backup ->
1) I will flash 4.4, with full wipe and update to 4.4.2
2) Flash twrp and root.
3) Restore my data from my old nandroid backup.
Click to expand...
Click to collapse
Hmmm. By that do you mean a nandroid restore of /data only on top of a fresh (full wipe) install and OTA update? That's a bit unusual - if any changes occurred in the total count or naming of pre-installed system .apks, that could lead to UID mismatch problems. Also, sometimes OTAs do removal/cleanup of things in /data ... you ought to look in the updater-script (OTA .zip file META-INF/com/google/android/updater-script) to see if any of that is going on. That's why both AnDiSa and I suggested methods that leave the data in place during the OTA update.
I guess what I am saying is that what you are proposing *might* succeed but it's a little bit nonstandard. (It prevents the OTA process from cleaning anything up in /data. Admittedly, that's a little unusual, but I think I have observed it in the past.)
Whatever you do, take a full Nandroid of where you are now; if things get screwed up you can always go back to your current setup and try a different approach.
Thanks a lot for all your invaluable inputs. Too much for me to work on now. I'll report what happens.
Sent from my Nexus 7 using Tapatalk
I am ready to do a dirty wipe. But I am not able to find the boot.img and system.img in the zip of KRT16O.
It is the 4.4 base.
It has a folder called patch which contains boot.img.p , but no system.img
There should be Bootloader.IMG and another tgz. If you extract this tgz you will find boot.img, system.img, data.img.
Be careful to not mix up bootloader.img and boot.img.
Sent from my Nexus 7 using xda app-developers app
---------- Post added at 04:59 PM ---------- Previous post was at 04:58 PM ----------
... one question: are you sure you have the Google Factory Image?
Sent from my Nexus 7 using xda app-developers app
You were right, I was looking in the wrong file,
So extracted the real factory image and there was another zip in that which contained the respective files!! Lets see what I can do now!
Solved!!
Okay. I am now on 4.4.2!! Cheers!!
But dirty flashing didn't worked for me!
I flashed the system.img and boot.img from 4.4 base, and then tried flashing 4.4.1. It worked. But flashing 4.4.2 zip failed just like before.
So after that I took a backup of my sd card and did a full flash of 4.4 base. (KRTO) and then updated to 4.4.2>flashed twrp>waited for OTA>installed OTA from twrp. Worked like a charm.
Now the challenge lies in restoring the data back completely. I have a nandroid backup and TiBu. Guess I will be usin TiBu!!
This thread will be an excellent guide for people facing me problem update OTA over rooted stock rom!
Thanks everyone for their help and support!! Cheers
@neo1691
happy holidays indeed!
The nice thing about nandroids is that you can jump back and forth between two ROMs if necessary.
For instance, suppose you forgot to do TiBu in the prior ROM - no problem! Just make a nandroid of the current (new) ROM, restore the prior Nandroid, do the TiBu backup, restore the (new) ROM nandroid, and then perform the TiBu restores. Easy-peasy.
Backups are awesome. Make 'em often - you can always toss them after a while if you aren't going to use them.
Cheers.. Thanks again everyone
Sent from my Nexus 7 using Tapatalk
Hey all. I am getting an error when trying to sideload the update. I was having trouble with my drivers for a while, and just now got around to fixing them, so I thought that I would update, since I have TWRP, and the OTA obviously doesn't install with that. So anyway, here I am, using the Nexus Root Toolkit to sideload, and everything went well. Until the Nexus was verifying the current systen. Here is the error:
"EMC:/dev/block/platform/sdkci-tegra.3/by-name/LNX:5109760:c804e149ffe2595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35" has unexpected contents.
E:Error in /tmp/update.zip
(status 7)
Installization aborted.
Any help would be great. Thanks
LNX is the boot partition.
You could experience that problem if you
- installed a custom kernel
- modifed your ramdisk (and then repacked the boot image)
- anything else that would alter a single byte in the boot image
the solution is to re-install the stock boot image.
The OTA will probably affect your ROM root (usually by changing the setuid permissions on the "su" binary), so be prepared to resolve that.
In general, OTAs are not intended for updating modified devices.
bftb0 said:
LNX is the boot partition.
You could experience that problem if you
- installed a custom kernel
<b>- modifed your ramdisk (and then repacked the boot image)</b>
- anything else that would alter a single byte in the boot image
the solution is to re-install the stock boot image.
...
In general, OTAs are not intended for updating modified devices.
Click to expand...
Click to collapse
Thanks. I forgot to mention that I am just unlocked and rooted running stock. The only thing that is different is that I have MultiRom installed also. I imagine that is what the issue is. I was thinking of trying out the official CM11, but I didn't want that as my primary. Is there a way to leave MultiRom installed and still update?
jma9454 said:
Is there a way to leave MultiRom installed and still update?
Click to expand...
Click to collapse
Sure. You can always unpack the OTA zip file, remove the parts you don't like ( in the command script META-INF/com/google/android/updater-script ), zip the whole shebang back up and flash it. Neither of the custom recoveries seem to give a $hit whether or not the .zips are signed.
Probably a good idea to make a nandroid backup before you begin.
good luck
bftb0 said:
Sure. You can always unpack the OTA zip file, remove the parts you don't like ( in the command script META-INF/com/google/android/updater-script ), zip the whole shebang back up and flash it. Neither of the custom recoveries seem to give a $hit whether or not the .zips are signed.
Probably a good idea to make a nandroid backup before you begin.
good luck
Click to expand...
Click to collapse
so can I take out this whole part?
apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35") || abort("\"EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35\" has unexpected contents.");
set_progress(1.000000);
(Just to let you know, this comes from almost exactly halfway into the updater-script)
thanks for your help
jma9454 said:
so can I take out this whole part?
apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35") || abort("\"EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35\" has unexpected contents.");
set_progress(1.000000);
(Just to let you know, this comes from almost exactly halfway into the updater-script)
thanks for your help
Click to expand...
Click to collapse
There are TWO such lines. (First, the check and then later on the actual patching operation)
The OTAs always run through 100% of the checks before a single file is modified. If a single check fails, the OTA stops immediately ... without anything being touched. It has been the convention in OTAs that the very last thing to be checked is the boot image (if it is getting updated)... that's why you are finding that apply_patch_check() about halfway through the file; you will notice that the actual patching of files starts shortly after that, and each file is patched in series in the same order that they were checked.
So, towards the very end of the file you will find the matching patch operation of the LNX (boot) partition; you should remove that line as well because that patching operation will cetainly not produce correct results. (And the boot partition is kinda important, no?)
To anybody else besides the OP who is reading this: for arbitrarily modified ROMs, this approach is not recommended (trying to take only PART of an OTA) as there may be components in an OTA update which are interdependant across multiple files. For an OTA that fails only due to a single modified file, it might be acceptable - but you accept all the risks of fooling with things this way.
EVERYONE should take a Nandroid backup before attempting such mods.
bftb0 said:
There are TWO such lines. (First, the check and then later on the actual patching operation)
The OTAs always run through 100% of the checks before a single file is modified. If a single check fails, the OTA stops immediately ... without anything being touched. It has been the convention in OTAs that the very last thing to be checked is the boot image (if it is getting updated)... that's why you are finding that apply_patch_check() about halfway through the file; you will notice that the actual patching of files starts shortly after that, and each file is patched in series in the same order that they were checked.
So, towards the very end of the file you will find the matching patch operation of the LNX (boot) partition; you should remove that line as well because that patching operation will cetainly not produce correct results. (And the boot partition is kinda important, no?)
...
Click to expand...
Click to collapse
so do I remove this whole part or just everything until the delete script?
ui_print("Patching boot image...");
apply_patch("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5109760:c804e149ffe3595235595a35a25096d53e1c5ea2:5111808:40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35",
"-", 40ea9855a3b10fd1e65ace0fc3b7bb19bec8bf35, 5111808,
c804e149ffe3595235595a35a25096d53e1c5ea2, package_extract_file("patch/boot.img.p"));
set_progress(0.999993);
delete("/system/recovery-from-boot.p",
"/system/etc/install-recovery.sh");
Well, I just read your sig
That file is an extremely simple programming language (barely even that as it has no loops, conditionals or jumps). It just executes each "line" in turn one after another unless there is an error; and in that case it just stops.
Like most programming languages, things like balanced parentheses and line termination characters (e.g. semicolons) are significant.
So have a hard look at those lines above, make a decision about what you think is correct... and move forward knowing that if you make a mistake you will have a Nandroid backup waiting to put you back where you were. (To be super sure of that, get a copy of it off your tablet before you start flashing.)
If that makes you uncomfortable, then don't do anything. From here on out, *you* are in charge.
good luck.
Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.
I have same issue. After returning to stock 4.4.2 I had difficulties in rooting. Good thing that I managed to install CMW (using Wug's toolkit) and flash a SU to root my device (I searched in help forum).
After having stock 4.4.2, rooted (tested and verified by deleting system APK) and custom recovery, I cannot flash a custom ROM. Let us know if someone can actually solve this!
jma9454 said:
Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.
Click to expand...
Click to collapse
* As per link below, TWRP will skip the below asset check (resulting to status 7 error).
* Using Wug's Tool, restore tablet to stock 4.4.2
* I found out that file in "D:\nexus7\data\Recovery_Custom\TWRP" is less than 7.58 MB. So I downloaded TWRP manually in below link. Save this in same location and install TWRP using Wug's tool. You can root as well at the same time (I forgot this step)
* Copy the ROM & GAPPS in tablet and rebooted to TWRP (using Wug's tool).
* Wipe option in TWRP
* Install ROM successfully , then install GAPPS
* Since I forgot to root, TWRP option asked to root my device... I selected root.
Finished...
asset check link: http://highonandroid.com/android-rom...ooted-android/
TWRP link: http://techerrata.com/browse/twrp2/grouper
Wug's Tool: http://forum.xda-developers.com/showthread.php?t=1766475
austin_dreq said:
I have same issue. After returning to stock 4.4.2 I had difficulties in rooting. Good thing that I managed to install CMW (using Wug's toolkit) and flash a SU to root my device (I searched in help forum).
After having stock 4.4.2, rooted (tested and verified by deleting system APK) and custom recovery, I cannot flash a custom ROM. Let us know if someone can actually solve this!
Click to expand...
Click to collapse
jma9454 said:
Well, I deleted everything till the delete line. Hopefully I don't have problems, as now that I am reading the entirety of it, I should have done the whole thing. It flagged and booted just fine though. Thanks for all the pointers.
Sent from my Nexus 7 using Tapatalk
--------edit--------
Well, no root access, but the simple task of rerooting should do the trick, I think.
Click to expand...
Click to collapse
Good job man.
These lines in the updater-script
Code:
set_metadata_recursive("/system/bin", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata_recursive("/system/xbin", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
are what cause the loss of root.
The "su" binary is still present in the ROM ... but the *recursive* (all files underneath the directory given) change of permissions alters the "setuid" nature of the "su" binary so it no longer runs with root identity. (depending on which version of root kit you have, the "su" binary could be in either /system/bin or /system/xbin)
note there is also a non-recursive version of "set_metadata" for dealing with individual files.
You can't just delete the recursive call as it manipulates lots of files other than the one you are trying to protect ("su").
But *after* that recursive mode-setting is done, you could certainly add an instance of set_metadata on the su binary in order to restore the ownership and file modes that the su binary needs to work correctly.
And then you would have - ta-da! - your own customized version of the OTA that skips the stuff that cause failures, and doesn't stomp on root.
Figuring out the correct selinux syntax is left as an exercise for the reader.
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
So, since once a month I find myself having to click a bunch of links and read how to do a bunch of commands, I wanted to create a thread that (rather generically) explains how to manually flash the OTA monthly updates if you're rooted with Magisk. So, minimally, here's a thread for me to review every month... if it helps you all out, all the better!
Pre-requisites:
Download Latest OTA zip file from Google.
Obtain the STOCK boot.img (required) and dtbo.img (optional) of the System ROM you are currently running. This can be done if you already have the full System Image file downloaded, downloading it currently, or just obtaining the stock boot and dtbo image files elsewhere. (NOTE: This can be skipped if you successfully uninstall Magisk BEFORE you start the process and choose to restore the Stock images in the uninstall process.)
Download Latest Magisk Zip file
Download latest TWRP recovery image
If applicable, have latest USB drivers, adb/fastboot/ files etc.
Preparation:
1) Extract or open the Full Image file and locate the boot.img and dtbo.img files. You will want these on your PC in the platform-tools folder (I usually put the Month name at the beginning, ex. - Jan_boot.img). Again, you can skip if you successfully uninstall Magisk prior to all of this.
2) Copy your OTA zip file to the platform-tools folder, again naming it after the month helps (ex. - Feb_Pixel2XL_OTA.zip)
3) Put your TWRP recovery in platform-tools folder.
4) Place the latest Magisk zip on your Pixel's internal storage (what used to be the SDCard on phones so equipped).
Commands:
1) From PC, open command prompt and change directory to your platform-tools folder.
2) If your phone is on, "adb reboot bootloader" If powered off, press power and Vol Down button to get to Bootloader. Plug your phone into your PC.
3) [If Magisk is not uninstalled first] Command: fastboot flash boot {Name_of_boot.img File}
4) [If Magisk is not uninstalled first] Command: fastboot flash dtbo {Name_of_dtbo.img File}
5) On your phone, hit Vol Down until you see Recovery, then press power button.
6) Once in recovery mode, press power and Vol Up to bring up menu
7) Scroll to item: "Apply update from ADB" and press power
8) Command: adb sideload {Name_of_OTA.zip file}
9) After the OTA finishes flashing, exit recovery back into the Bootloader
10) Command: fastboot boot {twrp_filename.img}
11) Install Magisk Zip file (and any other Zip files you want installed... Kernels, etc.) within TWRP
Then after flashing your zip files, reboot to system and you should be all set.
I believe everything above is correct, but if I've made a glaring mistake, please let me know. I also realize there may be other methods to this madness, but this is what works for me.
With this method do you have to worry about removing your password from your phone before you try to go into twrp?
uofirob said:
With this method do you have to worry about removing your password from your phone before you try to go into twrp?
Click to expand...
Click to collapse
Yes. Mine is set to pin, which I had to put in and it let me finish.
Sweet. I'll give this method a try tonight!
WorldOfJohnboy said:
Yes. Mine is set to pin, which I had to put in and it let me finish.
Click to expand...
Click to collapse
Thank you for this. Just to be clear in step 2 under prerequisites you say more on this later. Then in step 1 for preparation you prefix your boot and dtbo with Jan xx.img. I get what your saying, but for the newer noobs they may get confused. Maybe reword to say, extract or open the factory image your currently using or the previous months image. Obviously you do this first so that you can sideload the ota. I don't mean any disrespect.
I believe you also need remove the -w from the end of the .bat file after you extract the OTA; otherwise, all of your data will be wiped.
But great job of getting all this info in one place!
So I did this, and now I'm bootlooping. I guess I'll re-flash the Jan factory image and wait a little longer... **UPDATE** I fixed the bootloop by re-trying the process again (after re-verifying the MD5 hash on the update.zip. I rebooted after installing the update,
but before the TWRP flash to install MAGISK. Maybe this allowed the "update"
to finish processing. I also had to remove the pin from my lock screen in order to allow me to get into twrp. After rebooting into the system and removing the pin, I adb reboot bootloader and then flashed twrp. Thanks for the guide!
---------- Post added at 07:58 AM ---------- Previous post was at 07:50 AM ----------
PuffDaddy_d said:
I believe you also need remove the -w from the end of the .bat file after you extract the OTA; otherwise, all of your data will be wiped.
But great job of getting all this info in one place!
Click to expand...
Click to collapse
You don't need to remove the -w from the .bat file since you aren't using it at all to do the update. That is only if you're flashing your factory image.
Fe Mike said:
Thank you for this. Just to be clear in step 2 under prerequisites you say more on this later. Then in step 1 for preparation you prefix your boot and dtbo with Jan xx.img. I get what your saying, but for the newer noobs they may get confused. Maybe reword to say, extract or open the factory image your currently using or the previous months image. Obviously you do this first so that you can sideload the ota. I don't mean any disrespect.
Click to expand...
Click to collapse
I changed some wording under prerequisite...
I agree with everything on this guide...
just teasing...
I'm actually glad you created this thread...I wanted to create one also and try and help out as much as I could, but I don't have the cahones and didn' t think I had experience enough to start a "guide" thread :silly:
I mean no disrespect, but this seems awful complicated compared to just flashing the full image with the removed (-w). Especially since your downloading it anyway. I do that then boot the TWRP image and flash the TWRP zip. Reboot into recovery and flash kernel and magisk and reboot system. Again I'm asking for clarity, not dumping on you. Great write up btw!
CyberpodS2 said:
I mean no disrespect, but this seems awful complicated compared to just flashing the full image with the removed (-w). Especially since your downloading it anyway. I do that then boot the TWRP image and flash the TWRP zip. Reboot into recovery and flash kernel and magisk and reboot system. Again I'm asking for clarity, not dumping on you. Great write up btw!
Click to expand...
Click to collapse
Well...I can't speak for the OP, but I wrote my extremely similar identical one because, for whatever reason, many users would choose OTAs over flashing full factory images. I/me & you understand the benefits of the factory images over the OTAs; especially understanding the process you must go through to install the OTAs as-of-current is almost the same as flashing the factory images anyways...
But if I were to give a possible explanation to their reasoning is that, like many of them, I come from a non-Google phone (S5 for me), and OTA's were simpler, takes less bandwidth (which still remains true today), they were significantly simpler to install vs. factory images, and with a lot of popular phones you only flash factory images to recover your phone; i.e. muniz_ri's OTA's for the S5 and FlashFire were loads simpler than flashing a whole factory image. But, again, understanding the difference for Pixel 2 and Oreo's OTA & factory images (or the small difference thereof), it's probably better to do a few extra steps and/or downloads to do the whole image than sideloading an OTA.
In the end, this is for people who insist for OTA updates most likely because that's how they are familiar (and therefore more comfortable) with; whether it being explained to them or not...
Cheers!:good:
Fair enough, thanks for the input!
CyberpodS2 said:
I mean no disrespect, but this seems awful complicated compared to just flashing the full image with the removed (-w). Especially since your downloading it anyway. I do that then boot the TWRP image and flash the TWRP zip. Reboot into recovery and flash kernel and magisk and reboot system. Again I'm asking for clarity, not dumping on you. Great write up btw!
Click to expand...
Click to collapse
It may seem awful complicated, but to be honest, to me is less complicated than having to edit a script file (which if you forget to do, will lose all of your data). Also, though the steps I wrote out seem like a lot more if you were to write out a process using the full image, it actually works out to be almost the same number of steps.
Lastly, as someone else hinted at, the OTA file size is smaller. The only full image you need is what you are currently running (which in most cases I have on my phone in case the sh__ hits the fan with my phone), not the new full image. (To be even more precise, you only need the boot.img and dtbo.img from the full image file--there may be places to get just those two files out there.)
As I put in the last sentence, I realize there are other methods to this madness, this is basically what works for me. I wanted to get it in writing so I wouldn't forget this down the road, and if it helps anyone here, just icing on the cake. Clearly I'm no Dev and not forcing anyone to perform the updates this way!
WorldOfJohnboy said:
It may seem awful complicated, but to be honest, to me is less complicated than having to edit a script file (which if you forget to do, will lose all of your data). Also, though the steps I wrote out seem like a lot more if you were to write out a process using the full image, it actually works out to be almost the same number of steps.
Lastly, as someone else hinted at, the OTA file size is smaller. The only full image you need is what you are currently running (which in most cases I have on my phone in case the sh__ hits the fan with my phone), not the new full image. (To be even more precise, you only need the boot.img and dtbo.img from the full image file--there may be places to get just those two files out there.)
As I put in the last sentence, I realize there are other methods to this madness, this is basically what works for me. I wanted to get it in writing so I wouldn't forget this down the road, and if it helps anyone here, just icing on the cake. Clearly I'm no Dev and not forcing anyone to perform the updates this way!
Click to expand...
Click to collapse
Hey bud, wonder I I could pick your brain just a little. When doing monthly Google updates, are most of their proprietary files located in the boot, dtbo, and vendor images?? Your posts have intrigued me a little, and are very well written BTW. My reasoning is this. On my old 6p, about all we needed to do was flash the new vendor, and of course the bootloader and radio if there were any worthwhile improvements. Would the same possibly apply to the P2XL?? I'm just wondering because, now that we're starting to see custom roms, if this would be a viable option, and simplify the updating process. Thank again for your great write up ??
Badger50 said:
Hey bud, wonder I I could pick your brain just a little. When doing monthly Google updates, are most of their proprietary files located in the boot, dtbo, and vendor images?? Your posts have intrigued me a little, and are very well written BTW. My reasoning is this. On my old 6p, about all we needed to do was flash the new vendor, and of course the bootloader and radio if there were any worthwhile improvements. Would the same possibly apply to the P2XL?? I'm just wondering because, now that we're starting to see custom roms, if this would be a viable option, and simplify the updating process. Thank again for your great write up
Click to expand...
Click to collapse
I'll be perfectly honest with you, I haven't taken a dive to see what is in the OTA files and would imagine that it varies depending on the monthly updates.... that said, the only reason why I have stated to re-flash the stock boot.img is because if you are rooted with Magisk, it takes the stock boot.img and modifies it. In order to take an OTA sideload, you need to be on stock boot.img and stock recovery. dtbo is only in my process because there was one time when I tried to sideload and my dtbo wasn't stock (or corrupt). You may not need to flash the stock dtbo.img, but it doesn't hurt to do so.
WorldOfJohnboy said:
I'll be perfectly honest with you, I haven't taken a dive to see what is in the OTA files and would imagine that it varies depending on the monthly updates.... that said, the only reason why I have stated to re-flash the stock boot.img is because if you are rooted with Magisk, it takes the stock boot.img and modifies it. In order to take an OTA sideload, you need to be on stock boot.img and stock recovery. dtbo is only in my process because there was one time when I tried to sideload and my dtbo wasn't stock (or corrupt). You may not need to flash the stock dtbo.img, but it doesn't hurt to do so.
Click to expand...
Click to collapse
I'm really happy to see our device has graduated to this level of discussion, instead of the random guessing and 14 different "possible" routes to a solution. Lol
Custom roms abound, once TWRP gets squared away and someone master's the art of turning monthly updates into zip installs we'll pretty much be there!
Btw OP, great write up... Clear and precise!
I do not understand the purpose for downloading the full system image and then flashing only the OTA zip - what am I missing? There is a widely distributed method for performing monthly OTA updates by uninstalling Magisk, updating OTA normally, then flashing Magisk again - seems much simpler, any reason why it would not work?
Brenneke said:
I do not understand the purpose for downloading the full system image and then flashing only the OTA zip - what am I missing? There is a widely distributed method for performing monthly OTA updates by uninstalling Magisk, updating OTA normally, then flashing Magisk again - seems much simpler, any reason why it would not work?
Click to expand...
Click to collapse
Downloading the full system image is not required. You only need the Stock versions of boot.img (required) and dtbo.img (optional) of the ROM version your phone is currently running. I actually keep a full system image on my phone in case something goes awry.
I'm going to update the OP to more clearly state that you only need the stock boot.img file--how you obtain it is up to you. Uninstalling Magisk will do the same exact thing, however I tried to do that a couple of months ago and it created more issues for me than if I had just flashed the stock boot.img in the first place.
WorldOfJohnboy said:
Downloading the full system image is not required. You only need the Stock versions of boot.img (required) and dtbo.img (optional) of the ROM version your phone is currently running. I actually keep a full system image on my phone in case something goes awry.
I'm going to update the OP to more clearly state that you only need the stock boot.img file--how you obtain it is up to you. Uninstalling Magisk will do the same exact thing, however I tried to do that a couple of months ago and it created more issues for me than if I had just flashed the stock boot.img in the first place.
Click to expand...
Click to collapse
I have not tried the uninstall Magisk method but plan to do so at next update. What kind of issues did it create for you?
Thanks.
Brenneke said:
I have not tried the uninstall Magisk method but plan to do so at next update. What kind of issues did it create for you?
Thanks.
Click to expand...
Click to collapse
For some reason, I don't think it restored the correct (or not corrupted) boot.img version. Then, there were remnants of the Magisk APK and other files so I ended up having to do a full TiBu of my apps and flashed (with wipe) a full System image. It may have been something I did or just my bad luck, but I prefer not to chance it and instead manually flash the Stock image as my "guide" here states.