Develop Bugs

Init.d do not run

I am using the rom IML74K Android 4.0.3 Build 8 from bigxie and franco.Kernel #13.
I think the rom and kernel suppose to support init.d scripts. And I can found the script in etc/init.d named 97schedmc.
I wanna the hotplug function, so I put a file named 98hotplug(I don't know how to named the script), but I found it would not work. The parameter would not change after restart the device. Even I excute it(rename to sh file) in RootExplor, the parameter did not changed.
I try to run or sh the command in adb shell, it works fine, and the parameter changed.
I thinks it is relate to the access right issue, but I don't know how to fix it.
Could any one can help me?
Thanks for the guy who reply me.

you most chmod the files. Just sticking them it won't allow them to run.

I am not such understand... What should I do then?

chmod them?
755 works.

Hi,
Like this:
For 755,right permissions for scripts in Init.d folder,a good link i think: http://www.elated.com/articles/understanding-permissions/
Do not create a sh. file,for example in Root Eplorer,go to system/etc/init.d and menu/New file then put your script with #!/system/bin/sh first then space then enter.
Or on your pc take a init.d file in a rom,erase the script,copy yours with the correct script,reput in your phone,set the correct permissions then reboot.
Are you really sure your rom/kernel suppot Init.d ?
Just one question,I do not use this combo...
Hoping this helps

Permissions are set correctly, the kernel (faux123) supports init.d scripts, and the script works when run from terminal, but it still does not run on boot.

Thanks for your reply and great help!
I am sure the kernel support the init.d, but I not sure the rom, is it necessary both of them to support init.d?
What is your combo??

Hi,
To monkeyzou,yes i use the same kernel wich support Init.d script,but i use aokp rom,the rom you are using seems not support Init.d (it is not specified?),but in any case the Franco kernel support it,and it create the necessary lines in "init.rc" for activate the init.d support+the init.d file+the correct permissions,all automatically when you flash the kernel...
So i don't now what is wrong
Are you sure you set the right permissions for your file script in init.d?Are you sure your script is written correctly?
Can you share it?
After that my knowledges stop there,sorry...

init.d support only needs to be in the kernel ramdisk. As for rom support, that only goes as far as needing the directory. Note that some of the kernels out there are anykernel format and therefore would not support init.d scripts.

I was trying to do the exact same thing and couldn't make it work either. Eventually I just used Script Manager (on market) and let it run the script at boot.
Here is my script:
Code:
#!/system/xbin/bash
echo 1 > /sys/module/dsscomp/parameters/hotplug_enabled

Re,
To monkeyzou can you test this script at the bottom of my message?
Remove the .txt and copy it to your init.d folder then set the right permissions for it as i have shown above.
Or test another script where you could see a change?
At the end are you sure your script don't work?
After reboot with the script go to /sys/module/dsscomp/parameters/hotplug_enabled and see if the value is set to 1,if yes it's ok,if no (so set to 0),i don't know more...

ctbear said:
I was trying to do the exact same thing and couldn't make it work either. Eventually I just used Script Manager (on market) and let it run the script at boot.
Here is my script:
Code:
#!/system/xbin/bash
echo 1 > /sys/module/dsscomp/parameters/hotplug_enabled
Click to expand...
Click to collapse
Hi,
Test the script i've posted above:
#!/system/bin/sh
echo 1 > /sys/module/dsscomp/parameters/hotplug_enabled
Click to expand...
Click to collapse
I hope that helps

viking37 said:
Hi,
Test the script i've posted above:
I hope that helps
Click to expand...
Click to collapse
Thanks. Unfortunately it still didn't work, but I've found a workaround (looks stupid, but somehow works):
Basically I have a script file at the root of storage, and it contains just the echo line. My init script will just run that /sdcard script and it works fine.

viking37 said:
Re,
To monkeyzou can you test this script at the bottom of my message?
Remove the .txt and copy it to your init.d folder then set the right permissions for it as i have shown above.
Or test another script where you could see a change?
At the end are you sure your script don't work?
After reboot with the script go to /sys/module/dsscomp/parameters/hotplug_enabled and see if the value is set to 1,if yes it's ok,if no (so set to 0),i don't know more...
Click to expand...
Click to collapse
Tried this script and it works

Usage of init.d scripts

Hi
Actually there are already a lot of threads on xda which describe this
so everyone interessted can already get a enough information about it.
If you have specific questions you can of course use this thread
for asking them.
I just want to share some "insights" that I recently discovers which maybe
of interest for e.g. ROM developers that use init.d scripts
Typically init.d scripts are "enabled" by using the following in
the "main" startup script that is executed right after the kernel
has booted which is /init.rc
/system/xbin/busybox run-parts /system/etc/init.d
So it requires busybox and is using the command "run-parts" which is
simply executing all scripts found in /system/etc/init.d
This is how the line looks in Titanium kernels
but this line can create a small "problem"
Depending on your busybox installation run-parts is already a symlink
in /system/xbin to busybox
The effect is that now all scripts are executed TWICE
If you use e.g. myONE you can check this by examing
/data/zipalign.log where yuo will see everything twice
The init.rc parser seems to "know" that run-parts is already a executable
and therefore runs both
busybox run-parts /system/etc/init.d
AND
run-parts /system/etc/init.d
Aside from the "bad" that scripts are executed twice which needs more time
it can have unwanted sideeffects depending on what you are doing in init.d scripts
There are two ways to "fix" this
1) remove the symlink run-parts in /system/xbin
2) change the line in init.rc to
run-parts /system/etc/init.d
But since this file is typically in the ramdisk of the boot.img you
dont have full control of this file since flashing a different kernel
may override it again.
Actually the best way to fix this would be in init.rc to check if the
symlink is there or not. But I dont know have enough knowledge about
all of this at the moment.
regards
max

Thanks for the heads up. I just checked mine and all the init scripts were running twice so I moved /system/xbin/run-parts to /system/xbin/run-parts.bak

this should be posted under "GENERAL"....

1ceb0x said:
this should be posted under "GENERAL"....
Click to expand...
Click to collapse
Feel free to tell the mod
regards
max

[GUIDE] how to create init.d

This page explains how to create init scripts.
PHP:
#!/system/bin/sh
# Example script
START= 10
STOP =15
start() {
echo start
# commands to launch application
}
stop () {
echo stop
# commands to kill application
}
What this means:
Click to expand...
Click to collapse
START=10 - this means the file will be symlinked as /etc/rc.d/S10example - in
other words, it will start after the init scripts with START=9 and below, but before
START=11 and above.
STOP=15 - this means the file will be symlinked as /etc/rc.d/K15example - this
means it will be stopped after the init scripts with STOP=14 and below, but before
STOP=16 and above. This is optional.
start() - these commands will be run when it is called with 'start' or 'boot' as its
parameter.
stop() - these commands will be run when it is called with 'stop' as its parameter.
If you add a section like the one below:
Click to expand...
Click to collapse
PHP:
boot () {
echo boot
# commands to run on boot
}
… then these commands will be run on boot, instead of those in the start() section. This
is handy for things that need to be done on boot, but not every time the program it calls
restarts.
You can add your own custom commands by using the EXTRA_COMMANDS variable, and
provide help for those commands with the EXTRA_HELP variable, then adding sections
for each of your custom commands:
PHP:
EXTRA_COMMANDS = "custom"
EXTRA_HELP =" custom Help for the custom command"
custom () {
echo "custom command"
# do your custom stuff
}
If you run the script with this code added, with no parameters, this is what you'll see:
Shell Output
Click to expand...
Click to collapse
PHP:
[email protected]:/# /etc/init.d/example
Syntax: /etc/init.d/example [command]
Available commands:
start Start the service
stop Stop the service
restart Restart the service
reload Reload configuration files (or restart if that fails)
enable Enable service autostart
disable Disable service autostart
custom Help for the custom command
If you have multiple custom commands to add, you can use here documents to add help
text for each of them:
PHP:
EXTRA_COMMANDS = "custom1 custom2 custom3"
EXTRA_HELP =<< EOF
custom1 Help for the custom1 command
custom2 Help for the custom2 command
custom3 Help for the custom3 command
EOF
custom1 () {
echo "custom1"
# do the stuff for custom1
}
custom2 () {
echo "custom2"
# do the stuff for custom2
}
custom3 () {
echo "custom3"
# do the stuff for custom3
}
Enable and disable
Click to expand...
Click to collapse
Dont forget to chmod +x /etc/init.d/example !
In order to automatically start the init script on boot, it must be installed into /etc/
rc.d/ .
Invoke the "enable" command to run the initscript on boot:
Shell Output
[email protected]:/# /etc/init.d/example enable
To disable the script, use the "disable" command:
Shell Output
[email protected]:/# /etc/init.d/example disable
The current state can be queried with the "enabled" command:
Shell Output
[email protected]:/# /etc/init.d/example enabled && echo on
on
See the attachment(also a init.d file)

credit goes to:
Allah(swt)
me
and some websites and some developers who helped me(not on xda)

i'm afraid that guide is for linux. in android we only need to use this pattern
Code:
#!/system/bin/sh --> the header
echo bla bla bla --> the script
the script will be executed in alphabetical order.

kurotsugi said:
i'm afraid that guide is for linux. in android we only need to use this pattern
Code:
#!/system/bin/sh --> the header
echo bla bla bla --> the script
the script will be executed in alphabetical order.
Click to expand...
Click to collapse
is it wrong bro...

the only thing need to fix is your header. the correct one in sgy is "#!/system/bin/sh" since we don't have sh binary file in /sbin. the other parts...I don't know. it seems too complicated for me (lol) anyway, don't you think you should give some init.d script as an example? it will easier for anyone if they can see an example.

attachment added

just take a reference to any init.d script
I don't know what to say as I never created init.d scripts like this as these make no sense to me.
what kurotsugi said is true and I had done that for simple scripts but if you basically do in normal Linux way
check this sample init.d script of smb used in Linux
The /etc/rc.d/init.d/smb script file
Just consider above linked script as a reference to your init.d script and create your own

I found this http://forum.xda-developers.com/showthread.php?t=1933849. How to make it work on sgy? I cant understand
Sent from my GT-S5360 using xda premium

@explodeaamir
just info. android did not support init.d. most (maybe all) init.d in custom rom technically only fake init.d. true init.d not only support running script in boot process but also in shutdown process (like in your example). your example using OpenWrt which is true linux distro, but android is not.
@kundancool
OOT. bro, do you still developing rokr e6 ?

@decka: that stuff doesn't work for stock sgy since our kernel doesnt support install-recovery.sh

i thought just easy as create folder in etc,, just name it init.d,,rwrwrwrw permission,,,,i was wrong

irfanbagus said:
@explodeaamir
just info. android did not support init.d. most (maybe all) init.d in custom rom technically only fake init.d. true init.d not only support running script in boot process but also in shutdown process (like in your example). your example using OpenWrt which is true linux distro, but android is not.
@kundancool
OOT. bro, do you still developing rokr e6 ?
Click to expand...
Click to collapse
Actually my e6 is badly damaged to get in flash mode and since there is no activity from others so I have halted all development for that
And galaxy Y is my primary phone so I have no development going on for it but as soon as get a backup phone I might do some for people at XDA
Sent from my GT-S5360 using xda app-developers app

SOLVED! Python on the command line (scripts on post #17)

Hello everyone,
If your just reading this, skip to page 2 to save me some embarassment... Been a learning curve.
Go here .... http://forum.xda-developers.com/showpost.php?p=47607547&postcount=17
First post here and well I hope it's in the right place. I am definitely a novice programmer, am a little comfortable writing small python scripts which leads to this...
I got my phone rooted, I have sl4a ( It Nice! I like it. You like dogs?), and I just got my CM 10 source on Ubuntu 10 like Google recommends. I got adb working and Terminal IDE so I originally wanted to get python to be able to be called by the bash shell it provides ( I think its bash). I sorta got it working for a single session but what a drag, and I would get an error along the lines that the title suggests, so I,m not happy about that.
I also managed to get a copy of python from com.googlecode.pythonforandroid into /system/bin/ and now when I type "python" into an ADB shell I get the python interpreter!!! Whoo hooo, but I still got that same error. A "import sys", "import ephem", and maybe a few more workes but still something is wrong it said something thiss stuff here..
"""[email protected]:/data/data # python
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""

update/bump
Ok so looking at the error message again it seems that it wants two prefixes for the $PYTHONHOME variable, I assume two paths and the secon one is to the executable that I put in /system/bin/ which is already in my path hence why python is callable. I had also fumbled around haphazardly with my $PATH vriables the other day and may have added the path to some of the libs python was asking for such as libpython2.6.so, I think I added the directory that lib is found in to my path (its found in "/data/data/com.googlecode.pythonforandroid/files/python/lib/" I think, need to double check that one), so thats what ive done that made this 'click' so to speak into popping out the python interpretor.
Also I found this file...MSM8960_lpm.rc but I forgot from where it came. It looks as if it contains some global variables that get set during boot, am I right?
This is the top part of it...
"""
on early-init
start ueventd
on init
sysclktz 0
loglevel 3
# setup the global environment
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export EXTERNAL_STORAGE /mnt/sdcard
export EXTERNAL_STORAGE2 /mnt/sdcard/external_sd
export USBHOST_STORAGE /mnt/sdcard/usbStorage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
"""
So I am thinking that if I set the paths to my Python exec and libs here, as well as Paths for Lua, Perl, JRuby, Python 2.7, Etc, etc then I would have an assortment of scripting languages to launch into ffrom ADB, am I right? This would help me and others write scripts for ADB in many languages to do repetitive grunt work from scripts.
Any advice would be great as it works but its like python is injured, "import os" didnt work ;( but "import sys" did
It would also be nice if these same vriables could be set for Terminal Emulator, Terminal IDE, and the like, I know SSH is in the works with T. IDE and that one has telnet though I havent figured that out yet.
What should I do? This seems like an OS related issue but if the interpreter is there and compiled for arm and the libs aswell why would this not work?

python -v output
this is the "python -v" output to show what's happening, maybe it'll help....
"""
[email protected]:/ # python -v
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
'import site' failed; traceback:
ImportError: No module named site
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import os
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named os
>>>
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 3 unfreed ints
# cleanup floats
[email protected]:/ #
"""

That snippet you posted is from the init.rc inside the boot.img...so yes, it has all sorts of initialization code

CNexus said:
That snippet you posted is from the init.rc inside the boot.img...so yes, it has all sorts of initialization code
Click to expand...
Click to collapse
Ok, so I'll so some reading on setting $PYTHONHOME variable and others, I need to learn how that all works anyways. Most if not all of what I find documents how to set the variables for Windows, Mac, or Linux and not for Android. I will do my best to use that knowledge to fit this situation. I also need to dive around the file system a bit more and find all those libs and try to get the paths set for those to work with ADB and not just SL4A.
If I can do that maybe some more Linux programs/commands can be moved into Android's system, I know alot of the GUI apps for Linux have dependencies for python and gtk and qt, those modules might be portable to Android if they haven't already done so. Not to mention the other interpreters like Perl. To be perfectly honest what I want to do is port over Kali's toolset (at least the cmd line tools) over to android to they can be run from a terminal emulator or adb its self. Thats what I want to do with it, then wrap it all up into a ROM and build it. I know they have already compiled most of Kali's and BackTrack's programs on ARM so I was thinking of pulling those apps from there after an upgrade and then moving them into Androids system e.g /system/bin : /system/lib : /etc/* and so on, if the file systems are too different I suppose I can add directories and make a PATH for them or add them to $PATH once I learn how all that works.
Any good documentation on related issued anyone might be able to link to would be great, I'll be droppin by every so often while I'm grinding through google, thanks in advance for any help and thank you for your time, a bit of a read I suppose.

Environment variables like that would need to be set inside the boot.img, so if you want to unpack it and see exactly how things are defined and what other files are there (good exercise all around IMO), grab my tools from over here and unpack it for yourself and take a look:

cool tools
CNexus said:
Environment variables like that would need to be set inside the boot.img, so if you want to unpack it and see exactly how things are defined and what other files are there (good exercise all around IMO), grab my tools from over here and unpack it for yourself and take a look:
Click to expand...
Click to collapse
Well I downloaded twrp 2.3.1.0-d2spr and I used the split_boot tool in the package and got a little tree of files including the init.rc and the other msm one, they seem very similar if not identical (?), weird.
I just have a quick question, do I need to repack all this at a certain size? In other words, if I make any changes in the ramdisk image will it refuse to boot? I browsed over some sites and read somewhere that if I changed the kernal image it would fail a hash check and that the type of hashing ( I use bubble bags, but that's for another forum). How much attention do I need to pay to the size of these files I may alter before I repack and flash to the device?

Edge-Case said:
Well I downloaded twrp 2.3.1.0-d2spr and I used the split_boot tool in the package and got a little tree of files including the init.rc and the other msm one, they seem very similar if not identical (?), weird.
I just have a quick question, do I need to repack all this at a certain size? In other words, if I make any changes in the ramdisk image will it refuse to boot? I browsed over some sites and read somewhere that if I changed the kernal image it would fail a hash check and that the type of hashing ( I use bubble bags, but that's for another forum). How much attention do I need to pay to the size of these files I may alter before I repack and flash to the device?
Click to expand...
Click to collapse
Yes, actually. You need to repack at certain offsets/addresses or the device will be unable to read it properly
Run the boot_info script on your .img file and it will give you everything you need to know to repack the boot.img correctly
First you gotta repack the ramdisk (repack_ramdisk [optional out file])
Then after you do that, you can use the mkbootimg binary along with the info from my boot_info script to make a new boot.img with the right offsets
I've done a ton of boot.img splitting, so here's what it should look like (I forget the cmdline parameter)
Code:
mkbootimg --kernel KERNEL --ramdisk RAMDISK --base 0x80200000 --oversize 2048 --cmdline 'android.I.don't.remember.this.one' --ramdiskaddr 0x81500000 -o new_boot.img
Sent from my S3 on Sense 5 (you jelly?)

CNexus said:
Yes, actually. You need to repack at certain offsets/addresses or the device will be unable to read it properly
Run the boot_info script on your .img file and it will give you everything you need to know to repack the boot.img correctly
First you gotta repack the ramdisk (repack_ramdisk [optional out file])
Then after you do that, you can use the mkbootimg binary along with the info from my boot_info script to make a new boot.img with the right offsets
I've done a ton of boot.img splitting, so here's what it should look like (I forget the cmdline parameter)
Code:
mkbootimg --kernel KERNEL --ramdisk RAMDISK --base 0x80200000 --oversize 2048 --cmdline 'android.I.don't.remember.this.one' --ramdiskaddr 0x81500000 -o new_boot.img
Sent from my S3 on Sense 5 (you jelly?)
Click to expand...
Click to collapse
Thanks,
I actually just got the CWM ROM manager, I updated my CWM and am backing up my rom now, its pretty much stock lacking updates cuz of root I think, I eventually wanna get over to CM or some other rom but CM seems to be supported pretty well.
1) So the backup just finished a second ago, can I pull a boot image out of that? :EDIT: Check. I saw it in the recovered folder.
2) I'll use the boot info on that img when I get it.
3) I guess this is all for testing the variables and getting interpreters to run from adb and T.E. after that I need to install CM 10 to get some blobs, thats all thats hanging me up from modifying the source to build my own version, this is great exercise as it will need to be done when building this "Cyano-Kali" or whatever, I was also thinking "Kali0id" as in Kalioid and Kali zero i.d.

ok well I did some messing around and I got this lill chroot setup working from adb which is kool, I just took a no gui kali.img and a script I found to chroot into it ( Maybe Google "Weaponizing Android"), it needs a lil investigating though I get a couple errors, it looks like it was modified from a chroot into ubuntu (arm).
I put the script into /system/xbin/ and then made it executable (that seems to be the only place I could chmod), I looked at the sript at it points to a coded directory for the kali.img which is something like "/storage/sdcard0/kali/kail.img". This puts the script in a location that is already in the environ variable and you can call it from any cwd by typing "kali".
Note: Interesting tip (may be trivial to the pros), typing "bash" gives me a colorful interface and the bash interpreter, this is good for a first command when entering the terminal or adb because then you can modify the bash rc file found in "/system/etc/bash/" (I think, I'll double check later.*FIXED*).
So, I think I might be able to mod those variables there to include PYTHONPATH, PYTHONHOME, etc...
Then when I launch bash i should be able to launch python and whatever else. (*Check*, it works but you must first "bash" and then "python" to allow the bashrc file to get ran and add PYTHONHOME and PYTHONPATH to the enviroment)
I think the first shell that you get put into is shell and not bash but maybe I'm wrong.
*side note, If you want to su into bash its best ime to do that first, then bash, otherwise when you su while in bash you loose the color, idk why.
heres my results so far...
Code:
[email protected]:~$ adb devices
List of devices attached
xxxxxxxxxx device
[email protected]:~$ adb shell
[email protected]:/ $ su
[email protected]:/ # bash
void endpwent()(3) is not implemented on Android
localhost / # kali
ioctl LOOP_SET_FD failed: Device or resource busy
mount: Device or resource busy
net.ipv4.ip_forward = 1
[[email protected] ~$ cd .. && ls
bin dev home lost+found mnt proc run selinux sys usr
boot etc lib media opt root sbin srv tmp var
[[email protected] /$ which macchanger
/usr/bin/macchanger
[[email protected] /$ which ophcrack
/usr/bin/ophcrack
[[email protected] /$ which reaver
/usr/bin/reaver
[[email protected] /$ which aircrack-ng
/usr/bin/aircrack-ng
[[email protected] /$ python --version
Python 2.7.3
[[email protected] /$ perl --version
This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabi-thread-multi-64int
(with 80 registered patches, see perl -V for more detail)
Copyright 1987-2011, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
[[email protected] /$ bash --version
GNU bash, version 4.2.37(1)-release (arm-unknown-linux-gnueabi)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[[email protected] /$ python
Python 2.7.3 (default, Jan 2 2013, 22:35:13)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import sys
>>>
[[email protected] /$ exit
Shutting down Kali ARM
failed: Device or resource busy
losetup: /dev/block/loop255: Device or resource busy
localhost / # exit
1|[email protected]:/ # ^D
1|[email protected]:/ $ ^D
[email protected]:~$
Does anybody know how to mount an external sdcard from the command line on the Debian version of Linux on Android?
Is that even possible, like driver wise and what not?

Nice!
To mount it, first you would need it's device name or UUID..
Sent from my S3 on Sense 5 (you jelly?)

Success!
Alright! I got Python working from the terminal emulator!
I ended up copying the files that got installed by the original installer into my system/ lib, xbin, and, bin directories I just kinda put stuff here or there and then I just got one error about platform independent libraries instead of both dependent and independent. I'm alil add about things sometimes. Then about ten minutes ago while chilling on the patio the syntax for the PythonHome and path variables became clear to me. So i changed it to export and wrapped the paths in quotes and figured out the prefix : exec_prefex thing.
Now python works!!!!!!! ill run it on adb tomorrow and show the results as well as exactly how to get it working after i figure out exactly what i did right. It was probably the last thing.

Edge-Case said:
Alright! I got Python working from the terminal emulator!
I ended up copying the files that got installed by the original installer into my system/ lib, xbin, and, bin directories I just kinda put stuff here or there and then I just got one error about platform independent libraries instead of both dependent and independent. I'm alil add about things sometimes. Then about ten minutes ago while chilling on the patio the syntax for the PythonHome and path variables became clear to me. So i changed it to export and wrapped the paths in quotes and figured out the prefix : exec_prefex thing.
Now python works!!!!!!! ill run it on adb tomorrow and show the results as well as exactly how to get it working after i figure out exactly what i did right. It was probably the last thing.
Click to expand...
Click to collapse
Nice
Sent from my S3 on Sense 5 (you jelly?)

Solution !
Ok I got everything cleaned up a bit, lets see whats going on here...
So hopefully bash is preinstalled for everyone, I just found it, the only changes I made in the past week are installing...
1) CyanogenMod, I believe you will need to already be rooted, have busybox, and a custom recovery to get this far. If you can get CyanogenMod working then you'll probably be able to replicate this, mayeb even with just root and busybox on a stock sprint rom, idk.
2) SL4A along with Python 2.6, Perl, and JRuby. (I hope normal ruby programs can be ran will JRuby, if not I'll either mod the programs or port ruby to android or look for another port.
3) Terminal IDE. This could have been a source of bash if it wasn't native to android or the Terminal Emulator/busybox.
Once you have The above, at least python 2.6 with SL4A, Terminal Emulator, Busybox, and root.
You can (the file system maybe different for different phones but since we are in a specific place of this forum I'll stick with what I found on my phone specifically)
Use a root browser and find a way to remount your file system to read/write or r/w or rw mode so you can write to /system directory. It is located in the / directory of the entire system, not just the sdcard0 partition.
You can open a terminal and type "set" to get a closer look at whats happening here on Android. We are mainly interested in the Environment Variables.
What I did was copy
"/storage/sdcard0/com.googlecode.pythonforandroid/extras/python" ----> "/system/etc/python" ##THIS IS A DIRECTORY
"/data/data/com.googlecode.pythonforandroid/files/python/lib/python2.6" ----> "/system/lib/python2.6" ##THIS IS A DIRECTORY
"/data/data/com.googlecode.pythonforandroid/files/python/bin/python" -> "/system/xbin/python ##THIS IS A FILE, IT IS AN EXECUTABLE!
"/"/data/data/com.googlecode.pythonforandroid/files/python/lib/" ----> "/system/lib/python2.6/" ##WE WANT ALL THE "*.so" FILES NEXT TO THE ORIGIONAL "*/PYTHON2.6/" DIR IN THE "DATA/DATA/" SIDE OF THE TREE TO BE COPIED TO THE SYSTEM SIDE AND INTO THE "/system/lib/python2.6/" DIR NEXT TO THE "/system/lib/python2.6/lib-dynload/" DIR
We want our "/system/lib/python2.6" directory to contain the following :
"/lib-dynload" is a dir; and all the .so files from earlier there are about 8 with a fresh install of python and no modules, some of you may already know how to incorporate modules from this point, but I still need to do some experimenting.
---------------------------------------------------------
OK
if you still following then your gonna wanna do the following
go to "/system/etc/bash" and open the bashrc file, we need to add PYTHONPATH and PYTHONHOME to it, this is how I set it up....
About half way down it will read
Code:
"""
# set some environment variables
HOME=/sdcard
TERM=linux (maybe change this to "Administrator" but that may break something)
"""
# Our additions follow:
export PYTHONHOME="/system/etc/python:/system/xbin/python"
export PYTHONPATH="/system/etc/python:/system/lib/python2.6/lib-dynload:/system/lib/python2.6"
Ok, now if you go to your teminal emulator or ADB shell you can type:
bash [press enter]
python [press enter]
and check out the results
or
su [enter]
bash [enter]
python [enter]
and see what happens
whats happening is that your PYTHONHOME and PYTHONPATH variables are being set when you enter bash, and since they are exported from the bashrc file they get carried over to any child activities that may spawn, such as "python". Correct me if I am wrong.
I may have forgot some little file I put somewere a few days ago or something so let me know if it doesn't work for you i'll do my best to help you get it working on your phone to,
other then finding a rc file for the shell that you start with when you launch the terminal or any other process maybe even, I may need to do what CNex suggested and complete the change in a boot.img to flash to my phone. that should result in the variables being passed to all activities.
Peace yo
Any questions I'll drop around if this dies of from here, well live and let die I suppose.

Just a screen shot
Just a screen shot.

I found the "mkshrc" file in "/system/etc" today so I added the PATHs to that file and now when teminal emulator starts it has access to python's libs. ("/system/etc/mkshrc" should be the location)
I've run into two problems, the first I can live with, the second is only more reason to port Kali's toolset into android.
1) I can't yet access the pydocs for interactive help, for example...
Code:
[email protected]:~$ adb shell
[email protected]:/ $ python
dlopen libpython2.6.so
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> help (android)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/site.py", line 431, in __call__
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/pydoc.py", line 1720, in __call__
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/pydoc.py", line 1766, in help
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/pydoc.py", line 1508, in doc
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/pydoc.py", line 1314, in pager
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/pydoc.py", line 1338, in getpager
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/tempfile.py", line 286, in mkstemp
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/tempfile.py", line 254, in gettempdir
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/tempfile.py", line 201, in _get_default_tempdir
IOError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']
>>>
And
2) When I chroot into Kali.img the PYTHONPATH and PYTHONHOME variables get carried over and interfear with python within Kali. ????
Work around: is just modifing "bashrc" then when you want python or other inerpreters launch bash first and call kali from shell.
Solution: is porting Kali's Toolkit and more Linux programs and commands into Android. Then release as rom or give instructions on how to set up.

No Really, I think I got it figured out this time.
If your running python 2.6 via Py4a then youll use the first script to access python from the command line or over adb, you'll need su to but it in /system/bin or /system/xbin and to use this command to write to the system partition "mount -wo remount systemfs /system" when your done use "mount -ro remount systemfs /system" (with out the quotes of course).
Note: adbd can only be ran as root, so this method will only work as root. Also I had some trouble disconnecting from adb as "exit", it hung till I unplugged the phone from usb. But, still I got to run scripts python that utilize the androids api with-out having to directly open sl4a and then the python interpreter from there.
Note2: Maybe one who was slick enough could get the source for sl4a and pick out the server and facade code, then make a little dex to be ran from the command-line instead of starting the server via "am" and instead of using sockets, maybe ashmem to share the JSON results that get sent back to python.
This is the script for 2.6 :​
Code:
#!/system/bin/sh
am start -a com.googlecode.android_scripting.action.LAUNCH_SERVER \
-n com.googlecode.android_scripting/.activity.ScriptingLayerServiceLauncher \
--ei com.googlecode.android_scripting.extra.USE_SERVICE_PORT 54326
export AP_PORT=54326
export AP_HOST=127.0.0.1
adbd &
export EXTERNAL_STORAGE=/mnt/sdcard/com.googlecode.pythonforandroid
export PY4A=/data/data/com.googlecode.pythonforandroid/files/python
export PY4A_EXTRAS=$EXTERNAL_STORAGE/extras
PYTHONPATH=$EXTERNAL_STORAGE/extras/python
PYTHONPATH=${PYTHONPATH}:$PY4A/lib/python2.6/lib-dynload
export PYTHONPATH
export TEMP=$EXTERNAL_STORAGE/extras/python/tmp
export HOME=/sdcard
export PYTHON_EGG_CACHE=$TEMP
export PYTHONHOME=$PY4A
export LD_LIBRARY_PATH=$PY4A/lib
$PYTHONHOME/bin/python "[email protected]"
This one is for 3.2 :​
Code:
#!/system/bin/sh
am start -a com.googlecode.android_scripting.action.LAUNCH_SERVER \
-n com.googlecode.android_scripting/.activity.ScriptingLayerServiceLauncher \
--ei com.googlecode.android_scripting.extra.USE_SERVICE_PORT 54332
export AP_PORT=54332
export AP_HOST=127.0.0.1
adbd &
export EXTERNAL_STORAGE=/mnt/sdcard/com.googlecode.python3forandroid
export PY34A=/data/data/com.googlecode.python3forandroid/files/python3
export PY4A_EXTRAS=$EXTERNAL_STORAGE/extras
PYTHONPATH=$EXTERNAL_STORAGE/extras/python3
PYTHONPATH=${PYTHONPATH}:$PY34A/lib/python3.2/lib-dynload
export PYTHONPATH
export TEMP=$EXTERNAL_STORAGE/extras/python3/tmp
export HOME=/sdcard
export PYTHON_EGG_CACHE=$TEMP
export PYTHONHOME=$PY34A
export LD_LIBRARY_PATH=$PY34A/lib
$PYTHONHOME/bin/python3 "[email protected]"
Explanation:​-First, the server which handles calls to Android's APIs gets starts by it's activity with am and port is set.
-Second, AP_PORT and AP_HOST get exported so that android.py will have its parameters set to interact with the "facade"
-Third, adbd gets started in the background (I cant give a full explanation, but I found the RPC mechanism between the python interpreter and the sl4a server when android.py is imported and droid.* is attempted)
-Fourth, Python's environment variables get set, doing it this way helps to avoid copying the whole python installation to /system (as I did in the past ), just put one of these scripts in /system/bin or /system/xbin and name it "python" then chmod the script "chmod 755 python" you will be able to call the interpreter and put the shabang in your python scripts (ie "#!/system/bin/python").
-Fifth, launch the interpreter.
Here is a short session over adb:​
Code:
[email protected]:/ # python
dlopen libpython2.6.so
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> droid = android.Android()
>>> droid.makeToast("Hello!")
Result(id=0, result=None, error=None)
>>> droid.getLastKnownLocation()
Result(id=1, result={u'passive': {u'bearing': 0, u'altitude': 0, u'time': 1384816643565L, u'longitude': -67.551754299999999,
u'provider': u'network', u'latitude': 96.0520909, u'speed': 0, u'accuracy': 3533}, u'network': {u'bearing': 0, u'altitude': 0, u'time':
1384816643565L, u'longitude': -67.551754299999999, u'provider': u'network', u'latitude': 96.0520909, u'speed': 0, u'accuracy':
3533}, u'gps': None}, error=None)
>>> exit()
And some credit to others:
http://code.google.com/p/python-for...sh?r=997929b1bbaa53cdf76acfff419ec13c13f869b7
http://stackoverflow.com/questions/10839879/python-sl4a-development
Those are links to where I got some info from to help put this together. The adbd thing was just trying "adb forward tcp:xxxx tcp:xxxx" but that didn't work, so I tried adbd forward tcp:xxxx tcp:xxxx and it looked like it hung there, so I ctl^ c and then just adbd and it hung there again, but when used the "&" to background it and then went to python to try android.py, it worked:good:
And for a lot of fun, go here:
http://code.google.com/p/android-scripting/wiki/ApiReference
-or here-
http://www.mithril.com.au/android/doc/index.html

Assistance modifying build.prop from updater script.

Hi all -
I have made updated scripts before, but something isn't working out for me. I started with this guys script here:
https://forum.xda-developers.com/showpost.php?p=19093919&postcount=20
Purpose is to add lines to build.prop from the script (also does a backup).
First time through I was getting an error which I resolved by updating to a different updater-binary.
I know that the .sh script that I am copying over is running (using some simple touch statements), however it never seem to touches my build.prop.
I think the issue is that somehow it can't access the build.prop file, possibly because it isn't mounting /system properly.
It seems to use busybox commands which I don't have on my device (and I'd rather not install, as I don't want to have to depend on it after clean flash).
Can someone help me out or point me to another script/method of updating build.prop via updater-script?
thanks

Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?

TraderJack said:
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
Click to expand...
Click to collapse
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.

Tulsadiver said:
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Click to expand...
Click to collapse
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.

TraderJack said:
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
Click to expand...
Click to collapse
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.

Tulsadiver said:
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Click to expand...
Click to collapse
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.

TraderJack said:
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
Click to expand...
Click to collapse
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Edit:. That code in bptweaks.sh and that you posted is not mine either. It came from one of the links in your original post. I thought you were indicating that you could not get a script to install. All I did was try and make a vehicle for a script that could modify the build.prop.

Tulsadiver said:
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Click to expand...
Click to collapse
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?

TraderJack said:
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
Click to expand...
Click to collapse
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.

Tulsadiver said:
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Click to expand...
Click to collapse
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/

TraderJack said:
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
Click to expand...
Click to collapse
Yes, it's in the mounting. Pixel 3's don't seem to use BusyBox. They've looks like they've gone to toybox. What this dumbed down version of magisk util_function.sh appears to be doing is installing BusyBox and setting it to be used instead. This one is more like you are used to seeing. The only way I could get it to work is still by using magisk util_function.sh for mounting purposes. I would not be able to write a script like that myself.

I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.

HesThatGuy said:
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
Click to expand...
Click to collapse
Thanks, but 100% not relevant - not only to the replies, but also to the OP.

TraderJack said:
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
Click to expand...
Click to collapse
Sounds like you need to disable dm-verity to edit build prop without using Magisk. Magisk is one big overlay seems to be the way of the future tho. I personally been disabling verity then adding xbin folder to root then linking to system then installing BusyBox to xbin. I don't like using Magisk to install BusyBox module or any module that alters the system because you will have to use Magisk to modify system from there on out instead of jus manully doing it yourself with a root explorer.
Also if you was to flash a open gapps zip it would add a addon.d folder to system. which open gapps and Magisk will install their backup scripts to the addon.d folder. would be a good place for you to add your own backup script as well.

Yeah, you need to disable verity to properly mount /system, /vendor, and /product partitions. It is not hard. In magisk manager just go to advanced options, untick verity, then install magisk from the app. After changes you can put verity back if that bugs you.