My phone (3T) has an unlocked bootloader, is encrypted, not rooted, and running stock OOS 5.0.
I flashed TWRP and discovered that stock OOS restores the stock recovery in boot.
I saw the Oreo dm-verity thread by xenet, had a look at the zip file, noticed that it just modified fstab to prevent force encrypt, so I flashed it to see what happens.
And nothing happens. After the system had booted, fstab is unchanged from the original stock copy.
So I'm wondering whether this file is also restored when booting up on stock.
I get aggressive and go back to TWRP and delete /system/etc and /system/bin and modify build.prop.
Surely now the phone won't boot!
Wrong! It boots up and everything is back to normal in /system.
I go back to TWRP and have a look at /system and it shows me one without the etc and bin folders and has the modified build.prop.
What's going on? How can I see one version of /system in TWRP but a different version (ie, stock) when the phone has booted?
By the way I've been an Android user for many years and have rooted and flashed custom ROMs on a variety of phones and I've never seen anything like what's happening on my 3T. I'm sure that dm-verity is somehow involved in this.
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
nicknacknuke said:
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
Click to expand...
Click to collapse
Thanks.
I should have mentioned that I'm also not rooted. So stock OOS 5.0.
Sent from my OnePlus 3T using XDA Labs
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Click to expand...
Click to collapse
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Click to expand...
Click to collapse
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Click to expand...
Click to collapse
Thanks, you are correct. I'd forgotten that that TWRP remembers. Deleting .twrps does bring up the RO prompt after decrypting storage.
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
I had allowed changes to the system otherwise I couldn't have made changes to it, which includes the ability to restore the system partition.
But I'm still unclear why if I make changes to the system partition and boot with the stock kernel, then after the boot none of the changes are present in the system partition, but if I boot back into TWRP then the changes are all there.
I recall someone in another OOS 5 thread saying that the stock kernal replaces TWRP with stock recovery if you don't flash root (magisk/superSU). Is it possible that the kernel re-flashes system on boot? Another possibility is that TWRP thinks it's making changes to system but it's not actually? Not quite sure, I've never heard of anything like this before either, just throwing other ideas out there.
I've never read anything about the OP3T or any oneplus phones for that matter having A/B system partitions like the pixels. *shrug*
@nhshah7, something's like what you suggest must be going on to account for what I'm seeing. I'm hoping that someone can confirm my observations and provide a definite answer.
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Xennet said:
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Click to expand...
Click to collapse
Actually it doesn't explain how TWRP can make changes to system yet the phone boots up on an unmodified system if using the stock kernel. And then, when you boot back into TWRP and look at system, the changes are still there.
Where does the unmodified system come from?
Where does the modified system live?
Why doesn't modifying system result in a failed boot due to dm-verity, while restoring a backup of system does result in a failed boot?
So many questions with no answers.
BillGoss said:
....So many questions with no answers.
Click to expand...
Click to collapse
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
rk2612 said:
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
Click to expand...
Click to collapse
I'll come back to 1.
2. That makes sense and accounts for why a restore of the system partition with the stock boot image causes me to get dumped back in fastboot mode. If I flash the stock system zip file then the system boots properly.
3. I've not had any issues with strange boot behaviour. I'm always starting with stock or flashing kernels that modify the stock boot image, like Blu Spark.
4. I gathered this from my reading of various threads. If I want to make changes to the system partition and get them to stick and not fail dm-verity then I have to flash a custom kernel. I've proven this in my testing. (A rooting solution would also work, but I've not done this).
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
BillGoss said:
....
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
Click to expand...
Click to collapse
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
rk2612 said:
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
Click to expand...
Click to collapse
Good questions. They got me thinking more about how this could possibly work.
I had a look at the cache and there's definitely no copy of the system hiding there.
I also unpacked the ramdisk in the boot image and it had nothing in system. Furthermore, the boot position is only 64 MB, no where near enough to hold the system.
Then I installed Magisk so that I could browse around the phone's partitions and take copies.
I learnt two things from this:
1. If there's a second copy of the system there are only three partitions large enough to hold it (/proc/partitions shows the sizes in 1 kB blocks). The system is about 1 GB. There is space in the system partition (sde20) for 3 GB. There's also space in the data partition (sca15). And there's space in the major partition holding the modems (sdf).
I could eliminate the data partition by formatting it but restoring the internal storage (sdcard) is such a a pain.
So I'll just accept that there is space for a copy, but I'm unlikely to find out exactly where.
2. When I had Magisk installed installed and the system boot, I added a folder and file to /system/priv-app using a file manager (so not using TWRP). I then booted into recovery, flashed the stock boot image, and rebooted. I was expecting it to fail dm-verity (modified system) but it didn't. After booting up there's no evidence of the folder I added to priv-app.
And if I restore the Magisk boot image then the additions show up again.
I'm actually very impressed with how the stock system (kernel, recovery, system) protects itself from modification. Very cool!
Related
Thanks to everyone here up front for all the awesome help available here.
I just got my Nexus 6, and no issues unlocking bootloader, installing custom recovery (TWRP), getting root and flashing ROMs/zips (currently loving Pure Nexus with xposed).
My question is regarding backups. When you backup your current setup, most of the information I've found don't show the "System Image" partition under the "System" partition when you go to make a new backup. It's quite large, and I was wondering exactly what that is, and if you need to include that in your backup. Anyone know of a helpful link that explains the partitions?
Also, if you make a bunch of backups, and move them to your computer, does that make things harder if you want to restore from a backup? Can you restore from a backup on your computer just as easily as a backup on the phone's internal storage?
Thanks again
Edit (1/15/2016):
Thanks to RMarkwald and scryan for the quick responses and info. So it seems that the system image isn't going to be needed, and backing up System, Data, and Boot will be good enough for normal backup of the phone/rom before trying something that might break the current setup.
giantninja said:
Thanks to everyone here up front for all the awesome help available here.
I just got my Nexus 6, and no issues unlocking bootloader, installing custom recovery (TWRP), getting root and flashing ROMs/zips (currently loving Pure Nexus with xposed).
My question is regarding backups. When you backup your current setup, most of the information I've found don't show the "System Image" partition under the "System" partition when you go to make a new backup. It's quite large, and I was wondering exactly what that is, and if you need to include that in your backup. Anyone know of a helpful link that explains the partitions?
Also, if you make a bunch of backups, and move them to your computer, does that make things harder if you want to restore from a backup? Can you restore from a backup on your computer just as easily as a backup on the phone's internal storage?
Thanks again
Click to expand...
Click to collapse
According to TWRP in regards to System Image: The Team Win Recovery Project has released version 2.8.7.0 of its custom recovery, known simply as TWRP. This update brings a system read-only option that's intended to help you make a pure backup of your system image that you can later flash to receive over-the-air updates after having rooted or ROMed your device.
If you move backups to your computer, you'll either need to move them back to the internal storage of your phone or USB stick to use USB OTG to restore backups.
I already rooted my phone. Where can I get the pure system image now that I can later flash to receive over-the-air updates.
rocco24 said:
I already rooted my phone. Where can I get the pure system image now that I can later flash to receive over-the-air updates.
Click to expand...
Click to collapse
why would you want to unroot your phone, loose all your info, to flash a factory image, just to get an ota? why waste your time??? you can remain rooted, grab the system.img from a factory image, flash it with fastboot, not loose any info, then just reflash SuperSU and a kernel, and be updated. factory images are here https://developers.google.com/android/nexus/images?csw=1#yakju
simms22 said:
why would you want to unroot your phone, loose all your info, to flash a factory image, just to get an ota? why waste your time??? you can remain rooted, grab the system.img from a factory image, flash it with fastboot, not loose any info, then just reflash SuperSU and a kernel, and be updated. factory images are here https://developers.google.com/android/nexus/images?csw=1#yakju
Click to expand...
Click to collapse
Thanks for the explanation. I meant the system.img not the full factory image my bad.
rocco24 said:
Thanks for the explanation. I meant the system.img not the full factory image my bad.
Click to expand...
Click to collapse
the system.img is in the factory.img, just like the boot.img, cache.img, etc..
Nailed it thanks
RMarkwald said:
According to TWRP in regards to System Image: The Team Win Recovery Project has released version 2.8.7.0 of its custom recovery, known simply as TWRP. This update brings a system read-only option that's intended to help you make a pure backup of your system image that you can later flash to receive over-the-air updates after having rooted or ROMed your device.
If you move backups to your computer, you'll either need to move them back to the internal storage of your phone or USB stick to use USB OTG to restore backups.
Click to expand...
Click to collapse
Ok, cool... So, if I want to try another ROM out, when I backup my current setup (Pure Nexus with xposed and some themes etc...), should I just backup System, data and boot? or should I backup that System Image as well? or is that System Image the snapshot of the stock ROM that the phone came with?
Thanks again
giantninja said:
Ok, cool... So, if I want to try another ROM out, when I backup my current setup (Pure Nexus with xposed and some themes etc...), should I just backup System, data and boot? or should I backup that System Image as well? or is that System Image the snapshot of the stock ROM that the phone came with?
Thanks again
Click to expand...
Click to collapse
Don't need the system image.
IIRC the system image will give you and .img file of your backup, you could then fastboot that to restore system. (I think... never tested. I believe you can do install and switch from zip to img as well...)
But for just a standard backup with TWRP so you can restore later if you have any problems... Just do as you said with the normal System (os), data (apps & app data), boot (kernel)
Not really sure who is using the system image option, or why...
scryan said:
Don't need the system image.
IIRC the system image will give you and .img file of your backup, you could then fastboot that to restore system. (I think... never tested. I believe you can do install and switch from zip to img as well...)
But for just a standard backup with TWRP so you can restore later if you have any problems... Just do as you said with the normal System (os), data (apps & app data), boot (kernel)
Not really sure who is using the system image option, or why...
Click to expand...
Click to collapse
Awesome. That's what I was thinking, but I've been wrong before, so it never hurts to verify.
Thanks!
Opps wrong thread... Lol
Do any of you know how to reduce the size of or remove the System Image partition on the phone? It's taking up over 4gb on my phone and preventing me from restoring my data partition since it's running out of space during the restore.
cstokes86 said:
Do any of you know how to reduce the size of or remove the System Image partition on the phone? It's taking up over 4gb on my phone and preventing me from restoring my data partition since it's running out of space during the restore.
Click to expand...
Click to collapse
I delete any foreign keyboards I don't need to reduce the system partition size. Delete /system/app/(GoogleHindiIME, GoogleJapaneseIME, GooglePinyinIME, KoreanIME). You can either mount system in TWRP and delete, or delete them with a root explorer if you're rooted.
JimSmith94 said:
I delete any foreign keyboards I don't need to reduce the system partition size. Delete /system/app/(GoogleHindiIME, GoogleJapaneseIME, GooglePinyinIME, KoreanIME). You can either mount system in TWRP and delete, or delete them with a root explorer if you're rooted.
Click to expand...
Click to collapse
Thanks, Jim. I can wipe my main system partition to free up some space and then restore it later so I don't need to worry about tediously going through and removing unnecessary files. My issue is the "System Image" partition which is actually just over 3GB on my phone. I cannot seem to locate this partition and clear it out so I'm kinda stuck until I can figure out how to reduce the size of this partition ie clear out files from the partition either manually or entirely.
I'm in npd90g preview flashed via twrp.if I want official ota
Just flash system image of mm latest and this downgrade doesn't brick my phone ? Can I get ota? And what other should I flash with system image ? Boot ,data and recovery also ?
I dont no much english like othetr peopel
Promblem is i root my honor5x then device get so heat up . After that i deciede to reset it factory setting i have done it but now my device is stuk in twrp loop its not going back normal condition like factory setting plz help me ........ plz
@Shakil jamali: Wrong forum. Go to Honor 5X forum and ask again.
cstokes86 said:
Thanks, Jim. I can wipe my main system partition to free up some space and then restore it later so I don't need to worry about tediously going through and removing unnecessary files. My issue is the "System Image" partition which is actually just over 3GB on my phone. I cannot seem to locate this partition and clear it out so I'm kinda stuck until I can figure out how to reduce the size of this partition ie clear out files from the partition either manually or entirely.
Click to expand...
Click to collapse
Good question. Is this system image actually a partition? Or something TWRP does combining the system image part with a few others into one file? If it is a partition would it be possible to delete it and resize system partition to make use of the extra space? I'm on a nextbit robin stock 7.1.1. Sys image shows as 3,072mb.
For some reason, i cant backup my device through twrp because of error 255. I tried unticking system, then ticked system image and somehow the backup worked. My question is, is it ok to backup with the system image instead of system? What happens when i restore? TIA
soyti2x said:
For some reason, i cant backup my device through twrp because of error 255. I tried unticking system, then ticked system image and somehow the backup worked. My question is, is it ok to backup with the system image instead of system? What happens when i restore? TIA
Click to expand...
Click to collapse
First, for your 255 error, look at this post. Get rid of the corrupted file and a normal nandroid will work.
To answer your main question, you can use the system.img as a backup. It is intended for people who want an complete, untouched system backup to restore prior to attempting a OTA update.
An alternative approach to backup/restore that works very well in N6, is Chainfire's FlashFire.
Since the first Nougat dev build, I've been running stock unlocked Android. However, I haven't been able to keep my recovery installed, and I've had to reflash it via my computer every time I wanted to be able to flash things via TWRP. In addition, nothing I flash (except when I root the device, for some reason) survives the reboot into system, even if it was a successful flash. Any help is appreciated.
Nexus 6
Stock Android 7.0 Nougat
Unlocked, but not rooted
Sent from my Nexus 6 using Tapatalk
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
doitright said:
Specifically, the script at /system/bin/install-recovery.sh.
Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
I've never made an edit to the recovery.sh file but I've always ran a noforce nonverify boot img and TWRP always stuck for me. I read that when you allow TWRP to modify system that it automatically edits this file which I do. Is this way it's sticking? I never had any problems and it seems a lot of "TWRP not sticking" threads are popping up.
Sent from my Nexus 6 using XDA-Developers mobile app
doitright said:
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
Could you explain how to do all of that? I have no idea what to edit or where those things are.
Sent from my Nexus 6 using Tapatalk
I have had my fair share of problems modifying android before but I have never had a phone flat out lie to me and say an operation was successful and actually nothing happened at all.
Have had my nexus 6 for a year or so now. Have had minor issues rooting / modifying marshmallow in the past but I figured out it was all caused by the system partition having basically 0 free space. Made a huge mistake and installed to the latest 7.0 OTA. Wanted to simply enable tethering and edit the thermal config to not shut cores down. Should be as simple as pulling the files, editing them, pushing them back to the phone in twrp with the system partition mounted and thats the end of it right? Wrong.
First of all twrp 3.0.2 refuses to let me touch the system partition without some giant prompt about how its going to make itself stick and offer to root the phone. Simple enough I have seen it in previous versions I say yes as usual except twrp proceedes to immediately spew a bunch of superuser files that do nothing throughout the system partition without asking me if I want root. Dumb but whatever. I mount /system as read write and I go edit and replace my two files like usual (build.prop and thermal config). No matter if I ADB push or use twrps built in file manager it claims the file replacement is successful. Reboot into android and not only have both files not been touched (Verified by adb pull) but the recovery gets overwritten with the factory recovery anyways. (NEVER had issues with twrp sticking on marshmallow. Now after every reboot it gets wiped out)
Second of all if I select yes to twrp mounting system as writable and it does its spewing as I mentioned before then installing SuperSU instantly causes the phone to not boot. Rewrite the boot.img to factory and it boots fine OR Rewrite the clean factory system image and the SuperSU boot works fine. But modifying /system with twrp and then running supersu at the same time is a no go. TWRP is obviously doing something stupid to system that pisses off supersu so undoing twrps mess or uninstalling supersu makes it bootable again.
I dont even want root! Everyone is claiming you need to run "settings put global tether_dun_required 0" as root along with adding the usual "net.tethering.noprovisioning=true" in the build.prop to get native tethering working again! On 6.X only the build.prop edit was needed to get it working.
So long story short. I just want native tethering to work and to tweak my /system/etc/thermal-engine-shamu.conf . Is there anyone here who has done this successfully on nougat? I feel like its all twrps fault but im far too tired and frustrated to try another version tonight.
You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.
Strephon Alkhalikoi said:
You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.
Click to expand...
Click to collapse
It's stated in the op he's using twrp 3.0.2.
Didgeridoohan said:
It's stated in the op he's using twrp 3.0.2.
Click to expand...
Click to collapse
I misread his post then. I wonder if perhaps he is running TWRP via fastboot instead of installing it.
Flashing recovery using "fastboot flash recovery XXX.img"
Hi,
I own a Pixel XL 128GB, running 8.0.0 October FW. I have installed Magisk 14.3 beta 1437. Almost everything works, except for:
1. When installing Magisk using Magisk's internal installer it always downloads MAgisk 14.0 and tries to install this old, outdated version. Is this a bug?
2. I can't install OTAs, tried following john's installing instructions...
https://github.com/topjohnwu/Magisk/blob/master/docs/tips.md#ota-installation-tips
My steps were:
* Install stock boot loader - Magisk almost immediately confirms that it has installed the stock boot image. That's a bit surprising, I don't see any flashing dialog like when installing Magisk. Bug?
* trying to update using the internal OTA fails. It takes very long and suddenly stops.
Any idea what went wrong?
niko26 said:
Hi,
I own a Pixel XL 128GB, running 8.0.0 October FW. I have installed Magisk 14.3 beta 1437. Almost everything works, except for:
1. When installing Magisk using Magisk's internal installer it always downloads MAgisk 14.0 and tries to install this old, outdated version. Is this a bug?
2. I can't install OTAs, tried following john's installing instructions...
https://github.com/topjohnwu/Magisk/blob/master/docs/tips.md#ota-installation-tips
My steps were:
* Install stock boot loader - Magisk almost immediately confirms that it has installed the stock boot image. That's a bit surprising, I don't see any flashing dialog like when installing Magisk. Bug?
* trying to update using the internal OTA fails. It takes very long and suddenly stops.
Any idea what went wrong?
Click to expand...
Click to collapse
1. If you wan't the current beta to install, you need to change to the beta update channel in the Manager settings.
2. You've probably done something that messes with important partitions (/system, /vendor, etc). It's enough to just mount the partition rw to destroy the ability to update through OTA.
Restoring the stock boot image through the Manager is instantaneous...
Hi @Didgeridoohan,
thank you very much for the quick answers!
Didgeridoohan said:
1. If you wan't the current beta to install, you need to change to the beta update channel in the Manager settings.
Click to expand...
Click to collapse
Thanks - I didn't know that.
2. You've probably done something that messes with important partitions (/system, /vendor, etc). It's enough to just mount the partition rw to destroy the ability to update through OTA.
Click to expand...
Click to collapse
Hm, how do I find out what has been messed on /system, and/or /vendor?
Does installing and using AdAway tamper with /system or /vendor?
So reflashing the stock boot image is not sufficent, correct?
And most important.. how do I fix this?
niko26 said:
Hi @Didgeridoohan,
thank you very much for the quick answers!
Thanks - I didn't know that.
Hm, how do I find out what has been messed on /system, and/or /vendor?
Does installing and using AdAway tamper with /system or /vendor?
So reflashing the stock boot image is not sufficent, correct?
And most important.. how do I fix this?
Click to expand...
Click to collapse
If you let AdAway directly write to /system/etc/hosts, then yes, you have a compromised system partition. If you're using Magisk Systemless Hosts you should be fine though. Do you have TWRP installed? That'd be an issue as well...
If you want to make sure that you can update through OTA in the future, clean flash a factory image (you can leave data intact) and then make sure not to touch /system or /vendor at all.
* DELETED *
Didgeridoohan said:
If you let AdAway directly write to /system/etc/hosts, then yes, you have a compromised system partition. If you're using Magisk Systemless Hosts you should be fine though.
Click to expand...
Click to collapse
Yeah, I've been using Magisk's systemless hosts-file.
. Do you have TWRP installed? That'd be an issue as well...
Click to expand...
Click to collapse
TWRP has not been installed permanently.
If you want to make sure that you can update through OTA in the future, clean flash a factory image (you can leave data intact) and then make sure not to touch /system or /vendor at all.
Click to expand...
Click to collapse
There aren't a lot of apps I am granting root. One of them is Titanium Backup. It may have tampered the fs.
Is there any kind of diff against the original folders which I can run to find out what has been tampered to possibly identify which app is causing the issues?
One of the main reasons for installing Magisk was because I was tired of flashing the entire system when updates have been released.
I never couldn't get Flashfire working properly when it comes to install updates / OTAs.
niko26 said:
Yeah, I've been using Magisk's systemless hosts-file.
TWRP has not been installed permanently.
There aren't a lot of apps I am granting root. One of them is Titanium Backup. It may have tampered the fs.
Is there any kind of diff against the original folders which I can run to find out what has been tampered to possibly identify which app is causing the issues?
One of the main reasons for installing Magisk was because I was tired of flashing the entire system when updates have been released.
I never couldn't get Flashfire working properly when it comes to install updates / OTAs.
Click to expand...
Click to collapse
Since the OTA can check for a tampered system, I'm sure there's a way to check. Question is if it's worth the effort.
Any app that has root access can be the culprit... Could also be that you let TWRP mount system rw or something similar. Really hard to say...
Didgeridoohan said:
Since the OTA can check for a tampered system, I'm sure there's a way to check. Question is if it's worth the effort.
Any app that has root access can be the culprit... Could also be that you let TWRP mount system rw or something similar. Really hard to say...
Click to expand...
Click to collapse
Does TWRP mount system as rw by default? Because all I really do is.. boot to TWRP, flash the Magisk's zip. That's it. Nothing else.
Is there any other way I can install OTAs without using a computer with USB (and keeping root of course )?
As said... I never could FlashFire to work correctly. The documentation leaves a lot of questions open - BTW.. props to the Magisk's docs - much better.
niko26 said:
Does TWRP mount system as rw by default? Because all I really do is.. boot to TWRP, flash the Magisk's zip. That's it. Nothing else.
Is there any other way I can install OTAs without using a computer with USB (and keeping root of course )?
As said... I never could FlashFire to work correctly. The documentation leaves a lot of questions open - BTW.. props to the Magisk's docs - much better.
Click to expand...
Click to collapse
TWRP doesn't mount system as rw unless you let it.
I've never used Flashfire and haven't updated through OTA since, 2014-ish. :laugh: I'm mainly going on theoretical knowledge here... On my Nexus I used fastboot to flash the factory image (until I switched to ROM flashing in TWRP) and now I just flash the full update package that OnePlus provides in TWRP.
For a while there I also flashed the system.img and boot.img files in TWRP. If that months security update only had anything to do with those files it was just a matter of downloading the factory image and unpack those two files and flash them directly in TWRP. No computer needed (unless there was an update to the bootloader and/or radio). No idea if this is viable on a Pixel...
My main use for Magisk is that all my system modifications are still there after I update my phone. Drastically cuts down on the time it takes to set my phone up after an update.
Didgeridoohan said:
I've never used Flashfire and haven't updated through OTA since, 2014-ish. :laugh: I'm mainly going on theoretical knowledge here... On my Nexus I used fastboot to flash the factory image (until I switched to ROM flashing in TWRP) and now I just flash the full update package that OnePlus provides in TWRP.
Click to expand...
Click to collapse
I've tried installing TWRP permanently, but the moment I have installed an official patch, it got wiped - and I haven't found any docs how to prevent that.
My main use for Magisk is that all my system modifications are still there after I update my phone. Drastically cuts down on the time it takes to set my phone up after an update.
Click to expand...
Click to collapse
What settings are you referring to?
niko26 said:
I've tried installing TWRP permanently, but the moment I have installed an official patch, it got wiped - and I haven't found any docs how to prevent that.
Click to expand...
Click to collapse
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
What settings are you referring to?
Click to expand...
Click to collapse
I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.
Didgeridoohan said:
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
Click to expand...
Click to collapse
Well, TWRP is gone after an update - I can't boot into it.
[/quote]I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.[/QUOTE]
Hm, I am not sure if I get you right. If it is about apps, I use Titanium Backup to recover my old apps+settings.
system files
Most of the setting you mentioned are messing with the system files. "debloating" or removing and system applications with titanium backup will fail a system check with OTA update. You can freeze the apps i believe.
I changing the screen density and boot scripts. These are all system files locations.
I have had an ota work be re-installing the system apps from titanium backup and reverting all the other changes when it was failing before. Think this was back on android 6.0 though.
Didgeridoohan said:
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.
Click to expand...
Click to collapse
automattic said:
Most of the setting you mentioned are messing with the system files. "debloating" or removing and system applications with titanium backup will fail a system check with OTA update. You can freeze the apps i believe.
I changing the screen density and boot scripts. These are all system files locations.
I have had an ota work be re-installing the system apps from titanium backup and reverting all the other changes when it was failing before. Think this was back on android 6.0 though.
Click to expand...
Click to collapse
Since all of the things I mentioned are done with Magisk, none of them will cause an OTA to fail...
Reinstalling system apps will not work, since nowadays an OTA will fail just by mounting /system as rw.
Hi guys, trying to install latest OTA patch for Pixel 2. I am assuming process would be the same. I tried to follow the guide but hit the bump immediately. I can't see "Restore Stock Boot" when pressing uninstall. But there is restore images option. Hitting it does nothing, I receive the message that there are no backups. Where does the backup go so I can put the original file for it to be reinstalled?
I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
edit: I installed TWRP and booted into it with no problem. But when I then booted system, powered off and boot back to recovery, it was gone.
lewmur said:
I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
Click to expand...
Click to collapse
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.
V0latyle said:
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.
Click to expand...
Click to collapse
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.
lewmur said:
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.
Click to expand...
Click to collapse
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.
V0latyle said:
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.
Click to expand...
Click to collapse
What is +GSM?? Is that google services management?
lewmur said:
What is +GSM?? Is that google services management?
Click to expand...
Click to collapse
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps
V0latyle said:
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps
Click to expand...
Click to collapse
I'll give it a try a little later. Right now I'm bushed!! Thanks
lewmur said:
I'll give it a try a little later. Right now I'm bushed!! Thanks
Click to expand...
Click to collapse
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.
lewmur said:
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.
Click to expand...
Click to collapse
What file did you try to flash?
In most cases, you need to extract the system.img from the zip package. You can't flash the archive itself.