Related
FixFlash - Flash Verify and Repair Tool by SavvyX4
I was always running into problems getting my Hero CDMA to boot custom ROMs. After eventually getting frustrated enough with what seemed like inexplicable errors, I finally determined that on my phone, I would occasionally end up with corrupt files after the flash process was done. If I was lucky, it would be an unimportant file or two that would end up corrupt, but sometimes it would be a critical framework, which is why I was having trouble booting.
Enter FixFlash, a shell script that runs on the phone after flashing a new ROM image from recovery. FixFlash will verify the integrity of the files copied to the phone during the flash process and in the event of a problem, automatically make a fresh copy of the corrupt file in an effort to resolve the problem.
I developed this tool because of my own problems, but I think that I may be able to help some other people who's phones are giving them them same sorts of problems that mine does me. I am open to any suggestions on improvements, and welcome any feedback!
FixFlash is very easy to use, and only requires that you do the following:
1. Copy FixFlash.sh to the root of your sdcard
2. Extract the zip of the ROM you want to flash to your phone on your computer. This is necessary for the verification process.
3. Copy both the original .zip file and the extracted folder of the .zip to the root of your sdcard
4. Boot into recovery and follow your normal flash procedure.
5. Once the flash has finished, but before doing anything else in Recovery, run this command from your computer's terminal/command prompt:
adb shell sh /sdcard/FixFlash.sh
You should see output in your terminal/command prompt indicating if there were any corrupted files encountered, and whether or not they were repaired. The whole process is fairly quick, and should only take a minute or so, depending on your sdcard speed.
6. Reboot your phone and enjoy!
At this point you can remove the extracted copy of the zip from your sdcard, its job is done!
** Updated Script available ** Download from link below and replace existing copies with that file to update.
Sep 9 2010 - 1.1 - Fixed problem with files like AVRCP.kl showing as bad because of case change of filename between phone and zip
More information (including full changelog) is available here:
http://notepad.cc/fixflash
Direct Download Link:
http://db.tt/GPssIoe
If you have any problems with FixFlash PLEASE post your recovery.log to PasteBin along with a description of the issue so that I may look into whatever is causing the problem. Thanks!
SavvyX4 said:
I was always running into problems getting my Hero CDMA to boot custom ROMs.
Click to expand...
Click to collapse
I have always wondered what people might be doing wrong, because I have *never* had an issue booting a known good ROM.
Perhaps the internet connection or SD card is to blame?
Hmm, this is a very good idea. Maybe it will be incorporated into future CyanogenMOD builds?
x99percent said:
I have always wondered what people might be doing wrong, because I have *never* had an issue booting a known good ROM.
Perhaps the internet connection or SD card is to blame?
Click to expand...
Click to collapse
I always verify hashes on downloaded ROMs, and as the files are extracted to the sdcard they are verified by Recovery. The problem is that they aren't verified after they are copied to the phone's internal storage, which is where with my phone I'm seeing corruption. I have been dealing with this problem for a long time, and tried numerous different combinations before finally catching a break with a flash that corrupted one of the frameworks that gets called immediately when booting. that narrowed down the number of files to check manually and once I found a bad hash on my phone's internal storage, I knew for sure what was wrong and set about automating a workaround.
SavvyX4 said:
... once I found a bad hash on my phone's internal storage, I knew for sure what was wrong and set about automating a workaround.
Click to expand...
Click to collapse
Is it fair to say that, in your case, this workaround is a software fix for a hardware problem?
x99percent said:
Is it fair to say that, in your case, this workaround is a software fix for a hardware problem?
Click to expand...
Click to collapse
I would agree, this would certainly qualify as a software fix for a hardware problem.
Sent from my HERO200 using XDA App
mrinehart93 said:
Hmm, this is a very good idea. Maybe it will be incorporated into future CyanogenMOD builds?
Click to expand...
Click to collapse
Even better, this should be incorporated into Clockwork & Amon RA!
I would agree, having the recovery automatically verify the flashed files in a similar manner to what I've done with this script would be ideal. Even though I believe that FixFlash is easy to use, not having to do anything other than a normal flash would be easier and possibly save people who may not be aware of a lurking issue with their phones a lot of grief.
Sent from my HERO200 using XDA App
Savvy, you should contact Koush and have him add this into ClockwordMOD... you would help SO many people out with this. Quick question just so I can learn something: How does the script know how to repair the framework files? I mean how can it tell what ROM it is, and know the correct file to repair?
I am using the recovery.log that is generated during the flash process to figure out which files belong where. Inside the zip for the rom the files are in the same directory structure so it ended up only requiring some minor work to get it to locate everything. And the same log identifies what is being flashed which is how it knows which directory to work with.
Sent from my HERO200 using XDA App
SavvyX4 said:
I am using the recovery.log that is generated during the flash process to figure out which files belong where. Inside the zip for the rom the files are in the same directory structure so it ended up only requiring some minor work to get it to locate everything. And the same log identifies what is being flashed which is how it knows which directory to work with.
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
This is really nice Savy, good work. I hope I never have to use u'r script tho, lol (in a completely non-offensive way)
But, if that day ever comes, I have to say, it's great to know that someone like u'r self has been able to locate and work around the issue.
SavvyX4,any way i wiil try........
Uploaded with ImageShack.us
hey Savvyx
man please you have any other method for repair without adb??
my desire bricked lost adb, lost root, radio, completely stock again but with usb bricked and sd card but sd working now but my usb is over, do you have any idea what i have to do to restore my usb??
thanks
this works on all android devices or just Hero?
I only have my Hero to test it on but I don't know of any reason why it wouldn't work on any phone. I'm not doing anything specific to the device.
Sent from my HERO200 using XDA App
marken said:
hey Savvyx
man please you have any other method for repair without adb??
my desire bricked lost adb, lost root, radio, completely stock again but with usb bricked and sd card but sd working now but my usb is over, do you have any idea what i have to do to restore my usb??
thanks
Click to expand...
Click to collapse
Unfortunately what I've put together here completely relies on having access to a shell with all the utilities that come with it. If you've lost your root and can't get adb to work then this tool isn't what you need.
I have heard of people who have been having trouble with adb getting it back by turning off usb debugging, rebooting their phone and then turning usb debugging back on but I don't know if that would help you with all the troubles you described.
Sent from my HERO200 using XDA App
Worked like a charm Savvy!!! It found two bad files nd replaced them no problem. Hey will this work on any type of flashable zip for example if u want to flash a new kernel or theme could i extract the zip to the sd card flash thru recovery nd then run FixFlash to verify the it flashed correctly? This is awesome bro!!! Should definitely be incorporated into both Clockwork and Amon Ra recoveries!
SavvyX4 said:
I only have my Hero to test it on but I don't know of any reason why it wouldn't work on any phone. I'm not doing anything specific to the device.
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
Ok imma test it tonight my G1. I've been having problems loading 90% of the roms, already tried pretty much everything so i'll give this a try. Will post my results later.
Yup, should definitely work with any flashable zip file.
Sent from my HERO200 using XDA App
Thanks for this great utility. Evo owner here and just wanted to give my input.
Just flashed a new ROM and ran FixFlash. Here's my output.
Code:
E:\aEVO\android-sdk-windows\tools>adb shell sh /sdcard/FixFlash.sh
* daemon not running. starting it now *
* daemon started successfully *
FixFlash - Flash Verify and Repair Tool by SavvyX4
Gathering verification data...
Mounting phone file systems...
Extracting file information from flash log...
Verifying file integrity...
Hash mismatches detected: 13
Bad files...
/system/app/EPST.apk
/system/app/HTC_IME.apk
/system/app/IQRD.apk
/system/app/PCSCII.apk
/system/app/RSS.apk
/system/customize/CID/cidProfile1.xml
/system/customize/CID/cidProfile2.xml
/system/customize/CID/default.xml
/system/customize/COMMON.xml
/system/customize/MNS/default.xml
/system/etc/TPA2018.csv
/system/etc/WPDB.zip
/system/usr/keylayout/AVRCP.kl
Replacing bad files...
Verifying replacement file integrity...
All hash mismatches repaired!
So, it definitely does work for other phones. I then immediately Wiped Data/Cache/Dalvik, Flashed the same ROM again, and then ran FixFlash again.
Lo and behold, different results (meaning that FixFlash is a very valuable tool, and should definitely be used after flashing any ROM or .zip for that matter.) In my eye, it is a must use tool now.
Code:
E:\aEVO\android-sdk-windows\tools>adb shell sh /sdcard/FixFlash.sh
FixFlash - Flash Verify and Repair Tool by SavvyX4
Gathering verification data...
Mounting phone file systems...
Extracting file information from flash log...
Verifying file integrity...
Hash mismatches detected: 26
Bad files...
/system/app/EPST.apk
/system/app/HTC_IME.apk
/system/app/IQRD.apk
/system/app/PCSCII.apk
/system/app/RSS.apk
/system/customize/CID/cidProfile1.xml
/system/customize/CID/cidProfile2.xml
/system/customize/CID/default.xml
/system/customize/COMMON.xml
/system/customize/MNS/default.xml
/system/etc/TPA2018.csv
/system/etc/WPDB.zip
/system/usr/keylayout/AVRCP.kl
/system/app/EPST.apk
/system/app/HTC_IME.apk
/system/app/IQRD.apk
/system/app/PCSCII.apk
/system/app/RSS.apk
/system/customize/CID/cidProfile1.xml
/system/customize/CID/cidProfile2.xml
/system/customize/CID/default.xml
/system/customize/COMMON.xml
/system/customize/MNS/default.xml
/system/etc/TPA2018.csv
/system/etc/WPDB.zip
/system/usr/keylayout/AVRCP.kl
Replacing bad files...
I am posting this in the Developer forum, because it is still a little more than a In-experienced user can handle at the moment, and the potential to get into a bootloop is a little higher if you are not familiar with what you are doing here.
If you are at all new / uncomfortable with Android, UNIX/LINUX, this phone, or adb, then: PLEASE DON'T TRY THIS AT HOME.
If you get into a bootloop I am not responsible for this, nor is this the place to complain if that happens. You can ask for support here though if this process has caused that.
If you do get into a bootloop, then try and help me out, with providing as much info as possible with what happened (any output or screen prints are VERY helpful). I am also posting the original /system/etc/init.goldfish.sh file here AT THE BOTTOM OF THIS POST. That way if it does all go wrong it is here to grab. So don't go asking for it someplace else, or even asking here for it.
You have been warned!
Now with that out of the way, on to the good stuff.
1) Go grab some kind of bloat freeze program, from the market. I have used bloat freezer from the market with great success.
Just download and install it, don't run it just yet, if you already have, and frozen the "Device Health Application", then unfreeze it, and reboot, before doing the next step.
It is VERY important that it is done in EXACTLY this order. The reason is, if the Device Health program is frozen when you let the init script run, it will not work exactly as it should and these services will restart, since part of it is frozen when it first runs, and it all has to be disabled in the proper way, so that it can not be restarted remotely, or we will HAVE to use cron to run checks. Cron is an elaborate hack, I don't want to have to do, unless we HAVE to. If you do it in the exact order noted here, cron will not be needed and this will not restart.
2) Go get the init.goldfish.sh file from http://dl.dropbox.com/u/45576654/init.goldfish.sh.tar
push this tarball to your phone:
Code:
adb push init.goldfish.sh.tar /data/local/
End code
Now is the command line part of this hack.
Code:
adb shell
su
mount -o remount, rw /system
cd /data/local
tar -xvf init.goldfish.sh.tar
cp /system/etc/init.goldfish.sh /sdcard/init.goldfish.sh
cp ./init.goldfish.sh /system/etc/init.goldfish.sh
chown root /system/etc/init.goldfish.sh
chmod 550 /system/etc/init.goldfish.sh
mount -o remount, ro /system
reboot
End code
Now when your phone comes back up:
3) Open your bloat freezer program and freeze the "Device Health Application"
Your phone will freak out, and tell you that Device Health has stopped and it will keep asking you to FC, all you can do is pull the battery.
Put the battery back in the phone an boot it up.
Now CarrierIQ should be 100% disabled on your Atrix 2.
As promissed, here is the Original /system/etc/init.goldfish.sh file in a tarball, just use the same code above to put this back in place.
DON'T USE ROOT EXPLORER TO COPY THESE FILES INTO PLACE!!!
Original /system/etc/init.goldfish.sh file:
http://dl.dropbox.com/u/45576654/init.goldfish.sh-orig.tar
The Jedi Master strikes again!
The force is strong in this one. Seriously Jim you absolutely amaze me. You are the Linux guru.
Sent from my MB865
Train us, he will.
Sent from my MB865 using Tapatalk
LOL....
Hopefully I have not scared everyone from trying this.... I just want to let all the newbies who just got this as thier first android phone yesterday, and rooted it today, and now think that this is a good hack to try, that this is not the best thing for them just yet. It can and will bootloop the phone if you get too excited and don't follow the directions exactly... I got mine in a bootloop testing this all out, and finding the exact steps, but it was not hard to get out of, because it gets into android enough to let you adb in, if you screw up...
quick question: Why would rooting followed by freezing not work for that application? I think I did that when I got the phone. I don't see anything called Device Health in my running or installed applications.
Is carrierIQ still running on my phone? Have you got a string I can look for in the 'ps' output in the Terminal to confirm? There are 100000 processes running on these phones these days, most with cryptic names.... I miss the G1 days....
devsk said:
quick question: Why would rooting followed by freezing not work for that application? I think I did that when I got the phone. I don't see anything called Device Health in my running or installed applications.
Is carrierIQ still running on my phone? Have you got a string I can look for in the 'ps' output in the Terminal to confirm? There are 100000 processes running on these phones these days, most with cryptic names.... I miss the G1 days....
Click to expand...
Click to collapse
No just freezing the device health app just stops the collection process.
The part where you run the commands to stop the services in android are where the data can and will be sent to CIQ or AT&T, there are other things collected that att does not care much about (ATT only wants what is collected with the dev health app), and that goes straight to CIQ, so the services at the OS level are VERY important to stop. There is really not a way to see them running, but I have found that these can and will restart if my instructions are not followed 100%. To find out if CIQ is doing anything take a look on youtube there is a video that explains how to look at the system logs and see what is being collected if anything, and what is being sent out. After a lot of trial and error, I found this is the ONLY way to stop it 100%.
Hey Jim. sorry I've been out of the forums for so long on this. I was going to dig around my atrix2 and see what I could find wrt carrieriq. I got stuck on missing shell tools and you gave me some advice wrt paths and such. I was wondering if you could point me in the right direction for fixing up my env when I shell in? I also don't seem to have grep anywhere... odd.
YOu mentioned doing some of the destructive work in an emulator, and I would like to try the same thing, but I've no idea how to get the atrix2 ROM into an emulator. How did you accomplish this?
I followed the instructions above precisely and verified that my init.goldfish.sh is indeed modified correctly with the carrieriq stuff, and have suffered no ill effects. I have not, however, attempted to determine if carrieriq processes have stopped running. I did notice that after having frozen and unfrozen device.health.monitor a few times, it doesn't ever register as a running app... wonder what's up with that.
thanks for the help.
I was wondering....could this be made into a handy dandy flashable zip?
Then after flashing just freeze the app?
Sent from my MB865 using XDA App
tylercarter said:
I was wondering....could this be made into a handy dandy flashable zip?
Then after flashing just freeze the app?
Sent from my MB865 using XDA App
Click to expand...
Click to collapse
Yep, working on it, should have it up for download tomorrow.... It will also be in my rom.
Jim
Sent from my MB865 using xda premium
jimbridgman said:
Yep, working on it, should have it up for download tomorrow.... It will also be in my rom.
Jim
Sent from my MB865 using xda premium
Click to expand...
Click to collapse
Sent from my MB865 using xda premium
jimbridgman said:
Sent from my MB865 using xda premium
Click to expand...
Click to collapse
NICE! you really are a jedi master!
Who wants to be the first to try this out? I have created a flashable zip to disable CIQ on every boot, all you have to do is grab the file below:
http://dl.dropbox.com/u/45576654/NoCIQ.zip
Then with CWM, flash it, don't wipe anything, except maybe dalvic cache, but nothing else. This will only flash one file to your phone.
You will still have to freeze the device health app as in the OP.
This is just a test right now, once someone other than me tests this, and reports back, that all is great, then I will update the OP, to this method.
jimbridgman said:
Who wants to be the first to try this out? I have created a flashable zip to disable CIQ on every boot, all you have to do is grab the file below:
http://dl.dropbox.com/u/45576654/NoCIQ.zip
Then with CWM, flash it, don't wipe anything, except maybe dalvic cache, but nothing else. This will only flash one file to your phone.
You will still have to freeze the device health app as in the OP.
This is just a test right now, once someone other than me tests this, and reports back, that all is great, then I will update the OP, to this method.
Click to expand...
Click to collapse
It said switch to edify scripting. Installation aborted. Something about gingerbread cwm 3. Not sure. Never see this before. I checked the zip and it has 2 updater scripts. One just has a ~ at the end. I know nothing of code but just trying to help.
Sent from my MB865 using XDA App
jimbridgman said:
Who wants to be the first to try this out? I have created a flashable zip to disable CIQ on every boot, all you have to do is grab the file below:
http://dl.dropbox.com/u/45576654/NoCIQ.zip
Then with CWM, flash it, don't wipe anything, except maybe dalvic cache, but nothing else. This will only flash one file to your phone.
You will still have to freeze the device health app as in the OP.
This is just a test right now, once someone other than me tests this, and reports back, that all is great, then I will update the OP, to this method.
Click to expand...
Click to collapse
Tried this. No go. Here is the error in CWM.
Installing Update...
Amend Scripting (update0script) is no longer supported.
Amend Scripting was deprecated by Google in Android 1.5.
It was necessary to remove it when upgrading to the ClockworkMod 3.0 Gingerbread based recover.
Please switch to Edify scripting (updater-script and update-binary) to create working update zip packages.
Installation Aborted.
There ya go. Hope this helps.
holeshot77 said:
Tried this. No go. Here is the error in CWM.
Installing Update...
Amend Scripting (update0script) is no longer supported.
Amend Scripting was deprecated by Google in Android 1.5.
It was necessary to remove it when upgrading to the ClockworkMod 3.0 Gingerbread based recover.
Please switch to Edify scripting (updater-script and update-binary) to create working update zip packages.
Installation Aborted.
There ya go. Hope this helps.
Click to expand...
Click to collapse
hes working on it. wont be much longer
Why not use the app by TrevE?
Sent from my MB865 using xda premium
1.18.12 said:
Why not use the app by TrevE?
Sent from my MB865 using xda premium
Click to expand...
Click to collapse
That does not perform the hack, only detects if it is running. The voodoo ciq detection app works much better though.
Jim
Sent from my MB865 using xda premium
I just rooted my phone, applied the hack and used Titanium Backup to freeze the Device Health App but I didn't see any FC.
Although when I opened Ti Backup, it told me that my su right are wrong. They are 4755 instead of 6755 or something like that and TiBu told me that it will fix it. I fixed it then froze the app and no FC or nothing. Phone is running fine but not sure if it worked.
Is it really necessary for the app to FC in order to show that it worked?
Should I try it all over again?
Thank you.
noobsquared said:
I just rooted my phone, applied the hack and used Titanium Backup to freeze the Device Health App but I didn't see any FC.
Although when I opened Ti Backup, it told me that my su right are wrong. They are 4755 instead of 6755 or something like that and TiBu told me that it will fix it. I fixed it then froze the app and no FC or nothing. Phone is running fine but not sure if it worked.
Is it really necessary for the app to FC in order to show that it worked?
Should I try it all over again?
Thank you.
Click to expand...
Click to collapse
Go download and install this, and it will show you if it (CarrierIQ) is active or not.
https://market.android.com/details?id=org.projectvoodoo.simplecarrieriqdetector&hl=en
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows.bat and follow instructions. Takes 30 seconds - 1 minute all in all.
Thanks, but...
gee2012 said:
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows,bat and follow instructions. Takes 30 seconds - 1 munute all in all.
Click to expand...
Click to collapse
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Casteel said:
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Click to expand...
Click to collapse
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
gee2012 said:
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
Click to expand...
Click to collapse
What do you mean by "injects SuperSU" ?
It sounds very simple from the way you say it. Why can't I do this myself?
I believe it doesn't just mean copy it to the right place.
Does it also include putting the su binary in the right system path with the right permissions?
How does the root privilage is gained?
Does only unlocking the BL let me write to the system partition?
I would really appreciate some technical details to understand this rooting process and what this image file contains.
Thanks again!
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
gee2012 said:
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
Click to expand...
Click to collapse
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Casteel said:
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Click to expand...
Click to collapse
Look here https://www.google.com/search?q=how+root+works&ie=utf-8&oe=utf-8&aq=t and other sites how root works http://stackoverflow.com/questions/...hat-are-the-pre-requisites-for-it-to-work-wha.
With Google you can find anything
Actually, I read this also...
It only talks about gaining root privilage using some system exploit.
So, you're telling that CF-Auto-Root is running some script in its bootable image file that is using some kind of exploit to gain root access?
Shouldn't it be less "hacky" thing in nexus devices?
And how can it be that the image file is related to specific devices and not to specific stock versions?
What prevents from other apps to use this so called "exploit"?
This is probably what you are looking for...
Embedded in the boot image a folder cfroot with the SuperSU apk file, the su binary and the necessary init scripts and there is a binary under sbin does the remaining steps of copying the files to the respective places. It is not an exploit, it merely uses the boot image and the boot process to "install" SuperSU. You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
In more detail:
1. Embedded in the ramdisk is a folder "cfroot" with "99SuperSUDaemon, install-recovery.sh, su and Superuser.apk".
2. In the sbin folder in the ramdisk is a binary "cfautoroot" which does stuff like copy the above files to the correct locations and set the appropriate permissions, etc.
3. This file is called through the "recovery" script/binary in the sbin folder
4. The "recovery" script/binary is executed as a startup server via the init system in "init.rc" within the ramdisk
The result:
When you boot up, the superuser files are copied to the respective locations with the right permission, thereby rooting the system
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
craigacgomez said:
there is a binary under sbin does the remaining steps of copying the files to the respective places.
You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
Click to expand...
Click to collapse
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Casteel said:
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Click to expand...
Click to collapse
"cfautoroot" is a binary created by Chainfire which is embedded in the sbin folder in the kernel ramdisk. It's in the CF Auto Root boot image. Android kernels are essentially Linux kernels and have an init process which is basically a bootstrap/startup process. init.rc is part of this process. It is run when the kernel boots up. Anything within the init process is low-level and essentially run as "root". It kick-starts various other processes like zygote which is the Android process management system. This will help you understand the init process a bit better (http://www.mekya.com/blog/2012/03/android-initialization-from-init-rc-to-third-party-code/). In the init.rc file is a line which "executes" the file /sbin/recovery (which is embedded in the ramdisk along with cfautoroot). This in turn "executes" cfautoroot which takes care of copying the superuser files to the correct locations and setting the correct permission. All this is done within the init process and has elevated (root) permission.
Unlocking the bootloader does not root your phone. It simply allows you to flash "unsigned" (custom) boot images.
Any phone with the ability to flash a custom boot image can make use of this process.
Exploits make use of holes or workarounds to either flash a custom boot image or inject files into the system partition without unlocking the bootloader and are only needed if you cannot unlock the phone bootloader.
Hope this helps!
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Thank you for asking the question and being polite yet persistent about getting your answer. I have been trying to get to this answer myself for some time now.
Sent from my Nexus 5 using Tapatalk
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Casteel said:
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Click to expand...
Click to collapse
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
craigacgomez said:
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
Click to expand...
Click to collapse
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Casteel said:
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Click to expand...
Click to collapse
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
craigacgomez said:
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
Click to expand...
Click to collapse
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Casteel said:
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Click to expand...
Click to collapse
Glad I could help you... It's what communities are all about... Sharing knowledge and experiences.
Sent from my Nexus 5
Excellent thread. Thanks to OP and members who responded.
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.
@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.
I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app
We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.
ATT Pretty Please
me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories
Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app
Works on the LG G5 also...
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.
LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'
Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim
My thread and project are inactive now. Please accept my apologies for this inconvenience.
ast.ls
Blackout
ast.np
Blackout
ast.pm
Blackout
ast.ops
Blackout
ast.settings
Blackout
ast.storage
Blackout
2nd Feedback
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
hotcell said:
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
Click to expand...
Click to collapse
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
I'm sorry, I don't recall what was exchanged in reference to 2.c.
Since I know you like AST, how about sharing something with the community about how it made things easier for you? That is a feedback too. No one would take my word for it because they think I'm on my way to become a millionaire.
3rd Feedback
xdav20 said:
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that..
Click to expand...
Click to collapse
I never do posts asking or hoping for likes. That would be rather strange assumption. Regarding your obviously negative connotation here, it would be more appropriate if you simply remove the "like" you made.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Click to expand...
Click to collapse
Thank you for more detailed explanation. I have to note that you added the explanations in your post #3 after I asked the relevant net policy questions. Either way, IMHO your statement "I think the performance loss or gain is debatable, totally dependant on how Android internally implemented it, and, frankly, this is something I don't wish to get heavily involved with. Please kindly, keep me out of future debates." is not very encouraging. To me it seems that you aren't interested in the discussion of benefits in performance or possible battery savings here, thus logically negating the major possible purpose of using your tool from users perspective. That's strange indeed, but I do respect your wish, so that's it.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
Click to expand...
Click to collapse
Here you are contradicting yourself. As you previously mentioned, you made a deliberate effort to ensure any script can be renamed and still maintain its integrity thus boosting flexibility of usage even more. But here you are basically insisting such move would not be practical. In previous post I suggested you to maintain this flexibility by introducing renaming templates file, so updating the tool will be a simple seemless step/command, without manual intervention required, regardless of a chosen naming scheme. Well, again, it's your call. Perhaps you'd reconsider, just like you did with the inner AST folder in the distribution archive (Thanks BTW for that!).
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
Click to expand...
Click to collapse
Indeed I mentioned this due to failure to obtain the expected result on execution of ast.install. Note this script can't be run from ext SD card due to the obvious permission / media format issue. But, normally the /system is in RO state, so even if jackterm has required root permission, the ast.install still would fail when run from internal storage:
elsa:/storage/emulated/0/Download/ast #sh ast.install /system/xbin
cp: /system/xbin/ast.ls: Read-only file system
chmod: chmod '/system/xbin/ast.ls' to 100755: Read-only file system
cp: /system/xbin/ast.net: Read-only file system
chmod: chmod '/system/xbin/ast.net' to 100755: Read-only file system
cp: /system/xbin/ast.pm: Read-only file system
chmod: chmod '/system/xbin/ast.pm' to 100755: Read-only file system
cp: /system/xbin/ast.ops: Read-only file system
chmod: chmod '/system/xbin/ast.ops' to 100755: Read-only file system
cp: /system/xbin/ast.set: Read-only file system
chmod: chmod '/system/xbin/ast.set' to 100755: Read-only file system
cp: /system/xbin/ast.sto: Read-only file system
chmod: chmod '/system/xbin/ast.sto' to 100755: Read-only file system
cp: /system/xbin/astcore: Read-only file system
chmod: chmod '/system/xbin/astcore' to 100755: Read-only file system
I) ast.install: Installation completed.
elsa:/storage/emulated/0/Download/ast #
Why and how reboot supposed to resolve that?
EDIT: Looks like it works fine when performed right after reboot! It would be nice if install script would try to perform a mount, cp, chmod and report about the failure. Instead of showing the (fake) message "Installation completed." the hint to reboot and retry would be much more useful.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
Click to expand...
Click to collapse
It has nothing to do with wrong impressions. All I tried to suggest was an attempt to provide a path to easy and working solution to install/update AST and have a workaround for system RO state issue as described above. One still will have to ensure the system partition is mounted in TWRP before doing AST install/update. Sure if ast.install or its exec environment can be fixed, there would be no need to reboot to recovery or perform manual steps with a file manager.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
Click to expand...
Click to collapse
If and when I'll proceed with net policy customisation and start to have some comarative data on battery consumption, I'll try to post here without involving you to the subject as per your wish to keep you out of future debates.
@hotcell
I have attached a modified version of ast.install that would double check if 'mount' command remounted /system rw or not. If the script still fails to copy your scripts, without displaying an error message, then, and previously, the problem has nothing to do with my script. I haven't developed 'mount' binary nor know why on your particular system things doesn't work normally. There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not. For such non-critical job, doing more is waste of time.
"ast.storage -lb online" displays the mounted partitions. The very last data is the current read/write status of the partition. After a reboot, could you run the above command to see what it prints about /system partition before and after running ast.install please.
I'm a tool maker, I'm not going to tell anyone where you can use my tool. I can provide guidance how the tool should be used, for productivity purposes only. What thing you have forgotten was, ast.np is a helper tool for Android Netpolicy tool. Without ast.np it is, literally, impossible to use it due to the input format it takes. Knowing how over analytical you can be, I made it clear I wish to stay away from any future debates myself. I have not stated, no one else can debate about it on my thread. I'm sorry, if you took my statement personally and I encourage you to use my thread to discuss anything related to AST. I would response, if I had to.
I thought for a while, how can I prove to @hotcell I wasn't being sarcastic when I "liked" his post? My proof is at the very end of that post when stated: "Since I know you like AST, how about sharing something with the community about how it made things easier for you?" If I didn't mean it, I wouldn't have stated a factual thing, I would had said; "If you like AST then why don't you...". Since I meant what I said without a menacing connotation, I stand by my previous decision. However, I do share your sentiment about the "like" system in place.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Edit: Noticed your edited comment about everything started working after a reboot. I do not like to discuss about something, specially in a public forum, when I do not have factual information. I'm normally good at observing patterns. I'm purely guessing, the reason behind the failure of mount command is to do with how certain file managers that support root handle mounting /system partition. Of course, there is always more than one reasons to such conditions.
Here is what you can do to see if that is the caase or not. Do everything as you would do after a reboot. Use the file managers you use and access the /system partition and copy something over to force the file manager to make the /system partition rw. Exit the file manager and then try the installer script again. Repeat the same thing, this time don't use the same file managers and after the system has been up and running for awhile, try the installer script again. What did you observe?
4th Feedback
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
xdav20 said:
There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not.
Click to expand...
Click to collapse
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Click to expand...
Click to collapse
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
hotcell said:
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
Click to expand...
Click to collapse
Thank you for the quick response. Of course, if my script fails, so as everything else from command line. Now that we established my guess is an actual fact, I have another immediate concern.
Thanks to your screenshots, I have noticed storage.ast -lb command is not displaying the partition fs type and partition read&write status of /system and /userdata and there were errors. I installed Mixplorer and navigated to xbin and created a file. Went back to terminal and used ast.storage -lb online again and it reported everything correctly. You either have a corrupt fs table or there is a condition that I haven't seen before. To make sure, I would like to ask you to send me the following files by running these commands please:
Code:
cat /proc/mounts > mounts
cat /proc/self/mountinfo > mountinfo
cat /proc/self/mountstats > mountstats
Please make sure you have used Mixplorer or the usual things you do that may cause the problem first.
Edit: After a reboot, please run the ast.storage -lb online again and please report back if there were errors. I'm guessing if you do, there is something wrong on your end.
Disclaimer: At the time of publication of this article, I have not found a way to remedy the problem with the application mentioned in this article. If you did, please notify me to make the appropriate changes to this article.
This article came to existence after exchanging messages with @hotcell to which my further investigation revealed a problem with MIXplorer app. I understand MIXplorer has a thread on XDA so there is a chance the developer to be contacted to rectify the problem.
The problem is after /system partition is remounted 'rw' (Read & Write) MIXplorer does not set the partition back to 'ro' (Read-only) even after the application is closed explicitly. This can leave you extremely vulnerable in case a malicious app awaits for such opportunity. Fortunately, after a reboot all partitions will be set back to their default status. However, users might not reboot their phones for days.
Root Explorer from SpeedSoftware has a mount toggle (rw,ro) button for each partition you use which it gives you the control to change the status at will. Then I tested ES File Explorer, as soon as I closed the app the /system was remounted back to 'ro'.
Thanks to ast.storage -lb command I could easily tell what was going on. My advice to you is, to either contact the developer of MIXplorer and request the partitions to be remounted as 'ro' upon exiting the app or similarly to provide a toggle button. In the mean while, I wouldn't use MIXplorer on a device that is connected to the internet.
5th
@xdav20
Although irrelevant in the thread common context, please see the attachment below (as it looks like you disabled PM functionality).
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed. As you noticed about re-mounting on-the-fly from UI, reboot can be avoided by remounting the /system as RO in Root Explorer. Also, another decent file manager X-plorer doesn't need an (clean) exit as it will re-mount the system as RO after FS operation finished.
hotcell said:
@xdav20
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed..
Click to expand...
Click to collapse
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Edit: I have attached a screenshot to prove everything works. I deliberately set the /system to rw.
6th
xdav20 said:
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Click to expand...
Click to collapse
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
hotcell said:
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
Click to expand...
Click to collapse
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes use /system partition and bound to be conflicts.
7th
xdav20 said:
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes uses /system partition and bound to be conflicts.
Click to expand...
Click to collapse
Thanks, although I have no idea what you are going to fix (as it seems the issue is in mounting)
Anyway, I thought you can try to implement an algo like this:
1. check if /system looks mounted as RW, remember the state for later restoration, if not RW, try to re-mount
2. create am empty file named as current time in installation dir
3. try to check if it exists. if yes, delete it and set flag ready=true and proceed to #5.
4. if flag tried is not set (false), try to make double re-mount RW>RO>RW, set flag tried=true, return to #2.
5. if flag ready=false, return error message asking to either reboot or mount /system as RW and exit
6. if ast.rename is absent from install dir, perform scripts copy, otherwise the same with renaming according to the template
7. set chmod on script files as required. Done.
@hotcell
I have attached a pre-release version of AST to this post. This release contains support to handle multiple mountpints on online blocks. Android by default has one single mountpoint per block. However, components/su such as Magisk creates additional mountpoints, one on /dev/block/sda14 and two on /dev/block/sda18. AST can now handle multiple mountpoints on any online blocks, referring to -lb command. Thank you again for the files and your assistance in resolving this issue.
As you have guessed by now, Magisk was the cause of errors and I'm guessing the source of your /system mount issues. Now, that '-lb' command can show correct information on your device, you can keep your eyes on read and write status of both mountpoints on /dev/block/sda14. Please kindly provide a screenshot of '-lb online' so I can make sure everything was okay before releasing it on OP. Since you have installed AST in /system/xbin, please do not run anything locally without specifying its full parh in command line. I'm updating OP about this point shortly.
One minor matter, I have to respectfully ask you to refrain from referencing to AST scripts as your renamed versions. I got confused when you referenced ast.np to ast.net. For anyone following our conversations it can workout confusing too. At this point of time, I don't wish to make a rule and publish it on OP. I hope you can understand the point I raised. Thank you for your understanding.
Edit:01
Added two screenshots. Magisk-Partitions image shows the online partitions with Magisk being installed (based on your device data files) and Default-Partitions image shows a typical device without Magisk? Have you spotted the additional entries?