Database Users

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

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

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

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

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

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

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

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

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

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

4.2.1 to 4.2.2 rooted stock rom upgrade nightmare

Hi there, i've got a problem updating, like many it seems and I'm pretty new to rooting etc. so please bear with me.
I have 4.2.1 stock rom, rooted and with twrp v2.4.1.0 recovery. I was originally rooted with CWM recovery (using n7 toolkit) but I have flashed twrp to try and update with no luck either.
Anyway I get an error (see attachment image) via ota or via downloading the zip and copying it to the n7 then browsing for it in recovery and installing it that way. I'm basically wondering if there's a quick fix to this problem and can you please help me with it even if there isnt a quick fix. I really don't want to reset my device and have to set everything back up again.
Also, i dont know if this is related, probably is, I cant boot into recovery using the power off hold volume down trick, getting into fastboot mode and then selecting recovery as it just brings up the google logo forever and I have to reset the tablet due to it doing nothing. The only way I can get into recovery is to clear data from google services framework and do an ota update (1970 thing) and that reboots into recovery. I then get the error 7 message in attached photo.
Plz help?!?!
Thanks in advance

Here's what to do.
First, look at those errors in the image you posted very very carefully.
2nd, use the search function on this forum: try the terms "OTA debuggerd" (without the quotes)
3rd, read those posts.
4th, decide if you want the hassle. You are not obligated to perform an upgrade.
5th, Download from Google the 4.2.2 Factory images and extract the "boot.img" and "system.img" files
(make sure you understand that nakasi == grouper == WiFi N7, and nakasig == tilapia == 3G N7)
Hint: search on Google for "Google Nexus Factory Images"
finally
fastboot flash boot name-of-boot-image-file.img
fastboot flash system name-of-system-image-file.img
This will remove root from the ROM, so you will need to flash a SuperSU or Superuser root kit.
Doing things this way is a band-aid. You need to learn how to make full backups & perform full restores; how to flash individual partitions - using both fastboot & the custom recovery; know exactly what the roles of each partition are; know the difference between a kernel, ramdisk, and boot image; understand how to retrieve a small number of files from prior backups; and to know where the installer scripts are located inside flashable .zip files & be able to read them so you can understand what they do.
Finally, you should understand what apps like Titanium Backup and Carbon are capable of, and how backup of System app&data has different consequences upon restore than similar operations for user-installed apps.
OK - get started.

Kernel/bootloader/recovery

Hi guys,
1. What is the advantage/disadvantage of flashing a custom kernel?
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
7. Difference between unlocking bootloader and rooting.
8. How to find out N7's latest stock kernel version.
Many thanx
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
1. What is the advantage/disadvantage of flashing a custom kernel?
Click to expand...
Click to collapse
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
valapsp said:
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
Click to expand...
Click to collapse
I believe it does. I don't remember which one though, since I don't use CM.
valapsp said:
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
Click to expand...
Click to collapse
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
valapsp said:
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
Click to expand...
Click to collapse
I believe it contains stock ROM and kernel.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
valapsp said:
7. Difference between unlocking bootloader and rooting.
Click to expand...
Click to collapse
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
valapsp said:
8. How to find out N7's latest stock kernel version.
Click to expand...
Click to collapse
Google. Sorry, can't help you with this one.

That was a great answer @Rirere

Rirere said:
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
I believe it does. I don't remember which one though, since I don't use CM.
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
I believe it contains stock ROM and kernel.
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
Google. Sorry, can't help you with this one.
Click to expand...
Click to collapse
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.

valapsp said:
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
Click to expand...
Click to collapse
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).

Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.

kbeezie said:
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
Click to expand...
Click to collapse
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img

valapsp said:
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
Click to expand...
Click to collapse
bootloader img would be the original stock bootloader for the Nexus 7, chances are you never replaced it, you only unlocked it. There's usually no reason to replace the bootloader with a custom one since all you need to do is unlock it.
userdata.img would be the /data partition. The firmware download basically has a image for all of the partition in the original out-of-the-box stock state. Technically you don't even to flash it, as long as you wiped /data before rebooting (since that would be the same as a clean install if you instead flashed the system and boot partition).
Edit: If I were messing with it to get back stock rom (but not messing with recovery, cuz custom recovery is still handy to have), I would only flash the boot.img and system.img , then log into Recovery and wipe data (ie: factory reset which wipes cache and /data but doesn't touch /data/media), Then I would be able to reboot into a clean stock install of the rom.
(from there I could just make a backup from recovery so I wouldn't have to do a fastboot flash again).

kbeezie said:
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Click to expand...
Click to collapse
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.

@valapsp
Small but important clarification.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Essentially 100% of custom ROMs install a kernel. (Actually, a kernel plus a ramdisk packaged together as a single ("bootable image") file, typically named "boot.img".) So your preexisting boot image containing the kernel is always overwritten during a ROM installation. See next answer.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Almost, but not quite. If you want to use a different kernel than what ships with a given ROM, you flash it after you have installed the ROM, not beforehand. See prior answer.
One more thing. Since you are new to this stuff, I'll make a suggestion:
Learn how to create and restore full Nandroid backups (using the custom recovery) immediately. And get in the habit of copying them off your tablet to your PC. You will thank me later for this advice.
have fun

Rirere said:
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
Click to expand...
Click to collapse
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.

GedBlake said:
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
Click to expand...
Click to collapse
I believe you are correct! Theoretically, the script could rather easily check for added files by checksumming the entire /system partition before running the update (using a fast hash algorithm-- you're only looking for the presence of any changes, afterall). And I did have one OTA that went fine, other than losing root back on my Galaxy Nexus.
Again though, it's a classic case of should versus real life. Some root methods might alter things in /system without your knowing, or root actions might alter permissions. Either way, it's a tricky, nasty little game.
So far as recoveries go: yeah, OTAs have a nasty habit of trying to do that. Some of the more advanced recoveries can resist being overwritten though/slipstream a root ZIP into the update process.

GedBlake said:
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Click to expand...
Click to collapse
Typically the OTAs also update the boot image, so the boot partition (LNX) is also checked. The stock recoveries almost always use the same kernel (with a different ramdisk) as the boot image, so they are usually rewritten too.
Owners of tilapia N7 devices have reported successful flashing of everything but radio firmware images when they used a custom recovery to process the OTA bundle. Not a disaster, as their devices will still function with old radio firmware, but it puts them in an unusual position of being unable to use the OTA to subsequently update the radio, even if they restore the stock recovery (the system files and boot images will have been changed, so almost all of the checksums will fail). At that point, using fastboot is an alternate option, but then the newbs will need to read about OTA images, unpack them, yadda yadda yadda.
IMO it is just a dumb idea applying OTAs to anything but a pure stock device. And when I say pure stock, I mean including the stock recovery. The boot loader can be left unlocked, but that's about it.
There are a lot of ways to skin the cat, but IMO the best way to proceed is to operate with two parallel but independent tracks of Nandroid backups/restores: one track is a sequence of pure stock, and the other your customized ROM du jour.
Let's presume you have a Nandroid backup of the pure stock ROM. Make a backup of your current (customized) ROM & get it copied off the tablet (in the event of a disaster), restore the pure stock ROM nandroid backup, flash the stock recovery back to the tab, and then take the OTA.
At this point:
[ unlocked bootloader ] soft-boot (no flashing) a custom recovery using fastboot, and then make yet another Nandroid backup of the newly updated stock ROM including the recovery image. (This becomes the new baseline for future OTAs)
[ locked bootloader ] re-root with motochopper, capture the (new) stock recovery partition using 'dd', flash a custom recovery ('dd' or other method), make a Nandroid of this. (These two backups become the new baseline for future OTAs)
Then, repeat any rooting customizations (if you are a "lightly customized rooted stock" kinda person), and restore apps (Market apps only!) with TiBu.
This may seem like a great deal of work, but it is the only way to insure that you can revert to a prior starting position. Look: after going down a road like this you can even restore the old customized ROM backup to make TiBu app backups after the fact, simply because you can return to any point in time if you have made a backup (and kept a copy of it off the tablet).
Everybody makes mistakes - even the experts. But the lazier folks are (read: toolkit user) the more likely is a disaster. Everybody needs to make backups.

What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app

valapsp said:
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).

kbeezie said:
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
Click to expand...
Click to collapse
Thanks, and does backing up thru cwm also back up the build.prop?

valapsp said:
Thanks, and does backing up thru cwm also back up the build.prop?
Click to expand...
Click to collapse
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.

kbeezie said:
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
Click to expand...
Click to collapse
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app

valapsp said:
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
If it's a backup done with 4EXT or TWRP most certainly since it's just a tarball package (or tar+gzipped if you enabled compression) and can be easily unpacked by tar, or any popular archive utility like 7Zip for windows. (restoration generally just looks at the file info to see what partition type it's supposed to be, formats the partition as such, and then just un-tars the content, with the permissions and such retained).
If it's older where it's an actual jaffs (may have spelled that wrong) disk image, I'm not sure off the top of my head how you would mount it as a disk , and then mount the ext4 or ext3 partition in order to get to it. I would assume ClockworkMod would have upgraded their backup method to the same as TWRP or 4EXT, but it's possible that they didn't for compatibility reasons.

[Guide]How to get an update if unlocked and rooted, but otherwise on stock EMUI

I just bought the Honor 8 and immediately unlocked and rooted it via Magik. Of course not long after that, I get a notification that there is an update available. You obviously cannot update the phone by simply pressing the "update" button since we have a non-stock recovery. I did a fair amount of research to find out how I could get the update and I wanted to share what I found. All of this information is out there already, but generally speaking it is spread out in many different threads. Hopefully these directions can help someone else.....
First, the usual disclosures.....
Code:
I am not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired because the alarm app failed. Please
do some research if you have any concerns about features included in this GUIDE
before flashing it! YOU are choosing to make these modifications, and if
you point the finger at me for messing up your device, I will laugh at you.
1) Make a NANDroid backup using TWRP: if the new update locks the phone, you will need this backup to restore data after unlocking it
2) Unroot your phone: honestly I did not do this step myself because I simply didn't think about it. The update process worked for me without unrooting but I am also using Magik which doesn't alter the system files. To ensure success I would definitely recommend you unroot. You will have to reroot the phone after the update regardless if you unrooted or not, so you aren't saving any steps by keeping root at this point. If you have used a different root method besides Magik, you must unroot prior to attempting an upgrade.
3) Obtain stock recovery.img file: the update won't work with TWRP as your recovery, so we need to flash the original Huawei recovery to replace TWRP. If you already have a copy of the stock recovery skip to step 4. If you are like me you don't have a copy of the stock recovery image on hand and we will need to extract it from the stock ROM image. Using a computer (not your phone) download the stock ROM image for your device. This website seems to have a list of recent versions and it is where I downloaded the L14 B389 version that I used.
Download the Huawei Update Extractor software and unzip the folder on the computer. Open the HuaweiUpdateExtractor app and use the software to extract the "Recovery.img" file. Here is a Youtube video showing how to do this. Please note, although the video shows several files being extracted you only need to extract the "Recovery.img" file for our use. Move the stock recovery image to your ADB folder so you can flash it in step 4.
4) Flash the stock recovery image: use the stock recovery file and flash it to recovery using the same instructions as you used to flash TWRP in the first place. If you need a refresher, look at section 2 (parts 1-5) of the first post in this thread. Just make sure you substite the name of the stock recovery image instead of the TWRP.img
5) Reboot into system
6) Install Update: go to the Settings - System Update menu on your phone. In the upper right corner, click on the three dots and it will bring up a menu where you can choose "Download latest full update". Click on this. This will start the update process by downloading the full ROM and not just the smaller update package. For me the package size was approaching 2gb, so make sure you are ready to handle that size transfer. After the download is complete, start the update process. I was nervous at first, but everything went fine. If for some reason the update fails, I would reboot and try again. I did have one failure, but I cannot explain if it was a bad download, or something I did wrong (like not unrooting the phone prior to attempting the update). It worked fine the second attempt.
7) Reboot: the phone will reboot and you should check the status to make sure you are on the latest version.
8) Flash TWRP recovery: I read where people said full updates would lock your phone and you would have to start from scratch unlocking it (and therefore wiping all data). This was not the case for me and this update using this method. I was simply able to flash TWRP again. You should be a rock star at flashing recoveries by now so get to it and flash TWRP again. If your phone is locked, then read the note at the bottom of this post.
9) Reboot into system
10) Flash Magik zip: reboot into recovery and flash Magik zip to get SuperSU.
11) Install Magik modules: reboot into system. Reinstall any Magik modules you use as they don't get carried over from the previous installation.
12) Enjoy your updated phone
If for some reason the full update did lock the phone, then you will need to unlock it again before you can flash TWRP. You have already done this before, so use whatever method was successful for you. Obviously this will fully wipe your phone. After flashing TWRP and Magik, I would make a backup of that raw "stock" image just in case this next step doesn't work. After making the backup, you can try to restore just the data partition of the NANDroid backup you made in step 1 (click restore in TWRP, select the backup made in step 1 but deselect everything except the "data" partition before starting the restore process.) I have never done this, but I have read it will recover all your data (apps, etc) without affecting the system partition and therefore it won't mess up the upgrade. I would not recommend doing this if going from Marshmallow to Nugget or Nugget to Oreo however. In those cases, it is better to simple start fresh and redownload all of your apps.

Thank you for this thread.
Hello sic,
I am having the same issue with my Huawei GR-5 2017 and like you, I have my fair share of researching for weeks now and I was really happy to stumble on this thread.
Before I start with the process, I have a few questions for you. I hope you could help me (even though this thread is half a year ago).
Can you elaborate steps 1 and 2 or could you provide me a link on how to do those?

I got xposed installed im on emui 8 i also tried flashfire but it only turns the phone off.. Ist it eneugh to uninstall xposed? And can i get the recovery img from fullota? And must i restore images in magisk? I will try it without xposed installed. And a theory: is the information abaut bootloader unlock stored in a partition like oeminfo? If it is we could restore oeminfo.

[How-To] Applying Monthly Security Patches if you're Rooted (Magisk)

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.