Database Info

[KERNELFIX] damageless/Fresh 2.0b2 kernel w/ Apps2sd REV 3

I have tested the following with the frest 2.1 2.0b2 build and it does enable Apps2SD.
Ver 3 now should work on fresh fine, and damageless (sometimes I found enabling apps2sd on damageless causes lockups at boot, these can be fixed by doing WIPE for DATA for now) :/
MAKE NANDROID BACKUP
This has been tested on: Fresh 2.0b2
ADDED INSTRUCTIONS TO ENABLE ON DAMAGELESS
Also this has been edited so the first few pages refer to the old style before I had signed zips working. xD
Flash the Update Zip Attached VIA recovery menu. That means copy it to the root of your sdcard (aka /sdcard/).
I tested this after a fresh wipe with a blank ext2 partition and one vfat (normal). I did not even boot it first run but you should be able to flash this on an existing rom. Others can test on other roms but I am using this for now on fresh 2.1 2.0b2.
Afterwards run the following after booting
FOR VER 3 SIGNED
Code:
[B]
adb remount
adb shell
cd /system/bin
ln -s /system/xbin/busybox /system/bin/sed
ls -l /system/bin/sed # make sure it exists
cd /
apps2sd on
# should say apps2sd enabled
reboot[/B]
FOR VER 1 SIGNED
Code:
[B]
adb remount
adb shell
cd /system/bin
busybox --install /system/bin
ls -l sed # make sure it exists
cd /
chmod 755 /system/bin/apps2sd
chmod 755 /system/xbin/apps2sd
apps2sd on
# should say apps2sd enabled
reboot[/B]
FOR VER 3 SIGNED for DAMAGELES
Code:
[B]
adb remount
adb shell
cd /
apps2sd on
# should say apps2sd enabled
# below fixes up the scripts generated by the 'apps2sd on' line.. who ever wrote that had it put DOS CR/LF on the ends and thats whats breaking APPS2SD on damageless!
cd /system/etc/init.d
dos2unix 04apps2sd
dos2unix 05userinit
reboot[/B]
Enjoy

Will this work on the other 2.1 ROMs?

I have only tested on fresh 2.1 2.0B . I would think that logically this should work on the other fresh 2.1 2.0 and perhaps Damageless's. As for darchstar's try it I havent run that rom in a few days.

kkruse said:
I have only tested on fresh 2.1 2.0B . I would think that logically this should work on the other fresh 2.1 2.0 and perhaps Damageless's. As for darchstar's try it I havent run that rom in a few days.
Click to expand...
Click to collapse
If someone could test this out and let me know if it works on my ROM then I would love to just use the same method to get it going with the author's permission (credit will be given).

i keep no space left on device when i do this command
cat /dev/zero > /dev/mtd/mtd2

networx2002 said:
i keep no space left on device when i do this command
cat /dev/zero > /dev/mtd/mtd2
Click to expand...
Click to collapse
same for me
cat: write error: No space left of device

If I remember right it is a different file than what he posted...
I will have to check.

Maybe you can help me w/ this... When I adb shell in recovery I get "/#" instead of "#" & I can't "mount -a"...

networx2002 said:
i keep no space left on device when i do this command
cat /dev/zero > /dev/mtd/mtd2
Click to expand...
Click to collapse
Another one with this issue.
Running Fresh 2.1 2.0b2 on a clean install.
Already have a partitioned SD card with apps installed (from fresh 1.1 rom)
Has anyone besides OP gotten this to work?

mrcharlesiv said:
Maybe you can help me w/ this... When I adb shell in recovery I get "/#" instead of "#" & I can't "mount -a"...
Click to expand...
Click to collapse
/# would mean you are adb into recovery......I think

Aye, / # means you are in recovery mode on the phone is all.
Not sure why you aren't able to mount -a. I'm curious if anyone has gotten this method to work yet..?

So I went ahead and did every step despite the errors it gave just to see what happens... It's booting....
EDIT: Seems like it worked. My internal memory dropped by a/b 20 megs and I'm reinstalling everything. Idk.

mrcharlesiv said:
So I went ahead and did every step despite the errors it gave just to see what happens... It's booting....
EDIT: Seems like it worked. My internal memory dropped by a/b 20 megs and I'm reinstalling everything. Idk.
Click to expand...
Click to collapse
K, I attempted to reboot and it hangs at the HTC screen, so I'm going to boot back into recovery and try to continue from the out of space error.

Last night I tried adding a2sd, e2fsck to /system/bin of Fresh and made a directory SD in /system
Then I added to the init.rc
on property:cm.filesystem.ready=1
class_start default
start a2sd
and
service a2sd /system/bin/logwrapper /system/bin/sh /system/bin/a2sd
disabled
oneshot
then mkbootimg and placed that boot.img into fresh's zip and resigned it.
It flashed ok. But still didn't take. I'm still learning, the stuff I did to iniit.rc I was just basically copying and pasting from other roms with a2sd init.rc's I was going to start a thread until I saw this one.

I was able to boot back into recovery and complete the setup past the out of space error (I still get it though) and reboot. It booted up, but apps are still installing to the internal memory, so it did not work.

mrcharlesiv said:
So I went ahead and did every step despite the errors it gave just to see what happens... It's booting....
EDIT: Seems like it worked. My internal memory dropped by a/b 20 megs and I'm reinstalling everything. Idk.
Click to expand...
Click to collapse
Try this from CMD Prompt
Adb remount
Adb shell
# cd /data/app
#pwd
let us know what you get
if data/app it didnt work.

So I've reinstalled about 15 apps and my internal memory is staying at 73...
I'm still kinda worried about those errors I got.

mrcharlesiv said:
Maybe you can help me w/ this... When I adb shell in recovery I get "/#" instead of "#" & I can't "mount -a"...
Click to expand...
Click to collapse
same here... anyone know where to go from here?

mrcharlesiv said:
So I've reinstalled about 15 apps and my internal memory is staying at 73...
I'm still kinda worried about those errors I got.
Click to expand...
Click to collapse
did you try doing what swaze said?
swaze said:
Try this from CMD Prompt
Adb remount
Adb shell
# cd /data/app
#pwd
let us know what you get
if data/app it didnt work.
Click to expand...
Click to collapse

kashb91 said:
did you try doing what swaze said?
Click to expand...
Click to collapse
Way to rain on my parade! Yeah it didn't work. Idk why my memory dropped and stayed lower then?

[Q] having issues pushing using ADB

Im trying to push a file over using the adb and Im getting a read only file system error. I check to see if I have SU permission and I do. Googling it but its getting me no where. Heres a screenshot to show you what I mean. Any ideas? I have an updated MMS.apk, but I cant get it pushed.

Idk if this would help, but have you tried root explorer or es file explorer to change system from read only to write?? Again, not sure if that would help, I am still, and always will be, a noob .........
ahhhhh...........gone todash..............

1. Use Root Explorer or adb shell to check and/or modify your (root)/default.prop to say:
Code:
ro.secure=0
2. Run the command:
Code:
adb remount
3. Push your app again.

suksit said:
1. Use Root Explorer or adb shell to check and/or modify your (root)/default.prop to say:
Code:
ro.secure=0
2. Run the command:
Code:
adb remount
3. Push your app again.
Click to expand...
Click to collapse
Very strange. I have root access but the ro.secure=1, I changed it to ro.secure=0, I wont have time to check it again until I get home, but I'm sure that was the problem. Thanks.

suksit said:
1. Use Root Explorer or adb shell to check and/or modify your (root)/default.prop to say:
Code:
ro.secure=0
2. Run the command:
Code:
adb remount
3. Push your app again.
Click to expand...
Click to collapse
I think this will not work b/c the default.prop file gets regenerated every boot. Is this correct?

skola28 said:
I think this will not work b/c the default.prop file gets regenerated every boot. Is this correct?
Click to expand...
Click to collapse
It will work until the next boot
Sent from my Nexus S using XDA App

[Q] flash insecure boot image from CWM?

Is there a way to flash an insecure boot image from CWM recovery?
I rooted my transformer with nachoroot, and installed CWM with the one-click recovery installer. None of these methods unlocked the boot loader, obviously, so I can't use adb remount and friends.
I have a B70 tf101, with the .21 firmware if that helps.

I think you need to flash an insecure boot.img.
There are a few few threads kicking around in the dev section that explain this. rebound821 posted an excellent thread. I think this is exactly what moshi and brk's root tools do via nvflash.
In a nutshell:
1) extract your boot.img from your TF
2) unpack the boot.img to the kernel and ramdisk
3) unpack the ramdisk
4) edit default.prop to set ro.secure=0
5) re-assemble in reverse order
6) zip and flash

gee one said:
I think you need to flash an insecure boot.img.
There are a few few threads kicking around in the dev section that explain this. rebound821 posted an excellent thread. I think this is exactly what moshi and brk's root tools do via nvflash.
In a nutshell:
1) extract your boot.img from your TF
2) unpack the boot.img to the kernel and ramdisk
3) unpack the ramdisk
4) edit default.prop to set ro.secure=0
5) re-assemble in reverse order
6) zip and flash
Click to expand...
Click to collapse
thanks for the reply, but I was asking if after I've done that I could flash the boot img with CWM? I've heard that nvflash doesn't work on B70 transformers.
Sent from my HTC Vision using Tapatalk

Yup, in step 6, you would zip it up and flash it via cwm.

pm sent!!!

perquisitor_omnia said:
Is there a way to flash an insecure boot image from CWM recovery?
I rooted my transformer with nachoroot, and installed CWM with the one-click recovery installer. None of these methods unlocked the boot loader, obviously, so I can't use adb remount and friends.
I have a B70 tf101, with the .21 firmware if that helps.
Click to expand...
Click to collapse
If you have root you can do adb remount.
Start a shell in adb and use su to get root. Now you can remount.
I assume this is about remount /system

gls9 said:
If you have root you can do adb remount.
Start a shell in adb and use su to get root. Now you can remount.
I assume this is about remount /system
Click to expand...
Click to collapse
Yeah, but even if I remount /system using adb shell I can still can't do "adb push" to /system so I assume I need to set ro.secure=0 in the bootloader for this to work.

perquisitor_omnia said:
Yeah, but even if I remount /system using adb shell I can still can't do "adb push" to /system so I assume I need to set ro.secure=0 in the bootloader for this to work.
Click to expand...
Click to collapse
I dont know because I don't use adb much.
But why not do this from terminal emulator and just copy the file from sdcard ?
(or with adb shell)
Something like this:
su
mount -o remount,rw /system
cat [source] > [destination]

gls9 said:
I dont know because I don't use adb much.
But why not do this from terminal emulator and just copy the file from sdcard ?
(or with adb shell)
Something like this:
su
mount -o remount,rw /system
cat [source] > [destination]
Click to expand...
Click to collapse
Thats what I am doing at the moment, but it is annoying to have to stage all files to /data/local or /sdcard before copying files to /system from the tablet, when it is much easier to do
$ adb push <file> /system/
from the host computer. Anyway, if I make a insecure bootloader for my tablet that can be flashed from the recovery, I'll post it here as it might be useful to other people in my position.

I've got an insecure boot.img from the US 8.6.5.21 firmware if anyone is interested. It's just the boot in a zip file.

Maybe I'm misunderstanding, but I thought that any image you flashed with CWM recovery was using an insecure boot.img, unless flashing back stock recovery. Anyway, for adb push or adb pull for that matter to work you have to install Asus sync software and USB drivers under Windows and if in Linux, you can search xda for the thread that explains how to get adb working. Once you've got that and root you can adb push and adb pull all day long til you run out of space.

sidneyk said:
Maybe I'm misunderstanding, but I thought that any image you flashed with CWM recovery was using an insecure boot.img, unless flashing back stock recovery. Anyway, for adb push or adb pull for that matter to work you have to install Asus sync software and USB drivers under Windows and if in Linux, you can search xda for the thread that explains how to get adb working. Once you've got that and root you can adb push and adb pull all day long til you run out of space.
Click to expand...
Click to collapse
I have adb working properly (I use it with my G2 all the time), and I use linux.
But for some reason, with my Asus Transformer, when I do
Code:
$ adb remount
I get a 'permission denied' error.
Even if I remount /system rw from the shell, I still get 'permission denied' when trying to use 'adb push' to any directory besides /data/local or /sdcard on the tablet. Is this a bug with the recovery I flashed? or is this because the bootloader hasn't had ro.secure=0 set?
Sent from my Transformer TF101 using Tapatalk

Are you trying this in recovery or under the normal system? Try it under both.
sent from my transformer

I'm trying under the normal system, I will try under recovery when I get access to my desktop.
Sent from my Transformer TF101 using Tapatalk

OK, how about some testing:
from your PC:
adb version
adb shell grep secure /default.prop (or adb shell getprop ro.secure)
This will check your adb version and also see if your ro.secure flag is set.
I tested 'adb remount' and it worked as intended. I'm on adb version 1.0.29 with ro.secure=0.
Also, the recovery ramdisk has it's own default.prop and ro.secure flag, so these can actually be set independantly, but I think you would notice it immediately if recovery wasn't insecure.

Code:
$ adb version
Android Debug Bridge version 1.0.29
$ adb -s shell getprop ro.secure
1
so that would be the problem. can I set the ro.secure property in build.prop?

perquisitor_omnia said:
I have adb working properly (I use it with my G2 all the time), and I use linux.
But for some reason, with my Asus Transformer, when I do
Code:
$ adb remount
I get a 'permission denied' error.
Even if I remount /system rw from the shell, I still get 'permission denied' when trying to use 'adb push' to any directory besides /data/local or /sdcard on the tablet. Is this a bug with the recovery I flashed? or is this because the bootloader hasn't had ro.secure=0 set?
Sent from my Transformer TF101 using Tapatalk
Click to expand...
Click to collapse
I am familiar with errors kind of like this from Mac OS, dunno if it applies here but you might try repairing permissions from CWM. I have fund that quite a lot of ROMs do not have correct permissions set.
Cheers!
-M
Xda member since 2007

perquisitor_omnia said:
Code:
$ adb version
Android Debug Bridge version 1.0.29
$ adb -s shell getprop ro.secure
1
so that would be the problem. can I set the ro.secure property in build.prop?
Click to expand...
Click to collapse
Yeah, that would cause the issues. Not sure how to fix it, but some ideas:
1) flash an insecure boot.img via cwm
2) use the staging partition to flash a boot.img/blob
3) ???

I finally used the SBK detect tool, my B70 has a nvflashable firmware, so I will pull the boot loader with nvflash and make it insecure that way.
Sent from my HTC Vision using Tapatalk

Need help with adb :\

Hey everyone!
Recently I've had problems with using the command "adb remount". I thought it was a kernel problem but it happened with both Trinity and
Elementalx kernel. I have installed the universal naked drivers 0.73 for my nexus 5. I think it is a root problem since nothing pops up on my phone
when entering "adb root". I have tried to retype it several times and it doesn't say "adb is already running as root" or something like that like it used
to. It keeps repeating "restarting adbd as root" whenever I type that command. Sorry if I'm not clear :/
Thanks everyone!

I personally prefer to run adb via recovery. Have you tried this?

I have also failed to use remount in android.
The solution is as rootsu suggests.
Boot to recovery and do
Adb shell mount /system
Or
Adb shell mount /data
Which ever partition you want to be changing
Sent from my Nexus 5 using xda app-developers app

rootSU said:
I personally prefer to run adb via recovery. Have you tried this?
Click to expand...
Click to collapse
It does work that way but am I stuck on using this method?

Lxve said:
It does work that way but am I stuck on using this method?
Click to expand...
Click to collapse
I don't think so. It's just easier.
With SlimKat and elementalx*
I have adb and apps set as root in slimkat although I doubt this is a requirement in non-AOSP roms that do not have this option. Need USB debugging on and the screen unlocked
Code:
C:\Users\rootsu\Desktop\tools>adb root
adbd is already running as root
C:\Users\rootsu\Desktop\tools>adb shell
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
[email protected]:/ # exit
exit
C:\Users\rootsu\Desktop\tools>adb push test.txt /system/
C:\Users\rootsu\Desktop\tools>adb shell
[email protected]:/ # cd system
cd system
[email protected]:/system # ls
ls
addon.d
app
bin
build.prop
core
etc
fonts
framework
lib
lost+found
media
priv-app
[B][COLOR="Red"][B]test.txt[/B][/COLOR][/B]
tts
usr
vendor
xbin
[email protected]:/system #

Android 7 overwrites /system/build.prop on every boot?

First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?

mgbelisle said:
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
Click to expand...
Click to collapse
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Sent from my SCH-I535 using Tapatalk

Droidriven said:
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Click to expand...
Click to collapse
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.

mgbelisle said:
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
Click to expand...
Click to collapse
You're using a temp recovery aren't you? Are you using that because your bootloader is locked? Are you rooted?
Sent from my SCH-I535 using Tapatalk

Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.

mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I doubt you'll make the changes and keep them without root.
Sent from my SCH-I535 using Tapatalk

Droidriven said:
I doubt you'll make the changes and keep them without root.
Click to expand...
Click to collapse
Hmm but that doesn't quite make sense to me. I made the changes as root and they've definitely persisted (even when I reboot into twrp) and the changes are there if you do the same thing in Android 6. There are many references to doing changes this way like in http://forum.xda-developers.com/nexus-5x/general/guide-how-to-unlock-tethering-nexus-5x-t3231301 but it's just with Android 7 now, the stock 7 firmware is mounting something on /system/build.prop that is different than what TWRP mounts at /system/build.prop. I'll try the same thing with CyanogenMod Recovery, maybe that will have different results.

mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Sent from my SCH-I535 using Tapatalk

Droidriven said:
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Click to expand...
Click to collapse
Yeah I understand that, but even though it wouldn't cause a problem it doesn't seem that would be necessary. Interestingly, when I'm booted into twrp with /system mounted, the build.prop file has the contents and timestamp I expect.
# ls -la /system/build.prop
-rw-r--r-- 1 root root 4919 Dec 17 16:52 /system/build.prop
But when booted into system (stock Android 7 like I mentioned) the timestamp shows a very different file is being mounted.
$ ls -la /system/build.prop
-rw-r--r-- 1 root root 4876 2009-01-01 03:00 /system/build.prop

More info, flashing twrp as opposed to just booting it had the same effect. I tried that because of what you said Droidriven, BTW thanks for your help so far.

Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...

tronik said:
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
Click to expand...
Click to collapse
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip

mgbelisle said:
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
Click to expand...
Click to collapse
Appreciate the prompt response. Yeah, I'm using twrp 3.0.2-2 also, and I've tried numerous versions of SuperSU all failing with the same sepolicy update error... I just don't get it. Never had these problems before Nougat.
Just tried with the specific one in the article you linked:
"Patching sepolicy
--- Failure, aborting"
So weird. Anyway, glad to know yours was fixed!
edit:
I finally decided to try this other root method (phh) and it is working: http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
I don't know why my trusty SuperSU no longer works.
Oh well.