Database Users

Rooted Hero Fails adb remount, can't move files from SD

I rooted my hero last night and tried out a few different ROMs but eventually decided to revert to stock and make some manual changes. I used nandroid to restore to just after the root (1.56.651.2). I was able to remove some apps using adb, but the adb remount command fails (permission denied), and I'm unable to push a new bootscreen on to the phone. I also tried a Root File Manager and pre-kitchen as alternatives for the bootscreen, and neither one works. The Root Manager won't paste the files from SD into /system/media/ and pre-kitchen just reboots the phone.
Any suggestions?

Any chance this has something to do with downloading only up to SDK Platform 1.5? I'm at a total loss. I RUU'd my phone, did a clean root at startup using adb shell, and I still have the same problem. The adb remount command won't work, and I can't push anything into the system directory. For what it's worth, when I still had Root Manager installed I was able to toggle RO R/W in any directory with no problem, and I could move files around within the ROM... but I couldn't move anything into it from the SD. I'm new at this, so I have no idea what the problem might be. Anyone else had this problem or have any suggestions?

If anyone else runs into this problem, this solution worked for me:
adb shell
# su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system (Or any subdirectory you want to push to inside system)
# exit
adb push <local file> <device location>
Restore modified permissions when done.
Though I'm still not sure why this is necessary in place of adb remount.

I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

dametzg said:
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Click to expand...
Click to collapse
Thanks... didn't realize stock wouldn't accept adb remount. If I use the above line from within shell, that doesn't help me push anything on to the phone though... so I needed to enable global permission and then do the push. Oddly enough I tried the same approach last night using Root Manager, and the transfer from SD still failed, even after I applied 777 to the dir I was trying to modify. The current solution may be kind of tedious, but at least it works.

you really shouldn't do 777 on your filesystem, ANY app can then write to your system, overwrite things, or install malicious code. Just remount manually and you should be able to push anything you want, just remember that w/ the stock rom you also don't get a full busybox either.

I'm not positive, but I would think after you remount, you should be able to "adb push" to /system. I suppose it might be specific to that shell, but I would think not.
You just may have to do it once each time you boot your phone.
Edit - err nevermind... you're having permission errors.... um... change adbd on the phone to run as root? not sure how off the top of my head...

[Q] Editing Build.prop results in failure to boot [bricked]

As you may know, some Android games especially most Gameloft games are not compatible with the Kindle Fire. So in efforts to find a way to make certain Gameloft games to work such as Modern Combat 2 and Shrek Kart and others, I resorted to editing my build.prop in the systems folder to make my device compatible with the apps. So I copied the original build.prop file, renamed it, and saved it to my SD Card folder. I took the copy I made and I then replaced it with the build.prop from HTC Glacier. (I never knew what could possibly happen) So then to apply those settings you have to reboot the device. I rebooted the Kindle and now it won't boot up. It get's to the Kindle Fire screen when booting up but after several seconds it just shows a black screen. No physical damage has been incurred to it but I feel like my stupid mistake of modding the build.prop resulted in the Kindle Fire unable to boot up correctly. It also isn't recognized by the PC when I hook it up to a USB cable. So far I've found nothing that could help to solve this. I've seen a Factory Default Settings Cable which is a special cable to reverts the device to its factory default settings but I'm not too sure if that would work. I'm in desperate need of help as in I use my Kindle Fire for everyday work and play. Thanks.
EDIT: I've tried adb push and renaming and moving the build.prop into the /system/ but returns that it is a Read-File System Only. Also adb shell and su doesn't work as in it ends up with segmentation fault. I've tried to zergRush root it and permanently root it using KFU but it ends up with 'Cannot Access Package Manager. Is System running?' Also the mount -o rw,remount.....command doesn't work either as it says Permission Denied. All of this would be easy to accomplish if only it ADB allowed me to write onto the /system file.
EDIT**: The biggest issue I'm faced with is the permission settings that prevent my from editing anything. You cannot simply change it from RO to RW because apparently the ADB is not rooted. And I also can't root it because problems exist when accessing either Package Manager or Activity Manager. What I need is a way to access the /system files without a root (non-rooted). Either that or enable fastboot because I cannot access that either. On a reply on the second page is the resulting lines when changing bootmodes on the KFU.

Don't know how to fix your problem, but just wondering, did you just completely replace the kindle fire build.prop with the HTC glacier? Because you can't do that, it will, as you have learned, mess up your device.. Your supposed to edit the build.prop and just change a few things. Next time read up on the subject before deciding to mod the device you use everyday...

the cable you'r talking about is a "factory cable" it forces the kf to fastboot mode - it don't restore any settings !
you need fastboot mode to install fff (firefirefire - custom bootloader) and twrp (recovery)
do you allready have installed fff & twrp (or cwm) ?
if you have twrp installed and booted into then you have adb command available and can copy back the original build.prop

Did you remember to restore the read/write permissions to build.prop? It should be set to 644.

As already stated, your not supposed to replace the whole file, build.prop tells android which device you have, so now Android thought and configured itself to different hardware config. which is not available to it. Adb seems like the only option.

I should have really looked more into it before modifying the build.prop. I replaced the ENTIRE build prop with the build.prop of HTC Glacer. (I know, i know I was stupid) And referring to the factory cable, I don't think I'll resort to that: too time consuming. In regards to the last person that posted before me who said that my only option was ADB could you elaborate? Thanks for all your feedback.

gococogo321 said:
I should have really looked more into it before modifying the build.prop. I replaced the ENTIRE build prop with the build.prop of HTC Glacer. (I know, i know I was stupid) And referring to the factory cable, I don't think I'll resort to that: too time consuming. In regards to the last person that posted before me who said that my only option was ADB could you elaborate? Thanks for all your feedback.
Click to expand...
Click to collapse
Your going to have to use adb to basically remove the HTC Glacier build.prop and replace it with the original build.prop.
For example:
Adb remount <- allows you to mount system as rw
Adb pull /path-to-original/build.prop
Adb push build.prop /system
Adb shell chmod 644 /system/build.prop <- sets permissions to rwrr
Adb reboot
Sent from my Kindle Fire using xda premium

You dont have access to recovery? Either TWRP or CWM?

daggy1985 said:
Your going to have to use adb to basically remove the HTC Glacier build.prop and replace it with the original build.prop.
For example:
Adb remount <- allows you to mount system as rw
Adb pull /path-to-original/build.prop
Adb push build.prop /system
Adb shell chmod 644 /system/build.prop <- sets permissions to rwrr
Adb reboot
Sent from my Kindle Fire using xda premium
Click to expand...
Click to collapse
I tried doing that but it says something like Access Denied or Read-Only File System when i try to push the build.prop into it.

gococogo321 said:
I tried doing that but it says something like Access Denied or Read-Only File System when i try to push the build.prop into it.
Click to expand...
Click to collapse
Did you use the 'adb remount' command? Sometimes, when attempting to push a file to the system, I get the 'read-only file system' and I have to issue adb reboot followed by adb remount and then push the file again. It seems after a time the mount system as read write automatically goes back to read-only.
Sent from my ADR6400L using xda premium

Have you got TWRP or ClockworkMod?
Because you could flash a new rom then.

abd - root mode
Perhaps, running adb in root mode will
allow you to push the original build.prop
back. Then execute "adb remount / rw" to mount the
root directory as read/write. Hopefully you will be able to push
it then follow daggy1985's instructions.
* In Win 7, type "cmd " at the 'SEARCH/RUN' and hold
shift + ctrl while hitting 'Enter' to put yourself
in Admin mode which apparently makes adb work in root mode when you launch it.
* Xda-dev is the coolest site for Android that I have seen. Kudo's to everyone participating.

sum1nil said:
Perhaps, running adb in root mode will
allow you to push the original build.prop
back. Then execute "adb remount / rw" to mount the
root directory as read/write. Hopefully you will be able to push
it then follow daggy1985's instructions.
* In Win 7, type "cmd " at the 'SEARCH/RUN' and hold
shift + ctrl while hitting 'Enter' to put yourself
in Admin mode which apparently makes adb work in root mode when you launch it.
* Xda-dev is the coolest site for Android that I have seen. Kudo's to everyone participating.
Click to expand...
Click to collapse
Thanks but I have actually been running it from Administrator from the very beginning. I've used Kindle Fire Utility KFU and it says that ADB Server is Online and my Bootmode is 4000 but it says ADB root: No. And whenever I choose any bootmode whether it be Normal, Fastboot, or Recovery, it always shows this:
***********************************************
* Activating Normal (4000) *
***********************************************
Installing BurritoRoot, Courtesy of Jcase of TeamAndIRC!
1393 KB/s (1164225 bytes in 0.816s)
Error: Could not access the Package Manager. Is the system running?
Activating BurritoRoot...
Error type 2
android.util.AndroidException: Can't connect to activity manager; is the system
running?
Elevating the Shell...
* daemon not running. starting it now *
* daemon started successfully *
/data/local/tmp/BurritoRoot3.bin: permission denied
mount: Operation not permitted
mount: Operation not permitted
failed to copy 'files\rbfb' to '/system//rbfb': Read-only file system
Unable to chmod /system/rbfb: No such file or directory
Unable to chmod /system/rbfb: No such file or directory
mount: Operation not permitted
mount: Operation not permitted
***********************************************
* Root Activated *
***********************************************
The kindle is successfully running in root mode.
<idme> Invalid permission
reboot: Operation not permitted
Same goes for the Temp Burrito Root and installing FFF and TWRP. It always shows something about cannot access Package manager. I have no clue what the Package Manager even does but apparently I cannot find a solution to that.

I think you need to get a factory programming cable like we talked about on gtalk. I'm confident that will fix this.
Sent from my DROIDX using Tapatalk

I used android commander for windows, mounted system in TWRP and used android commander to copy a new working build.prop to the right place.
With a cable from my htc desire.

would make a little test:
issue "adb shell"
if you get a error message your up to a factory cable because the system shell is messed up and you have no possibility to get to fastboot mode to install fff & twrp
if you get a $ or # prompt you can resume and try "mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system" to mount system in read/write mode

daggy1985 said:
Your going to have to use adb to basically remove the HTC Glacier build.prop and replace it with the original build.prop.
For example:
Adb remount <- allows you to mount system as rw
Adb pull /path-to-original/build.prop
Adb push build.prop /system
Adb shell chmod 644 /system/build.prop <- sets permissions to rwrr
Adb reboot
Sent from my Kindle Fire using xda premium
Click to expand...
Click to collapse
hey, I've tried to remount my rooted galaxy y, fall in for same problem.but there show this message; "remount failed: Operation not permitted"
my device's usb debugging mode was off in last entire.
what I have to do now?

how did u edit build.prop in the first place if u don't have root and this might help
http://yaseminavcular.blogspot.com/2012/01/how-to-get-bricked-kindle-fire-back-to.html?m=1
Sent from my R800i using Tapatalk

Upgrading to 4.2.2 Issue

I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app

look for the error message in /cache/recovery/recovery.log

If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....

This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app

OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.

I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks

The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system

Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks

jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck

Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks

Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?

bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.

You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.

GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks

Edit build.prop on rooted Moto X Pure MM

Am trying to set up a new property in build.prop but am running into issues with not being able to save the edit properties.
Some things we tried:
mount -o remount,rw /system (BTW we never took it out of this state)
Somehow, during our various futzing, ADB no longer work (we are using Minimal ADB and Fastboot), but was working previously. Fastboot works fine.
Was going to try this in shell, with the following
adb shell mount /system
adb shell
echo "net.tethering.noprovisioning=true" >> /system/build.prop
but without being able to do adb, that won't work...
We did make a copy of the build.prop and moved it to the sdcard, but if I wanted to get it back to /system with the modifications, what do I need to do?
BTW, I remember when I first set this up before current security update (which wiped the prior changes), there was something about the system apps being the issue and we had to remove YouTube. I don't remember how we did that.

Need help: ad-blocking via hosts file android 7 nougat

Hello dear community,
I'm now struggling for some days to enable ad-blocking on my Huawei Nova with Android 7 Nougat (CAN-L01C432B340). I simply only need root to edit the hosts file and then un-root my device (that can be easily done by flashing boot.img via fastboot again). Reason for un-root is to be able to play Pokemon Go which has a root-block.
Following steps have been tried with root enabled
First things first: The normal way of using AdAway to create a hosts file does not work anymore: It seems to be impossible to remount the /system partition with r/w (read more) with the app.
So I tried many things so far to gain r/w while Android is booted up
Reversed the order on how we give the options to mount as suggested in chainfires posts: mount -o rw,remount /system fails (same does mount -o remount,rw /system)
Installing busybox to have another (probably working) mount command: Installation fails because of no rw on /system (doh)
Flashing busybox installable zip: The binaries seem to be gone when Android is booted up (but are visible in TWRP)
Using another busybox installer seem to be able to at least temporary flash busybox to /system/bin. Yet, busybox mount -o rw,remount /system did not make /system rw.
Flashing systemless AdAway also fails (similar to flashing busybox, the files are written but mystically, all changes are gone after booting into android).
Now I unrooted my device
Then I thought, why not use TWRP and mount the partition with rw there and copy my own custom-made hosts-file to /system. And hey, mounting with rw works! Also even writing and all kind of stuff.
But now the bummer: No matter what I do, the hosts file, formerly written to e.g. the /system partition is reverted back to default after a reboot to android. The strange thing: My modification is still there and visible in TWRP
Investigating on how the hosts file is managed in a booted-up android, I found out, /system/etc/hosts is symlinked to /vendor/etc/hosts.
So I mounted the /vendor partition in TWRP and copied the hosts file there.
mount /dev/block/platform/soc/7824900.sdhci/by-name/vendor /system && cp /external_sd/hosts /system/etc
After a reboot, I noticed /vendor/etc/hosts (= /system/etc/hosts) just has the default entries :crying: Strangely, when I now root my device again, the hosts-file shows my entries (but I need to be un-rooted )
It seems like that all changes done to any partition are somehow reverted back by the kernels drive-mapper. Does anyone have an idea on how to write a hosts-file to my system, which persists when I boot up android and does not require to be permanently rooted?