Database Info

[Q] having issues pushing using ADB

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

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

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

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

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

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

[Q] HELP - Changed LCD Density and EVERYTHING is so tiny.

Ok so I was going through this post
http://forum.xda-developers.com/showthread.php?t=1193245
and I used to own the HTC EVO 4G, and I liked the lower LCD Density, so now I own the HTC Sensation 4G, and I wanted to do the same. I downloaded the LCDDensity app from the market, to find out that it doesn't work at all, so I followed the steps from this post and I thought I changed the density to 200, and in reality judging from the way everything looks, the editing of the file didnt register the last 0, so looks like the LCD Density is set to 20... is there any way I can edit that file or gain a new one, because I can not read anything on the phone as EVERYTHING is super small.

Hello:
In a command prompt:
- adb pull /system/build.prop
- edit the file in Windows (put ro.sf.lcd_density=240)
- save the file
- adb push build.prop /system/
- adb reboot
You should then be ok

Or restore your nandroid you made before doing the changes

anthrax132 said:
Hello:
In a command prompt:
- adb pull /system/build.prop
- edit the file in Windows (put ro.sf.lcd_density=240)
- save the file
- adb push build.prop /system/
- adb reboot
You should then be ok
Click to expand...
Click to collapse
+1
I'm the one who started the post he is referring to. I should have put this information in there for accidents.

Do you have a screen shot?

maybe you first need to remount /system with write access:
adb shell mount -o remount rw /system
anthrax132 said:
Hello:
In a command prompt:
- adb pull /system/build.prop
- edit the file in Windows (put ro.sf.lcd_density=240)
- save the file
- adb shell mount -o remount rw /system
- adb push build.prop /system/
- adb reboot
You should then be ok
Click to expand...
Click to collapse

[Q] ADB problem

I switched to a 2.3.3 based rom today, and now adb won't allow me to remount or push. I can pull just fine. But if I type adb remount, I get the error, "remount failed: operation not permitted."
If I boot into CWM and mount /system or /data, I can remount, push, or pull with adb with no problems. But once I boot into the rom, all I can do is pull.
I am using a rooted rom with the latest superuser and busybox.
Anyone have any ideas?

Still really needing some help with this, please.

If you type adb shell, do you get a $ or a #?
Try opening the SuperUser app on your phone then doing adb remount.
Sent from my LG-P999 using XDA App

mmapcpro said:
I switched to a 2.3.3 based rom today, and now adb won't allow me to remount or push. I can pull just fine. But if I type adb remount, I get the error, "remount failed: operation not permitted."
If I boot into CWM and mount /system or /data, I can remount, push, or pull with adb with no problems. But once I boot into the rom, all I can do is pull.
I am using a rooted rom with the latest superuser and busybox.
Anyone have any ideas?
Click to expand...
Click to collapse
Look at the default.prop file on the root of your device. I bet that there's a line that says: "ro.secure=1".
For whatever reason, the maker of your ROM set ro.secure to be on, which limits a lot of what you can do via adb. No pushing to /system, no remounting in rw mode. This is part of the boot.img file in the ROM, and is set with every reboot. Ask the maker of the ROM to set ro.secure to 0.
I had this problem with EaglesBlood Froyo until I *****ed enough that the dev changed it on the next release.

Try typing in adb remount then adb push your files.
Sent from my LG-P999

mstrk242 said:
Try typing in adb remount then adb push your files.
Sent from my LG-P999
Click to expand...
Click to collapse
Ah, he says in the first post that he tries that but gets an error.

Still having the issue.
I searched through default.prop and ro.secure=0.
I also attempted to adb remount while running superuser, with no success.
I am on EB1.08 for 2.3.3 currently, but I also tested this on Weapon G2x 2.3.3 with the same results.

mmapcpro said:
Still having the issue.
I searched through build.prop and there is no ro.secure line at all...not set to 1, not set to 0...not there.
I also attempted to adb remount while running superuser, with no success.
I am on EB1.08 for 2.3.3 currently, but I also tested this on Weapon G2x 2.3.3 with the same results.
Click to expand...
Click to collapse
Not build.prop, but *default.prop*, should only be a few lines long, in the root of your phone's filesystem:
adb shell
ls
you should see the file. Mine looks like (minus the -----):
----------------------------------
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
ro.serialno=******* (censored by me)
----------------------------------

wewoapsiak said:
If you type adb shell, do you get a $ or a #?
Try opening the SuperUser app on your phone then doing adb remount.
Sent from my LG-P999 using XDA App
Click to expand...
Click to collapse
when I type "adb shell", it displays: sh-3.2$

lannister80 said:
Not build.prop, but *default.prop*, should only be a few lines long, in the root of your phone's filesystem:
adb shell
ls
you should see the file. Mine looks like (minus the -----):
----------------------------------
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
ro.serialno=******* (censored by me)
----------------------------------
Click to expand...
Click to collapse
Yeh, I went back and edited my post because I re-read your response and realized I was looking at the wrong file...but default.prop says ro.secure=0

mmapcpro said:
Yeh, I went back and edited my post because I re-read your response and realized I was looking at the wrong file...but default.prop says ro.secure=0
Click to expand...
Click to collapse
Well crap, scratch that idea. But the behavior you describe is exactly what happened when ro.secure=1 was set in EB Froyo, so it must be something...similar?

Problem with ROM!
Sorry for the late reply, but this seems close to the answer.You must be using a custom ROM not Stock GingerBread ,right? Well, some initialisation script(files like init.rc) are responsible for setting the state of adb daemon at boot time. There scripts normally check files like build.prop, default.prop,local.prop, environment variables and stuff like that and accordingly setup many features like heapsize, display mode, adb secure or insecure,etc. There should be something different with your ROM's initialization scripts.
Oh, and i forgot! You can't change default.prop like that. Every time you reboot, default.prop'll be reloaded from boot partition image, effectively undoing any changes you made. Flashing a better boot.img may solve the problem.

help with adb commands for s-off and perm root

Well let me first off say i'm feeling really dumb atm.
Just bought my wife the new m8 , I've already s-offd and perm rooted mine but for some reason im having trouble getting the commands to work for hers .
im using a mac btw but like ive said i did successfully do this on this exact setup
adb reboot <–important!!!!
adb wait-for-device push firewater /data/local/tmp <<<<<<<<
adb shell
su
chmod 755 /data/local/tmp/firewater
/data/local/tmp/firewater
do i actually put the data local tmp part in or am i supposed to be putting in my local directory where i have the file on my computer
when i adb devices , i can see my device, so it is connected
in adb when i " adb reboot" it does reboot my phone
but when i try to push the firewater file it does not push , i get this
cannot stat 'firewater': No such file or directory
firewater file is in my adb folder on my desktop and its the right size etc etc .
thanks in advance if anyone can tell me what im doing wrong!!!!

commandocon said:
Well let me first off say i'm feeling really dumb atm.
Just bought my wife the new m8 , I've already s-offd and perm rooted mine but for some reason im having trouble getting the commands to work for hers .
im using a mac btw but like ive said i did successfully do this on this exact setup
adb reboot <–important!!!!
adb wait-for-device push firewater /data/local/tmp <<<<<<<<
adb shell
su
chmod 755 /data/local/tmp/firewater
/data/local/tmp/firewater
do i actually put the data local tmp part in or am i supposed to be putting in my local directory where i have the file on my computer
when i adb devices , i can see my device, so it is connected
in adb when i " adb reboot" it does reboot my phone
but when i try to push the firewater file it does not push , i get this
cannot stat 'firewater': No such file or directory
firewater file is in my adb folder on my desktop and its the right size etc etc .
thanks in advance if anyone can tell me what im doing wrong!!!!
Click to expand...
Click to collapse
Have you already temp rooted her phone with weak sauce?
Sent from my HTC6525LVW using Tapatalk

wtoj34 said:
Have you already temp rooted her phone with weak sauce?
Sent from my HTC6525LVW using Tapatalk
Click to expand...
Click to collapse
yes i have temp root and su installed

commandocon said:
yes i have temp root and su installed
Click to expand...
Click to collapse
Hmm. Are you copy pasting the messages? Make sure you don't have any spaces in wrong places. Maybe try a factory reset on said device. Just confirming firewater and adb are in the same directory?
Sent from my HTC6525LVW using Tapatalk

yeah theyre in the same folder

commandocon said:
yeah theyre in the same folder
Click to expand...
Click to collapse
Click on weaksauce to make sure it is still working and you may have to click on a prompt and then try ADB again after that.

Figured out what it was at about 12 midnight, I had to add in the directory then put the data/local/ tmp/ etc after that.
So problem is all solved thank god was justa long night of trying commands

where you add the directory?

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

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

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

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

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

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

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

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

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

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

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

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

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

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