Related
Is it possible to change it using root or adb please?
Why would you want to?
Nope. Impossible
NeoTechni said:
Why would you want to?
Click to expand...
Click to collapse
just wanted to clone my wife's one for the hands free in the car to avoid having to switch through the menu in the car.
I was unable to locate /pds as per http://pocketnow.com/tweaks-hacks/motorola-atrix-4g-how-to-change-wi-fi-and-bt-mac from http://forum.xda-developers.com/showthread.php?t=992326. I suspect every phone maker puts Bluetooth address where they wish...
However I was able to locate a zero byte bt_mac_addr file with no extension in /proc folder. It is empty both when bluetooth is on and off.
I hope someone more technically skilled than me can figure out if it can be populated to change the bluetooth address succesfully.
Thanks in advance
I looked at the '/proc/bt_mac_addr' file again using root explorer this time and can see my bluetooth mad address in it and could edit the address and change permissions to it but the modifications don't stay saved even after reboot though the root explorer says changes saved successfully. Can someone help me modifying the file please.
I'm on rooted 2.3.3
/proc is a virtual Filesystem provided by the Linux Kernel. The changes you made there won't persist a reboot cause it only gets saved in Ram.
Thank you. Does it mean I need a script of some type? Is it possible to achieve a change some other way? The pocketnow article seems to do it for the motorola phone but by modifying text file in another folder which I cannot find.
I followed the same process as follows using below commands
C:\Program Files\Android\android-sdk\platform-tools>adb push C:\APK\bt_mac_addr /sdcard/download/bt_mac_addr
1 KB/s (18 bytes in 0.015s)
C:\Program Files\Android\android-sdk\platform-tools>adb shell
$ su
su
# cp /sdcard/download/bt_mac_addr /proc/bt_mac_addr
cp /sdcard/download/bt_mac_addr /proc/bt_mac_addr
cp: can't create '/proc/bt_mac_addr': File exists
Is there another file I can change for it maybe?
Thanks again for all the help.
If you really want to do it then you can (On stock rom) use the same trick that is used for adb remount (Put an echo whatever into into /etc/install-recovery.sh)
You need to make sure it runs as root as well
Have a play around.
Installing the insecure adb apk (From Paul Modaco).
and
adding to the end.
/system/xbin/echo 8D:64:22:01:E2:A9 > /proc/bt_mac_addr
looks like it should work.
(If you have an unlocked bootloader then you can just do it from init.semc.rc in the initramfs)
Or you can look at the method (I posted the manual method in the rooting/insecure adb thread).
This presumes that this is actually working (Its possible you might have to restart a service to actually change it).
just make a simple init.d script
Thank you both. I Will look at it when i'm at the pc. A bit scared having never done anything similar. I Appreciate your guidance very much
Sent from my R800i
Thanks again for your previous replies. I tried "/system/xbin/echo 00:01:02:03:04:05 > /proc/bt_mac_addr" using script manager with superuser permissions granted and running in root mode but it gives the following error: "echo: write error: Input/output error". Same problem in gscript unfortunately.
Would you please tell me what this means and kindly suggest what I should do. I have not figured out yet how to do adb insecure or init.d but hope you could suggest the best way after seeing the above error.
Thanks in advance
ps3taker said:
Thanks again for your previous replies. I tried "/system/xbin/echo 00:01:02:03:04:05 > /proc/bt_mac_addr" using script manager with superuser permissions granted and running in root mode but it gives the following error: "echo: write error: Input/output error". Same problem in gscript unfortunately.
Would you please tell me what this means and kindly suggest what I should do.
Thanks in advance
Click to expand...
Click to collapse
You probably have to remount /system writable
Atarii said:
You probably have to remount /system writable
Click to expand...
Click to collapse
Thank you - I tried this but still same error
ps3taker said:
Thank you - I tried this but still same error
Click to expand...
Click to collapse
try this:
Code:
echo "00:01:02:03:04:05" > /proc/bt_mac_addr
DooMLoRD said:
try this:
Code:
echo "00:01:02:03:04:05" > /proc/bt_mac_addr
Click to expand...
Click to collapse
Thanks - I tried this but it still gives the same input/output error unfortunatelly
Besides mounting system as rw via script manager option I also enabled run at boot, run on network change, run as root but still no change before and after reboot.
I hope you could think of something please. Maybe /proc folder needs to be mounted rw but i'm not sure how or if it is not rw already - root explorer has no problem openning it rw straight away...
Thanks again for everybody's help in advance
ps3taker said:
Thanks - I tried this but it still gives the same input/output error unfortunatelly
Besides mounting system as rw via script manager option I also enabled run at boot, run on network change, run as root but still no change before and after reboot.
I hope you could think of something please. Maybe /proc folder needs to be mounted rw but i'm not sure how or if it is not rw already - root explorer has no problem openning it rw straight away...
Thanks again for everybody's help in advance
Click to expand...
Click to collapse
It won't work as that interface is read only
Sent from my R800i using XDA App
Thanks for trying to help.
I wonder if there is another file somewhere. Any idea what Play's equivalent of Motorola's Atrix 4G folder called "/pds" is - as it it seems to work for them: http://pocketnow.com/tweaks-hacks/motorola-atrix-4g-how-to-change-wi-fi-and-bt-mac
Thanks again for all the help - it was exiting to try scripts and other things you pointed me to.
Hi all
I have read many threads with similar issue, then this my way how to fix it.
Ie: Folder mount app, which make reboot the phone after we mount a folder.
Just add this line to this file : /system/etc/install-recovery-2.sh
If the file is missing, just create it.
Requirement:
on JB 4.3
superSU atleast v200 installed
busybox installed, got it from Playstore, ie: Busybox X,
Code:
#!/system/bin/sh
pkill -f /sbin/ric; mount -o remount,rw /; chmod 644 /sbin/ric
#just to make sure ric is killed
pkill -f /sbin/ric
How to:
You better know than me. but here my way.
if your phone reboot after you touch mount rw in root explorer then adb or terminal emulator is your friend
remount rw system, make the file, then push/copy to target directory, and set correct permission , chmod 755 install-recovery-2.sh
done.
.
This thread lacks a lot of info. You just forgot to cite you must have busybox installed and that this line should be put in install-recovery-2.sh if running Android 4.3 firmware to avoid conflicts with daemonsu...
conclusion:
You didn't search enough
mbc07 said:
This thread lacks a lot of info. You just forgot to cite you must have busybox installed and that this line should be put in install-recovery-2.sh if running Android 4.3 firmware to avoid conflicts with daemonsu...
conclusion:
You didn't search enough
Click to expand...
Click to collapse
Hi mbc07,
i have put the line in that file and of course is work. never get reboot again. i have read the note by superSU in that file too.
but iam forgot to cite the busybox, and i have busybox installed.
but hey thanks, i edited the OP.
Dear friends and OGPro users,
I got annoyed by running SELinux permissive for only one app - Viper4Android - so I've started searching for a way to allow it to run under Enforced mode. So far, I have found two ways:
1) changing ROM's sepolicy before building to allow exec permission for mediaserver (which looks like a bad idea),
2) adding live SELinux rule via init.d script
Second way looks a bit better for me, and someone at forums already made a fix, but it's working only if you have SuperSU installed because it needs SuperSU's supolicy binary.
Since lots of us don't use SuperSU, but instead use implemented superuser option, and since supolicy is closed source and only available in SuperSU package, I took some liberty and some of my free time to spend on lots of Google searches to find a way to implement this fix.
Requirements for this are:
- Lollipop ROM and kernel with init.d support
- working init.d
- good will to try it
Basically, this script flashes setools-android with sepolicy-inject binary and simple init.d script which is run at every boot and sets needed rules for mediaserver, allowing V4A to run under SELinux Enforced.
Flashable zip is available in the attachment. Tested and working on my device, running PAC 5.1.
setools-android and sepolicy-inject are open-source software, and credit for those projects goes to:
- xmikos @ github, for creating this tool bundle,
- pasis @ github, for originally porting setools,
- Joshua Brindle @ bitbucket, for creating sepolicy-inject
Thanks! Great work!
Hi There, just wanted to say thanks for your great work, I had to edit the install script to allow it to install on my device (Samsung Galaxy Express GT-I8730 - Running CM-12.1). But it works perfectly! You should share this with the V4A Thread!
Thanks again!
onvsop said:
Hi There, just wanted to say thanks for your great work, I had to edit the install script to allow it to install on my device (Samsung Galaxy Express GT-I8730 - Running CM-12.1). But it works perfectly! You should share this with the V4A Thread!
Thanks again!
Click to expand...
Click to collapse
You're welcome I haven't tested it on other devices so I had to play safe. If it's working for you as it should, I'll fix installer script in few days
hi
will this work on cm12.1
jeevan_500 said:
will this work on cm12.1
Click to expand...
Click to collapse
It should work on any ROM/kernel combination with functional init.d or init.d simulation, like in Kernel Adiutor (just edit the updater-script and remove e980 lines if you're on different device)
For changing SELinux to Permissive mode permanently, run the following commands through Terminal Emulator:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "setenforce 0" > /system/su.d/permissive.sh
echo "0" > /sys/fs/selinux/enforce
chmod 755 /system/su.d/permissive.sh
fmaher said:
For changing SELinux to Permissive mode permanently, run the following commands through Terminal Emulator:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "setenforce 0" > /system/su.d/permissive.sh
echo "0" > /sys/fs/selinux/enforce
chmod 755 /system/su.d/permissive.sh
Click to expand...
Click to collapse
Point of this zip is to allow only domains needed for V4A to run as permissive, not whole system. System is still running under enforced, just V4A gets access to tmpfs it needs to work properly.
Hi @ShadySquirrel,
I really like your found solution. I think it's way better than flashing supersu and all the v4a stuff to get it working. However it doesn't seem to work on Android 6. More information is on the screenshot attached. Is it easy to fix this by changing the support range from 15-29 to 15-30 or any other way?
Thanks in advance
pittvandewitt said:
Hi @ShadySquirrel,
I really like your found solution. I think it's way better than flashing supersu and all the v4a stuff to get it working. However it doesn't seem to work on Android 6. More information is on the screenshot attached. Is it easy to fix this by changing the support range from 15-29 to 15-30 or any other way?
Thanks in advance
Click to expand...
Click to collapse
Marshmallow will have to wait until binaries I'm using there are fixed and get support for it, unfortunately... Since I'm not the author of binaries, I can't give you an ETA.
ShadySquirrel said:
Marshmallow will have to wait until binaries I'm using there are fixed and get support for it, unfortunately... Since I'm not the author of binaries, I can't give you an ETA.
Click to expand...
Click to collapse
Yes I understand.. Well, let's wait and see. Thanks for the quick reply.
do i need to reinstall this everytime i update rom?
[email protected] said:
do i need to reinstall this everytime i update rom?
Click to expand...
Click to collapse
Yes.
P.S. This is not necessary for Slim.
Thanks worked great on lollipop.
I hope you will update the thread when you come up with the solution for marshmallow.
Regards.
fmaher said:
For changing SELinux to Permissive mode permanently, run the following commands through Terminal Emulator:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "setenforce 0" > /system/su.d/permissive.sh
echo "0" > /sys/fs/selinux/enforce
chmod 755 /system/su.d/permissive.sh
Click to expand...
Click to collapse
Well I'm not sure what I have done wrong here... it revert backs to Enforcing mode everytime after reboot.
I am on CM 13
ShadySquirrel said:
.
Click to expand...
Click to collapse
Can you make it compatible with Nougat?
OsniNO said:
Can you make it compatible with Nougat?
Click to expand...
Click to collapse
No, sorry, I don't have any Nougat running devices to test (I'm still stuck on Lollipop), and I'm not even sure this method will work on N.
ShadySquirrel said:
No, sorry, I don't have any Nougat running devices to test (I'm still stuck on Lollipop), and I'm not even sure this method will work on N.
Click to expand...
Click to collapse
It's maybe just an error in policydb supported version. When I try to run the script manually, i get message "policydb version 30 does not match my version range 15-29". I've attached a screenshot
OsniNO said:
It's maybe just an error in policydb supported version. When I try to run the script manually, i get message "policydb version 30 does not match my version range 15-29". I've attached a screenshot
Click to expand...
Click to collapse
Yeah, 6+ uses newer sepolicy, I'm not sure tools I've used are supporting it yet. I know that SuperSU has it's own policy inject tool, so maybe you can try injecting rules with it and create an init.d script.
Really can't make it work with M/N, I don't have any devices to test
So i'm trying to create a profile in tasker to enable/disable airplane whenever i'm connected to Wifi and it seems SecureSettings isn't allowing root actions even though it has root privileges. Anyone know an app that works with tasker that can allow me to enable/disable airplane mode?
Thanks!
metpage said:
So i'm trying to create a profile in tasker to enable/disable airplane whenever i'm connected to Wifi and it seems SecureSettings isn't allowing root actions even though it has root privileges. Anyone know an app that works with tasker that can allow me to enable/disable airplane mode?
Thanks!
Click to expand...
Click to collapse
Is there any particular reason you are using systemless root?
Sent from my Nexus 5X using Tapatalk
Mainly for Android Pay to work but I'm not married to systemless root if system root makes this work. However I may have found a workaround using Locale instead.
Sent from my Nexus 5X using Tapatalk
In either a terminal on your phone, or via adb shell from the computer, enter these commands:
Code:
mount -o remount,rw /system
touch /sbin/su /system/bin/su /system/xbin/su
mount -o remount,ro /system
I can't remember if you need to reboot or not, but might as well, just in case. Afterward, run your task and allow Secure Settings root access.
After doing this, Tasker and Secure Settings works for me. If this doesn't fix your problem, I don't know.
Thanks I'll give this a shot if Locale doesn't work
Sent from my Nexus 5X using Tapatalk
lightningdude said:
In either a terminal on your phone, or via adb shell from the computer, enter these commands:
Code:
mount -o remount,rw /system
touch /sbin/su /system/bin/su /system/xbin/su
mount -o remount,ro /system
I can't remember if you need to reboot or not, but might as well, just in case. Afterward, run your task and allow Secure Settings root access.
After doing this, Tasker and Secure Settings works for me. If this doesn't fix your problem, I don't know.
Click to expand...
Click to collapse
I have the same problem, running CF-Autoroot on my S7 edge. I would like to try your trick but am not sure how to exactly . Could you please explain a little bit more in detail how this is done?
EDIT: nevermind, i solved it my self using THIS method.
Thanks in advance.
Works for Secure settings, but it's broken Titanium backup
When I try to implement this in adb I get the following:
mount: '/dev/block/platform/soc.0/f9824900.sdhci/by-name/system'->'/system': Device or resource busy
Can anyone help? Would greatly appreciate it. Thanks!
facted said:
When I try to implement this in adb I get the following:
mount: '/dev/block/platform/soc.0/f9824900.sdhci/by-name/system'->'/system': Device or resource busy
Can anyone help? Would greatly appreciate it. Thanks!
Click to expand...
Click to collapse
Try using this command instead:
mount -o rw,remount /system
It worked for me
PiousInquisitor said:
Is there any particular reason you are using systemless root?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
is there system root for 7.0 or is this thread about 6.0.1?
niklus101 said:
is there system root for 7.0 or is this thread about 6.0.1?
Click to expand...
Click to collapse
There are unofficial versions in in the super su section here.
LSI said:
Works for Secure settings, but it's broken Titanium backup
Click to expand...
Click to collapse
Yeh, unfortunately, it does, same with AdAway.
Does it have to do with Android N or is it about the fact that touch /sbun/su fails due to sbin being read only?
If someone knows a solution, that would be great.
LSI said:
Works for Secure settings, but it's broken Titanium backup
Click to expand...
Click to collapse
I have the same problem with this too. It would be great to have a solution, or at least knowing how to reverse it would be great.
lightningdude said:
In either a terminal on your phone, or via adb shell from the computer, enter these commands:
Code:
mount -o remount,rw /system
touch /sbin/su /system/bin/su /system/xbin/su
mount -o remount,ro /system
I can't remember if you need to reboot or not, but might as well, just in case. Afterward, run your task and allow Secure Settings root access.
After doing this, Tasker and Secure Settings works for me. If this doesn't fix your problem, I don't know.
Click to expand...
Click to collapse
Do you hit enter at each line?
I'm doing this exact thing with Tasker and Magisk. I just had to add a quick edit to my build.prop, and then Tasker could recognize root with Magisk, and it worked fine.
Fit some reason I'm getting this error when dropping the commands
That's because it's mount -o not -0.
I just got secure settings and tried these commands in terminal. However they don't work. I get device or resource busy.
I'm on PureNexus 7.1.1 root via supersu on my Nexus 5x IF that matters in any way.
Edit: never mind. Solved it by replacing 0 with o. *Facepalm*
I've encountered the same problem in Android 7.1.2 and the above solution didn't work out for me. Secure Settings system+ is unavailable.
Any other solutions?
The first command
mount -o remount,rw /system
gave me the following result:
mount: '/dev/block/platform/msm_sdcc.1/by-name/system' not user mountable in fstab
1|jfltexx:/ $
It seems like an error.
akran said:
I've encountered the same problem in Android 7.1.2 and the above solution didn't work out for me. Secure Settings system+ is unavailable.
Any other solutions?
The first command
mount -o remount,rw /system
gave me the following result:
mount: '/dev/block/platform/msm_sdcc.1/by-name/system' not user mountable in fstab
1|jfltexx:/ $
It seems like an error.
Click to expand...
Click to collapse
Try this:
Code:
mount -o rw,remount /system
touch /sbin/su /system/bin/su /system/xbin/su
mount -o ro,remount /system
I'll share how I fixed this problem, which might be a LOT easier for some people.
Install a file manager that has root access (ie Root Explorer).
Navigate to /system/bin
Click whatever button to mount /system as rw.
Create a directory (or file) and call it su
Reboot phone
Open Secure settings and enable root.
At this point (and with above solutions, Android Pay is broken. If you want it back.
Open file manager again.
navigate to /system/bin
mount rw
delete the su folder (or file) you created earlier.
reboot.
Secure Settings only checks for su file the first time. Once it's been granted access, it no longer looks for su, it just tells the system it needs root access. So it will work the way its supposed to, even though it no longer can find the su file in expected location.
Also, for those that don't know, "touch" creates a file. So if you want to pass SafetyNet still, go back and delete the 3 files created from the touch command. And note that you only need to do 1 of them, not all 3, for Secure Settings to work.
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.