Related
I couldn't find a thread on this. If there is one and I just missed it, please direct me that way and I apologize for the duplicate.
I hacked the .config file (kernel), compiled it, tested it in fastboot's boot mode (from the bootloader) and then flashed it to the phone with the instructions on this site:
credentiality2.blogspot.com/2010/08/nexus-one-htc-passion-compile-and-flash.html
It works and is wonderful, but I would love to find a way to create a boot.img file with the kernel I've hacked. Do any of you have any insight or know where I can look for more info.?
Do any of you know how to create the boot.img-ramdisk.gz file? I know how to put that with my hacked boot.img-kernel file and create a boot.img file that way.
Any help is much appreciated.
Fixed!
I figured out the problem was I couldn't the boot.img file from my Android 2.2 phone because the read-write permissions did not allow me to do the adb pull command. Now, I've pulled that boot.img file and can unpack and repack it with my hacked kernel using the directions on the website I originally referenced.
I used this command to change the permissions so I could pull the boot.img file:
#mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Hi,
I have rooted my HTC Dream successfully. I have flashed in CyanogenMod ROM.
Now I have downloaded Android Kernel and rebuilt it. Now I have the zImage which is the kernel image. Now how do I use this new image? I guess must modify the boot.img to use this new kernel image.
Any idea how can I do this? I tried using "fastboot flash:raw boot <kernel directory> <ramdisk directory>"
For <ramdisk directory> I point to the one in the android-sdk. But after flashing it stuck in the "G1 T Mobile" screen and doesn't proceed. Not sure how to resolve.
Thanks In Advance,
Perumal
I downloaded the boot.img file, split it into boot.img-kernel and boot.img-ramdisk.gz. Then, renamed my newly-compiled kernel's "zImage" file as "boot.img-kernel" and zipped them back up into boot.img. Then, I flashed it to the phone with fastboot. All of the directions are on this website:
credentiality2.blogspot.com/2010/08/nexus-one-htc-passion-compile-and-flash.html
It was written for HTC Passion / Nexus One, so you may want to pull your existing boot.img file first in case it doesn't work on the HTC Dream and you need to go back to where you started. I found this tutorial helpful for that.
credentiality2.blogspot.com/2010/08/extract-bootimg-from-android-phone.html
You probably need to change your permissions to push and pull the boot.img file. I would do that on my computer (with it tethered to the phone), using the following commands in a terminal window:
$ adb shell
$ su
# mount -o remount,rw /dev
For anyone who has had the Clockwork-mod Recovery MD5 mismatch! error.
Another way: for Example TWRP Cache.ext4.win
most recoverys now have a option to turn off MD5 checking
You can copy your backup folder to your computer, use attached app to check the md5 number , edit md5 file and check and verify and change
this thread is old so md5 file may not be named the same. the picture is TWRP custom recovery
example was with cache.ext4.win that has md5 file named cache.ext4.win.md5
another short cut to try
----------------------------------------------------------------------------
@aeneas1 Thanks!!
i did another google search and found a very simple fix, at least it worked for me, on the first try, and i have tested it successfully with some of my other backups that were also getting the mismatch error.
1. using your phone, navigate to your backup folder using a root browser, i use romm tool box root browser.
2. locate and delete the nandroid.md5 file
3. create a new file and name it nandroid.md5
4. boot into recovery, select restore your backup, and watch the magic begin!
---------------------------------------------------------------------------
Update: thanks @Exca
If you have androids SDK ( ADB installed) try this easer method by Exca
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
DO NOT renamed your backup with spaces Thanks ltredbeard and those who verified
-----------------------------------------------------------------------------------------------------------------------------------------------------------
This is what I did to fix mine and get my backup working again after getting MD5 mismatch! error
I was trying to restore my backup after trying another Rom.
http://forum.xda-developers.com/showpost.php?p=11768066&postcount=2965
carl1961 said:
For anyone who has had the Clockwork-mod Recovery MD5 mismatch! error.
This is what I did to fix mine and get my backup working again after getting MD5 mismatch! error
I was trying to restore my backup after trying another Rom.
http://forum.xda-developers.com/showpost.php?p=11768066&postcount=2965
Click to expand...
Click to collapse
Wished I'd have seen this before deleting 4 different backups. Can you tell me what exactly this zip does ?
crz6662 said:
Wished I'd have seen this before deleting 4 different backups. Can you tell me what exactly this zip does ?
Click to expand...
Click to collapse
Never mind, opened it up & read the PDF file. Wanted to also thank you for this.
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
Using these methods fixed my error! Thanks.
BTW: I name my backup and it contained a space. I ended up having to rename the backup w/o the space. Ex. From - Backup Froyo To - BackupFroyo
Exca said:
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
Click to expand...
Click to collapse
After follow this easy procedure on my ASUS TransformerTF101, here's the result in my clockworkmod recovery (v3.0.2.8):
1. Checking MD5 sums is OK
2. Restoring system is OK
3. Restoring data is not OK, there is message: ".android_secure.img not found. Skipping restore /sdcard/.android secure.
4. Restoring cache is OK
5. Backup complete
Then after reboot, all my data on that backup file is not restore as expected. I am afraid my data is gone :-(
Can someone help me?
Araf said:
After follow this easy procedure on my ASUS TransformerTF101, here's the result in my clockworkmod recovery (v3.0.2.8):
1. Checking MD5 sums is OK
2. Restoring system is OK
3. Restoring data is not OK, there is message: ".android_secure.img not found. Skipping restore /sdcard/.android secure.
4. Restoring cache is OK
5. Backup complete
Then after reboot, all my data on that backup file is not restore as expected. I am afraid my data is gone :-(
Can someone help me?
Click to expand...
Click to collapse
I'm guessing by following the zip instructions, you deleted the ".android_secure.img" since it says it's safe to delete if there's a nandroid.md5 file already. But that .md5 file does not match the original. So the backup was likely messed up when trying to fix it with the .zip instructions.
I believe the easier method in post #4 should be tried first on a fresh backup dir.
Whyzor said:
I'm guessing by following the zip instructions, you deleted the ".android_secure.img" since it says it's safe to delete if there's a nandroid.md5 file already. But that .md5 file does not match the original. So the backup was likely messed up when trying to fix it with the .zip instructions.
I believe the easier method in post #4 should be tried first on a fresh backup dir.
Click to expand...
Click to collapse
For future reference to all. What I do all the time is when I make a backup, I hook the tablet up to my pc and back the backup to my PC. This saved me from having to do those steps. I just rewrote the backup on my sdcard and it worked.
Thanks that worked for my mytouch 4G.
Works like a charm, Thanks Again!
carl1961 said:
For anyone who has had the Clockwork-mod Recovery MD5 mismatch! error.
Update: thanks Exca
If you have androids SDK ( ADB installed) try this easer method by Exca
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
This is what I did to fix mine and get my backup working again after getting MD5 mismatch! error
I was trying to restore my backup after trying another Rom.
http://forum.xda-developers.com/showpost.php?p=11768066&postcount=2965
Click to expand...
Click to collapse
CWM 3.0 stable
carl1961 said:
For anyone who has had the Clockwork-mod Recovery MD5 mismatch! error.
Update: thanks Exca
If you have androids SDK ( ADB installed) try this easer method by Exca
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
This is what I did to fix mine and get my backup working again after getting MD5 mismatch! error
I was trying to restore my backup after trying another Rom.
http://forum.xda-developers.com/showpost.php?p=11768066&postcount=2965
Click to expand...
Click to collapse
he... good work, thanks very much.
it helps me
Thanks for this, really did the trick! I was so scared I lose my DarkSide Sense backup! thanked!
Can anyone tell me quickly why i can't execute "md5sum"?
when i execute the md5sum command, I get:
"/system/bin/sh: md5sum: not found"
fkng awesome <3! this helped me out!!!
Eschmacher said:
Can anyone tell me quickly why i can't execute "md5sum"?
when i execute the md5sum command, I get:
"/system/bin/sh: md5sum: not found"
Click to expand...
Click to collapse
same problem. any1 got a solution? trying to restore MIUI rom backup.. no luck. restores stock rom backup with no probs.
I am on SGSII.
The MD5 checksum fix *worked* for me! TY!
HTC Evo 4G 2.3.3 / 2.16.0000 / CWM 5.0.2.2
carl1961 said:
For anyone who has had the Clockwork-mod Recovery MD5 mismatch! error.
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
Click to expand...
Click to collapse
THANKS SO MUCH!!! I thought that I was going to lose a bunch of stuff after I formated my SD card (thankfully I had a backup on my computer) while watching Netflix. This really saved my life and I'll be bookmarking this!
Yes I met it before.
But now there is not an issue anymore.
thank you
i used your code now hopefully i will have my 4g back with the back up im restoring right now
UPadte:
I restored a backup from when my 4g was working and nothing changed I still can't get 4g to connect!
This is a much easier way:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
usually does the trick
Click to expand...
Click to collapse
thank you so very much!!
Hi there!
Anyone willing to paste official images for U8800: (V100R001C00B522G001)
recovery.img
boot.img
cust.img
amss.mbn
EMMCBOOT.MBN
Thanks!
S.
If i am honest i need only boot.img
Brgds,
S.
I need the whole non-modified image folder. /.cust_backup/image/
Little guide for making a dump.zip
1. Download Busybox installer
2. install Busybox to /system/xbin;
3. enter these commands from terminal;
4. su
5. cd /sdcard
6. chmod 777 /system/xbin/busybox
7. /system/xbin/busybox tar czvf dump.tar /.cust_backup
A dump.zip is saved at your sd-card
I am unable to do this because I have modified cust.img and recovery.img. Installing stock firmware doesn't work..
Check my MediaFire in the signature. I have cust_data separated from cust because cust_data is carrier specific.
Sent from my U8800
Does someone know how to change splash screen at boot for defy?
Sent from my MB526 using Tapatalk 2
1. Download milestone bootlogo
2. Open 480 x 182 image with milestone bootlogo
3. Save that image with milestone bootlogo to logo.bin - it's size MUST been size 256 KB
4. Rename logo.bin to logo.img
5. Create new folder in sdcar/clockworkmod/backup & copy logo.img to NEW FOLDER
6. Copy nandroid.md5 file from any other CWM backup
7. Type in terminal emulator this commant to recheck md5 sums:
su
mount -o remount rw /sdcard
cd /sdcard/clockworkmod/backup/(YOUR BACKUP FOLDER NAME)
rm nandroid.md5
md5sum *img > nandroid.md5
8. Restore cwm backup: backup & restore/advanced restore/(logo_cwm_backup_name/logo
turffe said:
1. Download milestone bootlogo
2. Open 480 x 182 image with milestone bootlogo
3. Save that image with milestone bootlogo to logo.bin - it's size MUST been size 256 KB
4. Rename logo.bin to logo.img
5. Create new folder in sdcar/clockworkmod/backup & copy logo.img to NEW FOLDER
6. Copy nandroid.md5 file from any other CWM backup
7. Type in terminal emulator this commant to recheck md5 sums:
su
mount -o remount rw /sdcard
cd /sdcard/clockworkmod/backup/(YOUR BACKUP FOLDER NAME)
rm nandroid.md5
md5sum *img > nandroid.md5
8. Restore cwm backup: backup & restore/advanced restore/(logo_cwm_backup_name/logo
Click to expand...
Click to collapse
Thanks a lot. Worked Perfectely!!
- What does this line do.. mount -o remount rw /sdcard
- Why is it necessary to copy another nandroid.md5? Anyway we are deleting that.
hey,
in here are two thread or more with splash screen's in. only search for bootlogo not splash screen. there it's also a tool what worked, and I have a thread with a update-script posted to flash ur favorite splash screen and bootanimation together true CWM. and u can change splash screen with ROM toolbox if u chose there milestone.
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