Database Info

[Q] Cancelling In-Progress OTA Updates?

Hello, all!
I'm wondering, how do you cancel an OTA update once it has started? I mean after it has downloaded, and you have chosen to install it.
Here's my problem: Everyone talks about how running an OTA update unroots your phone. No problem, I can just re-root it. What no one talks about (at least I didn't run across it before doing this) is installing OTA updates when you have TWRP installed...
So, my phone downloaded the update, and it asked me to install it. I accepted, it restarted, and TWRP came up. From there, nothing happened. I tried restarting it, and it booted up just fine. After about a minute of being up, the "Phone is shutting down" (or something along those lines) message pops up, and it reboots again.
I'm wondering, how do I go about cancelling the update? I've read online I need to download the update manually and run it through TWRP, but until I learn how to do that (and spend a few hours downloading it on this freaking slow internet connection), I would like to be able to use my phone.
Another alternative that I don't know whether is possible, can I somehow use TWRP to browse to where the OTA update was downloaded to, and install it through there? If so, what would the procedure be for doing so?
Thanks!
ElectroPulse

ElectroPulse said:
Another alternative that I don't know whether is possible, can I somehow use TWRP to browse to where the OTA update was downloaded to, and install it through there? If so, what would the procedure be for doing so?
Click to expand...
Click to collapse
Boot into TWRP, click install, click(Up A Level) until you are at "/" and look in the cache folder for the update zip.
It should be in there.

meekrawb said:
Boot into TWRP, click install, click(Up A Level) until you are at "/" and look in the cache folder for the update zip.
It should be in there.
Click to expand...
Click to collapse
Thanks for the reply!
Is it the "Blur_Version21.23.4.peregrine_retus.retus.en.US.zip" file? If so, that didn't work... Unfortunately it failed.
Here's what it said just before failing:
Verifying current system...
"/system/bin/debuggerd" has unexpected contents.
E: Error executing updater binary in zip '/cache/..."
Error flashing zip '/cache/..."
Updating partition details...
Any ideas?
Thanks!
ElectroPulse

ElectroPulse said:
Thanks for the reply!
Is it the "Blur_Version21.23.4.peregrine_retus.retus.en.US.zip" file? If so, that didn't work... Unfortunately it failed.
Here's what it said just before failing:
Verifying current system...
"/system/bin/debuggerd" has unexpected contents.
E: Error executing updater binary in zip '/cache/..."
Error flashing zip '/cache/..."
Updating partition details...
Any ideas?
Click to expand...
Click to collapse
You must have stickmount installed. Uninstall it and try again.
Note: If you changed or deleted anything in /system partition the install will keep failing. You'd have to fastboot flash the system img's from the 4.4.3 firmware.

meekrawb said:
You must have stickmount installed. Uninstall it and try again.
Note: If you changed or deleted anything in /system partition the install will keep failing. You'd have to fastboot flash the system img's from the 4.4.3 firmware.
Click to expand...
Click to collapse
Thank you for the reply.
Nope, Stickmount is not installed. Not sure what other apps there are that could cause this.
Not sure whether I've changed anything in /system... I don't believe I have, but an app I installed very much could have.
I'll look up this "fastboot flash" you are referring to.
Anyway, for now I am good. I copied the .zip OTA downloaded file to another location, hit the "clear dalvik and cache," rebooted, and I'm back to a working 4.4.3.
Problem solved until I decide to try to get 4.4.4 installed! (which I may never end up doing... Now that Cyanogenmod is officially out for Peregrine, I'm probably going to flash it with that when it gets stable enough (i.e. no RAM issues)).

Problems when updating a previously rooted Nvidia Shield Tablet [MOVED HERE]

[This was already posted, I just moved it to the Shield Q&A.]
As many of you may know, Nvidia has recalled their Shield Tablets. I'll be getting a replacement soon. I'll be rooting it as soon as possible when I get it, but first I have a few questions.
First of all, I rooted my tablet using a guide at IBTimes (that used info from XDA forums) installing CWM recovery.
After rooting I installed Link2SD, pretty much the reason I rooted, to save up some space on my internal memory. Everything was going fine, until I received the recall notice. I moved all my app files back to the internal memory, deleted Link2SD, ran a full unroot on SuperSU, (after a while of hanging on the "Please Wait" screen the app just crashed, it wouldn't load up and Root Checker said I had no root access after rebooting.
I don't know whether this was supposed to happen or whether it should have gone more smoothly, please give me an answer to this and tell me if it affected my system in any way) and fastboot flashed the stock recovery.img.
However when I tried to install the update, I got a red triangle error. After checking the log I got an error saying "Package expects build fingerprint of ... or ..., this device has ...."
I can't remember what the fingerprints were, but the first one was something that began with "nvidia/", had a bunch of numbers in the middle followed by an underscore, then it ended with "/release-keys".
However the device's current build fingerprint was exactly the same as the first, except that it cut off halfway through, right after the numbers and the underscore.
I tried resetting my cache, I tried a wipe of the user data. The only way to fix this for me was to re-install a bunch of stock images - recovery.img, boot.img, system.img, etc.
I don't want to wipe my data next time. So I ask for this in my answer:
- An explanation of what the error means
- How this error is caused
- A way to fix this error without wiping my device
- How to prevent this error
- If what happened to SuperSU in my case is normal and if it affected my device in some way
- And, if possible, a way to install the update successfully without getting this error and without having to unroot or remove CWM, and details on how to do this method and any risks.
Thanks in advance. An answer soon would be appreciated.

Quick answer:
- You don't need to restore to full stock before updating to the latest OTA. This is what I did, running a rooted stock system with TWRP recovery:
-- Go to Settings > About tablet > System updates and continue to click Check Now until the update has been found. I had to click like 4 or 5 times before it was found. It'll download automatically to your device (not your SD card), but I forget where that download location is... XD
-- once you've found your downloaded OTA.zip, copy it to a location you can easily find from your custom recovery.
-- reboot into custom recovery, flash OTA.zip, reflash superSU.zip, wipe cache NOT DATA, reboot
-- wait until device boots up, wait until the Optimizing blah blah process is done.
-- enjoy!
Additional thoughts:
- I've tried the Link2SD app, but I think it messes with my system in a way I don't like; personally I'd rather delete the apps I never use via custom recovery (see THIS THREAD on how to debloat your tablet for yourself!
- I think your error happened when you flashed stock recovery on top of the custom one. To prevent this next time, simply wait for either a flashable zip in THIS OTHER THREAD, or you can check to see if nVidia released any OTA3.1 recovery images if you want that full-stock experience.
Hope this helps!

deleting system apps in recovery keeps them in running os

I want to switch from supersu to superuser, and having an interesting problem that supersu somehow covered up. I have a Nexus 5x running the stock rom. With every months upgrade I would flash using fastboot, go into twrp recovery before first full boot and remove a bunch of unneeded applications in /system/app. When I would boot up those applications would be gone. Somehow this isn't the case with superuser. I can still go into recovery and remove them, but when I boot up all the applications are still in /system/app. If I go back into twrp they are still shown as being missing. I've tried installing es file explorer, but it's unable to delete the applications once the system is up. remounting /system doesn't work either. Any help?
Unrooting supersu caused all the applications to come back; so does supersu not really delete them either, but somehow prevents them from showing up following the recovery scheme or something?

bsd1101 said:
I want to switch from supersu to superuser, and having an interesting problem that supersu somehow covered up. I have a Nexus 5x running the stock rom. With every months upgrade I would flash using fastboot, go into twrp recovery before first full boot and remove a bunch of unneeded applications in /system/app. When I would boot up those applications would be gone. Somehow this isn't the case with superuser. I can still go into recovery and remove them, but when I boot up all the applications are still in /system/app. If I go back into twrp they are still shown as being missing. I've tried installing es file explorer, but it's unable to delete the applications once the system is up. remounting /system doesn't work either. Any help?
Unrooting supersu caused all the applications to come back; so does supersu not really delete them either, but somehow prevents them from showing up following the recovery scheme or something?
Click to expand...
Click to collapse
You aren't doing something right or you don't have something setup correctly. With root, you should be able to unintelligible them completely.
When you removed them, did you wipe cache and dalvik/ART cache before rebooting? If not then the system probably still thinks they are there because they still have data loaded into cache.
I recommend sticking with SuperSU, superuser doesn't work as well as SuperSU
Sent from my SM-S903VL using Tapatalk

I've been googling a bit more. As it turns out there are two system partitions for nougat; in nexus 5x and some other devices apparently. This became more apparent when the file recovery-from-boot.p; which I rename in order to prevent recovery from being overwritten is not renamed when booting the OS. Nougat apparently pulls the system files from somewhere else. So whatever Chainfire did makes it boot the same partition as visible in recovery. Fully unrooting brings all those apps/system partition back. Haven't been able to find a good post that tells me how to to circumvent this without SuperSU; or exactly how this works.

Android 9, not 10, can't write to system

I've been having an issue recently and need some help figuring it out...
I rooted my 3a a while back and recently had gpay issues that I think came from EdXposed. My CTS and basic integrity were failing.
I decided to take the opportunity to reflash so I used the latest image from Google, which was a Q (10) image. I loaded her up, rooted, set up some stuff, and then found out the system restrictions with 10 and decided to go with the last Android 9 release from Google, "9.0.0 (PQ3B.190801.002, Aug 2019)".
So after flashing to 9.0.0 (PQ3B.190801.002, Aug 2019), I am unable to write to the system. Certain folders within the Root, seem to be read only, but why?
At first I thought it was maybe a verity issue, and disabled it, but still had the same problem.
In TWRP, I am able to write files into the restricted folders, but am denied access when booted up using Solid Explorer and Titanium. I am rooted with Magisk 20.1.
Is it simply a matter of file permissions?
Attached is the ls -al on the system directory after I chmod 755'd the system in twrp and then ran a chmod 777 on the system folder.
I cannot write a simple blank file into the system\priv-app folder using Solid Explorer, but I was able to copy a file into the same directory using twrp. I verified the file copied with twrp in still there after boot and tried to delete it with Solid Explorer and got denied.
Can someone please help me figure this out?

Did you do a full factory reset and reflash of the Pie image or was this flashed over 10?

ctfrommn said:
Did you do a full factory reset and reflash of the Pie image or was this flashed over 10?
Click to expand...
Click to collapse
I haven't done a factory reset. From my understanding, flashing the stock image over adb is a full wipe.
I did try wiping the data, system, and cache from twrp and reflashed and still have the same issue.
For the sake of trying everything, I just did a factory reset from the system settings. This factory reset kept my Magisk patched boot image in tact (reinstalled Magisk anyway) and it did not fix my issue.

My guess is 10 rewrote the partition tables and youre going to need to rewipe everything and then fresh install Pie.

I have read similar stories on other threads. It seems that once you go to Android 10, it keeps the file structure of Android 10 even when you move back to Android Pie. While I never saw a way to fix this issue, it may be that the users never came back and updated their story. Or perhaps they were never able to fix it.
I think you are definitely going to have to flash the factory image including the full wipe. Hopefully this overwrites the entire disk structure and gets you back to Android Pie structure. But if this doesn't fix the issue, then I'm not sure how else to help.
Full Factory Images - https://developers.google.com/android/images

sic0048 said:
I have read similar stories on other threads. It seems that once you go to Android 10, it keeps the file structure of Android 10 even when you move back to Android Pie. While I never saw a way to fix this issue, it may be that the users never came back and updated their story. Or perhaps they were never able to fix it.
I think you are definitely going to have to flash the factory image including the full wipe. Hopefully this overwrites the entire disk structure and gets you back to Android Pie structure. But if this doesn't fix the issue, then I'm not sure how else to help.
Full Factory Images - https://developers.google.com/android/images
Click to expand...
Click to collapse
I was using the Google factory images, and I was certain they formatted the partitions during the install but I guess not.
So the million dollar question is how does one perform a full wipe? or at least reformat the system (linux commands)?

I just boot into stock recovery and do a factory reset. Then you use the flash-all.sh script to flash the factory image. Whether this will redo the partition/disk format back to Pie style is something I cant say.

ctfrommn said:
I just boot into stock recovery and do a factory reset. Then you use the flash-all.sh script to flash the factory image. Whether this will redo the partition/disk format back to Pie style is something I cant say.
Click to expand...
Click to collapse
Right, I've been doing this and evidently it doesn't revert the partition system to full Pie.
I was reading something about an optional setting in the partition systems between 9 and 10. I'll have to look it up again, but it was in regards to something in the partitions being optional when going from pre 9 to 9, but enforced when going to 10.

avg2424 said:
Right, I've been doing this and evidently it doesn't revert the partition system to full Pie.
I was reading something about an optional setting in the partition systems between 9 and 10. I'll have to look it up again, but it was in regards to something in the partitions being optional when going from pre 9 to 9, but enforced when going to 10.
Click to expand...
Click to collapse
Yeah, no idea then, sorry.

How I fixed my bootloop problem without any format / data loss

Hello everyone, I was able to fix my bootloop occuring after flashing a zip on magisk, without any data loss. I wanted to share what I did to fix since it may be helpful for others. It is useful method worth trying if you know what caused the bootloop. It is definitely not a universal method of fixing bootloops or anything, but If you have a similar problem, you can try these steps.
The bootloop happened after I flashed a zip on Magisk that I downloaded using EdXposed Manager app. I remember downloading the latest alpha version zip and flashing it using Magisk (I had already had the riru core and riru edxposed modules installed on Magisk but on Edxposed manager app, it was showing some error, so I also flashed the zip that I downloaded using the app. I think this caused the bootloop somehow. ) I had no backups.
(I had also "unable to mount /data" problem on TWRP, I am explaining how I fixed that also, if you don't have the problem, you can skip this paragraph)
My TWRP version was 3.2.1.0. And when I was in recovery mode, I was getting "unable to mount /data" error. This is actually a well-known error, but I was able to fix it without a format by just updating my TWRP to 3.3.1.0. After the update, somehow, internal storage could be mounted and everything was fine. My goal by trying to fix this problem is to be able to have a backup using TWRP (using backup feature on TWRP) (just make sure that you didn't choose the compression option on options tab of TWRP backup page).
If you don't have "unable to mount data" problem at all, just make a TWRP backup. (just make sure that you didn't choose the compression option on options tab of TWRP backup page).
So, after having a TWRP backup of everything (actually just System and Data backup would also be fine), I tried to edit my backup files to fix the problem that caused the bootloop.
I changed 2 things in my backup files (you can edit the backup files ending with .win001 etc using 7zip on windows or anything similar. since the backup files are not compressed, you can just delete files) (I edited only the "Data" backup files due to my specific problem, but if your problem is something different, you may have to edit different files also):
1) I deleted everything about EDXposed manager(com.xx.edxposedmanager files) (It might have nothing to do with the fix, I am not sure)
2) In one of the data backup files (probably in the last one), there is a folder called "adb". In adb, there is a "modules" folder. I deleted riru core and riru edxmanager folders in modules.
After these steps, I restored "Data" and "System" using TWRP restore. Bootloop is fixed without any data loss.
If your bootloop is caused by something different, (the point I am trying to tell is) you can edit the nandroid backup files if you know the root of the problem and maybe fix your phone. When I was editing the backup files, I had no hope. As I said, I think this method is worth trying.

I Found this to be true. I also don't see the reason to reflash everything to fix a problem. Thank you for this tutrorial this is an undocumented tactic and i don't know why. Before i discovered this type of surgery i operated under the assumtion that android must be different from other operating systems in some way which would make this impossible. But like you i delved deeper and discovered that this is like a dark art the devs keep to themselves because of what ever but it works. I like this type of post and usually aside from asking for help or a little feed back this is the only type of post i ever make. I mean how do you expect people to learn how to do anything if you never teach them anything useful. EX: "You didn't do it exactly right from the beginning because if left out one thing in my tutorial so you would fail now erase everything and start over." "I only did that to teach you to backup" such bull ****! Thanks again for fighting the good fight.