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...
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
hi!
I flashed this update on my rooted XZ: [ROM] Stock 10.1.1.A.1.253 CWM/TWRP ZIP. (v5 root+dual recovery) LB/UB http://forum.xda-developers.com/showthread.php?t=2279661
since then, whenever I set /system to RW, the phone crashes a few seconds after.
I tried it via root explorer, ES File Manager, Terminal. Also tried repairing permissions in recovery. still doesn't work.
maybe someone has an idea?
thanks!
Reboot in recovery (TWRP is best).
Under /Advanced mount your /system, then go to the File Manager.
Head to this file: /system/etc/install-recovery.sh
Set new permissions with CHMOD 775.
Reboot, you're done!
Now you can mount r/w.
I have a Meizu M3 phone, which can be rooted only in older firmware versions using the "normal" meizu procedures.
As it is very easy to downgrade versions (back to an older "rooteable" one - 5.1.4.0), I've made my mind in doing some tests.
I've decide to give a try to flashfire to help me go from a rooted (but older) firmware version into a new version without loosing root:
I've choose the update.zip file of a newer version (5.6.8.30), configured everRoot to inject SuperSU into system and tried 2 approaches:
with and without mounting system R/W.
In both approaches the system is upgraded.
su is available in shell (# sign, after calling it).
But the system is NOT really rooted - tools complaining about no root, ES Explorer can't recognize the root, flashfire stays forever waiting for root access, and so on ....
Also, when trying to mount system as RW fails:
su
mount -o rw,remount /system
"Operation not permitted"
I ask the forum for suggestions:
Is there any suggestion with flashfire to help-me update versions without loosing root ?
Alternatively, should I repack update.zip removing both boot.img and recovery.img (editing also the update script) ?
Two possibilities:
1. setuid bit is not set for su. fire up a terminal, run
Code:
ls -al `which su`
and post the result.
2. there is a SELinux issue. this is more complicated...
I've now tried in several ways to change /system/build.prop (phone rooted) but I had no luck.
Method 1: BuildProp Editor
I've tried using this app to change the file, the save succeeds, but after rebooting, the "original" file is restored and the changes are lost.
Method 2: Remounting the filesystem
I've tried remounting the filesytem:
Code:
$ adb shell mount
/dev/block/dm-4 on / type ext4 (ro,seclabel,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl,i_version)
...
Code:
$ adb shell su -c mount -o rw,remount /
$ adb shell mount
/dev/block/dm-4 on / type ext4 (rw,seclabel,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl,i_version)
...
After making my changes, if I try to remount with ro access, it fails. After rebooting the changes are lost again.
Method 3: Modify system.img
I've tried changing the file in the system.img, repacking the super.img file and flash it as single AP file, same result, the changes are lost. I've tried to decompress the super.img and remount it (just to check the changes were still there) and indeed they were.
What am I doing wrong?
Is there any way to achieve this?
I've found a good description of how the system and Magisk work:
- https://topjohnwu.github.io/Magisk/details.html
- https://topjohnwu.github.io/Magisk/guides.html
hello, i am trying to modify build.prop to disable knox and enable multiuser but changes are not persistent, have you found a solution with magisk?
use notepad ++ to modify buildprop on pc. connect phone while off and while phone is booting push file to phone (repeatedly) theres a small window where you can inject during boot...takes awhile sometimes to hit it right. ive dont it on samsungs and lg.