yashsingh1/xdaforums huggingface dataset:
[SuperSU] krazekid7:
how can we mount the system on ODP3 on the pixel XL?
[SuperSU] Alxoom33:
Anyone know if ODP3 has a new Bootloader or Radio?
[SuperSU] bbender716:
They are new, yes.
[SuperSU] mishko:
My problems solved by reverting to stable 2.79. Had no issues w that one before really, don't know why I upgraded to 2.82. Maybe just the flashoholic in me, I guess ;)
[SuperSU] bbender716:
I think he was referring to the problem we have on Android O. In which case reverting isn't a possibility for us.
[SuperSU] Alxoom33:
Do you know the radio baseband and # for the ODP3 bootloader?

---------- Post added at 12:05 PM ---------- Previous post was at 12:02 PM ----------

Thanks, any idea where I can find the changes from 2 to 3? Or do you know the details?
[SuperSU] krazekid7:
I figured out how to mount the system in ODP3 on a pixel Xl
[SuperSU] bbender716:
...and?

---------- Post added at 05:40 PM ---------- Previous post was at 05:35 PM ----------

Baseband: 8996-013031-1705051332
[SuperSU] krazekid7:
By default, you aren't able to mount the system for the pixel. And the regular mounting doesn't work
[SuperSU] bbender716:
So how did you manage to?
[SuperSU] krazekid7:
I created a script and put it in /su/su.d/

Set permissions to 755 for the folder and script.

Code for script is:

#!/system/bin/sh

mount -o rw /dev/block/bootdevice/by-name/system`getprop ro.boot.slot_suffix` /system

You have to create a script or the system won't be mounted at startup. This breaks OTAs and safetynet (which never actually passed for me to begin with).
[SuperSU] Chainfire:
Which exact device and firmware? Which app or command did you use to test this?

Your report lacks too many details to be useful.

Does turning off the "mount namespace separation" option in SuperSU settings (and rebooting) fix the issue?

See my response above.

Note sure what is going on with the all, but I will look into fixing the remount issue.

On Pixel (XL) ?

Which firmware and device?
[SuperSU] scanno:
[MENTION=631273]Chainfire[/MENTION] it was not really a bug report, more a question if there are other people with the same problem. But to answer your question, it concerns the Samsung Galaxy Tab s2 (T813) running on Omni7 with the June security fixes.

External sdcard can not be accessed with filemanager apps and the omni snapdragon camera.
[SuperSU] j1gga84:
[MENTION=631273]Chainfire[/MENTION]

Galaxy Tab S (T805) running ResurrectionRemix N 5.8.3, but I flashed it again, removed magisk prior of flashing (the magisk folder in the ROM zip), flashed beans gapps, rooted it with 2.82 and updated to 2.82 SR1 and now external SD is accessible.

Regards

Gesendet von meinem SM-G900F mit Tapatalk
[SuperSU] krazekid7:
I was able r/w system on my pixel XL ODP3 by creating a script
[SuperSU] gubacsek:
Hi [MENTION=631273]Chainfire[/MENTION]!

about the mounting /system issue on the pixel (sailfish):

sailfish:/ # grep system /proc/mounts
/dev/sda33 /system_root ext4 ro,seclabel,noatime,data=ordered 0 0
/dev/sda33 /system ext4 ro,seclabel,noatime,data=ordered 0 0
sailfish:/ #

sailfish:/ # mount -o remount,rw /system
mount: '/dev/sda33'->'/system': No such file or directory
1|sailfish:/ # mount -o remount,rw /system_root
mount: '/dev/sda33'->'/system_root': No such file or directory
1|sailfish:/ #

1|sailfish:/ # ls -la /dev/block/bootdevice/by-name/system_a
lrwxrwxrwx 1 root root 16 1970-08-26 03:36 /dev/block/bootdevice/by-name/system_a -> /dev/block/sda33
sailfish:/ #

So in /proc/mounts I have "/dev/sda33" for system, but it seems to be called "/dev/block/sda33" now. So maybe during init it is mounted/called differently?

If I create a symlink, it looks better, but I'm not sure if this is the way to go :D

sailfish:/ # ln -s /dev/block/sda33 /dev/
sailfish:/ # mount -o remount,rw /system
mount: '/dev/sda33'->'/system': Device or resource busy
1|sailfish:/ # mount -o remount,rw /system_root
mount: '/dev/sda33'->'/system_root': Device or resource busy
1|sailfish:/ #

I have never seen a "busy" error during remounting something to rw from ro....
[SuperSU] mishko:
N5X running PureNexus rom (7.1.2, N2G470)
[SuperSU] piperx:
That's what I did also, I ended up back on pure nexus for about another week, need working phone, going to be a grandad again [emoji3]
[SuperSU] jcmm11:
[MENTION=2669141]gubacsek[/MENTION]

sailfish:/ # ln -s /dev/block/sda33 /dev/
sailfish:/ # mount -o remount,rw /system
mount: '/dev/sda33'->'/system': Device or resource busy
1|sailfish:/ # mount -o remount,rw /system_root
mount: '/dev/sda33'->'/system_root': Device or resource busy
1|sailfish:/ #

I have never seen a "busy" error during remounting something to rw from ro....

-------------------------------------------

Try flipping the order of the options, like so

mount -o rw,remount /system

(it's a toybox thing)
[SuperSU] bbender716:
Yup, on Pixel Android O DP3. Multiple types of root explorer apps fail to mount system r/w. The fix posted earlier that involves making a script in /su/su.d fixes it.
[SuperSU] gubacsek:
Holy damn **** :D :D

sailfish:/ # mount -o rw,remount /system
sailfish:/ # mount |grep system
/dev/block/sda33 on /system_root type ext4 (ro,seclabel,noatime,data=ordered)
/dev/block/sda33 on /system type ext4 (rw,seclabel,noatime,data=ordered)
sailfish:/ #

It seems it worked :D

It works even without the /dev/sda33 link ....

well, this was an easy fix :D

Thank you very much for the tip!
[SuperSU] Chainfire:
The cause for the issue has been found and fixed in my development branch. Next update will remount /system without further issue or scripts.
[SuperSU] bbender716:
You are the best as usual CF!
[SuperSU] JasePK:
Having an issue on OnePlus 3T after going up from OOS 4.1.1 to OOS 4.1.6. Had to reflash and update supersu to v2.82, but now the app simply doesn't respond. If a grant/deny prompt comes up I can't hit either option and it eventually crashes with the same not responding error that I get when opening the SuperSU app. Hitting "wait" doesn't make a difference because it never becomes responsive no matter how long I wait, so I'm forced to hit "close." Sometimes when trying to open the app it won't even give me the not responding error, it will simply never load or may just give me a black screen until I hit the back or home button to go back to the homescreen. I've tried going back down to both 2.79 and 2.78, both the binary and the app version, reinstalling, and nothing seems to fix the issue. When the app version and binary version are mismatched the app will actually load, but it won't let me go into any settings because it won't detect the binary and will just stay at the notification window with a link to rooting instructions.

Not exactly sure how to go about this.
[SuperSU] Ch3vr0n:
has the issue been found for the bootloop on the 6P i reported? Seems it loops on a signed version with SR1. 2.82 release works fine. Detailed report & logs in my earlier post
[SuperSU] Chainfire:
Attached test version - for the Pixel (XL) only - should fix both remounting /system as well as the TWRP/recovery ramdump issue. No other issues have been fixed. Let me know if it works right for you.

I suggest flashing back the stock boot image before flashing (TWRP and) this.
[SuperSU] holla420:
Anyone try this out and got TWRP working?
[SuperSU] Taebom:
Still not working for me

Flash back to clean dp3

then boot-to-root

then tried twrp and get flashing screen
[SuperSU] bbender716:
I didn't think he meant it was going to fix the issue of flashing twrp on ODP3 Pixel. He meant it will fix the mounting issue on ODP3 and the twrp issue on non ODP3 pixels.
[SuperSU] chazall1:
I just flashed SuperSU-v2.82-SR1-20170615211546-PixelFix. On my current setup all is functioning as expected.

No ram dump.

Great job
[SuperSU] Taebom:
my bad, i just assumed because he said it was for pixel mentioned twrp fix as well as mount.
[SuperSU] bleez99:
No recovery boot-to-root with SuperSU v2.82 SR1

I flashed back to stock, and all seems to be well, system is behaving properly, but with the last two releases, boot-to root seems to blow out the recovery, in my case the stock recovery.

Pixel XL.

EDIT:

Recovery is now working. Not sure what happened.

Thanks
[SuperSU] peterlee928:
did u delete old supersu

and then flash new vsn?

or just flash new vsn

on top of existing vsn?

EDIT

apologies

which twrp vsn r u using?
[SuperSU] chazall1:
Just flash over your current SU. I am using TWRP 3.0.2-0RC1.

The June bootloader does not verify the boot signature in the boot image.

Flash without the boot signer .zip
[SuperSU] peterlee928:
gotcha

much thx :)

im running twrp rc2

lets see if this combo works also

EDIT

pixelfix supersu :good:

at least wrt prev boot to recovery issue

ie no more ramdump

vzn pixel xl

stock rom

june update

twrp rc2

per [MENTION=2649074]chazall1[/MENTION]

boot to recovery

flash pixelfix supersu

no flashing vbs

reboot system
[SuperSU] peterlee928:
super noob q

apologies in adv

i purchased supersu pro

just upgraded to pixelfix supersu

if i install the pro license

wut impact (if any)

will it have?

much thx in advance :)

EDIT

specifically

will the pro license

break the fixes

on mount

and booting to recovery?

again much thx :)
[SuperSU] Bryanx86:
Muahahahahhahahaha!
[SuperSU] gverma1:
Just curious whats the difference between SuperSU-v2.82-SR1-20170615211546-PixelFix.zip (5.99MB) and root-marlin-pixelxl-v2.82-SR1-PixelFix.zip (19.37MB). Which one to use on a PixelXL (Marlin) after flashing TWRP? TIA.
[SuperSU] galen2:
SuperSU 2.82 SR1 broke something on my samsung S3 i9300 lineage 14.1 sd card. One sd card notification appears always when boot saying "sd card for pictures and multimedia" and apps cant access sd card and i cant access sd card when i connect phone to pc, only default file manager can, others file managers how solid explorer cant detect it. SuperSU 2.82 its working fine.
[SuperSU] ashyx:
Please don't use text speak on a forum.
[SuperSU] peterlee928:
wut is text speak
[SuperSU] Swamphound:
No it does not it does this:

SuperSU Pro adds the following features to your SuperSU installation:

- OTA survival mode (no guarantees)

- Full color-coded command content logging (input/output/error)

- Per-app logging configuration

- Per-app user override

- PIN protectio

And I'm sure Chainfire appreciates your aupport!
[SuperSU] peterlee928:
much thx :)

happy to support the master
[SuperSU] ktmom:
Um, that is [emoji3]

The problem is, when phonetic abbreviations are used, the meaning becomes lost to non-native speakers (and some of us older members). It's much better to use proper English in an English language forum.
[SuperSU] peterlee928:
fr?

thats trill

respeck

jkjk

fair point

full english it is

:)
[SuperSU] Ch3vr0n:
and now in full lines and sentences instead of just a few words per line. Makes things just as hard to read
[SuperSU] peterlee928:
would your highness prefer correct capitalization as well? like im back in grade school again :)

jk, all fair points. least i can do for all the great help yall provide :)
[SuperSU] Sr. Zé Alguém:
[MENTION=6089972]peterlee928[/MENTION] Are you writing in a mobile keyboard (app) or desktop keyboard?
[SuperSU] peterlee928:
app
[SuperSU] Sr. Zé Alguém:
Then you have an extra reason to write with good grammar, because any good mobile keyboard is able to properly correct grammar and typos automatically -- this doesn't happen with a real keyboard. Unless you want to give a bad impression -- as you have already achived, I guess.

Want to learn something in your life? Start by listening other's suggestions. Repeating your errors is not the way to go. Bye.

[/end-ot]
[SuperSU] edward566:
Perfect. Used Flashfire to flash SuperSU-2.82-SR1-20170615211546-PixelFix.zip onto NKG47L, both remounting /system as well as the TWRP/recovery ramdump issue has been fixed.
[SuperSU] yung40oz84:
New pixelfix 2.82SR1 working as expected. Pixel XL, dirty unicorns, Sharkey kernel.
[SuperSU] Golf c:
Deadly combo your running! ?

I have exact same setup. This phone with that combo, is unbeatable.
[SuperSU] Rob3rto90:
good on my Galaxy Tab S 8.4 LTE :)
[SuperSU] yung40oz84:
Ya definitely a deal breaker
[SuperSU] Surge1223:
So much this.

When you don't have control over your own security, you really can't even gauge how secure your device really is, yeah qcom and Google totes have my security in their hands, pretty arrogant for a non security based company. I still get "YOU'RE A WINNER!" pop ups in chrome mobile, and these guys control my security, I'm totes secure (sarcasm). It's like not being able to opt out of McAfee when installing flash in windows, then it running with admin privileges.

I'm more worried about chimera, gms, qcoms services, is etc.

When I helped substratum go rootless, I was majorly disappointed in myself.

It was the single hugest bummer of my life.

(late reply, I know)

/end off-topic lol

(also half of the above is meant to be humorous, trying to see if we can actually get a cf "lol", dude never laughs)
[SuperSU] guitar1238751:
Lol, well said man. I agree with you. It's one of the main reasons I run arch instead windows. First thing I always do across all my devices is root.
[SuperSU] mrrocketdog:
dude cant even find his shirt. aint got no time for lol's. :)
[SuperSU] AJ:
a very weird problem on the Pixel :

root checker says i have root , but all rooted apps don't work properly ( Adaway , emojiswitcher )
[SuperSU] ecsnead69:
Anyone else having problems getting AdAway to install hosts in systemless mode with this release?
[SuperSU] DEVILOPS 007:
If you're using SuperSu then why use systemless adaway? Isn't magisk what you would want if you want to leave the system alone? If you wish to use adaway systemlessly with supersu then go to the adaway thread and search systemless and you should find a link to a mod that makes adaway work systemlessly with supersu.

Edit: Here is the link to systemless hosts for adaway to work systemlessly with supersu for you.

https://www.androidfilehost.com/?fid=24438995911977059
[SuperSU] mrrocketdog:
g*dd*mnit. nevermind.
[SuperSU] ktmom:
You do *NOT* need this additional script for systemless Adaway anymore. Not for a very long time. It's built into the app. Just use the newest release and check the systemless option in Adaway settings (for supersu , different method for Magisk).

[MENTION=2737665]ecsnead69[/MENTION], if you still need help, the Adaway thread is pretty active.
[SuperSU] j1gga84:
[MENTION=631273]Chainfire[/MENTION]

Okay I had the same strange behaviour on my Galaxy S5 (klte) than on my Galaxy Tab S (T805) when I flashed N (official ResurrectionRemix 5.8.3).

I flashed SuperSU 2.82 SR1 in the recovery because latest RR build comes without root.

Now the external SD is not visible and accessible via file browsers and I get a message about the external SD in the status bar.

I removed SuperSU inside the app, rebooted to recovery and installed 2.82 final, now the external SD is visible and accessible without any issues and the message about the external SD does not appear.

I don't know it you can reproduce this behavior.

Regards

Gesendet von meinem SM-G900F mit Tapatalk
[SuperSU] Ibuprophen:
Are you referring to the Adoptable Storage Notification (example image attached)?

***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] Chainfire:
Nonsense, I was mildly amused by something just last week.

Gah, the misinformation that has been going on for ages. SuperSU is systemless itself, and includes components designed to allow developers to make systemless mods. Very few devs actually made use of that, but Systemless Xposed and Magisk actually started as exactly such mods. There have been systemless AdAway versions for a long time using that system. In fact, the code to make AdAway systemless on SuperSU was a one-liner.
[SuperSU] Chainfire:
Unfortunately I cannot reproduce this.

I flashed NN 5.8.3 latest nightly on my S5/klte and tested with and without SuperSU v2.82 SR1 both, with SD card both in adoptable storage and portable storage mode, and did not run into any issues. There's a missing component to reproducing this.

Does the issue go away if you flash SR1 and disable the "mount namespace separation" option in SuperSU settings (and reboot) ?
[SuperSU] AnkitGourav:
Thus this beta build can pass SafetyNet.
[SuperSU] jerryasher:
On Google+, Chainfire writes:

So yes, I have a Moto E 2nd Generation 2015 running a stock rooted rom that has been experiencing the Dalvik Cache rebuild with every reboot.

SuperSU reports it is v.282

Has there been a fix for that posted yet or what can I do to help get that fix made?
[SuperSU] IronTechmonkey:
I haven't reported this before because I've not yet had a chance to test further and log, but since there are similarities and it is on the same device...

On a Moto E 2nd Gen 3G device (Otus) which had been running fine with CM12.1 and SuperSU regularly updated via Playstore for a few years, after applying the May 28 2017 SuperSU 2.82 update from Playstore I did not see dalvik/system cache rebuild but did see the following...

- Most apps requiring root FC even though they might properly request and receive SU permissions.

- Subsequent boot into TWRP recovery reports system is read only and offers change to r/w which I granted and which seems to have persisted since being changed.

- Clean flashes of CM12.1 with various versions of SuperSU going back to 2.5x yield the same results.

- After uninstalling SuperSU or removing root from within SuperSU, the affected apps no longer FC (but of course cannot perform their root functions).

- As the device serves a dedicated purpose I flashed LOS14.1 with native LOS SU just to get it running again, but would prefer to go back to CM12.1 with SuperSU.

When I have enough time to do so I'll check out beta and report from that.
[SuperSU] PRL77:
I just flashed the boot-to-root on a new Pixel I only got this month and it got soft bricked so I had to reflash to factory. There are multiple versions of factory images available. Which is the latest that works with boot-to-root?

https://xdaforums.com/showpost.php?p=72604085
[SuperSU] mkaraniya:
[MENTION=8315409]mkaraniya[/MENTION]
[SuperSU] Chainfire:
For starters, please get a full logcat immediately after boot, and attach it to your reply.

( adb logcat -d > logcat.txt )

A logcat of the FCs would be helpful.

Get the latest factory image, and use boot-to-root from here:

https://xdaforums.com/showpost.php?p=72686197&postcount=10481
[SuperSU] bemanet:
[MENTION=631273]Chainfire[/MENTION]: I have the same issue on SM-P905 when I flash the SR1. Also "mount namespace separation" brought no success.

I then flash 2.79 SR3 with TWRP and the SD card is again visible under storage.
[SuperSU] PRL77:
[MENTION=631273]Chainfire[/MENTION], I meant one of the actual factory images that Google provides here: https://developers.google.com/android/images

Those images are almost 2 GB while your link has files 19 MB so I assume that is YOUR software? I was asking which factory image is the latest I can use your boot-to-root with. I just flashed 7.1.0 (NDE63P, Oct 2016) because I read somewhere that the November update patched the root method?
[SuperSU] toknitup420:
Why not just temp boot twrp and flash su.
[SuperSU] 93fuelslut:
I'm on rc1 also. So if all I did was clean flash PN, just simply flash the new SU 2.82 sr1 pixel fix, flash vbs 3, and reboot? (May) Because I never messed with the boot image.

---------- Post added at 04:22 AM ---------- Previous post was at 04:21 AM ----------

Did you ever find out
[SuperSU] Chainfire:
I know what you meant, but it seems you don't understand what I meant.

First: you get the latest factory image from that page for your device, and flash that.

Second: fastboot boot the right boot-to-root image OR flash the ZIP with TWRP
[SuperSU] Chainfire:
The ZIP is for TWRP, the IMG is for fastboot boot, you can use either.
[SuperSU] gverma1:
SuperSU.... file is to flash in Twrp, and root-marlin.... file is for boot to root (after extracting img for from the zip).
[SuperSU] Chainfire:
logcat ?
[SuperSU] rejtő:
Hi! My phone Redmi Note 4 Snapdragon 625 version.

I flashed via TWRP this version: SuperSU-v2.82-20170528234214.zip

No MTP connection.

After unroot from SuperSU the MTP connection is OK.

New SuperSU version solve this issue? Thanks.
[SuperSU] amitroutray:
I am using it no issues. Working perfectly. Try with the latest build which is on the OP.

Triggered from rn4
[SuperSU] ktmom:
If the previous suggestion doesn't work, pull a log with and without SuperSu and see if it points you to the problem.
[SuperSU] Jon8RFC:
Pixel XL on NJH47B

Previously had v2.82 and wanted to flash v2.82-SR1. I didn't see the same actions on screen after flashing supersu as I do when using the verified boot signer, so I thought I should flash that rather than risk a non-booting device. I ran the v6.1 verified boot signer and everything has been fine until I tried to boot into recovery again. It booted but then would go into a crash dump; I could boot normally, or attempt a recovery boot and get the crash dump.

I grabbed the v8 verified boot signer, fastbooted into TWRP, was not prompted to enter my password to decrypt my sdcard, so I rebooted again to the bootloader, fastbooted TWRP and was promtped to enter my password and decrypted the sdcard. I flashed TWRP, flashed verified boot signer v8, rebooted into recovery, all was well, but when I tried to reboot to system (via TWRP or cold boot), I now can only boot into recovery, and cannot boot normally.

Rather than take another risk, have any of you Pixel XL users experienced this after flashing v2.82-SR1, and what was your solution?

I'm not sure why recovery was lost, but if I need to flash boot.img from NJH47B, will I be able to boot normally and have recovery, or did I FUBAR my device and have to start fresh?

---------- Post added at 06:53 PM ---------- Previous post was at 06:23 PM ----------

[MENTION=631273]Chainfire[/MENTION]

After the above, I flashed v2.82-SR1 again (without using the separate verified boot signer) and could boot normally...but have lost the ability to boot into TWRP recovery again. I read something about a reboot flag not being cleared, which led me to flash v2.82-SR1 again. I no longer have verified boot signer v6.1 to test flashing TWRP and signing to see if it would boot normally or not.

Is there anything you'd like me to try out, to find the cause (and, hopefully, not have to wipe things clean in the process)?
[SuperSU] Alxoom33:
Has v. 2.82 SR1 been reported to work with the Pixel C on ODP3? I tried to flash the current TWRP Recovery v. 3.1.1 for the Pixel C and it was not able to decrypt my data. So I did not try flashing SuperSU. As I lost my data, I have not tried again, to date.
[SuperSU] peterlee928:
this problem was documented earlier in this thread. [MENTION=631273]Chainfire[/MENTION] fixed the issue (along with a mounting issue):

https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post72686197

im sure there is a more efficient method, but this was my process. worked for me and others.

1) flash factory image (wanted to start clean... optional step)

2) fastboot boot twrp img

3) flash twrp

4) reboot to system

5) go to google play store ("gps") and disable auto-updates (avoids automatic updates of supersu that might cause problems... low probability, but many people got a "bad" update on one of the more recent supersu updates released in the gps... easily avoided...)

6) reboot to recovery

7) flash supersu sr1 pixelfix (see link above)

8) reboot to system

i left out all the minor steps (unlock developer options, usb debugging, etc) as it sounds like you are well versed enough to know all those.

if you are on the june update, then you do not need the verified boot signer.

my phone background:

verizon pixel xl

stock june update

twrp/supersu

cheers
[SuperSU] chakruhero007:
I take it it wont work for my phone

micromax canvas play q355
[SuperSU] Alxoom33:
Check on your device blog. What have you been using to root up to now?