[RECOVERY][ROOT]TWRP 3.2.3-1 Galaxy Tab S4 - T830/T835 - Samsung Galaxy Tab S4 ROMs, Kernels, Recoveries, &

Unofficial release -TWRP recovery for the Galaxy Tab S4 2018 - SM-T830/T835 MSM8998
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
TWRP 3.2.3-0 Released
Aug 6, 2018
TWRP 3.2.3-0 is out now for most currently supported devices.
What's new in 3.2.3-0:
* Fix automatic installing of OTA zips on encrypted devices
* Remove SuperSU from TWRP
* Support both md5 and md5sum file extensions when doing MD5 checking for zip files
Want to get notifications when we release new versions of TWRP? Install the TWRP app and select your device!
We need your help! The bulk of TWRP work is done by a handful of people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
You can track the progress of builds here
Update 21/9/2018
Beta build released.
Current status - Beta (tested working)
Treble supported
Pretty much everything is working except for ADB and MTP at the moment.
You flash this at your own risk. Please ensure you have the stock ROM to hand downloaded from SAMMOBILE in case of problems. This will trip the knox counter.
NOTE: ON ANDROID 5.1.1> DEVICES IT IS NECESSARY TO GO TO:
Settings -> Developer Options -> OEM unlocking
AND ENABLE OEM UNLOCK FIRST OR YOU MAY ENCOUNTER 'BLOCKED BY FRP LOCK' WHEN FLASHING.
*****INSTALL INSTRUCTIONS:*****
Flash with ODIN in the AP slot.
1. Put your device in DOWNLOAD mode.
(Hold POWER + VOL DOWN + VOL UP) ]
2. Run ODIN and uncheck Auto reboot.
3. Load the file below into the AP slot and hit start.
twrp_3.2.3-1_t830_26918
4. After flashing and ODIN reports PASS immediately force reboot to recovery. Do NOT let the device boot to the OS.
You should now see TWRP recovery.
NOTE: FAILURE TO FOLLOW THE STEPS ABOVE IMPLICITLY WILL RESULT IN STOCK RECOVERY REPLACING TWRP AT FIRST BOOT.
*****OREO ROOT INSTRUCTIONS:*****
Note: A MicroSD card is required to install the files below to your device.
1. Flash the Forced encryption disabler patch. This is only required if you wish to have full functionality in TWRP.
Flashing this will disable Samsung's forced encryption. Disabling encryption will allow TWRP to mount the data partition.
After flashing the patch it is necessary to *FORMAT* (not wipe) the /DATA partition using the FORMAT DATA button under the wipe options.
PLEASE NOTE THIS WILL DELETE EVERYTHING ON INTERNAL STORAGE AND FACTORY RESET THE DEVICE, SO BACK UP ANYTHING YOU WISH TO KEEP.
TabS4_oreo_forced_encryption_disabler
2. To root I suggest installing Magisk as this is a currently supported project, SuperSu is no longer getting active development.
https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
3. Enjoy your rooted device.
DEVICE TREE: https://github.com/ashyx/TWRP_Samsung_GTS4LWIFI
PLEASE DO *NOT* DIRECT LINK TO THESE FILES. PLEASE LINK TO THIS POST
Credits: Me, Teamwin, @ianmacd. Huge thanks to Ian for his full support and testing, helping patch the kernel and providing everything needed to get this done.
Please note I don't own this device and spend a lot of my free time bringing these builds for you to use and benefit from.
FEEDBACK IS APPRECIATED PLEASE.
THANKS.
DONATE ME HERE IF YOU WANT TO BUY ME A BEER OR HIT THE THANKS BUTTON IF I HELPED YOU

ashyx said:
I don't expect this to even boot as I have been forced to use the stock kernel and even if it does there is likely to be problems mounting partitions or accessing certain parts of the file system.
This is due to Samsung's current kernel source being totally borked causing many compiler errors I have not yet managed to fix.
Click to expand...
Click to collapse
Let me be the first to say thank you for this, @ashyx.
I don't have time to flash it until later in the day, but you mention having to use the stock kernel, so I wanted to point you at my repo of Samsung's kernel source for firmware revision ARGH. Samsung hasn't released the source of a more recent version yet.
I built this before I even had the device (before it had even been released in Europe, in fact), so it's also untested, but I did fix all of the compile errors before committing it. You can either clone this repo, or just cherry-pick the commit that fixes all of the compile errors (e1af7e420d4d1eb0a3302d65bb1b6e8e54f7f36b). The defconfig is as released by Samsung, so probably needs a number of config options turned off before it will produce a kernel that will even boot as an unofficial build.
Thanks once again for all of your hard work (often on devices you don't even own).

ianmacd said:
Let me be the first to say thank you for this, @ashyx.
I don't have time to flash it until later in the day, but you mention having to use the stock kernel, so I wanted to point you at my repo of Samsung's kernel source for firmware revision ARGH. Samsung hasn't released the source of a more recent version yet.
I built this before I even had the device (before it had even been released in Europe, in fact), so it's also untested, but I did fix all of the compile errors before committing it. You can either clone this repo, or just cherry-pick the commit that fixes all of the compile errors (e1af7e420d4d1eb0a3302d65bb1b6e8e54f7f36b). The defconfig is as released by Samsung, so probably needs a number of config options turned off before it will produce a kernel that will even boot as an unofficial build.
Thanks once again for all of your hard work (often on devices you don't even own).
Click to expand...
Click to collapse
Ah good stuff.
Yep most of them were include and tracepoint errors. Had pretty much fixed most of them by the looks of it, but got fed up after a while and got stuck at multiple tracepoint defines errors.
Honestly sometimes Samsung just release any old rubbish source code just to comply with the GPL.
No way is this the actual source code used in the stock kernel.
Many thanks for the link to the kernel source. I'll ensure you get some credit for the commits.

ashyx said:
Honestly sometimes Samsung just release any old rubbish source code just to comply with the GPL.
No way is this the actual source code used in the stock kernel.
Click to expand...
Click to collapse
Yes, I wouldn't be a bit surprised if we're never able to produce a bootable custom kernel for this device, as with the Tab S3. Once we have TWRP up and running, however, I shall certainly give it my best shot.

ianmacd said:
Yes, I wouldn't be a bit surprised if we're never able to produce a bootable custom kernel for this device, as with the Tab S3. Once we have TWRP up and running, however, I shall certainly give it my best shot.
Click to expand...
Click to collapse
It's ridiculous. Many times I have had to debug Samsung kernel sources. As you have discovered some just do not boot the OS no matter what.
I had an issue with the Tab A a while back where no matter what I couldn't get the kernel to boot.
I put a complaint into Samsung's open source dept. and threatened to report it to the GPL for releasing unbootable source code.
Lo and behold the next source code release booted perfectly.

ashyx said:
Current status - UNTESTED
This is really only intended for users who have fair knowledge of flashing custom stuff. I do not recommend for novices until the build is proved stable and proper instructions are available.
I don't expect this to even boot as I have been forced to use the stock kernel and even if it does there is likely to be problems mounting partitions or accessing certain parts of the file system.
Click to expand...
Click to collapse
I've flashed this now, @ashyx, and there's both good and bad news.
The good news is that it boots!
The bad news is that, although I didn't swipe to allow modifications, it's no longer possible to boot back to system. dm-verity appears to have been triggered. Interestingly, it takes as long as a full boot before the system finally reports Verification failed, so possibly this can still be bypassed by making the right edits from TWRP.
That's all I've done with it at this point. Let me know which steps you would like me to carry out. I'll leave it as is now until I hear from you.
Photos attached. Note the newly appeared open padlock and Custom in the second photo.

ianmacd said:
I've flashed this now, @ashyx, and there's both good and bad news.
The good news is that it boots!
The bad news is that, although I didn't swipe to allow modifications, it's no longer possible to boot back to system. dm-verity appears to have been triggered. Interestingly, it takes as long as a full boot before the system finally reports Verification failed, so possibly this can still be bypassed by making the right edits from TWRP.
That's all I've done with it at this point. Let me know which steps you would like me to carry out. I'll leave it as is now until I hear from you.
Photos attached. Note the newly appeared open padlock and Custom in the second photo.
Click to expand...
Click to collapse
Great.
Now I know it boots I'll fix the DM-VERITY issue.
I take it DATA is unmountable until FORMATTED?

ashyx said:
Great.
Now I know it boots I'll fix the DM-VERITY issue.
I take it DATA is unmountable until FORMATTED?
Click to expand...
Click to collapse
I hadn't done any more with it, but I've just tried and data is indeed unmountable.
Less expected is that all other file-systems (system, efs, cache, etc.) are also unmountable. Or is that the result of dm-verity having been tripped?

ianmacd said:
I hadn't done any more with it, but I've just tried and data is indeed unmountable.
Less expected is that all other file-systems (system, efs, cache, etc.) are also unmountable. Or is that the result of dm-verity having been tripped?
Click to expand...
Click to collapse
As I mentioned previously I expected the file system to have access issues due to the kernel.
Will have to patch the kernel to fix that. However no part of DATA will be accessible until formatted.

ashyx said:
As I mentioned previously I expected the file system to have access issues due to the kernel.
Click to expand...
Click to collapse
Sorry, I was rushing out the door and keen to answer you before I left. As soon as I was outside, I remembered what you had written about expecting file-system access to be impaired.
Sent from my SM-G965F using XDA Labs

So...anyone succesfully rooted this device with TWRP help ? Step-by-step procedure requested. Thanks !!

ianmacd said:
Sorry, I was rushing out the door and keen to answer you before I left. As soon as I was outside, I remembered what you had written about expecting file-system access to be impaired.
Sent from my SM-G965F using XDA Labs
Click to expand...
Click to collapse
Ok have recompiled TWRP with the patched kernel and created a patched boot to disable dm-verity and a flashable zip to disable forced encryption.
twrp_3.2.3-1_t830_test_r2
To disable forced encryption, mount internal storage(DATA) and disable dm-verity:
1. Install the patched boot below. This can be installed with ODIN or extract the boot.img and flash with TWRP:
T830XXU1ARH8_dmverity_patched_boot
2. Boot to TWRP
3. Install the Forced encryption patch: TabS4_oreo_forced_encryption_disabler
4. Format DATA using the *FORMAT DATA button* under the wipe options.
(NOTE - THIS WILL WIPE ALL INTERNAL STORAGE!)
5. Reboot and check DATA is mountable
Done.

crissx said:
So...anyone succesfully rooted this device with TWRP help ? Step-by-step procedure requested. Thanks !!
Click to expand...
Click to collapse
The thread is only 2 pages, rather than asking you could have read the posts. If you would have read the thread you would see that the recovery is still being developed and has bugs being worked out. There are ways to root your device without twrp. If you need a step by step guide, hold off, because you may need another step by step guide to unbrick your device.

ashyx said:
Ok have recompiled TWRP with the patched kernel and created a patched boot to disable dm-verity and a flashable zip to disable forced encryption.
twrp_3.2.3-1_t830_test_r2
To disable forced encryption, mount internal storage(DATA) and disable dm-verity:
1. Install the patched boot below. This can be installed with ODIN or extract the boot.img and flash with TWRP:
T830XXU1ARH8_dmverity_patched_boot
2. Boot to TWRP
Click to expand...
Click to collapse
Thanks, @ashyx.
I'm afraid can't boot this version of TWRP. At first, I thought it was because dm-verity was tripped yesterday, so I first performed the factory reset demanded by the device, and then tried again, but no joy.
Instead of TWRP, it boots me into download mode, but rather than the familiar turquoise download screen, I get a mixed splash screen/diagnostic text display. Nevertheless, it is definitely download mode.
From there, I tried reflashing test2 of TWRP followed by the dm-verity patched boot image, but rebooting afterwards always puts me back in download mode. The only way I can seem to get out of it again is by flashing stock firmware.
I can't post a log, obviously, but I've attached a photo of the screen in question.
UPDATE:
I tried reinstalling yesterday's initial build of TWRP, just to see if I could still get into that, and it appears that I can.

ianmacd said:
Thanks, @ashyx.
I'm afraid can't boot this version of TWRP. At first, I thought it was because dm-verity was tripped yesterday, so I first performed the factory reset demanded by the device, and then tried again, but no joy.
Instead of TWRP, it boots me into download mode, but rather than the familiar turquoise download screen, I get a mixed splash screen/diagnostic text display. Nevertheless, it is definitely download mode.
From there, I tried reflashing test2 of TWRP followed by the dm-verity patched boot image, but rebooting afterwards always puts me back in download mode. The only way I can seem to get out of it again is by flashing stock firmware.
I can't post a log, obviously, but I've attached a photo of the screen in question.
UPDATE:
I tried reinstalling yesterday's initial build of TWRP, just to see if I could still get into that, and it appears that I can.
Click to expand...
Click to collapse
It could either be the custom kernel or the dtb, as I have modified both.
However regarding the dtb, I had issues splitting the dtb with aik, so had to use an alternative method.
I will compile twrp with the stock dtb and custom kernel and see how that goes.
Thanks

ashyx said:
It could either be the custom kernel or the dtb, as I have modified both.
However regarding the dtb, I had issues splitting the dtb with aik, so had to use an alternative method.
I will compile twrp with the stock dtb and custom kernel and see how that goes.
Click to expand...
Click to collapse
As you know, I had started work on a version of TWRP for this device myself, but not got very far. Like you, I had run into the issue of the embedded DTB. When I mentioned this to a developer on Telegram, he pointed me at this splitting tool. Before I could use it, however, you announced your build of TWRP, so I never tried it, but perhaps it can be of some use to you now.

ianmacd said:
As you know, I had started work on a version of TWRP for this device myself, but not got very far. Like you, I had run into the issue of the embedded DTB. When I mentioned this to a developer on Telegram, he pointed me at this splitting tool. Before I could use it, however, you announced your build of TWRP, so I never tried it, but perhaps it can be of some use to you now.
Click to expand...
Click to collapse
Yes thats one of the tools I've used to split the dtb.
It's not the splitting that's the issue I think it's the appending back to the kernel or the custom kernel itself.
Thanks anyway
EDIT: Compiled this one with just the custom kernel and stock dtb.
https://androidfilehost.com/?fid=1322778262904007632

ashyx said:
EDIT: Compiled this one with just the custom kernel and stock dtb.
https://androidfilehost.com/?fid=1322778262904007632
Click to expand...
Click to collapse
This one yields the same result, I'm afraid. I can't get into TWRP and am stuck in download mode until I flash stock firmware again.

ianmacd said:
This one yields the same result, I'm afraid. I can't get into TWRP and am stuck in download mode until I flash stock firmware again.
Click to expand...
Click to collapse
I hope it's not the kernel. I'm going to repack the stock kernel and dtb the exact same way and see if that boots.
I have a suspicion there's some special way Samsung are appending the dtb.
I'm also going to contact @osm0sis as he's a whizz at this stuff
Are you ok with the testing?

ashyx said:
I hope it's not the kernel. I'm going to repack the stock kernel and dtb the exact same way and see if that boots.
I have a suspicion there's some special way Samsung are appending the dtb.
I'm also going to contact @osm0sis as he's a whizz at this stuff
Are you ok with the testing?
Click to expand...
Click to collapse
No worries, my friend. I'll test whatever you ask me to.
The device is wiped and unusable now anyway without reinstallation, so I have everything to gain and nothing to lose.

Related

TWRP, ClockworkMod or other custom recovery available?

As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
samusalo said:
As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
Click to expand...
Click to collapse
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Entropy512 said:
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Click to expand...
Click to collapse
What about Kernel SOurces and Other Trees ?
GuneetAtwal said:
What about Kernel SOurces and Other Trees ?
Click to expand...
Click to collapse
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Entropy512 said:
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Click to expand...
Click to collapse
WEll it is same as Xperia C's Source and other Leaked Source :/ i Don't know why Mediatek don't make a Simple Filesystem like that of Nvidea and Qualcomm
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Zpik said:
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Click to expand...
Click to collapse
No, it does not. Stock Android "3e" recovery.
There's a TWRP image nearly ready, but who knows when it will be fully ready for public consumption. I won't be working on it (or anything else) at all this week for various reasons.

Shield TV 2017 (16GB) How to... DTB...

I own a Shield TV 2017 (16GB) remote only (P2894, Darcy) which currently has Nvidia 7.1.0 developer OS, unlocked bootloader and the boot.img was patched using Magisk Manager 6.2.1/Magisk 18.0.
It has been noted patching boot.img using Magisk Manager 6.2.1/Magisk 18.0 only performs a partial root and that something else in the "DTB" information needs to be modified in order to allow full root access to read/write.
I'm new to this so please forgive me if I ask something obvious.
I've connected my Shield TV to my PC via ADB and executed
fastboot oem dtbname
...
(bootloader) tegra210-darcy-p2894-0050-a08-00.dtb
OKAY [ -0.000s]
finished. total time: -0.000s
I don't know how to extract the *.dtb information or know what's required to patch it.
The command to flash it is
fastboot flash DTB tegra210-darcy-p2894-0050-a08-00.dtb
Can someone else help provide what's required to extract, modify, etc... in order to flash and gain full root access?
Mogster2K said:
Zulu99 mentioned something similar - that dm-verity was enabled in darcy's DTB file, preventing any custom firmwares from executing. Foster does not seem to have this problem.
He's provided a patched DTB here - use at your own risk: http://bit.ly/2CxB1hS (WARNING! ONLY FOR 2017 DARCY MODEL!)
Original post here.
Click to expand...
Click to collapse
It's my understanding that this is required to allow TWRP 3.2.3.0 foster to work properly. If not can someone please clarify this for us beginner users?
NOTE: The patched DTB file above is not for the same version as the one I have.
nanerasingh said:
As my test on 2017 16gb 7.2.2 official TWRP patched the boot img i got root access but not fully write.
I used the DTB and flashed from fastboot and reboot without any reset -w command.
No issue of unresponsiveness and boots up normal.I tried edit build.prop in system via ES explorer and reboot the see the persistent and rw works.
So system dm-verity patch by DTB works.
Click to expand...
Click to collapse
Noting this too...
Thanks for the confirmation!
The fastboot -w should only be required if the forced cyption was already in use on the device.
But if I am not mistaken than on the developer version only the data prtition is encrypted, which is no issue.
nadia p. said:
It's my understanding that this is required to allow TWRP 3.2.3.0 foster to work properly. If not can someone please clarify this for us beginner users?
NOTE: The patched DTB file above is not for the same version as the one I have.
Click to expand...
Click to collapse
AFAIK the patched DTB is for booting custom ROMs. More work still needs to be done to get TWRP working again.
---------- Post added at 09:45 PM ---------- Previous post was at 09:42 PM ----------
nadia p. said:
I own a Shield TV 2017 (16GB) remote only (P2894, Darcy) which currently has Nvidia 7.1.0 developer OS, unlocked bootloader and the boot.img was patched using Magisk Manager 6.2.1/Magisk 18.0.
It has been noted patching boot.img using Magisk Manager 6.2.1/Magisk 18.0 only performs a partial root and that something else in the "DTB" information needs to be modified in order to allow full root access to read/write.
I'm new to this so please forgive me if I ask something obvious.
I've connected my Shield TV to my PC via ADB and executed
fastboot oem dtbname
...
(bootloader) tegra210-darcy-p2894-0050-a08-00.dtb
OKAY [ -0.000s]
finished. total time: -0.000s
I don't know how to extract the *.dtb information or know what's required to patch it.
The command to flash it is
fastboot flash DTB tegra210-darcy-p2894-0050-a08-00.dtb
Can someone else help provide what's required to extract, modify, etc... in order to flash and gain full root access?
Click to expand...
Click to collapse
Is root not working for you now? If you have never upgraded the stock ROM past 7.1, then it should work without needing a patched DTB.
Mogster2K said:
AFAIK the patched DTB is for booting custom ROMs. More work still needs to be done to get TWRP working again.
---------- Post added at 09:45 PM ---------- Previous post was at 09:42 PM ----------
Is root not working for you now? If you have never upgraded the stock ROM past 7.1, then it should work without needing a patched DTB.
Click to expand...
Click to collapse
I'm quite the beginner at all of this Android stuff, although I have experience with several other software related things. I'm currently stuck trying to install TWRP 3.2.3.0 foster on my Shield TV 2017 (16GB, remote only + usb keyboard + usb mouse). I haven't been able to backup the entire device yet to use that to see if I can restore everything back to that exact state yet. I don't know how to tell how "rooted" I really am yet.
Steel01 says TWRP 3.2.3.0 fosters is working on Darcy. I'm still trying to confirm this. My main reason for TWRP is to complete a full backup which I can later restore back to that exact state if/when something should happen if accidentally updated and it breaks everything again.
nadia p. said:
I'm quite the beginner at all of this Android stuff, although I have experience with several other software related things. I'm currently stuck trying to install TWRP 3.2.3.0 foster on my Shield TV 2017 (16GB, remote only + usb keyboard + usb mouse). I haven't been able to backup the entire device yet to use that to see if I can restore everything back to that exact state yet. I don't know how to tell how "rooted" I really am yet.
Steel01 says TWRP 3.2.3.0 fosters is working on Darcy. I'm still trying to confirm this. My main reason for TWRP is to complete a full backup which I can later restore back to that exact state if/when something should happen if accidentally updated and it breaks everything again.
Click to expand...
Click to collapse
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher. 7.2 majorly broke a lot of things, including TWRP, which is why this thread has so much traffic lately and I why asked whether you had upgraded past 7.1. Please confirm whether you have or not.
Mogster2K said:
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher. 7.2 majorly broke a lot of things, including TWRP, which is why this thread has so much traffic lately and I why asked whether you had upgraded past 7.1. Please confirm whether you have or not.
Click to expand...
Click to collapse
Hello Mogster2K, Originally without any modifications the factory installed Nvidia software upgraded itself through on-line updates to 7.2.1 which then broke other 3rd party Apps for me. I then attempted to downgrade to 6.3.0 developer OS, however because it was my first time unlocking the bootloader it wiped everything so once it 6.3.0 was successfully flashed, I had to connect to the internet, sign-in again to Google Play and meanwhile it forced itself to update back to 7.2.1 again. Later by following ACiDxCHRiST's guide HERE, I was able to successfully downgrade to 7.1.0 developer by patching the 7.1.0 boot.img then manually flashed each line item in flash-all.bat.
Later I tried to install TWRP 3.2.3.0 so I could backup the device, however I've not been successful with that since I have a Shield TV 2017 (16GB) remote only model so I must use a USB keyboard and USB mouse to do it. I was reading these other posts here about what the issues might be preventing me from installing TWRP and using it to back everything up. Does this help answer your question?
So I'm currently on 7.1.0 developer OS, patched boot.img using Magisk Manager 6.2.1/Magisk 18.0. So far the Apps that were broken by 7.2.0 "factory" are again working fine in 7.1.0. I don't game, I mainly watch movies and tv series with my device so I don't have many requirements other than I'd like to back everything up so in case it accidentally gets updated somehow I can revert back to a working archive and continue from there.
Mogster2K said:
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher.
Click to expand...
Click to collapse
I realized I wasn't sure if by upgrading the "stock" rom this included updating the device to 7.2.0 (or later) via on-line updates or just flashing the rom itself to 7.2.0 (or later).
Does anyone know how to test for certain criteria to help determine if:
A) anything needs to be modified in regards to DTB
B) if their device has been updated in such a way that it currently breaks TWRP (or other things) in such a way there is no fix as of today
This should prove quite useful to help us understand if/anything needs to be done or where the device resides at any given moment.
nadia p. said:
I realized I wasn't sure if by upgrading the "stock" rom this included updating the device to 7.2.0 (or later) via on-line updates or just flashing the rom itself to 7.2.0 (or later).
Click to expand...
Click to collapse
Both. Anyway, I did not realize at the time that darcy could be fully downgraded to 7.1, sorry. It doesn't work on my foster, so I can't use TWRP at all. Also, to the best of my knowledge, TWRP requires at least a USB mouse to function regardless of which ShieldTV model you have. And the modified DTB is just for booting modified images on darcy 7.2+. You're fine without it on 7.1.
Stuck... post backup TWRP 3.2.3.0, now corrupt w/black screen
I'm not sure if this had anything to do with it but I'm suck at a black screen after backing up TWRP.
More information can be found at this POST.
Already this 7.2 update is creating topics all over the place
Anyway, let me try to at least some light on things.
My latest findings:
1. The bootloader does not downgrade to 7.1 once you had at least the 7.2.x installed, not sure about 7.2 as it is too late for me to test this.
I did not check with the 6.3 either but maybe someone who did is able to state what bootloader is working then.
2. The DTB is not included in the firmware images at all but it seems it was included in some pre 7.1 to include the "updates" for the Darcy models.
What makes the Zulu one tick is the simple fact that it is patched to disable DM-Verity completely.
Hence the requirement for the fastboot -w or a factory reset.
TWRP and such....
This might get quite long, so anyone without half decent knowledge about rooting, firmwares and recoveries can just skip it
First thing I learned from 7.2 was: Do not mess with your bootloader!!!
Second thing I learned is that Linus was right with his statement about NVidia and their open source suppport.
So what actually changed?
For starters the NVidia statement of the developer firmware being rootable is not true the same way it was before.
Google latest kernel fixes and changes have been implemented - look it up yourself please to spare me thausand of lines of typing!
In short it means that all backdoors or such that Magisk or SU have used are unavailabe now.
Rooting still works but with the limit of write access.
And that is the important factor one for TWRP, the second is "routing".
Let me try to word it as simple as I can...
We can not modify the system to ignore the stock recovery or related security features.
We can not write to required areas of the system required to boot into TWRP through the recovery.
If you somehow manage to get into TWRP, like when I still had a working mod, there again is no write access to system available and the internal memory will be corrupted if you write a backup.
The DTB Zulu provided gives us system wide write rights again by disabling DM-Verity but this only goes for the system!!
The recovery does not use the DTB in this way.
Best thing you end up with is a dark screen where ADB seems to be working.
It actually works with full root access for me in several cases LOL
So if that really is TWRP then why can't we see it?
My TV is great as it allows multi input formats.
So a 1080P signal will be accepted as such.
And every time this screen format changes I see a little pop up with the new resolutions on the screen.
Since 7.2 this popup no longer shows up....
TWRP might actually be there and working but we can not see or use it.
The strange thing however is that at least on the 7.2.2 I had the strange problem that just trying to boot into tWRP through fastboot resulted in a corrupt system.
The bootloader realises the recovery written into the temp area has no NVidia signature or hash code to match.
This means for the bootloader a possible attack on the system happened and it is "secured", resulting in a soft brick.
My plans to fix all this crap for good:
The DTB is a partial solution at best as we
a) don't really know how compatible it is with future updates.
b) we still fail to properly use TWRP again.
All up a total nighmare for any modder or person with a lot of data and apps to backup and restore.
My first attempt was to build the 7.2 from the sources, thinking at least here the NVidia statements are correct that their installer takes care of everything.
Lol! It did take of about 120GB in downloads but did not give me any of require software suites actually required to even load a build tree.
Would need far more time than I have to mae complete and work with registrations, accounts and all this.
So I decided to go back to my roots before Magisk was a thing.
Dissecting the firmware, disabling all new "safety" features and not required encryptions and hash checks.
That bit I think I finnished to my satisfaction.
On the packing to make it work to be installed under 7.2.X I am still working.
Biggest drawback for me is that I lost TWRP and that the TWRP builder does not even let me log in on my Shield.
So even if a more offical way or porting or building could be a way out I can not access it.
Means I can neither try to install my modded firmware nor test it.
So if anyone reading here has a confirmed way to downgrade to something that brings TWRP back to live with working write access and working backup functions:
Don't be shy, we don''t bite (much)!
Share your way, give us the links and if my magic still works a bit this nightmare shall soon be over for good
7.2 sources still have not been released yet, anyway. I found a reference to a new branch "rel-30-r2-partner-o" but that's all.
Downunder35m said:
Already this 7.2 update is creating topics all over the place
Anyway, let me try to at least some light on things.
My latest findings:
1. The bootloader does not downgrade to 7.1 once you had at least the 7.2.x installed, not sure about 7.2 as it is too late for me to test this.
I did not check with the 6.3 either but maybe someone who did is able to state what bootloader is working then.
2. The DTB is not included in the firmware images at all but it seems it was included in some pre 7.1 to include the "updates" for the Darcy models.
What makes the Zulu one tick is the simple fact that it is patched to disable DM-Verity completely.
Hence the requirement for the fastboot -w or a factory reset.
TWRP and such....
This might get quite long, so anyone without half decent knowledge about rooting, firmwares and recoveries can just skip it
First thing I learned from 7.2 was: Do not mess with your bootloader!!!
Second thing I learned is that Linus was right with his statement about NVidia and their open source suppport.
So what actually changed?
For starters the NVidia statement of the developer firmware being rootable is not true the same way it was before.
Google latest kernel fixes and changes have been implemented - look it up yourself please to spare me thausand of lines of typing!
In short it means that all backdoors or such that Magisk or SU have used are unavailabe now.
Rooting still works but with the limit of write access.
And that is the important factor one for TWRP, the second is "routing".
Let me try to word it as simple as I can...
We can not modify the system to ignore the stock recovery or related security features.
We can not write to required areas of the system required to boot into TWRP through the recovery.
If you somehow manage to get into TWRP, like when I still had a working mod, there again is no write access to system available and the internal memory will be corrupted if you write a backup.
The DTB Zulu provided gives us system wide write rights again by disabling DM-Verity but this only goes for the system!!
The recovery does not use the DTB in this way.
Best thing you end up with is a dark screen where ADB seems to be working.
It actually works with full root access for me in several cases LOL
So if that really is TWRP then why can't we see it?
My TV is great as it allows multi input formats.
So a 1080P signal will be accepted as such.
And every time this screen format changes I see a little pop up with the new resolutions on the screen.
Since 7.2 this popup no longer shows up....
TWRP might actually be there and working but we can not see or use it.
The strange thing however is that at least on the 7.2.2 I had the strange problem that just trying to boot into tWRP through fastboot resulted in a corrupt system.
The bootloader realises the recovery written into the temp area has no NVidia signature or hash code to match.
This means for the bootloader a possible attack on the system happened and it is "secured", resulting in a soft brick.
My plans to fix all this crap for good:
The DTB is a partial solution at best as we
a) don't really know how compatible it is with future updates.
b) we still fail to properly use TWRP again.
All up a total nighmare for any modder or person with a lot of data and apps to backup and restore.
My first attempt was to build the 7.2 from the sources, thinking at least here the NVidia statements are correct that their installer takes care of everything.
Lol! It did take of about 120GB in downloads but did not give me any of require software suites actually required to even load a build tree.
Would need far more time than I have to mae complete and work with registrations, accounts and all this.
So I decided to go back to my roots before Magisk was a thing.
Dissecting the firmware, disabling all new "safety" features and not required encryptions and hash checks.
That bit I think I finnished to my satisfaction.
On the packing to make it work to be installed under 7.2.X I am still working.
Biggest drawback for me is that I lost TWRP and that the TWRP builder does not even let me log in on my Shield.
So even if a more offical way or porting or building could be a way out I can not access it.
Means I can neither try to install my modded firmware nor test it.
So if anyone reading here has a confirmed way to downgrade to something that brings TWRP back to live with working write access and working backup functions:
Don't be shy, we don''t bite (much)!
Share your way, give us the links and if my magic still works a bit this nightmare shall soon be over for good
Click to expand...
Click to collapse
First of all thank you so much for putting all this in layman's terms so someone like me can understand it. Total respect!
Since my device is useless if there is some way I can offer you remote access to a PC, the device and anything else I can assist you with please don't hesitate to let me know.
If you need me to send you my device with remote that you can use to complete these things and get everyone unstuck from this dreadful situation I'm all for that too.
I wish there were a means, like with computers, that we can purchase a band new device, fully back it up before even connecting it to the internet and being forced to sign-in to Google Play before we even have access to the device. We'd also need a way to wipe, format and reinstall this backup without any issues. Is this too much to ask for in an Android world?
EDIT: I have time, access to certain hardware PCs, Macs and Linux, and have some basic skills with computers, phones, etc... If I can assist you or anyone with certain time consuming things let me know. The only Android device I currently own now is the Shield TV.
Would it Work to just flash the system/vendor files without updating the Bootloader?
nadia p. said:
Since my device is useless if there is some way I can offer you remote access to a PC, the device and anything else I can assist you with please don't hesitate to let me know.
Click to expand...
Click to collapse
Sorry, I've lost track of your particular situation. Are you unable to reflash Stock 7.2 or 7.2.1? I realize it's hardly ideal, but it would at least make the ShieldTV usable.
From what I understand the dtb file is in the blob file, so simply flashing back a blob file would put back the stock dtb file. The only issue with flashing blob files is if you tried flashing back a Nougat blob file if you were already on a Oreo Firmware, as long as you only try flashing a Oreo Firmware blob file you shouldn't run into any problems, I would have to go back and have a read, but I'm sure I read that you may have done this and if you had tried to flash a Nougat blob file when you were already on an Oreo Firmware, that could be where you first ran into problems. But I'm not too sure if you are asking where to get the modified dtb file or not, I'm not sure if you have already flashed the modified dtb file or you are asking where to get the modified dtb file. I checked the dtb version on my 2017 Darcy Shield and it came up with a different number version than yours, mine came back with: tegra210-darcy-p2894-0050-a04-00.dtb whereas you have posted you have the tegra210-darcy-p2894-0050-a08-00.dtb. I done the check on what version of the dtb I had before and after using the modified dtb and also after when I flashed back a Oreo blob file and back to a Full Stock Oreo firmware and they both came back as the a04 version.
I would try and flash back to the latest Stock 7.2.1 image released on Nvidia's site: https://developer.nvidia.com/gameworksdownload
If successful then I would look at downgrading back to 7.1 Stock Firmware. I'm still a bit confused if this is what you have done or you only have a black screen when trying to boot to system?
The Fifth and Sixth version on the downloads screen are the versions for the 2017 model, one being the Developer version and the one below being the Stock version of 7.2.1. I would try flashing the Stock Version first and see if that gets you back up and running again. If it does, I would again check the dtb version as I am sure the 2017 Darcy model should be showing the a04 version and not a08.
---------- Post added at 01:06 PM ---------- Previous post was at 12:55 PM ----------
I just had a quick read back, you have said you have flashed the Developer image and then also flashed a patched boot.img. I have not done this combo as it is not the way I would do things. I would use just the Stock Firmware and not the Developer image with a patched boot.img. I do not know 100% for sure if the only difference between the Developer version and the stock version is the boot.img but if you are going to use a patched boot.img anyway, this is the reason why I say there is no need to flash the Developer version as you are going to use a Patched boot.img anyway, I would just stick with the Stock version.
Mogster2K said:
Sorry, I've lost track of your particular situation. Are you unable to reflash Stock 7.2 or 7.2.1? I realize it's hardly ideal, but it would at least make the ShieldTV usable.
Click to expand...
Click to collapse
Hello Mogster2K, from the factory install which was updated OTA to 7.2.1 I was able to 1st unlock the bootloader and flash 6.3.0 developer OS to my device successfully, or so I thought so. What I mean by this is based on what Downunder35m said once the device has been updated to 7.2.0 regardless of how when flashing previous versions of OS (developer or recovery) it may not revert the bootloader to 6.3.0. This we still have to see and test to confirm, unfortunately he nor I have any way to test things right now. That being said because I unlocked the bootloader (forced wipe) then flashed 6.3.0 that all went fine accept when booting to the Nvidia home screen it required me to connect to the internet and then sign-in to Google Play. Doing this the OS forces it to update itself again back to 7.2.1 (at that time).
So now that the previous steps were useless I then discovered ACiDxCHRiST's guide HERE and followed that since the bootloader was already unlocked I could modify the boot.img form 7.1.0 then flash that. Well two things happened, it worked perfectly however it's most likely Magisk didn't truly root the device 100%, it only rooted it partially. So now the device worked fine on 7.1.0 and everything was going well UNTIL I decided to install TWRP and backup my device. Doing so totally screwed it, now I have a black screen.... Read THIS.
So one of the reasons I started this thread was to find out more about DTB and how do we start to first test a devices current state, perhaps patch it to what we need to recover from the 7.2.0 changes and restrictions. The benefit of all of this is we should be able, with expertise, be able to climb our way out of this hole and get back to a working device.
whiteak said:
From what I understand the dtb file is in the blob file, so simply flashing back a blob file would put back the stock dtb file. The only issue with flashing blob files is if you tried flashing back a Nougat blob file if you were already on a Oreo Firmware, as long as you only try flashing a Oreo Firmware blob file you shouldn't run into any problems, I would have to go back and have a read, but I'm sure I read that you may have done this and if you had tried to flash a Nougat blob file when you were already on an Oreo Firmware, that could be where you first ran into problems. But I'm not too sure if you are asking where to get the modified dtb file or not, I'm not sure if you have already flashed the modified dtb file or you are asking where to get the modified dtb file. I checked the dtb version on my 2017 Darcy Shield and it came up with a different number version than yours, mine came back with: tegra210-darcy-p2894-0050-a04-00.dtb whereas you have posted you have the tegra210-darcy-p2894-0050-a08-00.dtb. I done the check on what version of the dtb I had before and after using the modified dtb and also after when I flashed back a Oreo blob file and back to a Full Stock Oreo firmware and they both came back as the a04 version.
I would try and flash back to the latest Stock 7.2.1 image released on Nvidia's site: https://developer.nvidia.com/gameworksdownload
If successful then I would look at downgrading back to 7.1 Stock Firmware. I'm still a bit confused if this is what you have done or you only have a black screen when trying to boot to system?
The Fifth and Sixth version on the downloads screen are the versions for the 2017 model, one being the Developer version and the one below being the Stock version of 7.2.1. I would try flashing the Stock Version first and see if that gets you back up and running again. If it does, I would again check the dtb version as I am sure the 2017 Darcy model should be showing the a04 version and not a08.
---------- Post added at 01:06 PM ---------- Previous post was at 12:55 PM ----------
I just had a quick read back, you have said you have flashed the Developer image and then also flashed a patched boot.img. I have not done this combo as it is not the way I would do things. I would use just the Stock Firmware and not the Developer image with a patched boot.img. I do not know 100% for sure if the only difference between the Developer version and the stock version is the boot.img but if you are going to use a patched boot.img anyway, this is the reason why I say there is no need to flash the Developer version as you are going to use a Patched boot.img anyway, I would just stick with the Stock version.
Click to expand...
Click to collapse
In short the 7.2.1 update broke the factory install by affecting other apps I use and that were working perfectly fine in 7.1.0 before the update occurred. This was the sole reason I attempted to revert back to a previous OS.
Just flashing 6.3.0 didn't work as it updated itself back to 7.2.1 forcibly. I then had to work around that issue and the only way I found was to download 7.1.0, patch it's boot.img file, flash 7.1.0 developer to keep the bootloader uplocked so it wouldn't wipe the system whereby deleting the user info, apps, etc..., make sense? The only issue is that Magisk didn't fully root the device properly and with the new OS verification added to 7.2.0 it created all sorts of other protections where we're not able to fully wipe everything and flash back normally. These protections kick in and prevent it. This is why we're trying to see how to undo the protection settings so we can actually do what we need to do. DTB is part of this.

Would this procedure work? (install magisk and twrp on 10.0.3.0)

First, let me say I have been using rooted phones with twrp for several years and never had the slightest problem with them, so I generally know what I am doing, but the Mi A2 Lite is just a disaster area for me, not with Magisk, that works fine, but twrp seems impossible for me to install on 10.0.3.0 without soft bricking ( I had twrp installed on 10.0.2.0 and 10.0.1.0 so I am not unfamiliar with the method, but on 10.0.3.0 - no way). I have done so many factory resets now I have my own parking space at the factory! (That is humour btw).
So I wondered if a different approach to the problem might work. I am not a coder or phone guru, so what I propose might be nonsense, if it is I am sure somebody will tell me.
We are all used to the concept of the 'patched_boot.img' created by Magisk and if you don't want to produce your own version the forum usually has a link to it. Magisk though is not the problem, twrp is, so what I am proposing is that somebody provides a link to a 'double_patched_boot.img' ie a flashable boot image that contains both twrp and magisk and that can directly replace the stock boot via fastboot.
Apparently there are some folks that have managed to install both twrp and magisk on 10.0.3.0, so if one of them could extract the 'double_patched_boot.img' from their phone it might help out a lot. How do you achieve that? Well there is probably more than one way, but the way that I would choose (if I could manage to install them both in the first place) is to boot into twrp, connect to pc, take a miflash backup of the phone and then unzip it with the following command (this is a linux command I am sure someone can provide a windows equivalent):
Code:
tar -xzf ********.tgz
where ********.tgz is the name of your miflash backup.
Then extract the boot.img from the resulting folder, rename it to something like 'double_patched_boot_10.0.3.0.img' and provide a link to it on the forum. Then some brave soul could try it out (probably not me as I am sick of doing factory resets and don't have any backups because I don't have any recovery to make them from).
OTOH this might just not be practical, I don't know enough to be sure.
i was having similar issues. replaced my mi a2 lite and followed the guide for the aosp 109 gsi here in the forum replacing the fstab and one other file i forgot they name but it's instructed. i have twrp zero the fixed one, magisk, and I'm running the RR PIE ROM with zero issues and I've been back and forth in and out of recovery no problem. I'm pretty sure it will work for you too.
12:121390 said:
i was having similar issues. replaced my mi a2 lite and followed the guide for the aosp 109 gsi here in the forum replacing the fstab and one other file i forgot they name but it's instructed. i have twrp zero the fixed one, magisk, and I'm running the RR PIE ROM with zero issues and I've been back and forth in and out of recovery no problem. I'm pretty sure it will work for you too.
Click to expand...
Click to collapse
Interesting. I have certainly thought of jumping ship to a custom rom, but I would like to wait a little before I do so, ideally until someone fires up a Lineage rom for the A2 Lite. But if things continue as badly as they have done so far with stock roms then I might well join you on RR.
viking777 said:
Interesting. I have certainly thought of jumping ship to a custom rom, but I would like to wait a little before I do so, ideally until someone fires up a Lineage rom for the A2 Lite. But if things continue as badly as they have done so far with stock roms then I might well join you on RR.
Click to expand...
Click to collapse
also because of the new ARB thing, custom is much safer, i think i bricked my last device rolling back from ota 9.0 software to ota 8.1. that's a non-issue with custom. just something to be wary of. the current RR pie gsi is near flawless for he so far. hope that helps a little
12:121390 said:
also because of the new ARB thing, custom is much safer, i think i bricked my last device rolling back from ota 9.0 software to ota 8.1. that's a non-issue with custom. just something to be wary of. the current RR pie gsi is near flawless for he so far. hope that helps a little
Click to expand...
Click to collapse
Anti roll back is disabled and not an issue if bootloader is unlocked
Nice thread. Tried it as well but no chance 10.0.3.00 + twrp + magisk. And you are right the problem is twrp.
Sent from my Phh-Treble vanilla using Tapatalk
12:121390 said:
i was having similar issues. replaced my mi a2 lite and followed the guide for the aosp 109 gsi here in the forum replacing the fstab and one other file i forgot they name but it's instructed. i have twrp zero the fixed one, magisk, and I'm running the RR PIE ROM with zero issues and I've been back and forth in and out of recovery no problem. I'm pretty sure it will work for you too.
Click to expand...
Click to collapse
Does RR Pie have any issues on Mi A2 Lite? Whichever GSI I'd tried, I had lags :/
12:121390 said:
i was having similar issues. replaced my mi a2 lite and followed the guide for the aosp 109 gsi here in the forum replacing the fstab and one other file i forgot they name but it's instructed. i have twrp zero the fixed one, magisk, and I'm running the RR PIE ROM with zero issues and I've been back and forth in and out of recovery no problem. I'm pretty sure it will work for you too.
Click to expand...
Click to collapse
brother i also want to install RR PIE Rom can you please give me the guide link?
hossman said:
Anti roll back is disabled and not an issue if bootloader is unlocked
Click to expand...
Click to collapse
correct it is not. what happened was.. lol. i thought i was crafty and did some file swapping and made miflash setups that would flash so the stock files as usual , but with gsi's like RR and/or bootleggers for the system image. and it works, up until i flashed from RR to bootleggers with those setups described previously . there is where my genius was flawed. lol. lesson learned
---------- Post added at 06:43 AM ---------- Previous post was at 06:38 AM ----------
marstonpear said:
Does RR Pie have any issues on Mi A2 Lite? Whichever GSI I'd tried, I had lags :/
Click to expand...
Click to collapse
for me, i have not come across anything caused by the GSI. any issues I've faced are purely self inflicted.
I don´t get your problems... Just boot twrp, and install it as described in original thread.
After that flash back aboot from 9.6.11.0 and the message "your system got destroyed" will disappear!
Voodoojonny said:
I don´t get your problems... Just boot twrp, and install it as described in original thread.
After that flash back aboot from 9.6.11.0 and the message "your system got destroyed" will disappear!
Click to expand...
Click to collapse
You might not get my problem, but likewise I don't get your solution. Firstly aboot has never been touched during the attempted twrp install so why flash it at all, it has not been changed, and secondly you suggest I flash it with something that is how many versions old 4?, 5?, I'm not sure, when just about every post you ever read stresses that you should not mix old and new partitions at the same time.
I hope you forgive my scepticism, but can you actually suggest the slightest reason why this might work?
Or is it all just voodoo johnny (sorry, couldn't resist that).
viking777 said:
You might not get my problem, but likewise I don't get your solution. Firstly aboot has never been touched during the attempted twrp install so why flash it at all, it has not been changed, and secondly you suggest I flash it with something that is how many versions old 4?, 5?, I'm not sure, when just about every post you ever read stresses that you should not mix old and new partitions at the same time.
I hope you forgive my scepticism, but can you actually suggest the slightest reason why this might work?
Or is it all just voodoo johnny (sorry, couldn't resist that).
Click to expand...
Click to collapse
Aboot is the bootloader. Since Pie the aboot was modified to check wheather there are modification on your boot.img. So everytime you modify something (like installing twrp), you get the message "your system got destroyed".
9.6.11.0 is the last version of Oreo. Here the bootloader didn´t check boot.img.
That´s why you need to flash 9.6.11.0 - maybe the older verstions will work too. Didn´t check. But I guess only 9.6.11.0 will work becouse it was the latest oreo version and it had to have a bootloader which can boot up pie (to have ota working).
Here you can find the aboot.img I use... and which works without any problem on pie - right now I´m running 10.0.3.0...
Just flash it via fastboot.
Voodoojonny said:
Aboot is the bootloader. Since Pie the aboot was modified to check wheather there are modification on your boot.img. So everytime you modify something (like installing twrp), you get the message "your system got destroyed".
9.6.11.0 is the last version of Oreo. Here the bootloader didn´t check boot.img.
That´s why you need to flash 9.6.11.0 - maybe the older verstions will work too. Didn´t check. But I guess only 9.6.11.0 will work becouse it was the latest oreo version and it had to have a bootloader which can boot up pie (to have ota working).
Here you can find the aboot.img I use... and which works without any problem on pie - right now I´m running 10.0.3.0...
Just flash it via fastboot.
Click to expand...
Click to collapse
OK that makes sense now - thank you for the explanation. I will probably give that a try sometime, but not right now as I have a stable working phone for the first time in ages and I don't want to jeopardise that.
Just one question though. When I had twrp installed on 10.0.2.0, it was fine at doing backups, but on the two occasions I tried to restore with them they failed, by which I don't mean that the restore didn't repair the phone, but that it was impossible to even carry out the restore, it started but did not complete - just ended with 'Restore Failed' message.
Have you tried any restores with twrp installed in the manner you suggest and if so did they work? No point in installing it otherwise.
viking777 said:
OK that makes sense now - thank you for the explanation. I will probably give that a try sometime, but not right now as I have a stable working phone for the first time in ages and I don't want to jeopardise that.
Just one question though. When I had twrp installed on 10.0.2.0, it was fine at doing backups, but on the two occasions I tried to restore with them they failed, by which I don't mean that the restore didn't repair the phone, but that it was impossible to even carry out the restore, it started but did not complete - just ended with 'Restore Failed' message.
Have you tried any restores with twrp installed in the manner you suggest and if so did they work? No point in installing it otherwise.
Click to expand...
Click to collapse
There seems to be some bugs restoring system and vendor... Some users talked about... I usually only save and restore the data and boot partition and I never had any problems with that. For all other partitions you can use miflash or fastboot...
Yeah all my twrp full backups don't work after a fresh stock installment either, that's very annoying.
The twrp version for daisy is bugged. Backups are not working, the wifi with GSI Roms on pie stock is not working anymore as soon as twrp is installed as well.
Sent from my Phh-Treble vanilla using Tapatalk
Thanks for the replies above. @voodoojohnny
In my case it was the data partition that caused the restore to fail, vendor and system and boot all seemed to go through normally. @cd492
Based on what you say along with my own experiences and those of voovoojohnny, it looks like twrp is more trouble than it is worth at the moment. I think I will make do without it for now and hope for a better version in the future.
viking777 said:
First, let me say I have been using rooted phones with twrp for several years and never had the slightest problem with them, so I generally know what I am doing, but the Mi A2 Lite is just a disaster area for me, not with Magisk, that works fine, but twrp seems impossible for me to install on 10.0.3.0 without soft bricking ( I had twrp installed on 10.0.2.0 and 10.0.1.0 so I am not unfamiliar with the method, but on 10.0.3.0 - no way). I have done so many factory resets now I have my own parking space at the factory! (That is humour btw).
So I wondered if a different approach to the problem might work. I am not a coder or phone guru, so what I propose might be nonsense, if it is I am sure somebody will tell me.
We are all used to the concept of the 'patched_boot.img' created by Magisk and if you don't want to produce your own version the forum usually has a link to it. Magisk though is not the problem, twrp is, so what I am proposing is that somebody provides a link to a 'double_patched_boot.img' ie a flashable boot image that contains both twrp and magisk and that can directly replace the stock boot via fastboot.
Apparently there are some folks that have managed to install both twrp and magisk on 10.0.3.0, so if one of them could extract the 'double_patched_boot.img' from their phone it might help out a lot. How do you achieve that? Well there is probably more than one way, but the way that I would choose (if I could manage to install them both in the first place) is to boot into twrp, connect to pc, take a miflash backup of the phone and then unzip it with the following command (this is a linux command I am sure someone can provide a windows equivalent):
where ********.tgz is the name of your miflash backup.
Then extract the boot.img from the resulting folder, rename it to something like 'double_patched_boot_10.0.3.0.img' and provide a link to it on the forum. Then some brave soul could try it out (probably not me as I am sick of doing factory resets and don't have any backups because I don't have any recovery to make them from).
OTOH this might just not be practical, I don't know enough to be sure.
Click to expand...
Click to collapse
THIS HAS NOT BEEN TESTED ON GSI'S YET
I'm currently in the process of RR with TWRP but having extreme Encryption errors
Grab these two files (Big Thanks to Zerovoid, Seryioo, and mac12m99)
Fixed SDCard Support TWRP Image File (Put this on your SDCard and Computer)-
https://forum.xda-developers.com/mi...unofficial-twrp-daisy-mount-sd-fixed-t3889390
Fixed SDCard Support TWRP Installer Zip (Put this on your SDCard)-
https://androidfilehost.com/?fid=11410963190603893418
But I got TWRP on 10.0.3.0 with magisk, and Justic Kernel.
THIS WILL WIPE YOUR DEVICE I'M DEFINITELY NOT RESPONSIBLE FOR LOST DATA
Start with the phone being on with USB Debugging enabled correctly
Type adb reboot bootloader
So flash the 10.0.3.0 ROM through MiFlash using the flash_all.bat, this process has to be done so backup your data before erasing.
After it is done flashing it restarts, go ahead and hold power and volume down right back to the Bootloader
Type: fastboot boot twrp-3.2.3-0-daisy_zero.img
It would boot into TWRP, if you see something about decryption hit cancel this may mean you haven't followed directions so far
Tap install and find your SD Card, find the fixed-twrp-installer-daisy.zip where ever you put it on your SD Card and install it, this process takes a few minutes when finished DO NOT HIT REBOOT SYSTEM!
Hit the home button back to TWRP home screen and tap reboot >>> bootloader
Download this to your computer - https://androidfilehost.com/?fid=11410963190603884024
Type: fastboot flash aboot aboot_9.6.4.img
Then type: fastboot reboot
Afterwards your phone shall boot up to Android if it does hold power and volume up and release power and keep hold volume up when the screen turns back on to go-to recovery, if TWRP boots up you have successfully completed the task.
Now flash Magisk zip (optional)
Hopefully this helped kind of my first tutorial, this was my process.
InfinityXDA said:
THIS HAS NOT BEEN TESTED ON GSI'S YET
I'm currently in the process of RR with TWRP but having extreme Encryption errors
Grab these two files (Big Thanks to Zerovoid, Seryioo, and mac12m99)
Fixed SDCard Support TWRP Image File (Put this on your SDCard and Computer)-
https://forum.xda-developers.com/mi...unofficial-twrp-daisy-mount-sd-fixed-t3889390
Fixed SDCard Support TWRP Installer Zip (Put this on your SDCard)-
https://androidfilehost.com/?fid=11410963190603893418
But I got TWRP on 10.0.3.0 with magisk, and Justic Kernel.
THIS WILL WIPE YOUR DEVICE I'M DEFINITELY NOT RESPONSIBLE FOR LOST DATA
Start with the phone being on with USB Debugging enabled correctly
Type adb reboot bootloader
So flash the 10.0.3.0 ROM through MiFlash using the flash_all.bat, this process has to be done so backup your data before erasing.
After it is done flashing it restarts, go ahead and hold power and volume down right back to the Bootloader
Type: fastboot boot twrp-3.2.3-0-daisy_zero.img
It would boot into TWRP, if you see something about decryption hit cancel this may mean you haven't followed directions so far
Tap install and find your SD Card, find the fixed-twrp-installer-daisy.zip where ever you put it on your SD Card and install it, this process takes a few minutes when finished DO NOT HIT REBOOT SYSTEM!
Hit the home button back to TWRP home screen and tap reboot >>> bootloader
Download this to your computer - https://androidfilehost.com/?fid=11410963190603884024
Type: fastboot flash aboot aboot_9.6.4.img
Then type: fastboot reboot
Afterwards your phone shall boot up to Android if it does hold power and volume up and release power and keep hold volume up when the screen turns back on to go-to recovery, if TWRP boots up you have successfully completed the task.
Now flash Magisk zip (optional)
Hopefully this helped kind of my first tutorial, this was my process.
Click to expand...
Click to collapse
Thank you very much for posting this process in such detail, unfortunately I think you must have missed my last post where I said:
it looks like twrp is more trouble than it is worth at the moment. I think I will make do without it for now and hope for a better version in the future.
Click to expand...
Click to collapse
I meant it, at least for now, but maybe your post will help somebody else.
viking777 said:
Thank you very much for posting this process in such detail, unfortunately I think you must have missed my last post where I said:
I meant it, at least for now, but maybe your post will help somebody else.
Click to expand...
Click to collapse
Yes I didn't see that post but understand I didn't give you links to the official TWRP, I gave you the unofficial fixed TWRP which actually features SD Card Support and trust me it works completely fine I haven't had a problem yet. This took me hours upon hours to figure out what I was doing wrong.
The only specific reason you are not successfully getting TWRP is because you didn't flash the aboot.img after installing the zip.
I hope this helps you in the future!
thanks InfinityXDA for the tutorial, you should create a post just for it~

[Magisk] Root for the Galaxy S10 Series

Here comes official Magisk support for the Galaxy S10!
Let's get Magisk to kick start the development of these Samsung devices!
Link to Instructions
Carefully read through everything in the page linked above! Follow the instructions closely so you don't end up bricking your device
Technical Details
Google enforces all devices that ships with Android 9.0 to use system-as-root in part of "Project Treble", so Samsung finally introduced their own "flavor" of the implementation. More details regarding system-as-root can be found in the official Google dev site. Samsung is using the A-only system-as-root setup, meaning that its boot image will only contain the kernel binary without ramdisk included. Similar setup has already been deployed on many new devices, and the solutions for those devices are rather simple: add a new ramdisk section into the boot image and hexpatch the kernel to always use ramdisk as rootfs. However in Samsung's case, the bootloader simply does not load anything other than the kernel binary to the memory, meaning no matter what we do the kernel will always use the system partition as root directory. This leaves us no option but to install Magisk onto the recovery partition.
Installing to the recovery partition have its own issues: first is that a service called "flash_recovery" will run when the system starts up, which will restore the recovery image back to stock on startup. This is unacceptable because not only does it uninstall Magisk in the process, the data encryption key will also be changed due to fact that Samsung's data encryption keys are tied to the bootloader status and boot/recovery image signatures, and thus causing the device unable to boot in following reboots unless factory reset. The solution to this problem is to simply repack the boot image to remove the binary integrity and also the signature of the partition. The second issue is that since Magisk and recovery shares the same partition, how can we actually boot into recovery? (e.g. to factory reset your device, or have custom recovery co-exist with Magisk) Fortunately a solution that detects button key presses is introduced, which details are already provided in instructions.
To make matters even worse, Samsung introduced a "VaultKeeper" service, which adds another "lock" on top of the OEM lock of the bootloader. By default the service will "relock" the bootloader after data is wiped. Only after the initial setup will it verify the OEM lock option and changes the bootloader state accordingly. If you are running custom firmware with stock system, DO NOT try to wipe data or else you might end up bricking your device due to vaultkeeper locking your bootloader up, which will eventually lead to bootloader refusing to boot because unofficial partitions are detected.
For custom ROM developers, the first few things you would want to remove is VaultKeeper to protect your users from bricking their devices. For stock ROM users, just make sure to always boot to Magisk after a data wipe, or never power off your device before finishing the initial setup and verify OEM lock is enabled.
thx
Yay.
The best day of my life!!
Can I ask, when we install Magisk what sammy stuff will be broken? I understand Knox will be tripped but what 'features' will still be available.
Does the fingerprint still work for instance
Amazing work though, well done buddy
Fantastic!
I hope people carefully read those instructions!
ok, who's trying it first on an European S10+ ?
..
Amazing! Is this for unlocked Snapdragon too?
S9 Exynos not install
On S9 the installation does not give error, but on restart Magisk is no longer installed.
ooonea said:
On S9 the installation does not give error, but on restart Magisk is no longer installed.
Click to expand...
Click to collapse
I'm aware of this issue
cant even boot into download mode with the way you have given... is there a step missing?
ahh, turn the phone off, USB connected and press Bixby and Volume Down.
Fix?
topjohnwu said:
I'm aware of this issue
Click to expand...
Click to collapse
Will you fix it?
A couple of questions:
1. What will happen if I boot from boot partition after installing magisk? What steps will be needed to recover from that?
2. Why final wipe after installing magisk is needed?
ooonea said:
Will you fix it?
Click to expand...
Click to collapse
What an odd question... obviously.
I got some questions about Safetynet
1. Is Safetynet still passing with this method when you boot to system with magisk?
2. Also if you boot to system without pressing any button, so system without magisk, is Safetynet passing or failing?
Thanks for your hard work.
Download Mode doesn´t work for mee
is there a step missing?
Memento_Mori said:
Download Mode doesn´t work for mee
is there a step missing?
Click to expand...
Click to collapse
The cable must be in too
Thanks,
I have one question, after install Magisk can I still install OTA update ?
tiho5 said:
The cable must be in too
Click to expand...
Click to collapse
I know, but it doesn´t work for me too

General NEW: Solution without wiping. Pixel 6 Pro irregular error message: ''Your device is corrupt. It can't be trusted and may not work properly.

New including my solution without wiping:
I have great news, everyone:
First, a very brief summary of what didn't fix the issue:
I had tried flashing the full February factory image, both manually and using the Google Pixel Flash site without wiping, without any luck.
What just fixed the issue now:
I flashed the new (2nd) February full factory image without wiping. When I noticed I didn't get the corruption paused boot screen during one or more parts of the flash-all.bat flashing process, the phone booted normally after it was completely done.
So at the most, if this issue happens again, hopefully I'd only have to wait until the next full factory image is available.
Not pertinent to the solution, but:
Normally in the past, I go ahead and sign in, and let everything load, and then go back into Fastboot and flash my manually Magisk'd boot.img, but this time when it got to the lock screen, I went back into Fastboot right from there and flashed the Magisk'd boot.img I had prepared from before flashing the factory image. I then shut the phone off. I turned the phone on, and still, no corruption paused boot screen.
I haven't flashed a kernel yet. No idea if any need or can be updated for the 2nd February update - I just haven't checked and don't know if there is updated source code available, or if there will be before the March update.
Click to expand...
Click to collapse
Old:
Yes, I know there's a hair on the screen of my images taken with my original Pixel 1 of my Pixel 6 Pro.
Click to expand...
Click to collapse
I know there are other related threads such as this question thread Unlocked Pixel 6 Pro - "Your Device is corrupted and cannot be trusted" error after trying to manually flash Dec 2021 factory image, and other individual posts in various threads, but I wanted to create a thread where I will maintain the OP with what we figure out about this issue.
Click to expand...
Click to collapse
TL;DR:
So far, it seems the only full way to eliminate the issue includes flashing (via Flash-All.bat from the full firmware zip or Official Google Android Flash Tool) with a full wipe, so losing all user data and system settings. When these flashing methods require temporary rebooting in order to start flashing in a different mode, you may have to manually get the phone past the corruption screen for the flashing method to continue where it left off.​​Temporary workarounds are to use either of those two flashing methods while not wiping (in Android Flash Tool, have all the checkboxes unchecked) - this doesn't keep this screen from showing every time you reboot or turn the phone on after being off, but the phone is useable, even with a rooted stock kernel - I haven't tested a custom kernel again.​
Click to expand...
Click to collapse
​Back to the details you may or may not want to know...
This is the corruption screen in question, it precedes the normal bootloader unlocked screen, but in this case, it always requires a manual press of the power button to proceed:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Click to expand...
Click to collapse
The g.co/ABH link takes you to Understand warning about operating system safety. It's not very helpful in my opinion as it doesn't tell a way to fix the issue without a full wipe. Below are the contents of the page:
Understand warning about operating system safety​When you turn on an Android device, it checks the operating system to make sure it's safe to use. This means the code comes from a trusted source and hasn't been changed or corrupted.
If your operating system could have a problem, you can get a warning message that brings you to this page (g.co/ABH).
If you changed the operating system on purpose​You can continue using your device. But you acknowledge that your device might not work properly and your data could be exposed to corruption and security risks.
We recommend restoring your device's operating system. If you have a Pixel or Nexus, learn how to flash your device with the latest factory image.
If you didn't change the operating system yourself​
If your device is a Pixel, learn how to get help.
If it's a different Android device, contact your device manufacturer.
Click to expand...
Click to collapse
Spoiler: My original post from another related thread, in response to someone else's question about the solution.
sybor said:
Did you managed to do it using Android Flash Tool without wipping the device?
Click to expand...
Click to collapse
roirraW edor ehT said:
I'm preparing to create a catch-all thread just for this issue. I just experienced the issue for the first time, although I've observed the others who have encountered it under various circumstances.
For myself, it wasn't flashing the February image that caused the error, it was after I flashed a certain custom kernel.zip through EXKM (EX Kernel Manager) that I had the issue. I won't name the kernel as I don't think it's any particular kernel that's the issue, although I don't know what the cause is.
Previous to updating to the February firmware, I was on the January (and with Verity and Verity NOT disabled either time) and was using a different custom kernel zip without any issue. I went through the process pretty much identically to how I had previously. Using the stock kernel worked fine, and using the stock kernel rooted with Magisk 24.1 worked just fine as well. I first had the issue after rebooting from flashing a kernel.zip through EXKM, and I still have it.
I'm not 100% sure this was necessary but using the Android Flash Tool or the manual firmware flash-all.bat (both without wiping, and the Android Flash Tool with no checkboxes checked) both resulted in the phone being usable again, however when I reboot I still get that first (and different than the bootloader unlocked screen) corruption screen.
I will create my thread with images very soon, but I wanted to share what little I know so far, and at least the phone works, it's just a slight PITA that when I reboot or boot from the phone being off that I get that error which requires a manual power button press to go past. Note that during the re-flashing process that I sometimes had to manually press the button during the times the flash process reboots the phone into a different mode before it would continue the flashing process.
Click to expand...
Click to collapse
As you can see below, after flashing (but without wiping) I'm able to boot as normal (only tested with the stock February kernel, rooted with Magisk 24.1), with the only exception being the third screenshot from the top-left, about corruption, and requiring manually pressing the power button to get past the screen.
​
In case I need this post #2.
In case I need this post #3.
In case I need this post #4. (Last one of these)
It happened to me once when I sideloaded January's OTA and a full wipe with the Android Flash Tool worked, manually flashing via adb did not. However, I got that corrupt boot screen when flashing February's update via AFT. It was worse trying to fix the problem this go-around because I wiped the phone multiple times via AFT with various options (wiped, disable verity, even relocked the bootloader and returned to stock). It finally stuck but I'm not sure what I did.
I tried all the suggestions on XDA and around the Internet but nothing helped. Closest thing I could figure out was maybe one of the boot slots had had encryption and the other didn't so the update failed? It sucked, because now I'm hesitant to flash any kernels or even a patched magisk image because that damn corrupt boot screen appears way too easily.
Had this come up once on my wife's 5a.
This means there is dm-verity corruption:
Boot Flow | Android Open Source Project
source.android.com
Not a big deal really, the Magisk wizards will figure this out eventually. Sideloading the OTA fixed it.
Copied and pasted (for the most part) from another post of mine:
"That corrupt message means you have a dm verity corruption. Because there is a corruption, you are in eio dm verity mode. A clean flash (or factory reset) without corruption errors will allow the bootloader to see that a new OS has been installed and will switch back to restart mode and remove that warning. Apparently the root hash of the hash tree and the expected root hash aren't matching up, thus triggering this warning. Also, pressing the power button puts the phone in restart mode instead of eio mode and will allow you to boot up in this circumstance."
See documentation below (which shows the warning sign in red but with the same message).
Boot Flow | Android Open Source Project
source.android.com
Verifying Boot | Android Open Source Project
source.android.com
EDIT: And Ninja'd by 1 minute by @V0latyle
Lughnasadh said:
Copied and pasted (for the most part) from another post of mine:
"That corrupt message means you have a dm verity corruption. Because there is a corruption, you are in eio dm verity mode. A clean flash (or factory reset) without corruption errors will allow the bootloader to see that a new OS has been installed and will switch back to restart mode and remove that warning. Apparently the root hash of the hash tree and the expected root hash aren't matching up, thus triggering this warning. Also, pressing the power button puts the phone in restart mode instead of eio mode and will allow you to boot up in this circumstance."
See documentation below (which shows the warning sign in red but with the same message).
Boot Flow | Android Open Source Project
source.android.com
Verifying Boot | Android Open Source Project
source.android.com
Click to expand...
Click to collapse
Beat you to it, thanks for the additional explanation
V0latyle said:
Beat you to it, thanks for the additional explanation
Click to expand...
Click to collapse
I edited my post to reflect your Ninja prowess
Lughnasadh said:
I edited my post to reflect your Ninja prowess
Click to expand...
Click to collapse
It happened to me back in December when I first got my P6P and was rooting it. I couldn't get it to boot though. I tried using the repair tool, but it wouldnt find my device. I tried manual flashing via adb, but it would fail. I was about to send it back to google when I figured I would try to switch boot partitions and that fixed it.
dunno how I got this message as I only got it after flashing a custom kernel which dev said includes the magisk version that does not veed verity disabled.
i hope in march ota when I flash that it will go back to previous boot slot it dont say that.
I will probably do a full wipe and flash when I get some time as the message is annoying as it adds delay to boot
V0latyle said:
Had this come up once on my wife's 5a.
This means there is dm-verity corruption:
Boot Flow | Android Open Source Project
source.android.com
Not a big deal really, the Magisk wizards will figure this out eventually. Sideloading the OTA fixed it.
Click to expand...
Click to collapse
Thank you! Sideloading just now didn't fix it for me. I tried it while I was already on the February full firmware.
Spoiler: The details of my sideloading
I just sideloaded the full February OTA after I manually restored the unrooted stock February kernel. This might have been the first time I've sideloaded an OTA, or only the second time - I might have done it once on the Pixel 1. The Result code was 0 (zero) for both verification and installation, which appears to mean success where 1 would mean failure.
After success, I booted Android, unlocked the phone, kept it unlocked, and I waited at least 10 minutes since your instructions say:
Allow system to boot and wait for the update to complete. You must let the system do this before proceeding.
Click to expand...
Click to collapse
I never actually saw a notification regarding it, however - like I would if I tried an actual over-the-air update - "Finishing Update" or something like that. I rebooted after than 10+ minutes and still got the paused-boot corruption screen. After unlocking I waited again and then rebooted and same result.
I'm contemplating flashing the full firmware image for January without wiping and with suppressing reboot so no February-specific data is affected by suddenly being on the January firmware, and then immediately applying the February OTA again to see if that helps.
Do you anticipate any problems with this plan, or do you have a better suggestion for me to try first? No worries if anything goes wrong - I have nothing on my phone that isn't backed up, I'm just trying to avoid having to re-copy hundreds of gigs of FLAC formatted music yet again, LOL!
Lughnasadh said:
Copied and pasted (for the most part) from another post of mine:
"That corrupt message means you have a dm verity corruption. Because there is a corruption, you are in eio dm verity mode. A clean flash (or factory reset) without corruption errors will allow the bootloader to see that a new OS has been installed and will switch back to restart mode and remove that warning. Apparently the root hash of the hash tree and the expected root hash aren't matching up, thus triggering this warning. Also, pressing the power button puts the phone in restart mode instead of eio mode and will allow you to boot up in this circumstance."
See documentation below (which shows the warning sign in red but with the same message).
Boot Flow | Android Open Source Project
source.android.com
Verifying Boot | Android Open Source Project
source.android.com
EDIT: And Ninja'd by 1 minute by @V0latyle
Click to expand...
Click to collapse
Thank you! I appreciate the details and the additional link to relevant information.
roirraW edor ehT said:
I'm contemplating flashing the full firmware image for January without wiping and with suppressing reboot so no February-specific data is affected by suddenly being on the January firmware, and then immediately applying the February OTA again to see if that helps.
Do you anticipate any problems with this plan, or do you have a better suggestion for me to try first? No worries if anything goes wrong - I have nothing on my phone that isn't backed up, I'm just trying to avoid having to re-copy hundreds of gigs of FLAC formatted music yet again, LOL!
Click to expand...
Click to collapse
Well, this is how things went wrong on my wife's Pixel 5a:
Restored boot image in Magisk, installed OTA. Rebooted. Successful boot, no root (because she rebooted it before I had a chance to install to inactive slot)
Switched active slot to the "old" slot. Bootlooped.
Dirty flashed January factory image on old slot. Verity EIO corrupt warning. Bootlooped.
Dirty flashed January factory image to both slots. Bootlooped, Rescue Party data corrupt warning.
Downloaded and dirty flashed February factory image to both slots. Bootlooped, Rescue Party.
Sideloaded the February OTA to the "new" slot. Successful boot. Attempted to live boot previously patched image, I believe January patched with 23017. Rescue Party.
Patched February boot image in Magisk Stable 24, rebooted to bootloader and live booted. Successful. Performed Direct Install in Magisk, and rebooted. Successful boot with root.
There is something to do with the OTA mechanism that will bork everything if you try to mess with it. I do know that if it doesn't successfully boot the updated slot, it will mark that slot "unsuccessful" and won't try to boot it again, and will then revert to the old slot. I don't know why it didn't just boot the old slot in my case.
Going forward, at least until we figure out the problem with automatic OTAs, the safest method of update is either dirty flashing the factory image (can use Android Flash Tool as well), or sideloading the OTA.
I posted this back in November/December after trying to flash factory image without the wipe command (factory image not ota). The problem with mine was I couldn't get past the message. At all. I wiped the device twice in recovery menu and it still wouldn't boot. I had to reflash The mid November build (on both slots) and wipe in between.
Then in December I disabled Location for ImsService in the privacy menu and the message appeared again - this time it would boot but only for two seconds, then it would automatically restart. Duplicated the issue after January update but haven't tried it since.
Many posts on Reddit for the 5/5a with this issue and the fix for those devices was to update Play Services and All apps in safe mode (with Bluetooth off - many users experienced their devices restart with the 'device is corrupt' message after turning on Bluetooth). I'll edit my post when I find the other posts to these issues, but it seems like a few things can cause this message to appear.
Awesome thread though. Unfortunately it looks like @roirraW "edor" ehT will be copying 200gb of music soon enough if no solution is found.
searching for 'corrupt' on reddit's GooglePixel sub shows this problem was mostly prevalent from November-December, Pixels 4-6.
Alekos said:
I posted this back in November/December after trying to flash factory image without the wipe command (factory image not ota). The problem with mine was I couldn't get past the message. At all. I wiped the device twice in recovery menu and it still wouldn't boot. I had to reflash The mid November build (on both slots) and wipe in between.
Then in December I disabled Location for ImsService in the privacy menu and the message appeared again - this time it would boot but only for two seconds, then it would automatically restart. Duplicated the issue after January update but haven't tried it since.
Click to expand...
Click to collapse
Interesting experience. Thank you for sharing the details.
Alekos said:
Many posts on Reddit for the 5/5a with this issue and the fix for those devices was to update Play Services and All apps in safe mode (with Bluetooth off - many users experienced their devices restart with the crop message after turning on Bluetooth). I'll edit my post when I find the other posts to these issues, but it seems like a few things can cause this message to appear.
Click to expand...
Click to collapse
I'm trying this now since it won't hurt any. I rebooted to safe mode, eventually remembered to turn off Airplane mode, I turned off Bluetooth just to make it a controlled experiment, then I updated the ~14 apps that had updates available. For the heck of it, I checked to see if there was any Play System update available to me and there wasn't, so next I uninstalled all updates for Google Play services, and reinstalled them.
I then rebooted, but I still have the paused-boot corruption screen. Worth a try, though. If you find more details, let me know, please.
Alekos said:
Awesome thread though. Unfortunately it looks like @roirraW "edor" ehT will be copying 200gb of music soon enough if no solution is found.
Click to expand...
Click to collapse
LOL!!
Edit: I wish going to safe mode didn't cause Nova Launcher Prime from resetting all my home screen widgets. It's not that big a deal to reconfigure them but I wish there was a way to keep that from happening.
My three Weawow weather widgets and my two Multi Timer widgets are the worst - and not terrible, just a little bit tedious. I'm getting used to it, though! LOL!
roirraW edor ehT said:
Interesting experience. Thank you for sharing the details.
I'm trying this now since it won't hurt any. I rebooted to safe mode, eventually remembered to turn off Airplane mode, I turned off Bluetooth just to make it a controlled experiment, then I updated the ~14 apps that had updates available. For the heck of it, I checked to see if there was any Play System update available to me and there wasn't, so next I uninstalled all updates for Google Play services, and reinstalled them.
I then rebooted, but I still have the paused-boot corruption screen. Worth a try, though. If you find more details, let me know, please.
LOL!!
Edit: I wish going to safe mode didn't cause Nova Launcher Prime from resetting all my home screen widgets. It's not that big a deal to reconfigure them but I wish there was a way to keep that from happening.
My three Weawow weather widgets and my two Multi Timer widgets are the worst - and not terrible, just a little bit tedious. I'm getting used to it, though! LOL!
Click to expand...
Click to collapse
what's interesting is, just from reading the posts on Reddit, looks like Pixels 4-5 were fixed by the update solution, but not for the 6. Here's one post.
Also, your message is completely different than the one I saw. Mine looked like the attachment.
edit--
And it looks like at least 10 users on this sub have posted about this issue, including this user who still can't fix his phone.
edit--#2--
shoot I know, Safe Mode causes weird things to happen with Launchers.... dammit sorry!!
edit --#3-- fixed link, woops thanks @roirraW "edor" ehT
Alekos said:
what's interesting is, just from reading the posts on Reddit, looks like Pixels 4-5 were fixed by the update solution, but not for the 6. Here's one post.
Also, your message is completely different than the one I saw. Mine looked like the attachment.
edit--
And it looks like at least 10 users on this sub have posted about this issue, including this user who still can't fix his phone.
Click to expand...
Click to collapse
Very interesting. Maybe there's a slight difference in the cause or some other detail we don't know yet, since the problem on mine wasn't preceded by wired or wireless headphones being used. Very interesting! Your link "this" became garbled. Here's the fixed link. this
Alekos said:
edit--#2--
shoot I know, Safe Mode causes weird things to happen with Launchers.... dammit sorry!!
Click to expand...
Click to collapse
That's quite alright, not your fault. I've only recently started fooling with safe mode so it's still a slight surprise to me each time, but I think it won't stay a surprise for much longer.
Alekos said:
edit --#3-- fixed link, woops thanks @roirraW "edor" ehT
Click to expand...
Click to collapse
You're welcome!
I had this error after a non-wipe upgrade, coupled with bootloops. I had everything backed up so I did a complete factory image install and re-rooted. The phone runs like new again and all rooting conflicts are resolved.

Categories

Resources