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.

[Q] [SPH-L720]Manually patching files with OTA patches.

So, this deals with a post I already made here. I've tried patching the modem.bin file with the modem.img.p patch that came with the MDL update. When flashing the patched modem to the device, the baseband version still hasn't updated to MDL. crawrj mentioned that the MDM partition seems to have write protection on it, but I never got an error in heimdall saying that the partition couldn't be written to. In fact, the modem flashed just fine.
I've already got a custom kernel loaded, and KNOXAgent files removed, so I'd rather not have to downgrade to MDC in order to update to MDL. Also, patching the files went perfectly. No errors, and the file was the size that it was expected to be after patching. So, I'm not exactly sure what's going on with this.
This isn't the only file I would like to patch manually and update myself. I'm really questioning whether certain partitions on the device have write protection enabled for some reason, and how the write protection could be disabled so that the files can be flashed manually.
Anyone that could shed some light on this situation, it would be greatly appreciated. Thought about baking some ROMs, but it's impossible to have a custom kernel without having KNOXAgent removed or SEAndroid frozen. So being able to patch these files manually for future updates is a must.
Thanks in advance, guys.

RogueSly said:
So, this deals with a post I already made here. I've tried patching the modem.bin file with the modem.img.p patch that came with the MDL update. When flashing the patched modem to the device, the baseband version still hasn't updated to MDL. crawrj mentioned that the MDM partition seems to have write protection on it, but I never got an error in heimdall saying that the partition couldn't be written to. In fact, the modem flashed just fine.
I've already got a custom kernel loaded, and KNOXAgent files removed, so I'd rather not have to downgrade to MDC in order to update to MDL. Also, patching the files went perfectly. No errors, and the file was the size that it was expected to be after patching. So, I'm not exactly sure what's going on with this.
This isn't the only file I would like to patch manually and update myself. I'm really questioning whether certain partitions on the device have write protection enabled for some reason, and how the write protection could be disabled so that the files can be flashed manually.
Anyone that could shed some light on this situation, it would be greatly appreciated. Thought about baking some ROMs, but it's impossible to have a custom kernel without having KNOXAgent removed or SEAndroid frozen. So being able to patch these files manually for future updates is a must.
Thanks in advance, guys.
Click to expand...
Click to collapse
I've run into the same issue. Yes, there is some write protection in place.
What I've also tried so far is dumping the MDL mdm and NON_HLOS modem image files directly from an untouched unrooted MDL updated system (other than recovery) Then creating a tar.md5 file for use with Odin. This gave a secure check failed when trying to flash the modem.bin.
I also tried to use recovery to flash the files. No luck here either, it acts much like the low level HTC Radio_config Write protection in that it allows the flash, and even indicates that it was successful, but really it's just writing to a buffer and then checking it later (either on a reboot or whatever) and then since it fails some check, it discards it and uses the original partition.
I verified this by dd'ing the partition before and after the flash in the same recovery session. The partition does indeed change, but after the reboot, it reverts to the original image. Thus... no change.
I'm no expert on these, but from the way this seems, we need a way to install a modified bootloader or somehow set the "WRITE PROTECT: Enabled" to disabled on the bootloader/download screen to allow changes to certain partitions. (Modem and Non-HLOS being the only two that I think are the problem children right now)
What I haven't tried yet that COULD POSSIBLY work is adapting Dan's method of LOKI patching files and using a special command of aboot to flash them. (At least that's how it looks like it works based on a brief skim of the source code)
We'd have to figure out if our aboot is compatible with his method. We'd also need to find the location of the memory addresses and whatnot of where this special command exists in our aboot/memory.
But again, I don't know enough about it to make even an educated guess as to whether or not that would work at all...

Oh, and if Loki cannot be used for Modem patching/flashing, I'd bet the other variants of the device are also going to face the same problems as ours when trying to update modem/non-hlos partitions.
To add to the above post, I also tried using the apply_patch(...) bits from the OTA Update.zip's updater-script file and pulled the corresponding patch files and put them all into an update.zip to patch the partitions, which again said it was successful and of course reverted after rebooting.

Unknownforce said:
Oh, and if Loki cannot be used for Modem patching/flashing, I'd bet the other variants of the device are also going to face the same problems as ours when trying to update modem/non-hlos partitions.
To add to the above post, I also tried using the apply_patch(...) bits from the OTA Update.zip's updater-script file and pulled the corresponding patch files and put them all into an update.zip to patch the partitions, which again said it was successful and of course reverted after rebooting.
Click to expand...
Click to collapse
Ugh. Shoot me. -_-
I'll see if I can't try to figure out something on it. Probably spend some time on it tomorrow.
If anyone has anymore tips, that'd be awesome.

If it wasn't clear, it's not just the apnhlos/mdm partitions that are affected. The list of write-protected partitions during the MDL upgrade that I observe are:
mmcblk0p1: apnhlos
mmcblk0p2: mdm
mmcblk0p4: sbl2
mmcblk0p5: sbl3
mmcblk0p6: aboot
mmcblk0p7: rpm
mmcblk0p8: tz
Unknownforce said:
which again said it was successful and of course reverted after rebooting.
Click to expand...
Click to collapse
Just to make it clear to folks, the partition contents aren't reverting in a strict sense, the writes don't happen at all.
When write-protection is enabled, writes to the eMMC are silently dropped. Linux believes the writes are successful, and so keeps the updated contents in the page cache, which it then serves on subsequent read requests. Of course, when the device is rebooted, the contents of the page cache are lost.

This has been solved with Unknownforce's thread, found here.

Cannot update to 4.4.2 via otg.

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

TWRP has been ported

just links to original thread where recovery was first installed.
plus warning notes.
important for all who want to install custom recovery and root. It is unknown if it is dangerous to your device to accept OAT updates when you have done this. So If taking update is something you want or need to do you must be able to undo these changes.
howto's on undoing recovery and root to come later(maybe). Basically you need to use the backup you made in first steps of process to undo any system changes you have made then flash stock recovery.img and stock boot.img
http://forum.xda-developers.com/showpost.php?p=67890278&postcount=486

It appears that it's possible to boot both TWRP, and the modified boot.img (for systemless root with SuperSu).
This seems to indicate that the bootloader is unlocked. So free for all !

bibikalka said:
It appears that it's possible to boot both TWRP, and the modified boot.img (for systemless root with SuperSu).
This seems to indicate that the bootloader is unlocked. So free for all !
Click to expand...
Click to collapse
If it is: hyyyyyyyyyyyyype!
CM13 lets go!

mrmazak said:
just links to original thread where recovery was first installed.
plus warning notes.
important for all who want to install custom recovery and root. It is unknown if it is dangerous to your device to accept OAT updates when you have done this. So If taking update is something you want or need to do you must be able to undo these changes.
howto's on undoing recovery and root to come later(maybe). Basically you need to use the backup you made in first steps of process to undo any system changes you have made then flash stock recovery.img and stock boot.img
http://forum.xda-developers.com/showpost.php?p=67890278&postcount=486
Click to expand...
Click to collapse
Please take a look at this post :
http://forum.xda-developers.com/showpost.php?p=68734057&postcount=23
It appears that TWRP cannot write to /dev/block/mmcblk0boot0 for some reason ...

bibikalka said:
Please take a look at this post :
http://forum.xda-developers.com/showpost.php?p=68734057&postcount=23
It appears that TWRP cannot write to /dev/block/mmcblk0boot0 for some reason ...
Click to expand...
Click to collapse
so far all attempts we have tried have failed to write to the preloader.
I am far from professional with this stuff, but i am reading through the update script and I think the little kernel (LK) has something to do with the write protect.
Also the update extracts a u-boot image to the LK partition before coping the lk.bin over that and this is done before the preloader. I think that must be releasing a software write protect on the preloader section. but I have not been able to test this theory yet.
so if this is correct then the new lk.bin while blocking the spft connection, allows the preloader to be writeable.
spft also fails to write to mmcblk0boot0. Attempts to DD to it also give write not allowed.
When i tried to "download" backed-up preloader back to phone, it failed and left phone soft-bricked with DL-TOOL Fail. (an error message generated from LK (little kernel)). Writing preloader back-up back to phone with "Miricle Box" did bring phone back to life. Although so far phone with 6.6 also fails to connect to that software also.
sorry I did not create the recovery, I just announced it. So i dont know how to fix it

bibikalka said:
Please take a look at this post :
http://forum.xda-developers.com/showpost.php?p=68734057&postcount=23
It appears that TWRP cannot write to /dev/block/mmcblk0boot0 for some reason ...
Click to expand...
Click to collapse
i just checked. twrp is able to flash preloader. i went back and forth between prime v6.1 preloader and non-prime v12 and did readback , then verified the md5. I t does work,

mrmazak said:
i just checked. twrp is able to flash preloader. i went back and forth between prime v6.1 preloader and non-prime v12 and did readback , then verified the md5. I t does work,
Click to expand...
Click to collapse
What is the command that you used ???

bibikalka said:
What is the command that you used ???
Click to expand...
Click to collapse
litteraly just used the amazon update but took stuff out

This has only been tested on twrp. The code is unrefined and as with every modification you do on your phone, It is your responsibility to know what you are doing.
edited code to be least amount needed
Code:
ui_print("start to update preloader");
assert(package_extract_file("preloader_p6601.bin", "/tmp/preloader_p6601.bin"),
write_raw_image("/tmp/preloader_p6601.bin", "/dev/block/mmcblk0boot0"),
delete("/tmp/preloader_p6601.bin"));
MD5 for update_non.zip = fb9e2f7fce62a618a5fef69364b2127f
MD5 for update_prime.zip = fda9af43174691d4de50ce438274263c
*****attachments removed for the moment, more testing on 6.6 preloader , is underway*****
One tester claims it worked, but then imeadiatly bricked phone with spft. So now to play it safe for the general public I am looking for more testers to try. Let me know if your interested, and I will release the file for you.

mrmazak said:
This has only been tested on twrp. The code is unrefined and as with every modification you do on your phone, It is your responsibility to know what you are doing.
Code:
mount("ext4", "EMMC", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/system", "/system", "max_batch_time=0,commit=1,data=ordered,barrier=1,errors=panic,nodelalloc");
ui_print("Source: BLU/R1_HD/R1_HD:6.0/MRA58K/1469800396:user/release-keys");
ui_print("Target: BLU/R1_HD/R1_HD:6.0/MRA58K/1471954662:user/release-keys");
ui_print("Verifying current system...");
show_progress(0.100000, 0);
assert(run_program("/system/bin/dd", "if=/dev/zero", "of=/proc/driver/mtd_writeable", "bs=3", "count=1"));
assert(package_extract_file("uboot.img", "/tmp/lk.img"),
write_raw_image("/tmp/lk.img", "lk"),
delete("/tmp/lk.img"));
apply_sig(package_extract_file("sig/boot.sig"), "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/boot");
show_mtupdate_stage("/cache/recovery/last_mtupdate_stage");
ifelse (
less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "1") ,
(
ui_print("start to update general image");
package_extract_file("lk.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/lk");
package_extract_file("secro.img", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/secro");
package_extract_file("logo.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/logo");
assert(package_extract_file("preloader_p6601.bin", "/tmp/preloader_p6601.bin"),
write_raw_image("/tmp/preloader_p6601.bin", "/dev/block/mmcblk0boot0"),
delete("/tmp/preloader_p6601.bin"));
set_mtupdate_stage("/cache/recovery/last_mtupdate_stage", "1");
),
ui_print("general images are already updated");
);
ifelse (
less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "3") ,
(
if less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "2") then
ui_print("start to update alt loader image");
package_extract_file("trustzone.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/tee2");
set_mtupdate_stage("/cache/recovery/last_mtupdate_stage", "2");
endif;
switch_active("tee1", "tee2");
set_mtupdate_stage("/cache/recovery/last_mtupdate_stage", "3");
),
ui_print("alt loder images are already updated");
);
ifelse (
less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "5") ,
(
if less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "4") then
ui_print("start to update main loader image");
package_extract_file("trustzone.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/tee1");
set_mtupdate_stage("/cache/recovery/last_mtupdate_stage", "4");
endif;
switch_active("tee2", "tee1");
),
ui_print("main loader images are already updated");
);
delete("/cache/recovery/last_mtupdate_stage");
ui_print("Patching remaining system files...");
unmount("/system");
MD5 for update_non.zip = fb9e2f7fce62a618a5fef69364b2127f
MD5 for update_prime.zip = fda9af43174691d4de50ce438274263c
Click to expand...
Click to collapse
Sry can you explain to me what your zip/script does please in detail?

KazuDante said:
Sry can you explain to me what your zip/script does please in detail?
Click to expand...
Click to collapse
of course
this update.zip is a project i have been working on. It is the amazon script stripped of the version checks. As far as the reason why it is done they way it is, I dont really know. But I have used it several times. I went back and forth to make sure it did change the preloader. I was able to check by reading the md5 of preloader after each time i ran the update in recovery. It will replace the lk partition(lk.bin or
'llitle boot kernel" and the preloader.
this was an effort to reenable the use of spft, that Amazon or Blu has taken away on the recent 6.6 update.
the lk.bin and preloader_p0661.bin files in the zips are pulled from my two phones. The u-boot.img is from the 6,6 update.
there is some more codes in the script that get skipped as I left the files out of the zip.

mrmazak said:
of course
this update.zip is a project i have been working on. It is the amazon script stripped of the version checks. As far as the reason why it is done they way it is, I dont really know. But I have used it several times. I went back and forth to make sure it did change the preloader. I was able to check by reading the md5 of preloader after each time i ran the update in recovery. It will replace the lk partition(lk.bin or
'llitle boot kernel" and the preloader.
this was an effort to reenable the use of spft, that Amazon or Blu has taken away on the recent 6.6 update.
the lk.bin and preloader_p0661.bin files in the zips are pulled from my two phones. The u-boot.img is from the 6,6 update.
there is some more codes in the script that get skipped as I left the files out of the zip.
Click to expand...
Click to collapse
oh ok I understand , and yea that is a good thing , specially for the future , hope they arent on xda :highfive: .

[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.