yashsingh1/xdaforums huggingface dataset:
[SuperSU] jockovonred:
Sounds like permission issue. Is another app being run?
[SuperSU] trawel:
I have apps like Toggle Data and Toggle Network and I've created tasker profiles to turn on/off mobile data and switch network type and when the problem happens, there is a problem that for example network does not turn off though it should or network type doesn't change, also when trying to open one of these apps, the app freezes the same as supersu app. Do you mean any specific type of app? I didn't have that problem on Lollipop with supersu 2.49 and I was using the same set of apps and same settings. I have also viper4android and in tasker I had to create a profile on boot to change SELinux so that viper4android worked fine but I guess this wouldn't cause such an issue, especially that it happens in completely random moments.
[SuperSU] Chainfire:
It's very confusing to read.

Please try to identify exactly when SuperSU (and whichever other app) start freezing. That may help.
[SuperSU] Daniella3:
Quick question to Chainfire, or anyone else with relevant knowledge about this (new SuperSu user here..) :

Assuming the SuperSU v2.52 beta version works for me, is there any downside to using it compared to the official release?

Taking aside the technical differences of applying it (flashing the boot image etc.). I'm referring mainly - but not only - to security aspects.

p.s.: using a Nexus 5 + created a Nandroid backup.

Thanks in advance for your time.
[SuperSU] trawel:
What do you mean when SuperSU start freezing? Honestly, it's difficult to say because as I said - there is no pattern for that - once it happened in the morning - I have a tasker profile which disables my mobile data from 9:30PM till 9AM, and I was using it during that time and when I turned off my display (so that mobile data would disable) and turned it on moment after, nothing happened. Then I tried to open SuperSU and it froze the same with Toggle Data 5.0, after a reboot everything was running fine.

I'm not saying it is SuperSU's fault I'd rather say, there might be some stupid thing that is causing it but I thought that maybe someone had similar problem or maybe there are some things that may cause SuperSU behave unexpectedly (like in my situation).

Edit:

It happened few minutes ago, I'm posting logcat - maybe you can find someting interesting (I don't understand logs too much): http://pastebin.com/nPkP8eRH
[SuperSU] chrysik:
I'm wating "razor-mra58u-boot.zip".

Or, Can I make it ? (How to make it ?)
[SuperSU] DespairFactor:
I am having issues with using the sepolicy from the N5X for the N6P, it boots, but we get tons of FCs on everything, I will have a tester give me a logcat if that assists in any way, unless I get the device before he can give a log.
[SuperSU] ittakary:
The same here... Windows Device Manager sees the device during the bootlogo and sees the ADB connection but my razor Nexus 7 2013 cannot finish the boot....

I rooted it with 2.46. Is this the problem? If I clean install (from fastboot) my device and root it with the 2.52 beta, will it be good?

Thank you :)
[SuperSU] Chainfire:
razor mra58u and angler kernels posted
[SuperSU] Elancastro:
RE

Thanks , I'll try:fingers-crossed:
[SuperSU] nunoleite46:
+1
[SuperSU] ittakary:
God bless you, sir! Instant boot.... I thought I was messing up something I reinstalled my N7 like 3 times...

Thank you!
[SuperSU] sefrcoko:
I followed chainfire's instructions and modified the stock 5.1.1 N910W8 note 4 COI4 kernel supolicy. Kernel works perfect on stock roms with supersu 2.52 but causes camera fc on any custom rom I tried (including my own build). I confirmed with another n910w8 dev who ran into the same problem as me. Has anyone run into this issue? Are there any special permissions I should set for the camera in my auto-updater script?

This is sort of off topic but I've spent two weeks trying different solutions and reaching out to rom and kernel devs with no success. Feel free to pm me if you can point me in the right direction, this is driving me crazy and it would be great if our variant had an enforcing stock kernel (for now every dev on the n910w8 is just including custom permissive kernels).
[SuperSU] karthikrr:
Chainfire's sepolicy patch for the P607T

[MENTION=336863]garyd9[/MENTION] [MENTION=631273]Chainfire[/MENTION]

I have been trying to do the same thing that gary succeeded in doing with the Note 5, on my P607T Note 10.1 Tablet.

Long story short, I used SuperSU Beta 2.52 on my Note 2 to patch the stock sepolicy file, as per Chainfire's suggestion, and then after many different failed attempts, finally created a boot.img with a new ramdisk and the stock kernel using Carliv's Kitchen. The P607T fstab had no mention of support_scfs, that gary found on the Note 5, so I did not touch anything else in the ramdisk.

With my first 7 failed attempts (none with Carliv's Kitchen), flashing with ODIN would be successful, BUT the device would immediately boot back into Download mode with an error "Unable to boot normal mode". This, most likely, was caused due to the tools I was using not creating the new boot.img with the right offsets/addresses and possibly other parameters. In all 7 cases, the new boot.img was smaller than the stock.img, while I expected it to be very marginally bigger (2kb bigger!).

Carliv's Kitchen finally generated a boot.img that looked the same size as the stock, so finally it seemed I was on the right track and could validate Chainfire's solution and have a method of rooting the 5.1.1 ROM on the P607T without resorting to a permissive kernel... ODIN failed this time with my device saying "Unsupport dev_type".

In every case, flashing the stock boot.img set my device back to working order. Googling "Unsupport dev_type" only led me to some random talk about locked bootloaders, but I know for a fact that the P607T does not have a locked bootloader.

Does all this make any sense to anybody on this thread? All I can think of is that Chainfire's cf-auto-root made changes to the recovery.img, NOT the boot.img. Maybe I need to have TWRP on the device BEFORE I flash the new boot.img? Edit 1: Yes, I am aware the sepolicy patch is not root, but only enables rooting. Edit 2: I couldn't resist, so I put twrp 2.8.7.0 (KK) on it (takes a while to load, but seems to work) and tried the boot.img again. Same thing, "unsupport dev_type" and a failed flash.

The last attempt gave me a scare when ODIN failed once more while flashing the stock boot.img. So, though I want to now try to put twrp on it first, so that stock recovery is not messing up the new boot.img, I am a bit too scared to do it without some expert counsel, lest I brick my device and hate myself for the rest of my life...

Any thoughts?
[SuperSU] garyd9:
First and foremost - there are no "experts" here. If you're afraid to brick your device and aren't willing to take the risk, stop now and restore your stock firmware. I'm not being sarcastic or mean... I'm very serious. Anytime you flash anything to your device, you risk a bad flash and in some cases that can render your device unusable.

That being said, I think the very first thing you should do is step back from trying to actually accomplish anything and instead you should try to reinvent the wheel.

What I mean by that is that you should do everything with much smaller steps.

0. Restore your device to have stock firmware (kernel and what people on XDA mistakenly refer to as ReadOnlyMemory.)

1. Get a stock boot image file and flash it separately (and boot it successfully.) That will validate your flashing mechanism.

2. Take that same stock boot image, unpack it to its component parts (kernel, ramdisk, and possibly dtb's) - and pack them back up and flash that (and boot) successfully. That will validate your tools and process for unpacking and repacking the boot image.

3. Repeat #2, but this time also un-archive and re-archive the ramdisk (without changing anything.)

4. Repeat #3, but make a very minor change to the ramdisk. Perhaps just add a text file in the root. (The idea being that after you flash it, you can see the file in the root fs and know that everything is working.)

Once you get to #4, then you can worry about changing sepolicy. (I know it's a painstaking process, but when you perform 50 steps at once and things break, you have no way to know which of the 50 steps is breaking.)

Take care

Gary
[SuperSU] karthikrr:
That is some excellent advice! I will do this tomorrow, and hopefully that should get me one step closer to figuring this out. Thanks!!!

As for the risk of bricking, yes, I am aware and willing to take that risk. BUT, lets just say, of all the different things that can cause bricking, I would rather not let impatience be one of them :) I have personally (and know others who have) gotten carried away with 'experimentation' and messed things up when a bit more due diligence and care could have absolutely avoided 'brick-dom'. As evidenced by your suggestion, I am glad I stopped when I did, because now I have a methodical means to start eliminating possibilities, rather than try random 'solutions' that I read about that no experienced person here would EVER recommend ... :)
[SuperSU] Chainfire:
For the experimentally inclined Nexus 5 Marshmallow user: http://xdaforums.com/showpost.php?p=63197935&postcount=2. Root without modifying /system.
[SuperSU] Tzfardaya:
Awesome advice.. . I need to do this too...

But.. Later... Too many other projects on the go of somewhat more importance (too me).. Namely getting my house lights working properly.
[SuperSU] osm0sis:
Very very cool. I'll mess around with it this weekend after I'm done my night shifts. :D
[SuperSU] Ch3vr0n:
[MENTION=631273]Chainfire[/MENTION] if you actually are able to pull off fully working stable root WITHOUT modifying the /system does that mean you MIGHT have opened the door into having root AND still being able to get OTA's?

Verstuurd vanaf mijn Nexus 7 met Tapatalk
[SuperSU] osm0sis:
Yup, all you'd need to do is reflash stock kernel to pass the boot partition EMMC check, or, we could automate restoring the previous stock kernel, flashing the OTA and then injecting the new stock kernel with root after flashing (à la AnyKernel2 or MultiROM). So many exciting possibilities there where custom recoveries are concerned. :)
[SuperSU] Chainfire:
Honestly it's not so different from using FlashFire to flash re-flash system, then OTA, then re-root. But it is easier, yes.
[SuperSU] Chainfire:
Root-without-system-modification boot images posted for all the Nexus devices in the WIP thread - http://xdaforums.com/showpost.php?p=63197935&postcount=2
[SuperSU] osm0sis:
I'm still hopeful you can get FlashFire to stop failing with "insufficient storage" on Nexus OTA flashing (where flashing the same zip works fine from stock recovery). Since the fingerprint matches the one the OTA wants (as it's basically the booted ROM) it'd avoid the need to reflash stock recovery to sideload. :)

Also, I'd assume you already know, but on the off chance you don't since I haven't seen it mentioned, I wanted to report FlashFire hangs at Enumerating in Marshmallow. :good:
[SuperSU] Chainfire:
FlashFire hasn't been updated for M at all yet, and it will be a while. Be sure to remind me of the OTA things, it doesn't ring a bell.
[SuperSU] osm0sis:
This looks like my best report on it: http://xdaforums.com/general/paid-software/flashfire-t3075433/post61824046#post61824046

A couple people asked if there was any progress on it with v0.24 but it remained an issue with the Marshmallow OTAs when I tried to flash them. I'll definitely link to remind you when it looks like you're active over in that thread again. Thanks. :)
[SuperSU] Stephen:
On my devices, I like to modify the settings app and move your SuperSU app from the app drawer to the settings menu. If doing this, will it modify the system partition enough to fail the check and stop OTA, or do you think it will allow it to go through?
[SuperSU] efrant:
Starting with Android 5.0, OTA updates are now block-based rather than file-based, so

any

modification to the system partition will cause the OTA to fail, even mounting the system partition as r/w.
[SuperSU] 98lumina:
Chainfire is the root God =) hey Chainfire do you happen to know how to root the XT1058 running Lpa23.12-21.7?
[SuperSU] BeansTown106:
While your here and your attention is on the thread mind posting your selinux changes for supersu so us aosp developers can still have our own policy's instead of being forced to be permissive or use your precompiled binary, I'm sure tons will appreciate it
[SuperSU] Chainfire:
So, this is a difficult question. I don't have an answer. Or rather, I do have an answer, but I do not know if it is correct. You'll have to play around and do everyone the favor of reporting back. I never compile sepolicy from source, I've always just patched it, so this is untested.

In init.te, the following line is restricting daemonsu from launching (which in turn will call supolicy to make any other changes it needs):

neverallow init { file_type fs_type }:file execute_no_trans;

Either removing that line or making an exception for system_file should allow daemonsu to load.

However, supolicy also requires to reload the sepolicy, which has been disabled in the latest AOSP tree (according to androidxref.com ). I think you need the following two lines in init.te as well:

r_dir_file(init, security_file)
allow init kernel:security load_policy;

I'll be on vacation, but please let me know how that works out for you, so it can be properly documented (eventually).
[SuperSU] garyd9:
Can I suggest creating another thread elsewhere for this? Based on #2 failing, it wouldn't be related to sepolicy, root, or supersu.

If you open a thread in the section of the forum for your device ("device - dev discussion" if you have it, else just "device - development") and mention me (so I get a notification) and link back to your last post in this thread, I'll try to reply there (to the best of my ability.)

Gary
[SuperSU] karthikrr:
Fair enough. Though my ultimate goal is sepolicy and root and supersu, at this point, its none of them. I am unsure what section on my device forum gets attention, but will figure it out and start a discussion there.
[SuperSU] prot-:
Ooh nice! Now to the LG g4
[SuperSU] Fivesack622:
I installed 2.12 and got a prompt to update the binary. The binary update failed and I rebooted. The prompt did not come back upon reboot and I have since rebooted close to 20 times after various lengths of time and have yet to receive a prompt to update the binary. I believe the problem to be fixed. If anything changes over the next few days, I will let you know but I'm pretty confident (in you) that there will be no more issues. I am curious though as to why the binary update initially failed upon updating to 2.12. I assume it has something to do with some part of the old version still being active or some part of the new version not being active until I rebooted. Do you think that's the cause?

Either way, thanks a ton for your support and most of all, thanks for creating SuperSU. I'm glad I will not have to fix my phone with a sledgehammer after all. Only 18 more months before I can get a phone with an unlocked bootloader. F**king Verizon.... If I only knew the things 6 months ago that I know now, I wouldn't even own this stupid phone. Anyways, once again, thanks for all your help and everything you do for the Android community in general.
[SuperSU] Chinaboy5216:
Note3 SM-N9008V no problem so far. Thx Chainfire :)
[SuperSU] robygt:
Super SU pro 2.12/Nexus 4/Android L no problems so far!

Inviato dal mio Nexus 4 utilizzando Tapatalk
[SuperSU] darkrevlis:
Hello, first sorry for my poor English.

I have a samsung galaxy s4, variant GT-I9505.

I installed the beta 2.12.

When I run some applications the device freezes a few seconds. After SuperSU asked to give root permissions to android UID system. I accept permanent root access but then when I run the same application or a different same thing happens again.
[SuperSU] Chainfire:
Which firmware?

Which Android version?

Did the same thing happen on 2.11, or what is the last version of SuperSU you tried before this?

Have you tried enabling the "trust system user" setting?
[SuperSU] darkrevlis:
1 I am now with custom firmware specifically "imperium v12" and wanam 2.5 kernel.

2 android version 4.4.2.

3 if the same thing happened in 2.11 and earlier. I remember that from the 2.08.

4 I have not tried that setting.

5 I'll activate "trusted system user" and if the problems continue I'll let you know.

Note: When I install the "kernel wanam" SuperSU always asks me to update the binary. I can update the binary correctly, but I wonder why is the only kernel that requires me to install the binary again. thank you
[SuperSU] remicks:
2.12 running with no issues on CM11 10-03 nightly, Verizon M8.
[SuperSU] D@nge1:
everything is fine! device - OnePlus One 64Gb.
[SuperSU] shawek:
2.12 build working great on htc m7, with maximus 4.4.3 sense rom.thanx
[SuperSU] Chainfire:
It's probably because Wanam includes SuperSU in his kernel. They may conflict when first installed.
[SuperSU] Blac Caesar:
[MENTION=631273]Chainfire[/MENTION] v2.12 running perfectly for me. Nexus 5; Paranoid Android 4.6 Beta3, Elemental-X v1.10, Xposed Frame w/Wanam Kit
[SuperSU] JaCh0o:
2.12 Beta is not working under Pro and normal License (same as usually random root reject).

I've made tutorials for newbies:

http://www.oppoforums.com/threads/how-to-root-coloros-kitkat-2-0.21282/

and

http://www.oppoforums.com/threads/h...s-1-2-2-1-2-6-2-0-2i-beta-and-2-0-0i-k.17703/

and would be very glad if you would build a solution for it.

2.11 won't install but root stays

2.12 install same as 1.94 but randomly rejects root permissions.
[SuperSU] Mariner_1712:
2.12 operational on xdabbeb's 2.2.0 ROM.
[SuperSU] boyheadkick:
2.12 all good on CloudyG3 v1.3 for LG G2 D802

-aL

tapatalked from my super duper palm top computer
[SuperSU] momomok:
2.12 working good with Pro license @ nexus 5 stock KTU84P with Xposed framework

tested using TB, FasterGPS, Root Explorer, BusyBox Installer
[SuperSU] darkrevlis:
Thanks for the answer.

After testing, I can say that the configuration "user trust system" works perfectly. I no longer need to grant "root permissions" to "uid android system" all the time
[SuperSU] citBabY:
I tried flashing 2.12 here on my SM-G7102 Samsung Galaxy Grand 2 with firmware NG8 (KK4.4.2) because I was pissed off the "The SU binary needs to be updated" message... But whenever I try installing it, a message shows that it couldn't load the update file, could open "zip directory" (bad)

Any hope?

By the way, the latest version I had was 2.02 stable.
[SuperSU] adeich:
Sorry for my English.

Fly IQ446 (Gionee GN708w), android 4.2.2

Beta 2.11 set via TWRP (also tried and 2.10-2.11), gave the programs Root access. (screen 1)

After rebooting the phone, some of the programs that are installed on the SD card disappears from the list, it is necessary to provide them with a new mouth access (screen 2) Programs can vary (screen 3), often disappear Titanium Backup, SDMaid, Root Explorer, AdAway

In version 2.01, it's OK with PlayMarket

screens in the attachment

https://dl.dropboxusercontent.com/u/83550939/screens.zip
[SuperSU] dragonfixed:
Am having issues with ssh snd adb access cant communicate with phone or tablet on wireless network think it is super su and have disabled firewall on phone but no go
[SuperSU] NZgeek:
Have you tried to download the zip again?

Also, you need to be careful about the link in the OP. The way that Chainfire's download page is set up pretty much requires you to do the download from your browser rather than through any sort of download manager. If you are using a download manager, bypass it for this download and it should make a difference.

---------- Post added at 08:08 AM ---------- Previous post was at 08:01 AM ----------

If you think that SuperSU is at fault, have you tried to full unroot from within SuperSU? You'll need to reboot to make sure it's really gone. If the problem still happens, the cause of the issue is not SuperSU.
[SuperSU] Svirusx:
I use Galaxy s6 G9200 HK with Kernel compiled by me, but i have problem with root 5.1.1 and i think in future too 6.0

These root method is integrated in kernel source or i can integrate with those "boot.img systemless" my selfcompiled kernel?(repack boot.img with kernel compiled by me)

Is possible to work this new root method to android 5.1.1?

I have problem with gain root when i use kernel compiled by me ( STOCK kernel have too this problem BOOTLOOPs and FREEZEs on boot system) and i don't know how slove it :/

I found on chineese forums root integrated in boot.img it working good and isn't comunicat "KERNEL is not SEandroid enforced" but when i try integrate my kernel with this boot.img error with boot system :/
[SuperSU] Chinaboy5216:
SU v2.56 can this version be used on Lollipop or is it only intended for Marschmallow? Just seen it announched in this thread by Chainfire http://xdaforums.com/showpost.php?p=63197935
[SuperSU] natemup:
I apologize if this is too noob to even be responded to, but where do I find a stock /system for the Nexus 6 and how do I flash it? I am running the CM13 alpha right now.
[SuperSU] kroizo:
[MENTION=2680769]natemup[/MENTION] you're just kidding, right? http://bfy.tw/2YZv
[SuperSU] natemup:
OK... Does this mean flashing a stock-based custom rom would also work?
[SuperSU] Lrs121:
Assume it's intended for the versions of Android that have the properly modded boot image. Such as the ones listed in the thread that mention systemless
[SuperSU] russlowe73:
Factory images
[SuperSU] BeansTown106:
thanks for the response, using your proposed changes here: https://github.com/PureNexus/androi...mmit/f7e9971432285f971010e6cb13b384d4dc75fbab

i still get the error about

avc: denied { execute_no_trans } for pid=1601 comm="init" path="/system/xbin/daemonsu" dev="mmcblk0p41" ino=2027 scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=file permissive=0

i was however able to get around this error, but zyogote is still crashing i no longer get any supersu errors just

avc: denied { read write } for pid=4082 comm="app_process32_o" path="socket:[29209]" dev="sockfs" ino=29209 scontext=u:r:zygote:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket permissive=0

as well as init:Warning! Service zygote needs a SELinux domain defined; please fix!
[SuperSU] JsChiSurf:
I'm guessing no busybox for now since it installs to the /system partition, when using the new systemless root option?
[SuperSU] Ch3vr0n:
Busybox has a custom path option you know, just no success guaranteed.

Verstuurd vanaf mijn Nexus 5 met Tapatalk
[SuperSU] JsChiSurf:
Yes, but a custom path means it's not in a system PATH for convenient use. Not the end of the world, but an observation not yet brought up.
[SuperSU] RandomPooka:
So? It isn't like it's difficult to add it to the path environment variable
[SuperSU] JsChiSurf:
Pretty sure it wouldn't survive a reboot. I guess boot image / ramdisk could be modified to include a new permanent path for busybox elsewhere. Not "end user" friendly though.
[SuperSU] natemup:
So for the experimental non-system-modifying method, do I need to flash the boot.img

and

SuperSU every time I Factory Reset? I ran it once already with success and am on stock MM, but I want to go back to a CM13 alpha and am not sure if I need to flash the boot.img after I wipe.
[SuperSU] nicholseric:
To your credit, it looks like you and doitright had similar ideas for the direction you went with boot.img. I am glad your response to him spurred his action to pick up the original superuser and whip it into shape. An open market and competition spurs creativity. We all like having choices.
[SuperSU] Svirusx:
I tried insert this ramdisk to my kernel = don't working but system boot.

i tried too insert my "Kernel" to boot.img experimental root and bootloop.

Problem i have too with root via TWRP Stock ROM.

When i install SuperSU via TWRP on 100% stock ROM i have all time bootloop only pingpongroot method working for my phone and chineese Kernels but i don't know what changes they do :/

Now i use 5.0.2 but i want 5.1.1. I think this is problem too with experimental root bootloop.

Someone know how i can slove that problem?