Database Develop

[MM] [Flashable] Patcher to provide root access without /system modification

This patcher is now outdated. Use the new SuperSU instead. http://forum.xda-developers.com/showpost.php?p=64161125&postcount=3
This zip is a systemless version. That means that you'll get root and be able to use it normally, but your system partition will not be modified, like in normal root methods. Only for Marshmallow.
Keep reading for disadvantages and advantages
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
If you have rooted before, flash the system partition (or reinstall the ROM) before flashing this zip.
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Reboot to TWRP. If it asks you whether you want system to be mounted as r/w, and if you want to take OTAs later, choose to keep system read-only (this will replace TWRP with stock recovery on reboot).
Flash SuperSU-v2.56-20151030013730.zip
Reboot
TWRP will say that you are not rooted, just ignore that. Do not tell it to root it.
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.

out386 said:
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 (or newer, if it supports systemless mode) from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Flash SuperSU-v2.56-20151030013730.zip
Reboot
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.
Click to expand...
Click to collapse
Well done bro!
I'm just waiting for this

Help regarding installation
I am using MicroMax Android One with Marshmallow
Currently, I've not tired the phone.
When I open recovery, I see some options like Apply update from SD card, mount, cache wipe, factory reset, etc.
So which option should I use to flash the zip file.

out386 said:
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 (or newer, if it supports systemless mode) from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Flash SuperSU-v2.56-20151030013730.zip
Reboot
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.
Click to expand...
Click to collapse
Good work n thanks for mention bt can't understand why u created a patcher again where I'v already created one!
Its ok, good job.

Good.... Thanks for posting

metaspook said:
Good work n thanks for mention bt can't understand why u created a patcher again where I'v already created one!
Its ok, good job.
Click to expand...
Click to collapse
Yes, well, I would never have reposted the same thing, so, I'm sorry if it seemed like that.
This one uses Chainfire's new systemless root method. Unlike other root methods that need modifications to /system, this method uses modifications to the boot image to set up and run the su daemon from a loop device on the /data partition and achieve root. Right now, that doesn't have much of an advantage except to make flashing OTAs easier. Chainfire made it because future devices might need it. I made the patch because someone on FB asked about it.

<accidental double post, sorry. Can't delete>

kalpitandroid said:
I am using MicroMax Android One with Marshmallow
Currently, I've not tired the phone.
When I open recovery, I see some options like Apply update from SD card, mount, cache wipe, factory reset, etc.
So which option should I use to flash the zip file.
Click to expand...
Click to collapse
You need to install a custom recovery first. Go to the Android One (First generation) General forums on this site. You'll find a how-to at the very top of the list of threads. Once you have a custom recovery, flash this using the "install zip" option.

out386 said:
Yes, well, I would never have reposted the same thing, so, I'm sorry if it seemed like that.
This one uses Chainfire's new systemless root method. Unlike other root methods that need modifications to /system, this method uses modifications to the boot image to set up and run the su daemon from a loop device on the /data partition and achieve root. Right now, that doesn't have much of an advantage except to make flashing OTAs easier. Chainfire made it because future devices might need it. I made the patch because someone on FB asked about it.
Click to expand...
Click to collapse
Hmm... gotcha now.. Good work!
If u ever need any help just pm.
Thank you...

out386 said:
<accidental double post, sorry. Can't delete>
Click to expand...
Click to collapse

TWRP, System writing, Supersu, Impossible?

I have had my fair share of problems modifying android before but I have never had a phone flat out lie to me and say an operation was successful and actually nothing happened at all.
Have had my nexus 6 for a year or so now. Have had minor issues rooting / modifying marshmallow in the past but I figured out it was all caused by the system partition having basically 0 free space. Made a huge mistake and installed to the latest 7.0 OTA. Wanted to simply enable tethering and edit the thermal config to not shut cores down. Should be as simple as pulling the files, editing them, pushing them back to the phone in twrp with the system partition mounted and thats the end of it right? Wrong.
First of all twrp 3.0.2 refuses to let me touch the system partition without some giant prompt about how its going to make itself stick and offer to root the phone. Simple enough I have seen it in previous versions I say yes as usual except twrp proceedes to immediately spew a bunch of superuser files that do nothing throughout the system partition without asking me if I want root. Dumb but whatever. I mount /system as read write and I go edit and replace my two files like usual (build.prop and thermal config). No matter if I ADB push or use twrps built in file manager it claims the file replacement is successful. Reboot into android and not only have both files not been touched (Verified by adb pull) but the recovery gets overwritten with the factory recovery anyways. (NEVER had issues with twrp sticking on marshmallow. Now after every reboot it gets wiped out)
Second of all if I select yes to twrp mounting system as writable and it does its spewing as I mentioned before then installing SuperSU instantly causes the phone to not boot. Rewrite the boot.img to factory and it boots fine OR Rewrite the clean factory system image and the SuperSU boot works fine. But modifying /system with twrp and then running supersu at the same time is a no go. TWRP is obviously doing something stupid to system that pisses off supersu so undoing twrps mess or uninstalling supersu makes it bootable again.
I dont even want root! Everyone is claiming you need to run "settings put global tether_dun_required 0" as root along with adding the usual "net.tethering.noprovisioning=true" in the build.prop to get native tethering working again! On 6.X only the build.prop edit was needed to get it working.
So long story short. I just want native tethering to work and to tweak my /system/etc/thermal-engine-shamu.conf . Is there anyone here who has done this successfully on nougat? I feel like its all twrps fault but im far too tired and frustrated to try another version tonight.

You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.

Strephon Alkhalikoi said:
You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.
Click to expand...
Click to collapse
It's stated in the op he's using twrp 3.0.2.

Didgeridoohan said:
It's stated in the op he's using twrp 3.0.2.
Click to expand...
Click to collapse
I misread his post then. I wonder if perhaps he is running TWRP via fastboot instead of installing it.

Flashing recovery using "fastboot flash recovery XXX.img"

Correct root and TWRP recovery for OOS 4.1.6 on OP3T - please.

I've been all over the OP3T forums looking for current information about the correct versions of TWRP and (Magisk or SuperSU) to use with stock OOS 4.1.6. I kept my old TWRP 3.0.4-1 and when I tried to apply SuperSU 2.79 SR3 I got an unusable system and had to restore from nandroid backup. I updated to TWRP 3.1.1-2 as per the Official TWRP app and now every time I try to reboot to system from TWRP it warns "No OS installed", but the reboot works fine. I have Magisk 13.2 ready to install but I'm reluctant until I know I have the right combination - the TWRP 3.1.1-2 backup is missing some partitions and I want to make sure I can at least recover my system if Magisk screws things up.
I've been all over the forums and all the relevant threads were closed months ago, or are written about OOS 4.0.3 or 4.1.1, or describes some hideous way someone turned their 3T into a pile of molten lava. Is there any current information about what combination of TWRP and a root zip will work with the latest OOS 4.1.6? Everything is stock except the unlocked bootloader. I don't want to flash a different ROM, I don't care about passing SafetyNet, I just want to root and go on with my life.
A couple of numbers is all I ask. I can't be the only one. Please - I've been without root for a week and it's bugging me.

TWRP 3.1.1-2 has got at least one major bug where it reports the OP3T as a OP3. That'll mess up your OP3T specific installations... Don't know if there are any other bugs, since I'm staying on 3.1.1-0 until they fix that bug. You also have the option of using blu_spark's TWRP. I've never tried it, but many users swears by it.
What works for me:
OOS 4.1.6
Franco Kernel r25
TWRP 3.1.1-0 (official)
Magisk v13.2
Magisk Manager 5.0.6
No issues whatsoever (for me)...

Thanks for that. I'd rather not change kernels, though. How likely is it that the same combination works with the stock kernel? Does anyone have that running?

OK, I tried it. Swiped the Magisk 13.2 zipfile in TWRP. The script ran partway through and then said "Can't mount system" in red letters. Now the phone boots into OOS, Magisk Manager is there and says "Rooted but no root permissions, not allowed?" It has reported several times that it needs to update, to the same version of Magisk and Manager that are already there. I allowed it to go through the cycle and reboot, with no change to behavior. When I try to run an app that needs root I get the permissions screen, but when I grant I get the dialog that says "Rooted Android required" - Either the su binary could not be found or you did not allow root permission..."
So, the phone works fine but unprivileged as before. I'd like to try clearing the cache, but since TWRP still reports no OS found (3.1.1-0 does this, just like -2) I don't really want to write into a system the recovery can't see. Besides, the existence of the su binary doesn't seem like something a cache clear will fix.
Advice?

OK, I tried it. Swiped the Magisk 13.2 zipfile in TWRP. The script ran partway through and then said "Can't mount system" in red letters. Now the phone boots into OOS, Magisk Manager is there and says "Rooted but no root permissions, not allowed?" It has reported several times that it needs to update, to the same version of Magisk and Manager that are already there. I allowed it to go through the cycle and reboot, with no change to behavior. When I try to run an app that needs root I get the permissions screen, but when I grant I get the dialog that says "Rooted Android required" - Either the su binary could not be found or you did not allow root permission..."
So, the phone works fine but unprivileged as before. I'd like to try clearing the cache, but since TWRP still reports no OS found (3.1.1-0 does this, just like -2) I don't really want to write into a system the recovery can't see. Besides, the existence of the su binary doesn't seem like something a cache clear will fix.
Advice?

Scratch that request. Things seem to be turning around - su works in terminal emulator, lets me ls privileged directories like /data. Root Explorer is working again. The only thing that isn't is AdAway, which can't write the hosts file. Otherwise the system seems to be rooted and working OK.
I'm still nervous that TWRP can't see that there's an OS on the phone, and I haven't seen any other reports of this.

It looks like Magisk can't mount /system read-write. Adaway won't install, and neither will Busybox. Titanium Backup also reports problems. I tried installing Busybox and the installation failed when it tried to remount system /rw.
Will look for solutions to this problem and report back here.

I've found many solutions to this problem, like installing busybox (Stericson Busybox apparently doesn't work in OOS 4.1.6, tried two others. Problem is, busybox will only install into a partition on /system, which requires that /system be read/write.

When I have issues with mounting system or anything like that, I go mount system myself in TWRP and it usually starts working after I reboot....I don't know why, it just works for me....if I see that error, that's the first place I go, everytime...

JMB2K said:
When I have issues with mounting system or anything like that, I go mount system myself in TWRP and it usually starts working after I reboot....I don't know why, it just works for me....if I see that error, that's the first place I go, everytime...
Click to expand...
Click to collapse
That won't work either. When I go to the Mount page in TWRP I can't get the checkbox next to /system to check. It just stays empty.

mobilityguy said:
That won't work either. When I go to the Mount page in TWRP I can't get the checkbox next to /system to check. It just stays empty.
Click to expand...
Click to collapse
I seem to remember having that problem once before.... Can't recall what I did, I think it involved something with the terminal... I'm not at my desk right now, I'll look into it shortly and see if I can remember

Problem solved. The more I looked at the symptoms, the more I realized that the OTA I took after unrooting with SuperSU corrupted the system partition somehow. The first time I tried applying the OTA with the stock recovery it failed, but I was able to reboot and apply 4.1.6. That's when the trouble began - I was unable to reapply SuperSU. Fortunately I had done a nandroid backup between the upgrade and the attempt to re-root, and after the SuperSU script failed I was able to restore the backup (made and restored using TWRP 3.0.4-1) and continue working. It was either at that point or earlier, during the OTA itself, that /system was damaged - not badly enough to prevent the phone from working perfectly well, but enough to keep TWRP from mounting /system read/write. From that point on I was doomed. None of my other attempts to fix the problem had a chance as long as TWRP was restricted to mounting /system read-only. Then it got worse.
After a semi-failed attempt to install Magisk (rooted applications worked as long as they didn't try writing to /system) I restored my pre-root 4.1.6 backup one more time. After that, TWRP wouldn't mount /system at all, which prevented me from making any more nandroid backups.
It was time to act. I could keep using the phone unrooted, but the longer I went on the more work would be required to put things completely right. The risk would increase because I couldn't take any more snapshots of the phone to fall back to if I munged the device again. I also had a positive reason to fix things - during the two days the phone was rooted but couldn't access /system, Titanium Backup kicked in and did a full backup of all my software and settings.
With a damaged file system and full backups, there was no reason for halfway measures. I copied all my user data off the phone and used LloydSmallwood's unbrick tool to flash the phone back to its original OOS 3.5.4 state. That took care of rebuilding all file structures. As soon as I rebooted, OOS upgraded to 4.1.6 in one step, taking care of the system upgrade. Unlocked the bootloader, installed TWRP 3.1.1-0 (not 3.1.1-2, which has a serious bug for the 3T as someone posted above). I was able to mount and unmount /system from TWRP's mount screen, no problem. Ran Magisk 13.3 script without a problem, installed Titanium Backup, and tested an app restore. No problem. I'm now in the midst of copying all my stuff back onto the phone, after which I'll restore all missing apps and be back in business (I hope).
It's possible I could have done something tricky like reformatting /system and restoring the partition from my last good nandroid backup. But I always would have been concerned that problems would have popped up later, maybe during the Android O upgrade, when it would be way too late to recover my then-current setup. After seeing virtually every combination of working and non-working features, it just made sense to build from a clean system.
So thanks have been given to LloydSmallwood for his absolutely indispensable unbrick tool (this is the second time it has saved my phone). I should also thank my Galaxy S3, running the current build of LineageOS, which has gotten me through the two days it took to set my OnePlus straight. The Galaxy has performed better than a five year old phone running brand-new software should ever be expected to - if it supported LTE I could consider using it as a daily driver. This has been an education, and a reminder of how important it is to keep good backups at every step throughout an upgrade - and routinely during production use.
Thanks to all who gave advice in this thread.

Galaxy S8 boot loop after trying to install an older version of Magisk

First, I should point out that I'm just a user, not a developer or hacker. I'm posting this because I don't know where else to ask for help.
This will most likely look like the post of an idiot. But, oh, well, I did manage to mess up my phone, which means I am an idiot. So here it goes: I had 16.0 installed and I tried to install 14.0 from TWRP recovery mode. Basically, Magisk hide wasn't working very well so I wanted to see if it worked with an older version. Now my phone is stuck in a boot loop. It just shows "Samsung Galaxy S8 powered by Android" then restarts. I can boot into TWRP and connect the phone to the PC to access the storage this way, but I can't boot into the OS. Is there any way I can fix this, preferably without losing my data?
I tried flashing the official uninstaller, but I get the message "Update process ended with ERROR: 1"
Here's what the log says about the uninstaller:
Mounting /system, /vendor
-Device platform: arm64
cp: can't stat '/dev/tmp/install/arm64/.': No such file or directory
! Cannot find /data/adb/magisk
Updater process ended with ERROR: 1
I:Install took 1 second(s).
Error installing zip file '/sdcard/Download/Magisk-uninstaller-20180429.zip'
Updating partition details...
I: Data backup size is 32943MB, free: 2620MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
I:Set page: 'flash_done'
I: operation_end - status=1
I looked at the contents of the zip on my computer, and it doesn't have an arm64 folder. So the uninstaller doesn't work on arm64 phones?
Update: I managed to uninstall Magisk using a compatible uninstaller, but the phone still doesn't boot into the OS.
Update 2: if I have to flash the stock ROM, I'm planning to do the next thing: back up my data partition to an external hard drive with TWRP. After I flash the ROM and wipe everything, I want to reinstall TWRP and restore that backup. Would this cause any issues?

Yes, there's an issue on 64-bit devices with the latest available uninstaller. Use the next to last, here: https://github.com/topjohnwu/Magisk/releases/download/v16.3/Magisk-uninstaller-20180328.zip

Thanks. I've just left home and I'll be away for two days. I didn't take the S8 with me, so I won't be able to try any more fixes until Sunday. But I'll check then and update my post if there are any more issues.

Didgeridoohan said:
Yes, there's an issue on 64-bit devices with the latest available uninstaller. Use the next to last, here:
Click to expand...
Click to collapse
I managed to uninstall Magisk with that zip, but the phone still doesn't boot into Android.

vladone97 said:
I managed to uninstall Magisk with that zip, but the phone still doesn't boot into Android.
Click to expand...
Click to collapse
In that case, restoring the stock boot image manually might work. If not, a complete restoration of your device's stock setup might be necessary.
Your device's forum is likely the best place to get further help.

Didgeridoohan said:
In that case, restoring the stock boot image manually might work. If not, a complete restoration of your device's stock setup might be necessary.
Your device's forum is likely the best place to get further help.
Click to expand...
Click to collapse
I tried flashing the stock boot image and it still doesn't work. Stock restoration it is then.

Didgeridoohan said:
In that case, restoring the stock boot image manually might work. If not, a complete restoration of your device's stock setup might be necessary.
Your device's forum is likely the best place to get further help.
Click to expand...
Click to collapse
One more question, though: I backed up my data partition to an external hard drive with TWRP. After I flash the stock ROM and wipe my data, I want to reinstall TWRP and restore that backup. Would this work or would it cause problems?

vladone97 said:
One more question, though: I backed up my data partition to an external hard drive with TWRP. After I flash the stock ROM and wipe my data, I want to reinstall TWRP and restore that backup. Would this work or would it cause problems?
Click to expand...
Click to collapse
If you get your device up and running after the wipe and reinstall, you could always try restoring the backup. If it works, it works, and if it doesn't you can just wipe /data again.

Didgeridoohan said:
If you get your device up and running after the wipe and reinstall, you could always try restoring the backup. If it works, it works, and if it doesn't you can just wipe /data again.
Click to expand...
Click to collapse
Is there any other partition I should back up? That is, aside from the internal storage, which I've already taken care of.

vladone97 said:
Is there any other partition I should back up? That is, aside from the internal storage, which I've already taken care of.
Click to expand...
Click to collapse
Not if you're flashing back to stock anyways. Sounds like something is borked anyways so restoring anything might cause problems (including data). I would just start over. It's just data. Apps can be re installed. Contacts re sync.
I would start fresh, make sure it boots, make a full backup, then try restoring only data. Remember that /data may contain some of your old magisk stuff that may have added to the problem. So do that at your own risk. What data could be worth all that hassle?
Try to think of it like, if that phone got smashed, and you got a free replacement tomorrow. You'd survive right? Even without that data?
And definitely don't try to flash a magisk version that old over one that new one again.

vladone97 said:
Is there any other partition I should back up? That is, aside from the internal storage, which I've already taken care of.
Click to expand...
Click to collapse
Good advice by @madbat99.
Personally I only ever keep TWRP backups of the devices I test stuff on. But then I do a full backup of the device to have an easy way to get back to the setup I want.
On my everyday device I only keep a backup of the internal storage and messages (Signal). It's so easy to restore apps and other stuff anyway, so I don't really bother...

Didgeridoohan said:
Good advice by @madbat99.
Personally I only ever keep TWRP backups of the devices I test stuff on. But then I do a full backup of the device to have an easy way to get back to the setup I want.
On my everyday device I only keep a backup of the internal storage and messages (Signal). It's so easy to restore apps and other stuff anyway, so I don't really bother...
Click to expand...
Click to collapse
I did all that, but Magisk 19.1 still doesn't work. Some older versions work though. I tried Magisk 18.0, 18.0, 19.0 and 19.1. Only 18.0 and 18.1 worked. So I'm assuming there's a problem with the newer versions of Magisk?

Question Root stock Android 13

I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
edit: I installed TWRP and booted into it with no problem. But when I then booted system, powered off and boot back to recovery, it was gone.

lewmur said:
I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
Click to expand...
Click to collapse
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.

V0latyle said:
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.
Click to expand...
Click to collapse
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.

lewmur said:
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.
Click to expand...
Click to collapse
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.

V0latyle said:
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.
Click to expand...
Click to collapse
What is +GSM?? Is that google services management?

lewmur said:
What is +GSM?? Is that google services management?
Click to expand...
Click to collapse
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps

V0latyle said:
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps
Click to expand...
Click to collapse
I'll give it a try a little later. Right now I'm bushed!! Thanks

lewmur said:
I'll give it a try a little later. Right now I'm bushed!! Thanks
Click to expand...
Click to collapse
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.

lewmur said:
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.
Click to expand...
Click to collapse
What file did you try to flash?
In most cases, you need to extract the system.img from the zip package. You can't flash the archive itself.