yashsingh1/xdaforums huggingface dataset:
[SuperSU] Riseofdead:
hmm i have the latest Android (MRA58V) but i need write access to the /system partition (Xposed Framework and AdAway). What version of super su do i need? Or can i activate write access to the /system partition with the latest version of super su?
[SuperSU] Lrs121:
You have to change the kernel flags yourself. The zip does not unpack the boot img and change them for you.
[SuperSU] c3k:
http://xdaforums.com/nexus-5x/development/kernel-stock-rootable-forceencrypt-t3258352
[SuperSU] Archer.Queen:
Why
[SuperSU] ashyx:
My thoughts exactly on your pointless post :confused:
[SuperSU] TheoKondak:
hm, i can't really understand how to choose an image, and i can't find information regarding which one i should use for my One Plus One. Something i missed?hmm
[SuperSU] ashyx:
You have to create your own.
[SuperSU] TheoKondak:
So i have to go to http://xdaforums.com/showthread.php?t=2073775 and follow the instructions there in order to create my own image, then flash this image, and then should be ok? Or i can use another Android device to edit the files needed there, and then copy them to my android 6 device?
[SuperSU] ashyx:
System or systemless?
[SuperSU] shoey63:
- Root your device on (older firmware if required)

- unpack your target boot.img

- patch sepolicy and modify fstab as per instructions.

- Make ramdisk changes (unpack one of Chainfire 's modified boot.img's for reference if systemless root is the objective)

- repack boot.img

- flash new system and boot.img

- Flash appropriate SuperSU.zip in recovery.

- Done
[SuperSU] TheoKondak:
Thank you very much. I will try to do that. Is there any complete guide that might help me with this procedure? All steps are deep black waters for me. I will work this out, but I guess it will take forever before I can make it work without a proper guide.
[SuperSU] ashyx:
SuperR kitchen can unpack, modify sepolicy and repack the boot.img for system root without the need for a reference device.
[SuperSU] burduli:
Just flashed v2.52 BETA on CM12.1 (with PRO) and work great
[SuperSU] lePoMo:
since it's not apparent from this post: this post is about selinux on Samsung devices.

That's great news I guess. I started from the assumption that it would need to be present in some way to even work.

Now the other question is, what does the updater do when that directory is gone/empty?

It could hang indefinitely and drain battery, it could do something nasty on purpose, it could just restore it, or it could fail gracefully and not do anything (ideally).

Assuming it would restore the files, then the question is how will it behave if it can't?

Under the assumption that it will give up and do nothing bad if it fails to write to spota, here's other options you can use or combine to deny it to write:

mount .. -o ro ..

really mount readonly. then even root won't write to it

mount -t tmpfs -o size=0 ..

limit the size to 0 or something so small it can't write everything to it. That way it will fail with a different error (disk full instead of permission denied), and may behave differently/better for your situation. (doubtful but ideas are cheap :p).

other approaches without mount and just leaving harmless files in place:

chattr +i sepolicy

set files immutable. I may be wrong, but afair immutability even applies to root. So it can be read but not changed. (unfortunately there's no chattr command in stock android, at least not on my nexus 5)

chown root spota && chmod 0000 spota

if the updater is not running as root, simply denying regular write permissions should suffice :p (maybe decide on whether read permissions should be kept)

and a last one, possibly interesting if samsung takes selinux seriously: turn selinux against it.

currently, in file_contexts, spota has the following selinux label:

/data/security/spota(/.*)? u:object_r:security_spota_file:s0

pick a different file label that you estimate the updater has no permission to, and use that instead of security_spota_file (and if i'm right, call restorecon /data/security/spota to make it apply. or reboot)

Granted I only threw this in there because it might work, but no idea on what to choose. maybe u:object_r:system_file:s0
[SuperSU] kato7youknow:
try this

Try pasting super user app in all 3 places. put it in data/app, system/app, priv/app

Did you try flashing with Odin or tarp? Too?
[SuperSU] ashyx:
Does the superuser app show in app manager?

Also note that superuser has several different icons available.

If you don't see the yellow one look for the green one.
[SuperSU] databoy2k:
There's a few of us having an issue over in the Samsung forums (see e.g. http://xdaforums.com/galaxy-s5/general/canadian-users-g900w8-discussion-t3228804/page14). There's a customized kernel for the G900W8 there that was working as late as Friday with SuperSu 2.52 Beta. For those of us who weren't keeping up with the forums, though, and allowed an automatic update of a security policy (not sure when it was pushed out), SuperSu 2.52 Beta now bootloops. The only solution seems to be a factory reset pre-security policy update and then to disable automatic updates.

Is there anything that I can do (file to provide, etc.) to help get SuperSu updated for the new policy?

--Databoy2k
[SuperSU] Pkt_Lnt:
Logcats are always helpful for most any failure.

[Tutorial] How to Logcat

http://xdaforums.com/showthread.php?p=28181474#post28181474
[SuperSU] databoy2k:
As stupid as it seems I didn't know that you could logcat a bootloop. I'll reinstall SuperSu tomorrow morning (won't be back to my home PC with ADB until then), bootloop and then try to pull the logcat from recovery.
[SuperSU] Nagato Yuki:
For unlocker bootloader units, the systemless root would be much better way.

I am just curious about systemless root how to due with temporary unroot situation, since everything need by rooting ( su bin and supersu related things ) moved to bootimage.

( if it could be temporary unroot for most time usage, it is much better without reboot form normal bootimage )
[SuperSU] ashyx:
You can't, but you may be able to dmesg, failing that last_kmsg if the kernel allows it.
[SuperSU] databoy2k:
I wasn't sure but I've learned not to argue too much with quickly-given advice on XDA. I'll see what I can pull; I'm also looking for a way to undo the security policy update as well, maybe by corrupting the files that it updated so that it disregards them... Happy to try things if anyone has other ideas beyond dmesg/last_kmsg or a live logcat while bootlooping. Ultimately we probably need to get the policy update to [MENTION=631273]Chainfire[/MENTION] for him to update SuperSu.
[SuperSU] Pkt_Lnt:
I've been able to get logcats that help devs up to the point of bootloop. Sometimes it helps, but always worth a try. :good:
[SuperSU] lePoMo:
is the following possibly related/helping?

and also my thoughts (only ideas) on that spota directory:

http://xdaforums.com/showpost.php?p=64064686&postcount=2988
[SuperSU] databoy2k:
That, my friend, appears to have done the trick. Much appreciation to you and a shiny Thanks as well. Deleted the folder in question using TWRP's file manager, rebooted to confirm that I could still boot, back to Recovery for a SuperSu flash, and now confirmed Root's working again.

I'll post the link over onto the thread where those of us also affected are whining about it.

--Databoy2k
[SuperSU] Chainfire:
So, I just came back from vacation, so I'm backed up on everything.

This security policy update issue is something I've been expecting for a long time, I've never actually seen it happen though. I'd like to fix it properly.

Does deleting that folder not trigger the update again at a later time?
[SuperSU] Phil3759:
That folder is by default empty. It is probably just a holder for security updates when they come

The update can be disabled by unchecking "Automatic Updates" under "Settings/Security policy updates"

Now, if it can be applied while keeping root, sure it would be nicer, unless those updates are only to counter root...

However, I don't see Samsung fighting custom kernel users while providing odin and unlocked bootloaders.
[SuperSU] Rongxin:
I used this with Cm13 Nexus 6 and I can't get out of boot loop now
[SuperSU] shaggyskunk:
a) Try a Factory Reset - b) Restore your Nandroid

Sent From My SM-N910W8 Running SlimRemix V5.3
[SuperSU] Rongxin:
You mean SuperSu doesn't work anymore?
[SuperSU] Pkt_Lnt:
If you read a little you will see it works fine for most people. Some changed to Marshmallow on certain devices is causing issues. Careful with those big blanket statements, ok?
[SuperSU] Rongxin:
I installed 2.56. Works fine now
[SuperSU] ashyx:
System or systemless root?
[SuperSU] Wyneg:
I installed system root and works fine ;)
[SuperSU] vt0r:
Here's a modified MRA58X boot image for systemless root, in case anyone wants it:

https://www.androidfilehost.com/?fid=24269982087008659

Boot.img was extracted directly from the boot partition of my MRA58X install right after patching/verification via OTA.
[SuperSU] Alxoom33:
Thanks!
[SuperSU] SofaSamuraiX:
Thanks!
[SuperSU] ashyx:
Hang on, so you're saying boot loop with v2.52, but OK with v2.56?
[SuperSU] Wyneg:
Hi!

I didn't get bootloop with those versions (Not systemless installation, only flashed in recovery).
[SuperSU] natemup:
I'm running stock with systemless on my Nexus 6 and as of tonight I'm getting a weird bootloop-esque issue where after a a minute or two of normal function on a new boot, everything locks up and it reboots. Repeats itself non-stop.
[SuperSU] Almighty1:
I know it'll work in /data/app but what I was saying is once /data/app has a SuperSU, there doesn't seem to be a way to get the one working in /system again meaning in both app and priv-app. Seems to be a Android 5.0 and later thing. I'm trying to get it working from /system. I couldn't flash with anything else other than Flashfire as my bootloader is still locked.

---------- Post added at 09:58 PM ---------- Previous post was at 09:54 PM ----------

Nope, that's the problem. It's not just SuperSU that does this. Basically, if the app exists only in /system/app or /system/priv-app as the original, it will show up in app manager. If there is a newer version and it's installed, it will install in /data while the one in /system is still there and the one in data is the one that works. However, I can't copy the one in data to replace the /system version after deleting the data apps folder and apk as it will not show up in app manager. I remember before Android 5.0, I used to be able to just copy apk's around but that was on Motorola devices and not LG. So it seems like whatever it is, once Android sees the apk in /data. it will never use the one in system again even if the one in data was completely removed.
[SuperSU] Chainfire:
The new automated kernel patcher for 6.0 firmwares (and 5.1.1 firmwares?) is almost ready. Hopefully a new release tomorrow.
[SuperSU] santadomingo:
We wait[emoji3] !! And thanks for your work!
[SuperSU] coldheater:
Hey guys, i'm trying the systemless root for my Nexus 6P running build MDB08L and I cant seem to get the root to work. I have it unlocked and installed the boot image for my phone and installed TWRP. I applied the SuperSU v2.56 inside the recovery, and did a reboot, but I still dont have root. I get an alert from SU on my notification pull down window, it says, Tap to install SuperSU and root your device. I dont know if that means the update SU is trying to do a systemless or the regular root. Any help? Thanks in advance.
[SuperSU] Ch3vr0n:
You mean the CFAR's? Would I be out of line as to ask how far along you'd be in the rooting process for M with just the flashable zip file? The only reason I've been holding off on updating my nexus 5/7v2 is the modified boot image.

Verstuurd vanaf mijn Nexus 7 met Tapatalk
[SuperSU] ashyx:
Chainfire can I ask as to the reason why systemless root is currently only available for Android 6.0 roms or do you have any plans to make it possible for Android 5.0+? Thanks.
[SuperSU] prot-:
Can this be implemented on the LG g4??
[SuperSU] timeToy:
Systemless kernel request for the Moto X Style US XT1575

I do have a fresh copy of the XT1575 Marshmallow US kernel from my original TWRP backup (before the first boot)

Can somone make Systemless Root kernel? Thanks a lot!
[SuperSU] 89titanium:
I have never rooted before, but from the research I have done, it is TWRP offering to install SuperSU+root, which you should decline. If you have SuperSU 2.56, make sure you are using the systemless version of the MDB08L boot image, because there are two.
[SuperSU] djmonty9000:
Will this root my device?
[SuperSU] Chainfire:
CFAR is these days just an automated installer for the flashable ZIP file.

Both will be updated as soon as I have something working nicely.

Note that for 6.0, the ZIP will modify the boot image for you, but it will still be modified.

I'm probably going to backport it to 5.1/Samsung, but not sure about other firmwares. Note that system-less root is incompatible with locked bootloader devices, that's why I only activate it (by default) when needed, to prevent millions of locked users losing root. First priority is getting the 6.0 devices working nicely, after that we'll see.

I do not have a G4 at this time, and I know virtually nothing about it, so somebody else will have to report back about that.
[SuperSU] smitharro:
It's all so vague nowadays with CM13/Android6. No more simple .zip anymore to root my phone or at least use SuperSU. I can now only use CM's built-in root since SuperSU zips either don't work or give a bootloop. There's no kernel for my device to use SuperSU I'm afraid. Hope that in the future there will be a 'global' SuperSU again!

Written with my XT1068 using Tapatalk on CM13
[SuperSU] shaggyskunk:
No!

Take some time to read up on Rooting - Nandroids - Flashing - Custom Recovery etc.

Sent From My SM-N910W8 Running SlimRemix V5.3
[SuperSU] Ch3vr0n:
Although i appreciate your answer, it doesn't really answer the questions. Wasn't asking about what a CFAR was. Since i've gotten nexus devices and a bit more comfortable with flashing, i just place the latest flashable zip on the device, adb boot twrp (never flash it as custom recovery) and flash the zip to root. for L, this doesn't modify the boot image which is what the question was.

How far along the progress line you were to achieve that same thing with M, non-modified boot image. Just flash the zip & done. Or will you shift focus now to systemless root (wich would kill the ability to use adblock etc)...

The last time i used a beta zip it didn't turn out too well and i had to do a factory image flash + CFAR.
[SuperSU] coldheater:
I used the systemless version, its called bullhead-mdb08i-boot-systemless
[SuperSU] 89titanium:
Bullhead is the Nexus 5X. The Nexus 6P is Angler.
[SuperSU] tetakpatak:
If you have flashed SuperSU as zip in custom recovery and root still isn't working, most likely it has to do with outdated busybox. Try Busybox X app (from Play Store) short ago it was the only busybox installer that seems to can handle Android L :D

tetakpatalked from P5110
[SuperSU] dave99:
Uninstalled busybox, installed busybox x, tried flash supersu 2.14 in twrp, still no go.
[SuperSU] tetakpatak:
Just a question: Busybox X is just an installer, not the busybox itself, did you use it to install busybox?

I will try on the latest Lollipop test build. On the previous build LPV79 SuperSU has worked perfectly fine in combination with Busybox X

tetakpatalked from Nexus 7 flo
[SuperSU] Ben36:
Right for Android 5.0 test release you need this modified boot.img - https://www.androidfilehost.com/?fid=95747613655047203

And supersu 2.14
[SuperSU] Smultie:
Does that also work on the Nexus 7?
[SuperSU] Ben36:
Unsure on that. You're better off asking syko on his thread - http://xdaforums.com/showthread.php?p=56109156
[SuperSU] tetakpatak:
OK, I confirm this. Neither SuperSU v2.14 nor few earlier versions (since v2.01) have worked on Nexus 7 flo on the last "L" test version LPX13D. There was "SU binary cannot get installed, this is a problem" error on the stock kernel.

I went bit further with testing:

With Glitch kernel r226 installing binaries of SuperSU-v2.14 has worked and prompt for Superuser access was displayed, but after granting it, root still didn't work. There was displayed on the bottom of the screen afterwards that root apps have been granted access for an interactive shell, but nothing happened.

I am sure [MENTION=631273]Chainfire[/MENTION] is working on this already, I have added two logcats:

logcat.zip: SuperSU app freezes and causes reboot by clicking on back button

logcat2.zip: granting su permissions to several root apps (without effect)
[SuperSU] dave99:
I was able to get 2.14 to work fine by using the mod boot img from syko on my N7. There is a link in the N7 forum to it, not sure if it's the same as the N5, as I haven't updated my N5 yet.
[SuperSU] Ben36:
https://plus.google.com/app/basic/stream/z13lifpjyviffdby504cjl1aoor5ezninhc

Sent from my Android 5.0 Nexus 5
[SuperSU] tetakpatak:
OK, that is exactly what I've expected.

I'm back to my KK rom already, I've flashed "L" just to test, but I don't want to upgrade to Lollipop

tetakpatalked from Nexus 7 flo
[SuperSU] phileasx:
Thanks, the manual grant method worked for me.
[SuperSU] royalh:
Temporarily works for me... for some reason or another, the permission disappears from SuperSU and I have to redo the manual method.

Turning off the tapjacking setting doesn't solve the issue for me, nor does killing lux.

Ditto Note3 v5

Edit: others reporting same issue about previously granted apps disappearing from SuperSU in stable thread.

Edit 2: in response to CF in other thread - only the android process 1000 disappears, and that's obviously not installed to SD card.
[SuperSU] Chainfire:
v2.15 BETA released

You can find the v2.15 BETA release here: http://download.chainfire.eu/587/SuperSU/BETA-SuperSU-v2.15.zip

Flashable ZIP, if you want the APK, it's in there in the common folder. It is strongly advised to flash the zip, as using the APK method will not fix an already broken install!

This beta is focussed only the binary update issues:

- Binary update failing

- Binary update succeeding but asking again

- Binary update never completing

- Endless loading spinner in apps and logs tab (also related to binary update failure, though it doesn't show it)

Please test ASAP and report back if it solved your issue or not. Note that I consider the above issues solved until you report them again! So if you test this version and the issue is still present, say so, and explain again what the problem is, or if the problem remains the same, post a link to your previous report.
[SuperSU] Chainfire:
See the post above this one ( http://xdaforums.com/showpost.php?p=56226364&postcount=293 )... sorry XDA's mention system is terrible.

[MENTION=5460432]BoneWithABeagle[/MENTION] [MENTION=5363290]ccgx[/MENTION] [MENTION=6103196]BIG-MOEP[/MENTION] [MENTION=5975974]amardeep434[/MENTION] [MENTION=3288658]SirVss[/MENTION] [MENTION=3157729]p220fhf[/MENTION] [MENTION=6098826]Rubex74[/MENTION] [MENTION=336749]vadim-zh[/MENTION] [MENTION=5396088]power2top[/MENTION] [MENTION=2774605]shadow322[/MENTION] [MENTION=3352400]netfortius[/MENTION] [MENTION=5401012]Celestial Fury[/MENTION] [MENTION=4375132]Dr Goodvibes[/MENTION] [MENTION=4587767]egingell[/MENTION] [MENTION=4959412]gokunjp[/MENTION]
[SuperSU] JaCh0o:
I can confirm that SuperSU 2.15 Beta is not working on stock ColorOS 2.0.0I build 1017 on Oppo Find 7.

Binaries are not updating properly, no su file under system/bin/.

Wysłane z mojego Oppo Find 7 przy użyciu Taptalka
[SuperSU] Blac Caesar:
[MENTION=631273]Chainfire[/MENTION] .. Beta v2.15 working for me; Pro recognized as well. Nexus 5, LPX13D, Elemental X v2.00
[SuperSU] Chainfire:
^^^^ fixed in next release
[SuperSU] Chainfire:
There is never a su file under /system/bin. Is that the only issue? Details.
[SuperSU] vadim-zh:
Still absent binary file after install, unfortunately.

Thanks.
[SuperSU] Frank Westlake:
Debug help

DEBUG HELP

The attachment (debug.zip) might help Chainfire debug some of these issues if SuperSU is failing to install completely. After flashing SuperSU in Recovery immediately flash debug.zip. If there are problems with SuperSU then send the resulting debug file to Chainfire. 'debug.zip' collects copies of the files Chainfire requested and stores them in a zip archive in the same directory that you flashed 'debug.zip' from. The filename will be 'debug-[model]-[android version]-[timestamp].zip'. Example: 'debug-SM-900T-4.3-20141023T1309.zip'.

This works on my Note, Note3V, and Note3T, but it probably won't work on everything.

I'm still working on this debugging tool and I should have a Linux/Windows/Android script by Monday that will do the same thing through 'adb'.

For Chainfire, a trimmed down version of your install script is also included so that you can see the resulting environment of the install script. So you can see, for example, if someone says the device is Android 4.3 but the sdk is resulting to 20. That result is reported in the 'su-env' file.

Frank
[SuperSU] SamuriHL:
It works on 5.x versions. I made one for the S4 GPE and it works just fine. :)
[SuperSU] coldheater:
I also tried Angler and now it says the same, I get a message from SuperSU in my notification window that says , Super SU installer, tap to install SuperSU and root your device. I dont know if that is the systemless root or the regular.
[SuperSU] ashyx:
I'm talking about systemless root. It needs api 23.

5.x is api 21-22.
[SuperSU] vt0r:
But that's just an artificial requirement. If you've modified the boot image properly for some older version of Android, you can edit the updater-script from the SuperSU zip and remove the API check. It was created as an experiment specifically geared towards 6.0, so that was the easiest way to prevent issues for users of older releases.
[SuperSU] Lrs121:
Have you gotten it to work? I keep getting a request to update the subinary from the the SuperSU app which reverts to the old method. The Shield Tablet is the device.
[SuperSU] vt0r:
Nope. I don't have any devices running 5.X at the moment to test with.

Are you sure all the required ramdisk changes were made properly in your boot image? The PATH environment variable appears correct in the terminal as well (has /su/bin in it)?

If so, have you verified the su.img file exists in /data and is mounted as expected on boot?

And did you also flash the 2.56 zip (minus the API check)?
[SuperSU] arif_bmc:
bootloop and corrupt

hi,

i have flashed CM13 for my redmi 1s on this thread http://xdaforums.com/redmi-1s/development/rom-cyanogenmod-13-0-t3245327

and flash the supersu.zip, it works.

but then i have new build for this cm13 from different developer shared on facebook (unfortunatelly the dev not make the thread yet).

i have clean instal this rom and flashed supersu beta v2.52 link given on above thread, and got bootloop. i have make sure that this supersu that causing the bootloop.

and then i try to clean install the rom again, trying to install supersu from PS.

it's installed but when need to update binary on twrp, it say /cache/recovery/update.zip corrupt.

is this bugs from the supersu or just the rom that not stable yet?

:confused:
[SuperSU] Lrs121:
I did all of the above except I changes the api check to match that of what the tablet supports which is api 22
[SuperSU] ashyx:
If you read quite a few posts back I already tried this and it didn't work.

I already hex edited the updater binary in the supersu zip and that DOES enable systemless install. Along with the correct ramdisk changes.

Everthing installs correctly all required files are present in /su but no root.

Exact same ramdisk mods work fine on 6.0

If you can get it to work on a stock Samsung 5.0.2 rom then I'd be happy if you'd share how.
[SuperSU] swieder711:
I am on SuperSU Pro 2.49 with stock rooted 5.1.1 along with TWRP 2.8.7.1.

Trying to get my X1575 phone ready for MM. Thought it would be a good idea to upgrade SU to 2.52 Beta. Tried to install zip via TWRP, but it did not take. Did I miss a step? Is 2.52 compatible with my rooted Lollipop ROM or do I need to wait until MM is installed and than install SuperSU 2.52?