yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
Yikes. Guess I'll have to be checking this out. Remounting r/w, even without modifying anything, is a bad thing. OTAs can fail just because of the remount without any other modification.

Can you check on your N7 2013 what happens to this file:

"/sys/fs/" + Current_File_System + "/" + block + "/lifetime_write_kbytes"

Before, between, and after the various mounts?

I'll do so myself later if not.

(2) is not a bad idea, I just might do that.

The way to force system(less) install is already documented, if you need it to be a certain way. Please articulate exactly why you need to change the default.

Remember you need kernel support for root either way, both in system and in systemless mode.
[SuperSU] IronTechmonkey:
http://xdaforums.com/showthread.php?p=23427824
[SuperSU] deC9r:
Did anybody test it with htc one m7 with [ROM][MM][6.0.1] CyanogenMod 13.0? I installed it with the latest twrp manually (since the supersu app doesn't work) but i got a bootloop at the bootanimation. I think i just wait for a release that works in the meantime i'm using chrome for fb since it's force closing.
[SuperSU] IronTechmonkey:
You can try the latest version (presently 2.64) in the WIP thread (but first read-up on it and back-up your stuff0 or wait for it to get promoted to beta which might happen soon.
[SuperSU] mielletseed:
This is samsung's knox and pretty normal ...
[SuperSU] K-alz:
Then I'm golden. Thanks
[SuperSU] bobby janow:
I don't see the 5x as supported. I bought it some time ago so I still have access to it.
[SuperSU] Chainfire:
I cannot replicate the FC issue. Please, someone provide logcats, dmesgs, etc.
[SuperSU] vt0r:
I knew I forgot to do something! Sorry about that. Here is the archive with all three logs - logcat has all the fatals.
[SuperSU] bobby janow:
I'm sorry, my first impulse was to get the phone working again as it kept saying no sim detected. (Google Fi) I panicked and restored before getting any logcat. However, I did not do this in recovery root shell before the install... "the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu"). So perhaps that is the issue we are all having, we just flashed 2.64 over 2.62-3? If that is the case I will try it again and get a logcat this time if the same thing happens.
[SuperSU] cLogic:
flashed cm13-20151217-d2att on My galaxy s3 d2can followed by superSu beta 2.64 ... working perfectly :D

screenshot shows systemless install
[SuperSU] Zen Arcade:
Variation on option 1 for those comfortable with creating/editing/running scripts - here's one I created after manually installing Stericson's 1.24.1 busybox to /su/bin (removes all symlinks which mirror binaries in /system/bin except "sh"):

(That said, my vote is for option 2)

#!/system/bin/sh

cd /su/bin

rm basename
rm blkid
rm blockdev
rm bzcat
rm cal
rm cat
rm chgrp
rm chmod
rm chown
rm chroot
rm cksum
rm clear
rm cmp
rm comm
rm cp
rm cpio
rm cut
rm date
rm dd
rm df
rm dirname
rm dmesg
rm dos2unix
rm du
rm echo
rm egrep
rm env
rm expand
rm expr
rm false
rm fgrep
rm find
rm free
rm grep
rm groups
rm gzip
rm head
rm hostname
rm hwclock
rm id
rm ifconfig
rm inotifyd
rm insmod
rm ionice
rm ip
rm kill
rm ln
rm logname
rm losetup
rm ls
rm lsmod
rm lsof
rm lsusb
rm md5sum
rm mkdir
rm mknod
rm mkswap
rm mktemp
rm modinfo
rm more
rm mount
rm mountpoint
rm mv
rm netstat
rm nice
rm nohup
rm od
rm patch
rm pgrep
rm pidof
rm ping
rm ping6
rm pkill
rm pmap
rm printenv
rm printf
rm ps
rm pwd
rm readlink
rm realpath
rm reboot
rm renice
rm rm
rm rmdir
rm rmmod
rm route
rm sed
rm seq
rm setsid
rm sha1sum
rm sleep
rm sort
rm split
rm stat
rm strings
rm swapoff
rm swapon
rm sync
rm sysctl
rm tac
rm tail
rm taskset
rm tee
rm time
rm timeout
rm top
rm touch
rm tr
rm true
rm truncate
rm umount
rm uname
rm uniq
rm unix2dos
rm uptime
rm usleep
rm wc
rm which
rm whoami
rm yes
[SuperSU] osm0sis:
Great idea, but I wouldn't recommend executing that. I'm pretty sure app_process is required by SuperSU (hence the reason /su/bin takes precedence over /system/bin is by design). :eek:

For those that require Busybox (I certainly enjoy having awk, among other things) I have created my own Busybox installer zip that is "smart" in that it detects systemless installs and will target /su/bin over /system/xbin, wipes previous busybox (and only busybox) symlinks from the target location, and then create symlinks in the target location based on what the busybox binary itself outputs as having included applet-wise; in the case of systemless install also excluding creation of symlinks with competing links/binaries in /system/bin. :)

http://v.ht/osm0 -- http://xdaforums.com/showthread.php?t=2239421

As previously stated, Stericson's installer also has "Smart install" in the expandable menu under the main dialog, you just need to check the first box within to Enable it, the rest defaults to the appropriate excluding behavior we want for /su/bin (until Chainfire adds /su/xbin).
[SuperSU] Chainfire:
Did you see the commands in my other post?

No worries if you didn't or don't have time, just let me know, I'll dig up my N7 from somewhere.
[SuperSU] Zen Arcade:
Whoops... Fixed in my prior post - I also bow to your greater script foo. That's a nice bit of code (creating only the needed symlinks) in your busybox installer.
[SuperSU] osm0sis:
I got it. :)

Here's the mount check I use in my scripts to mimic EDIFY:

# is_mounted <partition>
is_mounted() {
case `mount` in
*$1*) echo 1;;
*) echo 0;;
esac;
}

Placing that before toolbox_mount should work around it for most, then checking between the two methods in toolbox_mount should do so for the rest.

On my N7 2013 freshly flashed with system.img, "mount ro only" set and persisting through reboots:

mount -o ro /system; #creates /sys/fs/ext4/mmcblk0p22
cat /sys/fs/ext4/mmcblk0p22/lifetime_write_kbytes; #outputs 0
mount -t ext4 -o ro,remount /dev/block/mmcblk0p22 /system; #file dates remain the same
cat /sys/fs/ext4/mmcblk0p22/lifetime_write_kbytes; #outputs 4
mount -t ext4 -o ro,remount /dev/block/platform/msm_sdcc.1/by-name/system /system; #file dates remain the same
cat /sys/fs/ext4/mmcblk0p22/lifetime_write_kbytes; #outputs 8
reboot recovery; #triggers "mount ro only" being unset/un-persistent.
mount -o ro /system; #creates /sys/fs/ext4/mmcblk0p22 again
cat /sys/fs/ext4/mmcblk0p22/lifetime_write_kbytes; #outputs 4
[SuperSU] _that:
How can remounting read-only increase lifetime writes? And how can lifetime writes decrease by rebooting?

I also still don't understand how TWRP would be able to write to a filesystem that's mounted read only. It might try (due to a bug), but it should not succeed.
[SuperSU] osm0sis:
You tell me! :p

Possibly writing between the remounts? It starts r/o and the remounts are also r/o. Definitely sounds like bugged behavior, either way.

I'm thinking TWRP only does its own stuff to /system after the reboot because once the lifetime writes increases it stops respecting "mount r/o only" and does what it wants. The related bug here that I wrote you about before where "mount r/o only" stops persisting must have to do with a routine that checks the lifetime writes. I'd suggest TWRP shouldn't check that after the initial dialog to ask, and should keep it "r/o only" if I've set it to, regardless of the lifetime writes.
[SuperSU] Empty Hand:
Is there a way within the su app, or with a terminal command to verify whether root is systemless or not?
[SuperSU] _that:
Are you sure that you're using the lastest version of the TWRP code (in the android-6.0 branch)? Because as far as I know, that's exactly the implemented behavior. I did neither write nor test that code, but I know that we had to give up the lifetime writes check and make it a persistent user setting because lifetime writes turned out not to be a reliable indicator of an untouched system partition (we'd actually want to know if the dm-verity checksum is still correct).
[SuperSU] Captain_Throwback:
8 posts ago. (from yours)
[SuperSU] Chainfire:
I've been trying to replicate this exact behavior on other devices, but can't. I don't see why this would happen, and I can't actually see it happening. Yes, I will dig up the N7, and yes, I will probably implement the workaround. It's just weird. The only thing that I can think of is that somewhere in one of the binaries, it first mounts rw then switches to ro.

By the way, according to Linux docs, the device parameter in mount is actually ignored when remounting, so using /dev/block/platform.... at one point and /dev/block/mmcblk... at another shouldn't really matter. If it does, that's even more weird.

At least if you mount in write mode, a counter in the ext4 header is updated. This causes a write to the block device (= underlying partition on the flash chips), and thus increases lifetime writes.

How it decreases when it reboots, I don't know. But one theoretical reason is that a filesystem check is performed at boot which resets these headers, but sets it to back to one write (usually 4kb due to block size) so you can still make the distinction between a never-modified and a modified-at-least-once filesystem.

The filesystem can of course be marked read-only while the block device isn't, and information in the block device (such as the ext4 headers) may be updated while there is no difference to the files themselves.

I don't know the entire logic behind TWRP's actions, but that .../lifetime_write_kbytes file is checked. That's why I had you output the contents.

If /su/bin/su exists, you're running systemless. If /su/bin is in $PATH, you're running systemless.
[SuperSU] Alxoom33:
Yes, go to your Root Explorer and fo to the Root tab. If you find a folder labeled su and it has other folders inside, you have Systemless Root. Otherwise you have root in your System Partition.
[SuperSU] HassanM:
Just for information, whats the difference between the 2?

Thanks in advance
[SuperSU] thgxda:
yes, finally this worked for me too, at least for "cm-13.0-20151223-NIGHTLY-peregrine" and "BETA-SuperSU-v2.64-20151220185127".

I also was able to enable the "su.d" as replacement for the "init.d" what does not work very good, at least no in cm13.

Create su.d-directory:

mkdir /system/su.d/
chmod 0700 /system/su.d/

Place your script that should be startet in this directory:

vi /system/su.d/01sudlog
->
#!/system/bin/sh
#
timedate=$( /system/bin/date +%Y-%m-%d,%T )

/system/bin/log -p i "Initialize su.d ..."
echo $timedate": Initialize su.d ..." >> /data/var/log/sud.log
-------------------------------------------
chmod 0700 /system/su.d/01sudlog

This script just creates some log-entries to see if it works, nothing more.

But "logcat" is not runnig after doing a "su -" (no output), don't know why.

I get also an error, when I connect via "adb shell", because an id is missing, probably this should be the "shell"-user:

> adb shell
id: unknown ID 2000
COLUMNS=112;LINES=35;export COLUMNS LINES;
2000@peregrine:/ $

And I still have an other problem, that might not only to be SuperSU-related:

2000@peregrine:/ $ pm list users
Users:
UserInfo{0:eek:wner:13} running
2000@peregrine:/ $ su -
COLUMNS=112;LINES=35;export COLUMNS LINES;
root@peregrine:/ # pm list users
Error: Could not access the Package Manager. Is the system running?

For running the "crond" a symlink from /system/bin to /bin is mandatory, but if this link exists, the package manager does not work as root anymore :(

Any idea?

kind regards, thgxda
[SuperSU] osm0sis:
I'm just using whatever you guys have up. Is there somewhere new I should be checking?

https://dl.twrp.me/flo/ is still at 2.8.7.0 - built prior to that change I'm sure. I'd love to test if someone wants to supply me with a newer build. :)
[SuperSU] purejoy:
Sorry, I left my xt1095 at home this morning. I get the logcat outputs now and some screenshots.

The phone is Moto X 2014 pure edition XT1095 running 6.0 marshmallow (24.11.18.us).

BL 0x6016 unlocked

TWRP- 2.8.7.1-victara

ROOT: 2.64.zip (system mode caused FC errors, system-less mode works fine)

ps: I can confirm 2.62 works fine on xt1095 running 6.0.

Update: 2.64 system-less mode works fine on xt1095 running 6.0.
[SuperSU] shoey63:
I don't think that will help. I compiled a fully up to date twrp for Leo a few hours ago and flashed SuperSU 2.64 on unmodified z3 MM concept rom. Rooted without any problems. Then I did a full unroot to get back to pure stock again and got the dreaded "Your device is corrupted and may not work properly " message on reboot :(

Clearly /system has been mounted r/w at some point, even with latest twrp - fancy new material design gui and all:p
[SuperSU] psychomaniac189:
do i have to flash a modified boot image or kernel when i already have root with superSU? the rom came pre rooted with suupersu installed.
[SuperSU] Chainfire:
@ all

FC issue has been found and solved. It will be gone next update.

If you are suffering from it right now, this command will fix it:

ln -s /system/etc/security/mac_permissions.xml /data/security/current/mac_permissions.xml

I have confirmed the issue on flo. Haven't been able to replicate it on any other device yet though.

I have to use a MultiROM TWRP (also 2.8.7.0) though, because the original TWRP doesn't work on new flo hardware models. And though I've sent Dees_Troy the patch, I haven't seen a fixed version materialize.
[SuperSU] Chainfire:
Have you guys not considered the remount counter? There is one in the ext4 header. I'm not sure which OTAs do and don't check for it, but I know some OTAs check exactly that.
[SuperSU] :
Flashing the 2.64 beta makes a whole load of system apps crash immediately (settings, telephony provider etc).

I was on cataclym rom+ franco kernel. Then I reflashed cata to get back to stock kernel.

When I then install 2.64 again everything starts fcing. I even tried to unroot before flashing cata, but it didn't work. Any ideas?
[SuperSU] Chainfire:
The answer is quite literally two posts above yours ... :/
[SuperSU] :
Ah damn, should get my eyes checked out. What would be the best way to run this command if I don't have access to a computer?
[SuperSU] jorgen2009:
Here is a build freshly compiled from today's OmniROM sources:

https://drive.google.com/open?id=0B60I5nmVaj3-aERlOWhvMDNNRGc

MD5: 693179B31A11D29F9461E89E7C9C5462

For reference here's the ROM as well:

https://drive.google.com/open?id=0B60I5nmVaj3-b1dzMlNEXzhoWEE

MD5: 1C1CA4FEC4A959C007AF90CC0C25FFB9

There were quite some chances for the recovery the last few days and certainly a lot since the latest official build.

Big warning though: these files are both UNTESTED as I don't own the device. I just compiled them without any changes to the OmniROM sources.
[SuperSU] regisso66:
Try Terminal Emulator from playstore.
[SuperSU] anoops_id:
Im running on stock 6.0.0 and rooted with recovery twrp-2.8.7.1-hammerhead.img and hellscore hC-b11-M kernal. Im using cataclysm Nov release 6.0.0 as my daily driver in secondary rom (and its pre rooted by the rom builder) and stock 6.0.0 as my primary rom.

Recently cataclysm released its Dec 8 stable release 6.0.1, i have clean flashed the same in secondary and its working perfect but no root access, after going through too many forums in xda i have flashed SuperSU 2.61 on the same to root it. but its just showing patching ramdisk in twrp more than 30 mins and nothing is happening.

Now kindly help me to root the same(cataclysm Dec 8 stable release 6.0.1) in secondary. Can i flash SuperSU-2.64 directly over cataclysm?? is that safe?? is that make any problem to primary stock??? is this brick my device??? pls pls pls guide me as im not getting any proper answer from any of the forum and there is too many members like me still confused flashing the SuperSu 2.64 in a multirom and its after effects.

in short can i flash SuperSU 2.64 over a secondary rom in multirom via twrp for root priviliage, will it bick or harm the device

Primary Rom: Stock 6.0.0 as primary, Kernal : hC-b11-M

Seconary Rom: Cataclysm Nov release 6.0.0, Kernal : hC-b15-M

Recovery: TWRP 2.8.7.1

Baseband: M8974A -2.0.50.2.27

Booloader: hhz12k

awaiting for your valuable reply hope you will help me...

i have posted this in many forums but nobody is giving me a right answer. can u pls help me
[SuperSU] _that:
We assumed that the lifetime writes were more reliable than the mount count. But there are ROMs or updates that do mount /system writable, change some files, and then restore the dm-verity checksum, so neither lifetime writes nor mount count will catch this case.

I wasn't aware that OTAs specifically check the mount count - I thought they fail because they are binary patches to the whole partition image.
[SuperSU] tamaraxxx:
I am having trouble with TB and backing up files to external sd-card (only internal sd-card is possible). I get the error message that the sd-card isnt writeable but file Explorer and nandroid are working fine. Writing with those programs to the external sd-card is no problem at all.

Have installed supersu version 2.52 and 2.64 but that didnt make a difference. All settings in apps have been checked and are set correctly.

See the images below for error message TB. Does somebody knows whats wrong?

Running nightowl cm13 (6.0.1) using philz recovery on my Note 1 (gt-n7000).
[SuperSU] Ch3vr0n:
That's a TB issue and has been described in the release notes.

Verstuurd vanaf mijn Nexus 7 met Tapatalk
[SuperSU] payne_307:
Is the BETA SuperSU v2.56 working with Bacon (OnePlus One) on AOSP builds? CM13 comes pre-rooted and there is no need as such for SuperSU.
[SuperSU] osm0sis:
I think it happens on my N5 as well, which is why I assumed it was universal. It's possible I'm confusing it with the related TWRP issue (from briefly mounting rw); mine's currently disassembled awaiting a new screen, so I can't test further on that device at the moment. Maybe [MENTION=4878287]_that[/MENTION] can see to getting that patch merged finally for the newer flo devices. :)
[SuperSU] osm0sis:
Thanks! No dice though:

E:Size (11558912 bytes) of image '/sdcard/TWRP/recovery.img' is larger than target device '/dev/block/mmcblk0p25' (10485760 bytes)
[SuperSU] _that:
The patch is merged in the Omni kernel since at least 5.0, so probably it just needs a rebuild. I don't know which tree is used to build the official TWRP release for flo, and I don't have access to the build server.
[SuperSU] osm0sis:
Thanks for checking that! Ah yes, I'd heard of similar issues before with f2fs functionality for the Galaxy Nexus repeatedly not making it in because the official builds are from Dees' private branches or something?
[SuperSU] v12xke:
On a completely fresh, clean slate install of stock ROM 6.01 on a Nexus device (5,6,7,9) how will Super SU 2.64's install script interpret and proceed to root... system or systemless? Will the resulting boot.img be no-force encrypt? Thanks.
[SuperSU] Ch3vr0n:
Systemless duh

Verstuurd vanaf mijn Nexus 5 met Tapatalk
[SuperSU] v12xke:
Ok thanks. It wasn't as obvious to me for 2.64 based on CF's notes in the WIP thread. How about the second part of the question? Since the systemless root method writes to the boot.img , is resulting boot.img modified to no-force encrypt?
[SuperSU] Ch3vr0n:
Afaik it disables if encrypted but can be reencrypted

Verstuurd vanaf mijn Nexus 5 met Tapatalk
[SuperSU] drewski_1:
I tried Systemless 2.64 on Secondary Multirom on Deb (N7 2013 LTE) and also the flash did not finish. Both my Primary & Secondary got messed up and needed to be re-flashed. I'm currently using 2.52 System Root on the Secondary ROM with no issues.

Guessing Multirom needs to be updated a bit to correctly deal with Systemless.
[SuperSU] madbat99:
Change the storage provider (right above where it says folder not writable). Use document provider storage, then select external.
[SuperSU] tamaraxxx:
Thanks madbat99. This workaround is working great.
[SuperSU] gamerZ1:
ln -s /system/etc/security/mac_permissions.xml /data/security/current/mac_permissions.xml

Terminal says permission denied.How do I grant permissions?to this command that Chainfire writed.
[SuperSU] osm0sis:
Sigh... type "su" first.
[SuperSU] Captain_Throwback:
Just to clarify - that isn't a workaround - that's how storage on Marshmallow works, and the reason the option exists in the app.
[SuperSU] drewski_1:
there's a Root toggle option in the CM Dev Options settings. make sure it's on.
[SuperSU] Chainfire:
Well I know that some of the very first OTAs that did the block-level patching checked specifically the ext4 header for this, as a quick check to abort before checksumming the entire partition. I am unsure if they still do that, though.

But as you say, as some ROMs patch around stuff anyway, it's probably not reliable either. I think tune2fs even has a parameter to reset all this.

Either way, long time since I looked into this.
[SuperSU] shoey63:
Can you (or anyone else) remember the command to set lifetime_writes back to zero?
[SuperSU] Chainfire:
v2.65 posted, see the WIP post and the changelog post
[SuperSU] Midomad:
It's safe to flash on top of v2.64?
[SuperSU] joeyfong:
Just did
[SuperSU] vjtigas:
Thank you! I have v2.64 (updated from v2.52 using APK) on my 4.4.2 device. You said you recommend flashing the ZIP. So to update SuperSU to v2.65, can I flash the v2.65 ZIP?
[SuperSU] Midomad:
And? :)
[SuperSU] Midomad:
http://xdaforums.com/showthread.php?t=3219344
[SuperSU] rcrd-pt:
i instaled 2.65 and apps were saying i have no root. i flashed over 2.64. is that the right procedure?
[SuperSU] Chainfire:
....

Which apps are saying they have no root? Did they work with 2.64? Which device? Which firmware?
[SuperSU] rcrd-pt:
well all apps that require root.

nexus 5 2013 cataclysm ROM 6.0.1.

yes they were working with 2.64.

maybe if i flash unsu.zip and flash 2.65 will work?
[SuperSU] Chainfire:
On 4.4 you can do either, doesn't matter.

You can certainly try.
[SuperSU] Vule991:
2.65 systemless working excellent (Official CyanogenMod 13- LG L90)!

All apps have root.

Working with Meefik's BusyBox.

:good:
[SuperSU] flocke000:
Dirty flashed systemless 2.65 over 2.64 and all Apps that require root are still working without problems (Nexus 5X with Chroma and ElementalX).
[SuperSU] dmb219:
Same result here with stock 6.0 on Moto X XT-1575.
[SuperSU] Taomyn:
What's the best thing for 2.65 and the new /su/xbin if on 2.64 with BusyBox pointed at /su/bin?

Uninstall BusyBox, update to 2.65 then apply BusyBox box to /su/xbin?
[SuperSU] rcrd-pt:
it worked bro.

chainmeister!
[SuperSU] Chainfire:
Yeah... if that fails to work properly, just remove the entire /su/bin folder and reflash the ZIP, then install to /su/xbin
[SuperSU] rolex0815:
Nexus 5 here, 6.0.1 (MMB29K).

I flashed SuperSU 2.65 over the installed 2.62-3 and got stuck after reboot, because I also flashed a modified framework-res.apk.

Okay, back to beginning I thought, reflashed boot.img and system.img (without flashing SuperSU) via fastboot, now Android comes up, but just before the GUI starts, I'm hanging now with "the process com.android.phone has stopped."

What can I do now, even after flashing new boot.img and system.img?

EDIT: Got it back to work, after completely resetting everything.

No root here yet.
[SuperSU] rebretz000:
"nevermind"
[SuperSU] wilflare:
(1) systemless root and OTA - I am reading conflicting information about whether having a systemless root will allow the phone to receive, download and install OTA updates.

- I understand that the norm is no but with systemless root (and the BETA allowing for auto-boot.img patching), has anything changed?

(2) 2.64/2.65 SuperSU.zip - It seems like the recent two updates may result in a non-systemless root afterall. Is this the case for the Nexus 6P?
[SuperSU] nathanchance:
1. You should be able to take OTAs since /system is unmodified (only if you did not force /system to be r/w though). You will just reflash SuperSU to get the patched kernel.

2. Depends on your ROM. Stock will have to use systemless as it doesn't have the necessary SELinux policy modifications but certain ROMs (like Pure Nexus and Cataclysm for example) have made those changes so you will need to force systemless root out of the installer via the terminal command "echo SYSTEMLESS=true>>/data/.supersu" before you flash it.