It's about time I finally do this. I have 1 question though.
I'm currently on SU2.52, 6.0.0 and I'm updating to SU 2.66 6.0.1. Chainfire mentions that with the newer systemless root we can install it as traditional root instead. I'm just not clear on how and what to do with what he says below...
His full instructions are:
"Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Click to expand...
Click to collapse
1.) Can someone rephrase what he said and make it sound a little simpler?
2.) Do I do both of these or one? (I'm flashing 2.66).
echo FSTABSYSTEMRW=true>>/data/.supersu or echo BINDSYSTEMXBIN=false>>/data/.supersu do both or 1?
3.) Should I override this with 6P? "The (2.64+) zip installer will try to detect a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu")."
I have a ton of apps that rely on root so I want to go with the best method that will give me the least compatibility problems. I don't care for android Pay.
Bump please
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
---------- Post added at 06:02 PM ---------- Previous post was at 06:01 PM ----------
toknitup420 said:
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
If you want traditional root flash a modified boot.img that will allow traditional root to work. Then flash SuperSU 2.66 and it will automatically install as traditional root.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
---------- Post added at 06:02 PM ---------- Previous post was at 06:01 PM ----------
If you want traditional root flash a modified boot.img that will allow traditional root to work. Then flash SuperSU 2.66 and it will automatically install as traditional root.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Basically I'm trying to decipher what he is saying in his notes I've quoted. There are 3 things he mentions that I could do if I wanted to and I'm asking what those 3 things are (question 2&3 in my op).
I shouldn't need a modified boot for 2.66 and would prefer not to.
JustRootDontCustomRomIt said:
Basically I'm trying to decipher what he is saying in his notes I've quoted. There are 3 things he mentions that I could do if I wanted to and I'm asking what those 3 things are (question 2&3 in my op).
I shouldn't need a modified boot for 2.66 and would prefer not to.
Click to expand...
Click to collapse
You don't need one if you're using systemless root. If you want traditional root then you need modified boot.img or custom kernel.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
You don't need one if you're using systemless root. If you want traditional root then you need modified boot.img or custom kernel.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
See the part where he mentions the kernel(boot) se policy, this is what you have to modify for root. So yes. It does require a modified boot to install to system. Which is exactly what is explained in the last 2 paragraphs of that quote. However you can override that and force a systemless install if you desire. See the echo command at the end of the 2nd to last paragraph in quote.
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
See the part where he mentions the kernel(boot) se policy, this is what you have to modify for root. So yes. It does require a modified boot to install to system. Which is exactly what is explained in the last 2 paragraphs of that quote. However you can override that and force a systemless install if you desire. See the echo command at the end of the 2nd to last paragraph in quote.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Not saying you're wrong here because I actually don't know but it isn't what I've been reading throughout the forum. Hoping to get a second opinion on this.
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
You definitely need a modified boot.img for none systemless root that includes a few system checks removed and a sepolicy. I do this myself on every factry imgs because I will never use systemless root is stupid and pointless...So he was dead right for root on 2.66 you need modified boot.img
Tigerstown said:
You definitely need a modified boot.img for none systemless root that includes a few system checks removed and a sepolicy. I do this myself on every factry imgs because I will never use systemless root is stupid and pointless...So he was dead right for root on 2.66 you need modified boot.img
Click to expand...
Click to collapse
Ok. That's a bummer I guess.
Still confusing though because it's the first I hear about this. I could of swore I read that chainfire said the systemless versions will automatically patch boot.. I think I probably misread.
I'm going to sleep right now but could you help me get started? Anything to get me on the right start is appreciated. I know I'll need a modified boot img that works for 6.0.1. you're on 6p right? Because systemless sounds pretty good for me atm. Sounds simpler. It supposedly the same thing as traditional except a very few apps that I hear have compatibility issues. Nothing that can't be fixed with a symlink I believe.
I'm still weighing everything in.
JustRootDontCustomRomIt said:
Ok. That's a bummer I guess.
Still confusing though because it's the first I hear about this. I could of swore I read that chainfire said the systemless versions will automatically patch boot.. I think I probably misread.
I'm going to sleep right now but could you help me get started? Anything to get me on the right start is appreciated. I know I'll need a modified boot img that works for 6.0.1. you're on 6p right? Because systemless sounds pretty good for me atm. Sounds simpler. It supposedly the same thing as traditional except a very few apps that I hear have compatibility issues. Nothing that can't be fixed with a symlink I believe.
I'm still weighing everything in.
Click to expand...
Click to collapse
if you like I can share my modified boot.img I did myself and yes I can help you just PM me. It will only take a few mins. You have working fastboot setup already? It's not the same I don't have time to explain right now tho. If you want help PM me when your ready
Tigerstown said:
if you like I can share my modified boot.img I did myself and yes I can help you just PM me. It will only take a few mins. You have working fastboot setup already? It's not the same I don't have time to explain right now tho. If you want help PM me when your ready
Click to expand...
Click to collapse
Pm you. I have fastboot ready.
JustRootDontCustomRomIt said:
Pm you. I have fastboot ready.
Click to expand...
Click to collapse
I didn't get a Pm. But I'm eating right this minute first you need to flash factory imgs for 6.0.1 via fastboot. Have you don't that before?
Related
I just received a notification on my 6P saying that the january security update is available. The thing is that I'm rooted with systemless root, xposed, EX Kernel and TWRP. Can I update using the update button?
With systemless I believe you should be able to.
I just posted about this too....no one got back to me. I got the same message and have more or less the same setup as you. I'm scared to reboot and update lol
Pain-N-Panic said:
I just posted about this too....no one got back to me. I got the same message and have more or less the same setup as you. I'm scared to reboot and update lol
Click to expand...
Click to collapse
No.
If you have TWRP installed you will not be able to take an OTA.
Why bother?
Just flash what you want.
Ok, so if I reboot and my phone tries to install the OTA, what happens?
I have exact the same setup and tried to let the OTA install but in TWRP it aborted because of the mismatching kernel I think (at least it said it expected the generic device name Google angler etc and in stead it found Huawei nexus 6P Dees-troy etc)
So no harm is done when you try to update other than it doesn't work
But as far as I know when using xposed there's no use for systemless root because xposed is changing system partition
This update message won't go away. Can I flash it myself through TWRP with Xposed installed?
You cannot use twrp with an OTA. You need stock recovery. Also I believe that Xposed modifies /system and that in itself would prevent the OTA with stock recovery.
dratsablive said:
You cannot use twrp with an OTA. You need stock recovery. Also I believe that Xposed modifies /system and that in itself would prevent the OTA with stock recovery.
Click to expand...
Click to collapse
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
I used step 10 from this guide then re-flashed TWRP, Super Su, ElementalX and everything seems to be fine, no data loss.
Pain-N-Panic said:
Ok, so if I reboot and my phone tries to install the OTA, what happens?
Click to expand...
Click to collapse
Nothing happens. it'll just fail to flash the update. It'll reboot to twrp, attempt to flash the update, and it'll fail the flash. So it just won't flash. Then you'll just reboot the system and nothing will be changed. I think you can flash these minor changes, but if you try to flash a major update through OTA it won't work with out stock recovery because that's part of the flash I think
---------- Post added at 03:40 PM ---------- Previous post was at 03:38 PM ----------
regenwurm16 said:
I have exact the same setup and tried to let the OTA install but in TWRP it aborted because of the mismatching kernel I think (at least it said it expected the generic device name Google angler etc and in stead it found Huawei nexus 6P Dees-troy etc)
So no harm is done when you try to update other than it doesn't work
But as far as I know when using xposed there's no use for systemless root because xposed is changing system partition
Click to expand...
Click to collapse
It does not bored because of mismatched kernel. Because I tried flashing the stock kernel and then OTA and it still did not work
kirkgbolton said:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
I used step 10 from this guide then re-flashed TWRP, Super Su, ElementalX and everything seems to be fine, no data loss.
Click to expand...
Click to collapse
This. At this time it's the only fix. I did it as well. Never flashed a factory image via fastboot before so I was a little intimidated but Heisenberg's guide is so smooth and easy to follow I did it in about 5 minutes lol. Plus it was a great learning experience for me.
Is it likely that eventually TWRP flashable zips will make this process easier? Or is there some sort of restriction with these updates for Nexus phones that will always require fastboot?
Not sure. I do know that the above method only took me about 10 minutes. Yeah it sucks you have to utilize a PC to do it but its really not that bad. Maybe in the future someone will figure out how to implement the updates via flashable zip in recovery.
I struggle with this too. I really hope that someone will find a solution to flash it via .zip (sadly I'm more a programmer than an Android-hacker, otherwise I would try my very best right now ).
Just to point it out, it looks like the article you are referring to has been updated since it was linked. I wouldn't want to wipe userdata, so I think 11. How To Flash The Factory Images (Return To Stock But Leaving Internal Storage Intact) is what you were referring to at the time. Apologies for the resurrection.
I just used the FlashFire app to update my Nexus 6p with the February update and it worked like a charm.
http://nexus5.wonderhowto.com/how-t...thout-losing-root-no-computer-needed-0168428/
So a lot of guide i have seen to root the 6P require a custom boot image which i assume has to do with encryption
but more recently ive seen ways of doing it without installing a custom image where SuperSU patches the boot image for you
so my question is if i install SuperSU (the newer ones that patch the boot image) can i install xposed and other zip's like viper4android as is, or would i still need to install a custom boot image to do that
basically im trying to figure out if hte SU patch patches only for SU or all flashable zip's
thanks a lot, Blisside
blisside said:
So a lot of guide i have seen to root the 6P require a custom boot image which i assume has to do with encryption
but more recently ive seen ways of doing it without installing a custom image where SuperSU patches the boot image for you
so my question is if i install SuperSU (the newer ones that patch the boot image) can i install xposed and other zip's like viper4android as is, or would i still need to install a custom boot image to do that
basically im trying to figure out if hte SU patch patches only for SU or all flashable zip's
thanks a lot, Blisside
Click to expand...
Click to collapse
If you just flash super su zip you will only get systemless root. And it isn't as good as regular root. So for regular root you still need a modified boot image
Sent from my Nexus 6P using XDA Labs
sjandroiddeveloper said:
If you just flash super su zip you will only get systemless root. And it isn't as good as regular root. So for regular root you still need a modified boot image
Sent from my Nexus 6P using XDA Labs
Click to expand...
Click to collapse
so if i were to flash this custom image how would i update the OS if i were to say stock, like if i wanted to adb the update over would i need a download a new image or can i stay on an old boot image and install new updates
blisside said:
so if i were to flash this custom image how would i update the OS if i were to say stock, like if i wanted to adb the update over would i need a download a new image or can i stay on an old boot image and install new updates
Click to expand...
Click to collapse
You need a new boot image for a new OS build
And you can't apply OTA if you have tinkered with system partition , so you gotta either us fastboot or use the app flashfire
Sent from my Nexus 6P using XDA Labs
sjandroiddeveloper said:
You need a new boot image for a new OS build
And you can't apply OTA if you have tinkered with system partition , so you gotta either us fastboot or use the app flashfire
Sent from my Nexus 6P using XDA Labs
Click to expand...
Click to collapse
Ok so now i ask you my last question (sorry LOL) so if i use flashfire or fastboot all I would need to do is install the tmg or tmz or whatever it is from the google site install the main components of it but instead of installing the provided boot image i should install a custom one?
when im updating
blisside said:
Ok so now i ask you my last question (sorry LOL) so if i use flashfire or fastboot all I would need to do is install the tmg or tmz or whatever it is from the google site install the main components of it but instead of installing the provided boot image i should install a custom one?
when im updating
Click to expand...
Click to collapse
Yup
Sent from my Nexus 6P using XDA Labs
blisside said:
So a lot of guide i have seen to root the 6P require a custom boot image which i assume has to do with encryption
but more recently ive seen ways of doing it without installing a custom image where SuperSU patches the boot image for you
so my question is if i install SuperSU (the newer ones that patch the boot image) can i install xposed and other zip's like viper4android as is, or would i still need to install a custom boot image to do that
basically im trying to figure out if hte SU patch patches only for SU or all flashable zip's
thanks a lot, Blisside
Click to expand...
Click to collapse
You don't need a modified boot.img, all you need to do is flash the latest beta SuperSU. I'm not sure why the other member here is telling you that systemless root isn't as good as traditional root, that's false, they achieve the exact same result. I have instructions in my guide here:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Heisenberg said:
You don't need a modified boot.img, all you need to do is flash the latest beta SuperSU. I'm not sure why the other member here is telling you that systemless root isn't as good as traditional root, that's false, they achieve the exact same result. I have instructions in my guide here:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Click to expand...
Click to collapse
Well you can't change anything in the system partition with systemless root, right? ( pls correct me if I am wrong)
Sent from my Nexus 6P using XDA Labs
sjandroiddeveloper said:
Well you can't change anything in the system partition with systemless root, right? ( pls correct me if I am wrong)
Sent from my Nexus 6P using XDA Labs
Click to expand...
Click to collapse
Yes you can, system-less works the same as traditional root.
Sent from my Nexus 6P using Tapatalk
bouchigo said:
Yes you can, system-less works the same as traditional root.
Click to expand...
Click to collapse
Well sorry for providing the wrong info then
When I flashed superSU on stock ROM , although I got root access but I wasn't able to delete any system app ( even the SuperSU app itself said that it can't be installed as system app as systemless root doesn't support it)
Sent from my Nexus 6P using XDA Labs
sjandroiddeveloper said:
Well you can't change anything in the system partition with systemless root, right? ( pls correct me if I am wrong)
Sent from my Nexus 6P using XDA Labs
Click to expand...
Click to collapse
Yeah you can, it does everything that traditional root can do. I've never had any issues with it performing any tasks.
Has anyone had any issues trying to flash the latest supersu beta on 7.1.1? I get an abort message whenever I flash
Guitarboarder28 said:
Has anyone had any issues trying to flash the latest supersu beta on 7.1.1? I get an abort message whenever I flash
Click to expand...
Click to collapse
Chainfire has stated before that root with SuperSU on 7.1 may be a while, that he's working on it but a lot has changed (at least I read this all from him on a Pixel related thread...I assume much of it holds true for 7.1 in general).
ohlin5 said:
Chainfire has stated before that root with SuperSU on 7.1 may be a while, that he's working on it but a lot has changed (at least I read this all from him on a Pixel related thread...I assume much of it holds true for 7.1 in general).
Click to expand...
Click to collapse
Oh thanks. I've seen others talk about rooting on 7.1 no problem. I'll have to do more digging I guess
I rooted the 7.1 DP 1 With supersu SR1-v2.78.
No issues at all (even A.R.I.S.E. worked after deleting audio_effects.conf)
Mgrev said:
I rooted the 7.1 DP 1 With supersu SR1-v2.78.
No issues at all (even A.R.I.S.E. worked after deleting audio_effects.conf)
Click to expand...
Click to collapse
Did you root after flashing the ota or full image? I've been trying sr1 and for whatever reason after the ramdisk patch script it fails.
Guitarboarder28 said:
Did you root after flashing the ota or full image? I've been trying sr1 and for whatever reason after the ramdisk patch script it fails.
Click to expand...
Click to collapse
I used Fastboot and flashed every image manually (so that i wouldn't loose data). I used twrp 3.0.2-2 fyi. What about you?
Mgrev said:
I used Fastboot and flashed every image manually (so that i wouldn't loose data). I used twrp 3.0.2-2 fyi. What about you?
Click to expand...
Click to collapse
I was trying after flashing the ota. I even tried the full image without wiping (same version of twrp as you). Something must have just gotten messed up flashing the ota though. I gave up and did a full flash with wipe and sr1 flashed no problem. Thanks for trying to help me out though, I appreciate it
Edit: worded better. @Mgrev no hate was meant, thanks for trying to help me out!
Guitarboarder28 said:
you sound like you need a hug!
Oh thanks. I've seen others talk about rooting on 7.1 no problem. I'll have to do more digging I guess
Click to expand...
Click to collapse
Interesting...maybe he was exclusively referring to the new Pixel partition structure, etc...Not sure. Good luck
I was able to flash SuperSU R1 from TWRP and it worked, but when I added SUHIDE it hangs at boot animation. I flashed the factory image file by file, and not the OTA.
ohlin5 said:
Interesting...maybe he was exclusively referring to the new Pixel partition structure, etc...Not sure. Good luck
Click to expand...
Click to collapse
Yes that's my guess too I'm assuming he's talking about the pixel and it's new partitions
dratsablive said:
I was able to flash SuperSU R1 from TWRP and it worked, but when I added SUHIDE it hangs at boot animation. I flashed the factory image file by file, and not the OTA.
Click to expand...
Click to collapse
oh thanks for the heads up. Who knows if we'll ever see an updated suhide with safetynet checking the bootloader it may never be possible to pass safety net anymore
Guitarboarder28 said:
Yes that's my guess too I'm assuming he's talking about the pixel and it's new partitions
oh thanks for the heads up. Who knows if we'll ever see an updated suhide with safetynet checking the bootloader it may never be possible to pass safety net anymore
Click to expand...
Click to collapse
Well not worried about passing safetynet, since I can do without Android Pay, just want to hide root to play PoGo.
dratsablive said:
Well not worried about passing safetynet, since I can do without Android Pay, just want to hide root to play PoGo.
Click to expand...
Click to collapse
Oh is it no longer using safetynet? There's a new hide method with magisk V8 maybe that'll work
Guitarboarder28 said:
Oh is it no longer using safetynet? There's a new hide method with magisk V8 maybe that'll work
Click to expand...
Click to collapse
Well my bootloader is unlocked, but having suhide installed on the developer preview causes a boot hang. Will have to try the other method out. Thanks.
Guitarboarder28 said:
I was trying after flashing the ota. I even tried the full image without wiping (same version of twrp as you). Something must have just gotten messed up flashing the ota though. I gave up and did a full flash with wipe and sr1 flashed no problem. Thanks for trying to help me out though, I appreciate it
Edit: worded better. @Mgrev no hate was meant, thanks for trying to help me out!
Click to expand...
Click to collapse
I didn't think you meant to express hate either!
I seemed to forget to mention that i backed up my data with titanium backup, flashed, then wiped, and then restored it. So in the end, you probably need to wipe (just like you did)
dratsablive said:
Well my bootloader is unlocked, but having suhide installed on the developer preview causes a boot hang. Will have to try the other method out. Thanks.
Click to expand...
Click to collapse
Magisk hide just hides Magisk itself... it doesn't do anything for root. As for PoGo, right now the only way to do that on 7.1.1 is to NOT be rooted.
Once the kernel sources for the 7.1.1 are released, this patch will make its way onto custom kernels, which means you'll still be able to edit /system while rooted, unroot, and keep the changes via the patched kernel, as well as bypassing the SafetyNet bootloader check.
A kernel does exist now with that patch (francokernel), but it is based on the 7.0 kernel sources, so some things are broken if used on 7.1.1.
In re: to the superSU ramdisk install failure, this will happen if there are old files left over in /data from a previous magisk install and/or patched boot images. The SuperSU installer script will detect those and step into code branches that it doesn't need to be in, and thus fail. The solution is deleting the offending files from TWRP w/ adb, and installing SuperSU zip again.
/thread
Thread cleaned a bit, please stay on topic.
Have a good day!
Forum moderator,
Matt
Works fine for me flashed 7.1.1 OTA then flashed SuperSU zip
I'm a little lost on the differences between the shield and every other android phone I've owned. What difference does the developer image offer compared to simply unlocking the bootloader and installing magisk through TWRP on the shipped firmware?
Ultimately I want to root for all the obvious reasons, but also use magisk hide to keep PSVue and the like still working with root undetected. It seems that the developer image is pre-rooted, can that be hidden?
Thanks for any clarification
tstack77 said:
I'm a little lost on the differences between the shield and every other android phone I've owned. What difference does the developer image offer compared to simply unlocking the bootloader and installing magisk through TWRP on the shipped firmware?
Ultimately I want to root for all the obvious reasons, but also use magisk hide to keep PSVue and the like still working with root undetected. It seems that the developer image is pre-rooted, can that be hidden?
Thanks for any clarification
Click to expand...
Click to collapse
No it is not, as long as your bootloader is unlocked and you follow the directions on the thread how to install Magisk you will achieve root
jionny said:
No it is not, as long as your bootloader is unlocked and you follow the directions on the thread how to install Magisk you will achieve root
Click to expand...
Click to collapse
You don't get true root with the ota firmware though.
You won't have write access to the root dir.
Which you will if you use the developer image through adb, or by disabling dm-verity.
You won't be able to do that on the ota.
mLgz0rn said:
You don't get true root with the ota firmware though.
You won't have write access to the root dir.
Which you will if you use the developer image through adb, or by disabling dm-verity.
You won't be able to do that on the ota.
Click to expand...
Click to collapse
So on non dev if I disable dm verity with magisk, I can write to system.
Or is it not that simple.
Sent from my SM-G965F using XDA-Developers Legacy app
Largewoodenspoon said:
So on non dev if I disable dm verity with magisk, I can write to system.
Or is it not that simple.
Sent from my SM-G965F using XDA-Developers Legacy app
Click to expand...
Click to collapse
No you won't be able to get write access on the non dev.
mLgz0rn said:
No you won't be able to get write access on the non dev.
Click to expand...
Click to collapse
I was referring to the Pro version
jionny said:
I was referring to the Pro version
Click to expand...
Click to collapse
Does not matter if it's the pro version or not.
You can only get write access to the root dir using the developer image.
mLgz0rn said:
Does not matter if it's the pro version or not.
You can only get write access to the root dir using the developer image.
Click to expand...
Click to collapse
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
On what firmware version?
I doubt you can write to the /system and /data dir if you are on 7.2+.
---------- Post added at 14:37 ---------- Previous post was at 14:31 ----------
Roamin64 said:
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
Click to expand...
Click to collapse
Which image was that?
You can't get write access on the ota that comes with the updater on the shield without modifying the kernel and build.prop.
Hence why they are making a developer image that is prerooted.
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
mLgz0rn said:
On what firmware version?
I doubt you can write to the /system and /data dir if you are on 7.2+.
---------- Post added at 14:37 ---------- Previous post was at 14:31 ----------
Which image was that?
You can't get write access on the ota that comes with the updater on the shield without modifying the kernel and build.prop.
Hence why they are making a developer image that is prerooted.
Click to expand...
Click to collapse
It was the boot.img posted by ACiDxCHRiST in that post : https://forum.xda-developers.com/showpost.php?p=78496132&postcount=163
He has since taken down the boot.img file, but I had saved it in my pc when he posted it. I never flashed it , because I didn't want to brick anything. That is why I had only "fastboot boot boot.img" . Worked fine on 7.2.1 , and then again worked fine on 7.2.2. I haven't tried to root 7.2.3 yet. If you need that exact file to test , I can provide it to you in a few hours when I get back home.
Roamin64 said:
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
Click to expand...
Click to collapse
Exactly and I also use x-plore
Roamin64 said:
It was the boot.img posted by ACiDxCHRiST in that post : https://forum.xda-developers.com/showpost.php?p=78496132&postcount=163
He has since taken down the boot.img file, but I had saved it in my pc when he posted it. I never flashed it , because I didn't want to brick anything. That is why I had only "fastboot boot boot.img" . Worked fine on 7.2.1 , and then again worked fine on 7.2.2. I haven't tried to root 7.2.3 yet. If you need that exact file to test , I can provide it to you in a few hours when I get back home.
Click to expand...
Click to collapse
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
mLgz0rn said:
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
Click to expand...
Click to collapse
That boot.img was patched , most probably by magisk itself. Anyways, sent you the link via PM.
mLgz0rn said:
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
Click to expand...
Click to collapse
magisk makes the modifications,, you patch the boot img with magisk then transfer it to your pc then abd fastboot flash boot patched_boot.img... really is that simple.. Has nothing to do with the developers image
Hi, just got around to rooting my Kindle. Currently using SuperSu, curious if anyone has used Magisk with this tablet? Any reason not to do so?.
Thanks in advance.
I've debated doing this as well, as I don't like having to default grant everything root access.
As far as I understand though, none of your root apps/su requests can modify the system partition, so I haven't tried it yet.
@diplomatic is this true for the bootless root method without dm-verity?
No, you can modify /system if there's no dm-verity, @Kctucka
diplomatic said:
No, you can modify /system if there's no dm-verity, @Kctucka
Click to expand...
Click to collapse
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Kctucka said:
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Click to expand...
Click to collapse
Thanks, guys!
SuperSU access workaround
Kctucka said:
I've debated doing this as well, as I don't like having to default grant everything root access.
.....
Click to expand...
Click to collapse
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Dan_firehd said:
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Click to expand...
Click to collapse
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Kctucka said:
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Click to expand...
Click to collapse
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Yeah will do! I'll probably try it tomorrow or the day after.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
So far, all of my root apps detect root, except for titanium backup. I've messed around with it for a bit but haven't been able to figure it out. I'm guessing it has something to do with the location of the su binaries.
Also of note, FlashFire did not work at first. I realized that this is because the timebomb method we used along with the older app version, was from before Magisk existed. I grabbed the latest version of FlashFire from apk mirror, and it started without issues. I haven't tested by flashing anything yet though.
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
All in all, this is a pretty solid root method, but obviously non ideal due to the locked bootloader.
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Kctucka said:
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
Click to expand...
Click to collapse
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into this after so long I feel like a n00b again.
koop1955 said:
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into thhis after so long I feel like a n00b again.
Click to expand...
Click to collapse
That option was all I did to remove SuperSu. Then I followed the instructions here:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
Didn't take long to get it working.
And the time change was to get the version of FlashFire working that was compatible with the version of SuperSu we could run. See this post for more info if you're curious:
https://forum.xda-developers.com/hd8-hd10/general/hd-10-2017-xposed-t3722252
But with this new method, the most recent version of FlashFire works, as it's compatible with Magisk. The older version of FlashFire I had is not.
Also, I'm a noob myself. That's why I tagged diplomatic again, to correct the dumb things I might have said
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
koop1955 said:
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
Click to expand...
Click to collapse
That's awesome! Would that pass signature verification? Or would it be through hacked fastboot?
Also, that'd make it much easier to set up the device after a softbrick. FlashFire would be good to flash backups right away.
Kctucka said:
.....
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
.....
Click to expand...
Click to collapse
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Dan_firehd said:
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Click to expand...
Click to collapse
My kernel tweaks were done with KA Mod Reborn, using the "apply on boot" setting:
https://forum.xda-developers.com/android/apps-games/approot4-0-ka-mod-reborn-v18-t3714105
I added 260 MB ZRAM with a swapiness of 10. You can also tweak low memory killer, laptop mode, and a whole bunch of other dials that I don't mess with as I don't fully understand what they do.
Kernel changes could also be done with a number of different apps that do similar things.
Unfortunately, the bootless root method doesn't give root on boot, so it and also most Magisk modules won't work. Can't think of a workaround currently.
Kctucka said:
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Click to expand...
Click to collapse
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
That's super beneficial then, you can swap back and forth easily depending on what you need.
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
How about just swapping the install-recovery.sh script for suboot.sh on devices that don't have dm-verity?
I think that's pretty much what SuperSU does as well.
That would give root much earlier during boot and not depend on the extra App.
Probably doesn't even need to run mtk-su each boot then either.
Yeah, that's on the right track, @k4y0z. What you can probably use is a modified SU_MINISCRIPT section of suboot.sh, at least as a starting point. That is the code that needs to be run as root. What should be changed is the path to the magiskinit & magisk binaries. Those could be placed somewhere on /system. You would only need mtk-su if selinux needs to be permissive. But I suspect it does for the 'magiskpolicy --live' call. (But then how does SuperSU handle it with enforcing?)