yashsingh1/xdaforums huggingface dataset:
[SuperSU] yung40oz84:
This happened to me, system UI FC then factory reset toast

---------- Post added at 07:25 PM ---------- Previous post was at 07:22 PM ----------

I tried this method too, your exact steps. And I tried VBS 3 on TWRP RC1 and tried VBS 8 on TWRP RC1. both times when I reboot to recovery after flashing superSU 2.82 SR1 it goes to ram dump. I'm running Pixel XL, I seen others having this issue.
[SuperSU] Golf c:
Yep, I spoke to soon. We are all getting the ram dump with no Twrp. I have seen nobody get into Twrp on a Pixel. Sorry ?
[SuperSU] yung40oz84:
No probs bud, thanks!
[SuperSU] Ibuprophen:
I was just wondering if you had taken a look at the following post?

https://xdaforums.com/showpost.php?p=72164937&postcount=1312

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise...
[SuperSU] chazall1:
I never lost TWRP. I am using twrp-pixel-installer-marlin-3.0.2-0-RC1.

And all is functioning as expected.
[SuperSU] peterlee928:
thx [MENTION=4828250]Ibuprophen[/MENTION]

in my case

vzn pixel xl

stock rom

june update

twrp 3.1.0

was running supersu 2.79 sr3

vbs v3

i was rooted

was able to boot into recovery

then i flashed supersu 2.82 sr1 in twrp

no vbs afterwards

post-2.82 sr1 flashing

i am still rooted

everything works fine

EXCEPT

cannot boot into recovery

goes to ramdump

so the only thing that changed

was flashing 2.82 sr1

prior to this

i had no issues booting to recovery
[SuperSU] Golf c:
Very strange. Your the only one so far I have seen that has Twrp and SuperSU 2.82 RC1. I wonder what's different?

---------- Post added at 08:02 PM ---------- Previous post was at 08:00 PM ----------

I am on June tmobile. Everything works as expected on SuperSU 2.82. 2.82 RC1 has no Twrp for me.
[SuperSU] peterlee928:
[MENTION=6302926]Golf c[/MENTION]

which twrp version

r u using?

wondering if we go stock

(im currently on stock)

with twrp 3.0.2 rc1

(im on 3.1.0)

we can get recovery again

thoughts?
[SuperSU] spainter:
Remember the Verizon variant ov the pixel phones are boot loader locked and the bootloader is a different animal. I know there is a method to unlock it but if I remember right it had some side effects.

Been a long time since I looked at it but I think the method was here on XDA
[SuperSU] Golf c:
It seems to be happening with Twrp RC1 + 2

Flashed June tmobile to both slots.

DU 6-8 rc build

Twrp RC1

Sharkey kernel R7

We supposedly only have one user with working Twrp on 2.82 Sr1.
[SuperSU] jekyll530:
The issue was fixed in RootSwitch 1.3.3.12, FYI.
[SuperSU] Ibuprophen:
I did notice a Tweet (from last month) that [MENTION=631273]Chainfire[/MENTION] had stated the following:

"Re: May update for Pixel (XL), SuperSU and bootloops: flash back April's bootloader to fix. Not sure what's up with the new bootloader yet."

The following is the link to that quoted Tweet:

https://mobile.twitter.com/chainfirexda/status/859475727653249026

Though, it was last month's Tweet, I've got a feeling that this issue is one of his "to-do's" along with his others on his, I'm sure, long list of items on his plate.

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise...
[SuperSU] Ibuprophen:
Please correct me if I'm wrong but, it looks as though you may have the versions of SuperSU and TWRP for the marlin device mixed up/intertwined.

It's TWRP that's being referred to for the RC1...

On 11 March 2017, TWRP had released v3.1.0-0RC2 for the Pixel/sailfish and the Pixel XL/marlin devices.

LOL!... There's not such SuperSU v2.82 RC1...

The recent SuperSU is v2.82 SR1... LMAO!

It's funny how the two was innocently mixed up.

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise...
[SuperSU] Golf c:
My bad. I have been doing that for the last ten posts. Sorry! Replace my last ten with Twrp Rc1 and SuperSu 2.82 SR1

---------- Post added at 09:10 PM ---------- Previous post was at 08:57 PM ----------
[SuperSU] claytonjn:
<rant>

Seriously...it's getting to the point that I would almost suggest to Chainfire to include a dialog when an overlay is detected that indicates why the buttons aren't working. Then again, this is a developer thread and su can cause serious security risks if not used properly so we really shouldn't be spoonfeeding people. I'm just getting irked by everyone simply advising users to disable tapjacking protection without explaining that doing so decreases security. I mean come one, Chainfire didn't add that just to mess with people's heads, it's there for a reason.

</rant>
[SuperSU] Clauu:
Yes i have, what do you mean by 'whitelist supersu' ?
[SuperSU] egingell:
Is also explained using Lux as the example app on (almost) every page.

I would also suggest a dialog or message on the current dialog stating that "tapjacking has detected an overlay" with the specific app name if possible.

Sent from: SGS2 - JB 4.1.2 GB27 / SGS4 - JB 4.2.2 MF9
[SuperSU] Srandista:
Yes, you're right. But on the other hand, I just don't understand, why these people using this evidently crappy programed app can't read at least last one or two pages in thread and find answer without posting same question again and again...
[SuperSU] Chainfire:
Google implemented the API used for tapjacking in an odd way which makes it impractical to provide a popup when it works.

Lux will probably work-around this in their next update, though, so then the question will mostly be gone.
[SuperSU] esgie:
You may want to give them proper permissions, ownership and selinux context as in the updater-binary file included in supersu zip.
[SuperSU] greyhd:
Go under settings and look for "white list" and add SuperSU to that list.
[SuperSU] tobitege:
[MENTION=631273]Chainfire[/MENTION]: there have been multiple reports on the LG G3 D855 threads about issues with v2.37 and the most recent LG firmware LRX21R V20C and ROMs based on it.

Although the ROM, like AndroidNow HD 5, came with SuperSU embedded, myself and others experienced issues like:

* "no su binary found" in SuperSu

* when switching options in SuperSU (Pro) the app became unresponsive

* root apps did not cause the grant root prompt to show up.

Took me 3 factory resets+format data and internal storage to get all working (coming from rooted/bumped V20A lollipop rom) to have the issues resolved (I suppose the format data was the actual "fix").

Just thought you might be interested to know, if you need any further info let me know, thanks.
[SuperSU] Clauu:
I don;t have such thing 'white list' in lux settings..
[SuperSU] greyhd:
Try looking under the "Sleep" list. If that doesn't work, try adding Lux to SuperSU.
[SuperSU] FoulDroid:
SuperSU 2.37 Working great on Nexus 7 2013 5.0.1 !

:)
[SuperSU] Waschmittel:
Seems to be working fine on my Nexus 9 with 5.0.1 / LRX22C

Thanks a lot! :)
[SuperSU] fhem:
+1
[SuperSU] 白い熊:
I'm having issues with the --mount-master option, in fact I haven't been able to mount anything in the master mount space ever.

Here is what I'm doing:

SuperSU 2.37

Note 4

I want to mount my SD card which is formatted in ext4 so that it's system readable - any app can access it - in my understanding that's what the --mount-master option does right?

su --mount-master -t ext4 /dev/block/mmcblk1p1 /storage/extSd

mounts the card, however only root can read it, regular user gets the no permission error.

Why? Can anyone use the --mount-master option successfully, or am I missing something.

Thanks a lot for any help.
[SuperSU] NZgeek:
Try running a logcat and see if they're are any SELinux policy violations. If there are, you may need to use supolicy to add rules to allow access. Another option is to switch to SELinux permissive mode, although this makes your phone a little less secure.

See http://su.chainfire.eu/ for more details about SELinux and supolicy.
[SuperSU] Frank Westlake:
I think this might be the SDCARD-write problem which began with Android 4.4. See if editing ' /system/etc/permissions/platform.xml' will help. Please look for discussion on this elsewhere.

Frank
[SuperSU] 白い熊:
I don't think that's it, my platform.xml is modified and I have sdcard write access, if the sdcard is exfat and gets mounted automatically...

It seems it'll probably be the supolicy, with which I wasn't familiar up to now, I'll read up there, so far I've tried

supolicy --live "allow unlabeled unlabeled filesystem associate"

but hasn't enabled access to the mount for regular users.

EDIT:

OK, just going dumbly by the example on http://su.chainfire.eu/ with some fiddling, I'm able to utilize the --mount-master option, basically what is needed:

supolicy --live "allow sdcardd unlabeled dir { append create execute write relabelfrom link unlink ioctl getattr setattr read rename lock mounton quotaon swapon rmdir audit_access remove_name add_name reparent execmod search open }"
"allow sdcardd unlabeled file { append create write relabelfrom link unlink ioctl getattr setattr read rename lock mounton quotaon swapon audit_access open }"
"allow unlabeled unlabeled filesystem associate"

and then intermediate mount of the sdcard to /data/media/somewhere and bindmount then to /data/media/0/somewhere.

Maybe it works in other ways too, I'll experiment now. Thank you very much for the pointer NZgeek !!!

Now, permissions issues, maybe this is also connected to the policies or so:

If I create a directory in a file manager, or copy a file, the files and directories are owned by 'root:1028' and the file permissions are 660 and dir permissions are 770.

I don't want especially the root ownership, is there a way to set a general umask for new files and dirs on volumes thus mounted and have each app create files and dirs with its ownership, or is that a no go due to the fact that the card is accessed through /system/bin/sdcard and thus, I assume, it's owned by root and the attributes are thus set?

Many thanks, this is a breakthrough for me.
[SuperSU] Chainfire:
Aside from the policy things in the other posts, this is not how you use the mount-master option - it's not a mount command. You'd either start an interactive root shell by calling "su --mount-master" or you do "su --mount-master -c mount -t ext4 ..."
[SuperSU] 白い熊:
Yeah, I know, this was a typo, of course I'm running:

su --mount-master -c 'busybox mount -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard

But without the supolicy, what I wrote in the original post happens - it mounts the card, however only root can read it, regular user gets the no permission error.

Regarding the ownership, and permissions as per my last post, is there a way to modify this? Because like this everything is owned by root, which is a problem, and also no way have proper linux attributes, even though the mounted drive is ext4...
[SuperSU] canodroid15:
[MENTION=631273]Chainfire[/MENTION] I just did a clean flash installed d2tmo Validus LP 5.0.1,flashed supersu v2.37, for the life of me can't access the app? I get the pop up, can grant and deny perms, but no settings or features it doesn't show in app drawer? Tried reflashing everything, ROM & supersu uninstalled,reinstalled from playstore, same results every time? Thanks in advance
[SuperSU] chazall1:
I just went back for the time being, to the April bootloader and SU 2.82 and all is normal. There is going to be some issues that will get resolved in the furture. Great work and thanks
[SuperSU] emdroidle:
Seems the SU disaster keeps on giving. I'm on a LG V10, Android 5.1.1, kernel 3.10.49.

I try to keep things as up to date as possible (something about security), ended up getting a SuperSU update early on May 29th (likely 2.82). Before this point I had minimal trouble with updates. I let SuperSU update the binary. Didn't actually get a bootloop, instead the device never completed the next boot, got to the LG logo and simply remained there for hours.

This is where things are at the moment.

I'm also rather annoyed that the most recent Play Store update to SuperSU refuses to show the grant/deny dialog (effectively disabling all functionality) unless you allow it to update the binary. Perhaps this is an ordinary bug, but in a situation like this, one is tempted to suspect this is meant to force people to update the daemon and given the situation this very much is not an option for me.
[SuperSU] Ch3vr0n:
That right there is the very definition of a bootloop!
[SuperSU] yung40oz84:
I tried RC1 too and lost it, what steps did u take exactly? Custom kernel?

---------- Post added at 01:03 AM ---------- Previous post was at 01:02 AM ----------

Ya but that is 2.79 SR3 and not using a customer kernel, that's kinda older
[SuperSU] krazekid7:
2.82 sr1 on dp3 breaks sound on calls for the pixel xl

You are also unable to mount the system. Any help would be appreciated!
[SuperSU] Sr. Zé Alguém:
Hello, we are on the thread for the Beta SuperSU, and, therefore, you may want to test it (2.82 SR1) and report your findings for this version.
[SuperSU] Golf c:
Chazall1 tried to access Twrp and got the ram dump. He went back to April bootloader. Now there are no confirmed pixels able to access Twrp on SuperSU 2.82 SR1.

https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post72624099
[SuperSU] yung40oz84:
I am on June bootloader hence the use of VBS, but same issue with booting to ram dump. I tried many different variations of.opti9ns and orders.of flashing custom kernel, TWRP, and superSU 2.82 SR1 and all same result. After flashing superSU 2.82 SR1 no TWRP.
[SuperSU] Golf c:
I don't know why he went back to April bootloader. Probably just to avoid issues?

Edit:

https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post72624465
[SuperSU] yung40oz84:
Ya, u don't need VBS with that bootloader so TWRP prob worked, but as far as I've seen nobody on June can get TWRP after flashing the SR1 superSU no matter the steps. I may play around here tomorrow. Lol
[SuperSU] peterlee928:
i think cuz

starting with may update

either u use april bl

or

vbs per the master (chainfire)
[SuperSU] Golf c:
I haven't seen anybody get Twrp working either. I suspect it won't happen on a Pixel with SU 2.82 SR1.
[SuperSU] yung40oz84:
The crazy thing is that superSU SR1 is intial pixel support it says in release post. Like boot slots, etc. Etc.
[SuperSU] altwu:
i'm also running into the ramdump issue. i have a verizon pixel xl with the june update(nhg47n) and twrp 3.0.2.0 rc1. before flashing supersu 2.82 sr1, i was running supersu 2.79 sr3. the boot image was signed with [MENTION=631273]Chainfire[/MENTION]'s VerifiedBootSigner-v8.zip. like everyone else, after flashing supersu 2.82 sr1, everything runs fine except when i try to reboot to twrp. when i try that, i get the ramdump message. it shows up for about 10-20 seconds and then the phone proceeds to boot normally. i tried to boot into twrp 2 different ways. 1) from the bootloader and 2) using [MENTION=3292224]franciscofranco[/MENTION]'s simple reboot app. both times, i got the ramdump message.

i tried flashing the supersu 2.82 sr1 zip by itself and another time the supersu 2.82 sr1 zip along with VerifiedBootSigner-v8.zip. the behavior was the same in both cases. i still got the ramdump message when i tried to boot into twrp.

i also noticed something else that seemed odd. both times, when i flashed the supersu 2.82 sr1 zip, i saw this in the log messages and also in the recovery.log, which i saved if anyone wants to take a look.

******************

Boot image patcher

******************

. . . . .

- Checking signature

--- Unsigned

. . . . .

prior to flashing supersu 2.82 sr1, the boot image was signed with VerifiedBootSigner-v8.zip. it's weird that the install process saw the boot image as unsigned. but when i flashed just the supersu 2.82 sr1 zip and nothing else, my phone still booted up fine and i'm on the latest 7.1.2 update.

anyway, to recover from this, i was able to fastboot boot the twrp 3.0.2.0 rc1 image, install the twrp 3.0.2.0 rc1 and supersu 2.79 sr3 zips, and everything works again.
[SuperSU] emdroidle:
Yeah, though I kind of dislike the term for this situation... Generally suggests boot starts, something panics and device tries to restart then panics... Whereas here it is a hang.

Seems rather unclear where to report issues, the version numbers are rather non-linear. Appears most versions of SuperSU are beta right now.
[SuperSU] snovvman:
For those who had the 2.82 = TWRP booting issue, once you restored TWRP and 2.79, did you update to 2.82 from the Playstore (and binary)? If yes, did that again cause a TWRP boot issue? Thanks.
[SuperSU] Sr. Zé Alguém:
I think it has stabilized by now. You know, in synthesis: 2.80 was a plagued release; 2.81 was a failed try to fix the mess; 2.82 initially was a modified 2.80 recompiled by Chainfire with bindfix, then this 2.82 plus an extra fix went to the Play Store, compiled by CCMT; 2.82-Test1 by Chainfire came a couple days after that, fixing bootloops and something else; and now, the numbers returned to their normal flow, and we are at 2.82 SR1.

I would say it is more useful reporting bugs for SR1 here considering that the version in Play Store (compiled by CCMT) is know to have bugs, and that Chainfire work is going into this SR1 branch.
[SuperSU] SSH316:
Hello

There is a problem with switching root off to pass safetynet (rootswitch) with Supersu 2.82 & 2.82 SR1

But i can with 2.79 SR3
[SuperSU] Golf c:
No, I never updated the binary from playstore.

2.79 SR3 - to

UPDATE-SuperSU-v2.82-20170528234214 - to

2.82 SR1

SR1 causes the loss of Twrp access.
[SuperSU] Ibuprophen:
Just a thought/suggestion (trying to think outside of the box or, more appropriately, outside of the device) so please bear with me but, i don't know if this will work as if/how it would apply to my idea...

I was wondering if anyone with the Pixel/Pixel XL issues tried using an app by [MENTION=631273]Chainfire[/MENTION] called LiveBoot?

[APP][4.3+][ROOT][2016.12.10] LiveBoot (Logcat/Dmesg Boot Animation) v1.50 by Chainfire

I was thinking that if someone had installed the LiveBoot app and then performing the steps that created the situation whereas the device gets stuck in boot/bootloops, wouldn't the LiveBoot display/reflect what/where, in the boot-up sequence/process, the device is hung up on?

I don't own either of the devices but, wanted to provide another idea to help you all out in some way.

Please let me know if this is a good idea or am I going to need to make a reservation to the funny farm?... LMAO!

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise...
[SuperSU] yung40oz84:
After flashing superSU 2.82 SR1 the device boots up fine so live boot will show a normal boot. It's when booting back into recovery that recovery is gone and it goes to ramp dump so there is no boot sequence for live display to show.
[SuperSU] Didgeridoohan:
SuperSU 2.82 revealed a bug in Rootswitch. There was an update recently that fixed it.
[SuperSU] osm0sis:
People can refer back to my post here:

https://xdaforums.com/showpost.php?p=72616034&postcount=10370

I've updated it with the latest build (v1.3.3.12) link. :) :good:
[SuperSU] jcmm11:
Any chance you can locate RootSwitch.zip (.supersu and custom_ramdisk_patch.sh) someplace other than mega? Don't want to have to install mega app.
[SuperSU] osm0sis:
Enable "Request desktop site" in Chrome and it doesn't try to force the app on you.
[SuperSU] SnapShot86:
work good on clear system, but Confuses a scattering of files in the root folder

UL10c00b356 emui 5 Android 7 works too..
[SuperSU] SSH316:
Didn't know about it

Thank you
[SuperSU] mugor:
Did you flash VerifiedBootSigner v8 after flashing the TWRP zip?

I updated from April bootloader to June bootloader yesterday while on the May edition of PureNexus, using the following steps.

Reboot into bootloader

Fastboot flash the June Bootloader

Fastboot reboot back into the bootloader

Fastboot flash June radio

fastboot reboot back into bootloader

Boot into recovery, using the volume up/down keys

Flash TWRP RC2 zip

Flash VerifiedBootSigner v8

Flash SuperSU 2.82 SR1

Flash VerifiedBootSigner v8 - force resigning but I don't think you need this step, since SR1 maintains the signed status from the previous steps

(Optional) Flash ElementalX v1.12 kernel

(Optional) Flash VerifiedBootSigner v8 - force resigning, I don't think you need this step either since ElementalX is already signed

Reboot into system

Reboot into recovery

I think the key is step 8. Since the TWRP RC2 zip is not signed.

Let me know how this works out for you guys.

The only issue I seem to be having is that sometimes I get the SuperSU 'stops working' pop up. However root is still there and everything is working as normal.

Edit: I have updated to PureNexus June Edition and now I also get the ram dump issue.
[SuperSU] SnapShot86:
Bug there is EMUI 5

SuperSU v2.79 and SuperSU v2.82 SR1 Does not appear in recent applications

Seen on video

https://cloud.mail.ru/public/Fri4/QQcHtGg7e
[SuperSU] grimmaniac:
I think it's not a bug. Iirc it never showed up in recent apps.
[SuperSU] scanno:
Anyone else here have problems with external SD cards on 2.82 SR1? Apps can't access the sdcard anymore and get access denied. The external sdcard gets mounted fine and apps can access the external sdcard with root rights, but not with normal rights .
[SuperSU] grimmaniac:
Give osm0sis' sdcard permissions fix script a try: https://xdaforums.com/showthread.php?t=2239421
[SuperSU] scanno:
Thx for the answer, but it is not a permission problem of files on the sdcard. Without supersu the external sdcard is working fine.
[SuperSU] yung40oz84:
Hmmm, did u actually try the optional steps? Flashing kernel after superSU? I thought it was kernel then superSU, but maybe I will try these steps. I cannot get recovery to boot at all, only ram dump, maybe this will help. Thanks!
[SuperSU] j1gga84:
I also had problems with external SD and 2.82 SR1, with final 2.82 everything is working fine.

Regards

Gesendet von meinem SM-G900F mit Tapatalk
[SuperSU] mugor:
I always follow my steps. Supersu first then kernel, not sure why but it works for me. I said it was optional since not everyone uses custom kernels.
[SuperSU] Shtiff1:
Do you have link for said signed boot image? Will it work on quark XT1254?
[SuperSU] Golf c:
A quark is a sub atomic particle. Signed boot images are for Google Pixel phones only.
[SuperSU] peterlee928:
[MENTION=6302926]Golf c[/MENTION]

quick q

did mugor's process

work for u?
[SuperSU] Golf c:
Of course not. It didn't work for him either. He updated to the June bootloader and no longer had Twrp.
[SuperSU] peterlee928:
lol

figured as much

thx for the 411

:)
[SuperSU] bbender716:
On ODP3 as well, I'm having the same issue with mounting. My calls are fine. I can mount r/w the root directory but can't mount r/w system. Root seems to work fine besides however...
[SuperSU] krazekid7:
It's weird that I'm the only one saying something about about. If we can't mount the system, that's a huge problem.
[SuperSU] bbender716:
Are you using sdcardfs enabled?
[SuperSU] krazekid7:
No twrp doesn't work. Any other way to flash it?
[SuperSU] mishko:
Same here. Problems mounting system using different root file explorers, like Solid Explorer and Mixplorer. Using SU 2.82 sr1.
[SuperSU] TheArkive:
Has anyone else noticed yet that on Pixel, with the June update, digital signatures aren't needed on the boot image?

It's being discussed here.

Edit: Just wanted to add that on Pixel, I actually wasn't able to boot after flashing SuperSU 2.82 SR1. SuperSU 2.82 did the trick though. Works as hoped. Nothing failed in the install log, just a failed boot.
[SuperSU] krazekid7:
So far, I haven't found a possible way to mount the system.

And does your phone app work fine for calls? I don't get any sound from the caller or from me.
[SuperSU] mishko:
Nope no issues w incoming calls.