[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,451
87,853
www.chainfire.eu
Encrypted Nexus 6 upgraded from rooted 7.0 to 7.1.1 N6F26Q via fastboot (bootloader, radio, recovery, boot, cache, system) gets into a boot loop when I boot TWRP 3.0.3-0 and flash SuperSU v2.79 SR2.

I have "Require PIN on start-up" enabled. Could that be interfering with the rooting process? Does it matter if I flash TWRP or simply boot into it? What logs can I provide?

I just flashed N6F26Q on my own Nexus6 with Pin-on-boot protection, it's working fine for me. If you're still having this problem, try deleting /data/su.img in TWRP and reflashing SuperSU.
 

yung40oz84

Senior Member
Sep 23, 2014
3,090
1,027
sites.psu.edu
A good developer would help @Chainfire debug and fix, just my thoughts.
 

Attachments

  • Screenshot_20170110-133528.jpg
    Screenshot_20170110-133528.jpg
    114.5 KB · Views: 1,054
  • Like
Reactions: habylab and bdwilk

scanno

Senior Member
Mar 27, 2008
2,250
3,821
Arnhem
Redmi K20 Pro
Xiaomi Poco F3
It has nothing to do with f2fs. Clark also has a data partition (stock) that is formatted as f2fs and has not problems. Also running omnirom.

Verstuurd vanaf mijn ONEPLUS A3003 met Tapatalk

---------- Post added at 07:47 PM ---------- Previous post was at 07:43 PM ----------

I really wouldn't know what. Disappearing root is very difficult to debug without a live device in my hand.
It is not really a disappearing root. If I am in a terminal session and want root (typing su) I see errors. Do not know what errors because a working supersu was not really on my to-do list.
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,630
39,962
Halifax
GT-i9250
Google Nexus 4
A good developer would help @Chainfire debug and fix, just my thoughts.

Further down arter97's timeline he points to Jan 6th as having the necessary info to fix. Reading back I think it's actually on Jan 5th and is apparently kernel/recovery-side and requires an update to the latest f2fs or at least include the following:
https://git.kernel.org/cgit/linux/k...le.git/commit/?h=linux-3.18.y&id=7a895023cc2c

I guess TWRP and ROM/custom kernels will all need this.

@Dees_Troy @Captain_Throwback @_that @flar2 @franciscofranco
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,451
87,853
www.chainfire.eu
@Chainfire

Hi,
SuperSU 2.79-SR2 (SR1 too) does not work on my Nexus 7 (2012) running stock Android 4.4.4.
I flash it in TWRP and it look like "ok", but after rebooting SuperSU say that I need update binary file and his update ("Normal & TWRP) failed.
Stable 2.79 work fine.
I attach logs.

This should be solved next update.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,451
87,853
www.chainfire.eu
Further down arter97's timeline he points to Jan 6th as having the necessary info to fix. Reading back I think it's actually on Jan 5th and is apparently kernel/recovery-side and requires an update to the latest f2fs to resolve the following:
https://git.kernel.org/cgit/linux/k...le.git/commit/?h=linux-3.18.y&id=7a895023cc2c

I guess TWRP and ROM/custom kernels will all need this.

@Dees_Troy @Captain_Throwback @_that

Arter told me he will post all the details here in a bit.
 

chipiko

New member
Jan 6, 2017
4
0
56
bacau
I restored and all is well. Guys please a ROM for HTC Desire 610 !!!! Most of the description is not compatible with my phone.
 

arter97

Recognized Developer
Oct 14, 2012
3,879
34,618
26
Seoul
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.
 
Last edited:

lordmago

Senior Member
Feb 13, 2010
489
142
Near Venice
If I have a rooted 6.0.1 Android in hand, what is the easiest reliable way to determine if the SuperSU installation is systemless or not? Could not find the answer googling or search ...... TIA :)

EDIT: I think the answer is if I have /su/bin/su , then it's systemless. Appreciate confirmation or other correct ways - thanks.
It's written in SuperSU app, wether it's installed systemless or not.
 

mekayzer

Senior Member
Oct 25, 2010
359
68
Project Treble
Xiaomi Mi Pad 5
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.
Man you are the boss
 

veez21

Senior Member
Feb 22, 2016
2,172
2,765
Guess Where
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.

Well, this sums up almost everything. Probably a "smoother" sailing for devs and the other guys from now on.
 
Last edited:

djb77

Recognized Developer / Inactive RC
Oct 2, 2011
3,094
7,367
46
NSW
github.com
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.

Thanks for this info, I'll look into it :)
 
  • Like
Reactions: 2x4 and shadyshadow

theoverseer

Senior Member
Dec 13, 2008
260
24
Can anyone shed any light on why my Shell commands within Tasker are no longer working in the two recent SR builds?
 

chipiko

New member
Jan 6, 2017
4
0
56
bacau
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.

Thank you for the information. I will remain at the current version. But TWRP can delete some applications that came with your phone? Where are we all searched through TWRP? Thank you !
 

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,085
36
/home/renderbroken/android
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.

Your hard work neither goes unnoticed nor is it not appreciated. Thanks for all you do. Thanks for the information. This resolves the issue I was having with Upstream F2FS.

I know devs can be under appreciated and under funded for that matter. I donated without reservations.

34U15922V7690451X

Kind Regards,
Zachariah
 

grep_i

Senior Member
Sep 19, 2015
1,551
621
f2fs with Android story is always complicated.

So why is SuperSU broken with many custom ROMs:
systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

This “fix” is rather dumb :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
(The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
So you have 2 choices :
A. Cherry-pick that fix separately
B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


But there are more stories to be told, unfortunately.
Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

Without this fix, the kernel will panic upon reading any data.


So we took care of the method A.
However, there is still an issue with method B : deadlock.

As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
It took about a month to bisect it, and I got the culprit commit :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


TL;DR
It’s not @Chainfire 's fault.
You have to ask the kernel developer to fix the issue.
2 methods for the kernel developers

A. Incorporate only the necessary 2 fixes to fix loopback images :
https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
(A little credit would be appreciated, as it took me a frustrating month to bisect this)

Thanks.

Thanks[emoji1]
I love your work and a lot of others love your work too.

After two days of struggling to get things working with f2fs filesystem I found your post a nice and detailed piece about f2fs which if I should have known this before testing (I would not even tried it then).

Now I know why I did not get it to work easily and reverted back to ext4 because it was not possible to root properly the root send to come and go it's not stable.

Also could not boot up normally all the time, sometimes it booted to full system keeps working for 30 second to a minute and then bootloops go to full system again and on and on.

So after formatting /data and /cache to f2fs it automatically reformats /cache back to ext4 during the flashing of the ROM (in my case Nexus 5 stock ROM December 2016 patch level) but not /data that partition stays f2fs.

Also restoring files back to f2fs did not seem to work it complains about the destination not being ext4 and stops, in my testing it did react like that, maybe I did something wrong there but I would not know for sure.

For now I stay out of the f2fs business as it does not seem to be full grown to me.

Keep up the good work,

Peace and respect

Sent from my Nexus 5 using XDA-Developers Legacy app
 
Last edited:

dahawthorne

Senior Member
Nov 15, 2014
2,135
1,927
Brighton
People, can I make a plea for a bit of common sense when replying. At least 6 people have copied arter97's entire long post, completely unnecessarily, which means that we have to spend more time scrolling than reading.
Copy only the part to which you're replying, and if it's a "thank you" then even that is unnecessary.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2533
    This thread is for SuperSU releases that are still in testing, and are not yet available through the Play store. The main thread for stable SuperSU releases is located here: https://xdaforums.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703. The changelogs are in the old release thread.

    Please keep track of the version numbers in the thread titles, as the latest test release may not always be newer than the latest stable release.

    The latest test release is:
    SR5-SuperSU-v2.82-SR5-20171001224502.zip
    RELEASE NOTES
    That is a recovery flashable ZIP (I recommend FlashFire or TWRP). If you want to install via APK, it is also present inside the ZIP, in the common folder.
    617
    unSU Script zip -- Unroot with ease!

    Originally this was a little zip to help with uninstalling the old system-modifying version of SuperSU. It properly restores all the original files the SuperSU installer backed up (so, file-based OTA friendly!) and removes any files added by the installer/app. I figured other people might find it handy as well so it's attached below. Be aware, if you flashed SuperSU twice mistakenly, the SuperSU installer wasn't written to recognize that and so you've lost your originals; a system.img flash WILL be necessary in your case.

    Due to popular demand by the custom ROM community using this to unroot and pass SafetyNet checks/use Android Pay, etc., the script has been expanded to unroot Koush's SuperUser, ROM su binaries, as well as SuperSU Systemless (su.img and BINDSBIN), phh's Superuser (which is also systemless), and now Magisk and LineageOS addonsu.

    Note: To completely remove all traces of the systemless roots, you still need to flash a different, unrooted boot.img, likely the default one that came with the ROM. You can extract it from the ROM zip (or a /data/stock*.gz backup from your root solution before flashing unSU) and flash it using TWRP's awesome "Flash Image" functionality, or, "dirty flashing" the ROM zip should also work.

    My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

    P.S. If you found this handy then please check out my Odds and Ends thread for more flashable goodness. :D

    Previous download counts: 58944; 158506; 59850; 226692
    578
    f2fs with Android story is always complicated.

    So why is SuperSU broken with many custom ROMs:
    systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
    The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
    This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

    This “fix” is rather dumb :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

    The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
    (The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
    So you have 2 choices :
    A. Cherry-pick that fix separately
    B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


    But there are more stories to be told, unfortunately.
    Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
    There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

    You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    Without this fix, the kernel will panic upon reading any data.


    So we took care of the method A.
    However, there is still an issue with method B : deadlock.

    As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
    It took about a month to bisect it, and I got the culprit commit :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

    I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
    Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


    TL;DR
    It’s not @Chainfire 's fault.
    You have to ask the kernel developer to fix the issue.
    2 methods for the kernel developers

    A. Incorporate only the necessary 2 fixes to fix loopback images :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
    (A little credit would be appreciated, as it took me a frustrating month to bisect this)

    Thanks.
    348
    --- reserved ---
    189
    @ everyone

    This post is likely an important one going forward, it could be the answer to various issues people have on 6.0 related to /system.

    The conversation below pertains specifically to Nexus 6 @ 6.0.1, which has an almost full /system, but I'll bet the issue exists on all Nexus devices.

    Do you mean that there's even less space than on 6.0?
    Titanium Backup reports that there 15.6 MB free. Shouldn't this be enough for a very small mod such as an edit to build. prop?

    So after some further investigation, something pretty odd is going on.

    ext4 (the filesystem) has various types of reserved blocks.

    I suspect the tools on booted Android do not count one type of reserved block. Indeed, when you use "df" utility (both toolbox and toybox), it shows 15mb or so free. Using the same "df" utility in recovery (busybox) shows 0b free. It does show that not all blocks are in use, but the remainder is likely reserved.

    If you use a root shell on either booted Android or in recovery, trying to write contents to a new file in /system will fail. To make matters worse, file creation succeeds, but writing content does not, so you end up with a 0 byte file. You need to delete a few extra megabytes of files, before you are able to write even 1 byte to a new file!

    Many editing tools remove the old file and write a new file at the same spot rather than truly editing a file. I'm not sure if the latter has any chance of succeeding, but the former would definitely fail in this scenario.

    While the issue is understandable technically, it is likely to trip up a lot of tools, as the error is generated at the least expected moment.

    This issue is a magnet for file corruption and bootloops. Beware this issue when modifying anything on /system!

    DEVS Immediate hunch is that the difference is explained by usage of struct statfs's bfree vs bavail member.

    TL;DR Yes, even though TiBu and whatever other tool are showing you megabytes free, adding/modifying files is likely to give unexpected results on a (near-)full /system partition, and an unlucky edit can definitely prevent the device from booting! Can't give you exact numbers right now, but before modifying files or adding files to /system, I would recommend deleting files until you have at least 30-ish mb free.