FORUMS
Remove All Ads from XDA

[DEVS-ONLY] SuperSU developer discussion

11,416 posts
Thanks Meter: 88,011
 
By Chainfire, Moderator Emeritus / Senior Recognized Developer - Where is my shirt? on 5th September 2014, 03:57 PM
Post Reply Email Thread
23rd December 2016, 09:37 AM |#71  
Chainfire's Avatar
OP Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,011
 
Donate to Me
More
Quote:
Originally Posted by Honestly Annoying

Hello! I am attempting to install SuperSU through and adb root shell, as I am on a userdebug Sprint LG G5 (6.0.1) and am limited for now to this. I have tried every third party script I could find and none of them worked, so I attempted to run the QC Galaxy S7 installer instead. Everything runs smoothly except for the last step (second to last line from "launch_daemonsu.sh"), as I get this error.

Code:
[email protected]:/ # /su/bin/supolicy --live
supolicy v2.74 (ndk:arm64-v8a) - Copyright (C) 2014-2016 - Chainfire

Patching policy ...
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
- Failure! 2
Is there anything you can do to help with this?

Here is a link to my current thread: http://forum.xda-developers.com/spri...print-t3523496

Replace su, daemonsu, supolicy, libsupol, and sukernel, with files from the 2.79-SR1 ZIP.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
 
 
23rd December 2016, 09:12 PM |#72  
Senior Member
Flag chicago
Thanks Meter: 842
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Replace su, daemonsu, supolicy, libsupol, and sukernel, with files from the 2.79-SR1 ZIP.

I will try this and update you, thanks for the response!
26th December 2016, 01:46 PM |#73  
_alexndr's Avatar
Senior Member
Thanks Meter: 15,093
 
Donate to Me
More
@Chainfire

I have a small but in my opinion very important proposal of change in your update-binary sh script

At this moment your SuperSU installer writes TWICE entire $BOOTIMAGE block. As you (probably) know - the most popular flash memory in currently available devices is TLC (Triple Level Cell) with about 1000-writes durability of single memory cell. This is not a big problem for /data as "system takes care" about not writing to the same cell until all available space has been physically used already.

This is also not a big problem for normal users which install your update once or twice a month

BUT IMHO this is real problem for Devs/Chefs who use your ZIP as a part of custom rom installer. Sometimes they perform 10 or more iterations before release ready for use custom rom. It usually means 10 times of custom ROM flash processes = 30 times of $BOOTIMAGE writes! (1 - pure stock kernel, 2 - wipe $BOOTIMAGE by SuperSU, 3 - kernel patched by SuperSU)

In case you accept below proposal your installer will write $BOOTIMAGE only ONCE and is still capable of cleaning unused part of $BOOTIMAGE:

Code:
[...]

    if ($CONTINUE); then
      if ($SAMSUNG); then
        # Prevent "KERNEL IS NOT SEANDROID ENFORCING"
        SAMSUNG_CHECK=$(cat /sutmp/boot.img | grep SEANDROIDENFORCE)
        if [ $? -ne 0 ]; then
          echo -n "SEANDROIDENFORCE" >> /sutmp/boot.img
        fi
      fi

      DEV=$(echo `resolve_link $BOOTIMAGE` | grep /dev/block/)
      if [ $? -eq 0 ]; then
        ui_print "- Flashing boot image"
        cat /sutmp/boot.img /dev/zero | dd of=$BOOTIMAGE bs=4096 2>/dev/null
      else
        ui_print "- Saving boot image"
        dd if=/sutmp/boot.img of=$BOOTIMAGE bs=4096
      fi
    fi

[...]
The most important change is marked in RED
The Following User Says Thank You to _alexndr For This Useful Post: [ View ] Gift _alexndr Ad-Free
28th December 2016, 09:43 PM |#74  
Senior Member
Flag chicago
Thanks Meter: 842
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Replace su, daemonsu, supolicy, libsupol, and sukernel, with files from the 2.79-SR1 ZIP.

So after trying this, SuperSU is still stuck on asking me to update the binaries and fails whenever I try. If you wouldn't mind, can you check out the forum that I have going for this so we can get SuperSU installed on the G5? Here is a link.

Thanks so much for all of your work!
31st December 2016, 07:45 PM |#75  
zaclimon's Avatar
Recognized Contributor
Flag Montréal
Thanks Meter: 7,330
 
Donate to Me
More
Hi everybody! I've been trying to get online kernel flashing directly using AnyKernel in the system itself. So far my testing has been pretty positive. (Doing every commands from an adb shell results in the kernel being correctly flashed) However, that's from a userdebug build without SuperSU installed. This is using a Nexus 4 on AOSP 7.1.1 with SuperSU v.2.79 stable.

Once SuperSU is installed (Systemless) and I attempt to flash the kernel, the repacked boot image doesn't seem valid anymore. Just in case, I tried with the stock kernel as well, the same result happened. At first I might think it is something related to init itself because I had the same kind of booting failure when porting Nougat. (On the Nexus 4, it stays on the Google logo for some time, then the logo fades a little bit and then the device reboots to recovery) The only thing that I could see that might make it fail is if the SELinux policies cannot be loaded for some reason after unpack/repack.

I was thinking that some permissions might have been altered which make init not being able to load the policies. it is possible that unpacking the image have broken some stuff that SuperSU needs in order for the device to boot correctly. Obviously, since I don't have UART cable, all of this is speculation... Though I wanted to know if anybody had this kind of issue while trying to patch with Systemless enabled.
3rd January 2017, 05:39 PM |#76  
Member
Thanks Meter: 28
 
More
@Chainfire

I just built sepolicy from source with some changes, can that same sepolicy file by applied on most devices regardless of the Android version? Granted 5.0+. To get the sepolicy I built a ROM for the Nexus 6P then grabbed the sepolicy file from the out folder. It works great on my 6P but would it work on other devices as well?

Edit: I used supolicy to load it.
3rd January 2017, 07:02 PM |#77  
Chainfire's Avatar
OP Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,011
 
Donate to Me
More
Quote:
Originally Posted by _alexndr

@Chainfire

I have a small but in my opinion very important proposal of change in your update-binary sh script

...

The most important change is marked in RED

This is implemented in v2.79 SR2.

Quote:
Originally Posted by Honestly Annoying

So after trying this, SuperSU is still stuck on asking me to update the binaries and fails whenever I try. If you wouldn't mind, can you check out the forum that I have going for this so we can get SuperSU installed on the G5? Here is a link.

Thanks so much for all of your work!

Sorry, is this still relevant? I'm quite busy, and without having a device myself I can't really test.

Quote:
Originally Posted by zaclimon

Hi everybody! I've been trying to get online kernel flashing directly using AnyKernel in the system itself. So far my testing has been pretty positive. (Doing every commands from an adb shell results in the kernel being correctly flashed) However, that's from a userdebug build without SuperSU installed. This is using a Nexus 4 on AOSP 7.1.1 with SuperSU v.2.79 stable.

Once SuperSU is installed (Systemless) and I attempt to flash the kernel, the repacked boot image doesn't seem valid anymore. Just in case, I tried with the stock kernel as well, the same result happened. At first I might think it is something related to init itself because I had the same kind of booting failure when porting Nougat. (On the Nexus 4, it stays on the Google logo for some time, then the logo fades a little bit and then the device reboots to recovery) The only thing that I could see that might make it fail is if the SELinux policies cannot be loaded for some reason after unpack/repack.

I was thinking that some permissions might have been altered which make init not being able to load the policies. it is possible that unpacking the image have broken some stuff that SuperSU needs in order for the device to boot correctly. Obviously, since I don't have UART cable, all of this is speculation... Though I wanted to know if anybody had this kind of issue while trying to patch with Systemless enabled.

I'm sorry I have no idea what is going on here.

Quote:
Originally Posted by InterestingTwist

@Chainfire

I just built sepolicy from source with some changes, can that same sepolicy file by applied on most devices regardless of the Android version? Granted 5.0+. To get the sepolicy I built a ROM for the Nexus 6P then grabbed the sepolicy file from the out folder. It works great on my 6P but would it work on other devices as well?

Edit: I used supolicy to load it.

Both the rules and file format are Android version and device specific. In some cases it may work. In some cases it will appear to work with subtle failures in random processes. I just wouldn't go there.
The Following 3 Users Say Thank You to Chainfire For This Useful Post: [ View ]
3rd January 2017, 08:43 PM |#78  
Senior Member
Flag chicago
Thanks Meter: 842
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Sorry, is this still relevant? I'm quite busy, and without having a device myself I can't really test.

Yes it is, and there are MANY people willing to test. My personal device is out for the next couple weeks, but once it is back to being up and running I will be available myself to test. If you will be less busy then, that's probably the better way to go
4th January 2017, 12:59 AM |#79  
Member
Thanks Meter: 28
 
More
Quote:
Originally Posted by Chainfire

Both the rules and file format are Android version and device specific. In some cases it may work. In some cases it will appear to work with subtle failures in random processes. I just wouldn't go there.

Hmm thanks for the information. I have used supolicy before to inject but when trying to inject the following lines supolicy says invalid syntax.

"set_prop(audioserver, dolby_prop)" needs to be in audioserver.te
"set_prop(mediacodec, dolby_prop)" needs to be in mediacodec.te
"media.dolby_memoryservice ubject_r:audioserver_service:s0" needs to be in service_contexts

Any help would be much appreciated, thanks for all you do.
4th January 2017, 03:38 PM |#80  
Chainfire's Avatar
OP Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,011
 
Donate to Me
More
Quote:
Originally Posted by InterestingTwist

Hmm thanks for the information. I have used supolicy before to inject but when trying to inject the following lines supolicy says invalid syntax.

"set_prop(audioserver, dolby_prop)" needs to be in audioserver.te
"set_prop(mediacodec, dolby_prop)" needs to be in mediacodec.te
"media.dolby_memoryservice ubject_r:audioserver_service:s0" needs to be in service_contexts

Any help would be much appreciated, thanks for all you do.

set_prop is a macro, you need to figure out exactly which allow rules these create. You can't copy/paste stuff from .te files into supolicy.

service_contexts is a file you need to modify. You may actually need to modify that in boot image ramdisk for it to work, I don't know.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
4th January 2017, 05:01 PM |#81  
Member
Thanks Meter: 28
 
More
Quote:
Originally Posted by Chainfire

set_prop is a macro, you need to figure out exactly which allow rules these create. You can't copy/paste stuff from .te files into supolicy.

service_contexts is a file you need to modify. You may actually need to modify that in boot image ramdisk for it to work, I don't know.

You are one smart guy, thanks I found the macro and have changed them to allow rules. As for service_contexts, I can confirm you can modify it by extracting ramdisk.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes