I recently flashed KaosGingerbread. I did a nandroid backup first. I tried to do a nandroid restore, and gave me this "run 'nandroid-mobile.sh' via adb". I've tried letting it charge, clearing up SD space, and looked on how to run the adb stuff. None of it has worked, and I can't figure out how to run 'nandroid-mobile.sh' via adb. I'm using RA eris v1.6.2. Help
xzillerationer said:
I recently flashed KaosGingerbread. I did a nandroid backup first. I tried to do a nandroid restore, and gave me this "run 'nandroid-mobile.sh' via adb". I've tried letting it charge, clearing up SD space, and looked on how to run the adb stuff. None of it has worked, and I can't figure out how to run 'nandroid-mobile.sh' via adb. I'm using RA eris v1.6.2. Help
Click to expand...
Click to collapse
The first thing you should do is to inspect the recovery log immediately after the (restore) error occurs in Amon_RA. There is a menu item available in Amon_RA (under "Other", iirc) which will copy the recovery log file at /cache/recovery/log to the root folder of your SD card. Then you can look at it using adb:
Code:
adb shell ls /sdcard/ (look for the file, I think it will be named "recovery.log" or similar)
adb pull /sdcard/whateverthefilenameis.log ./recovery.log
or just
adb pull /cache/recovery/log ./recovery.log
or just
adb shell cat /cache/recovery/log
Alternatively, if you are not familiar with ADB, you can use the Amon_RA "Toggle MS-USB" mode to mount the /sdcard to your PC (after you use the Amon_RA menu to copy the log file to your SD card root), and then copy the log file to your PC for viewing.
There are two reasons for looking at the log file.
1) The first is that Amon_RA himself told you to do so in his announcement post.
2) The second reason is that the Amon_RA process (/sbin/recovery) which spews that
Error : run 'nandroid-mobile.sh restore' via adb!
error message actually just got through running exactly that script... and it failed!
So, if you re-run it, it will certainly fail again, assuming that you use the same command line that Amon_RA did (which is an extremely good idea, BTW). And when it fails when you run it manually, it will produce error messages that give you an idea of what the failure problem was.
So, as you see, you might as well just look at the recovery log in the first place, rather than re-running "nandroid-mobile.sh" just to see it fail once again, and produce the same error messages that are already in the recovery log file.
Probably you ought to post up (here) a copy of your recovery log - some types of errors will not be correctable by running "nandroid-mobile.sh" manually.
If you insist on experimenting, note that "nandroid-mobile.sh" has some documentation built in to it - start a shell on your phone (in Amon_RA recovery mode, natch), and type the command
Code:
nandroid-mobile.sh --help
If you do that, you will find that there are lots of command line options. Inspecting Amon_RA's "/sbin/recovery" program using the well known Unix/Linux/Cygwin "strings" tool, you will find that Amon_RA calls restore commands which look like this:
Code:
/sbin/nandroid-mobile.sh -r -e --norecovery --nocache --nomisc --nosplash1 --nosplash2 --defaultinput -s SUBNAME
See the output of "nandroid-mobile.sh --help" for what SUBNAME is (presumable the folder name that has the desired nandroid backup set in it.
good luck
bftb0
I did that, the log file thing, and got this
Code:
Starting recovery on Sun Jan 9 23:29:34 2011
can't open /dev/tty0: No such file or directory
framebuffer: fd 3 (320 x 480)
Build : RA-eris-v1.6.2
I:Set boot command "boot-recovery"
Command: "/sbin/recovery"
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
ro.error.receiver.system.apps=com.android.updater
ro.build.id=ERD79
ro.build.display.id=ERD79
ro.build.version.incremental=134869
ro.build.version.sdk=7
ro.build.version.codename=REL
ro.build.version.release=2.1
ro.build.date=Thu Feb 11 22:36:17 CST 2010
ro.build.date.utc=1265898977
ro.build.type=user
ro.build.user=u70000
ro.build.host=Oven-X04
ro.build.tags=release-keys
ro.product.model=Eris
ro.product.brand=verizon
ro.product.name=htc_desirec
ro.product.device=desirec
ro.product.board=desirec
ro.product.cpu.abi=armeabi
ro.product.cpu.abi2=
ro.product.manufacturer=HTC
ro.product.locale.language=mdpi
ro.product.locale.region=
ro.wifi.channels=
ro.board.platform=msm7k
ro.build.product=desirec
ro.build.description=2.26.605.2 CL134869 release-keys
ro.build.changelist=134869
ro.build.modelid=
ro.product.ua=
ro.build.fingerprint=verizon/htc_desirec/desirec/desirec:2.1/ERD79/134869:user/release-keys
ro.product.version=2.26.605.2
keyguard.no_require_sim=1
rild.libpath=/system/lib/libhtc_ril.so
ro.ril.default.modem-type=2
ro.telephony.default_network=4
wifi.interface=tiwlan0
wifi.supplicant_scan_interval=15
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=268449905
ro.com.android.dataroaming=true
ro.com.google.locationfeatures=1
persist.service.mount.playsnd=0
ro.cdma.data_retry_config=max_retries=infinite,0,0,60000,120000,480000,900000
ro.sf.lcd_density=160
ro.media.enc.file.format=3gp,mp4
ro.media.enc.vid.codec=m4v,h263
ro.media.enc.vid.h263.width=176,352
ro.media.enc.vid.h263.height=144,288
ro.media.enc.vid.h263.bps=64000,800000
ro.media.enc.vid.h263.fps=1,30
ro.media.enc.vid.m4v.width=176,352
ro.media.enc.vid.m4v.height=144,288
ro.media.enc.vid.m4v.bps=64000,800000
ro.media.enc.vid.m4v.fps=1,30
ro.cdma.home.operator.numeric=310012
ro.cdma.home.operator.alpha=Verizon
ro.config.htc.nocheckin=1
ro.url.legal=http://www.google.com/intl/%s/mobile/android/basic/phone-legal.html
ro.url.legal.android_privacy=http://www.google.com/intl/%s/mobile/android/basic/privacy.html
ro.com.google.networklocation=1
ro.setupwizard.mode=DISABLED
ro.config.ringtone=Innovation.mp3
ro.config.notification_sound=Color.mp3
ro.config.alarm_alert=Light.mp3
ro.config.cal_notification=Vector.mp3
ro.config.msg_notification=Ascend.mp3
ro.com.google.clientidbase=android-verizon
ro.com.google.gmsversion=2.1_r1
net.bt.name=Android
net.change=net.bt.name
ro.config.sync=yes
dalvik.vm.stack-trace-file=/data/anr/traces.txt
ro.modversion=RA-eris-v1.6.2
ro.factorytest=0
ro.serialno=HT9CLHG11370
ro.bootmode=recovery
ro.baseband=2.42.01.04.27
ro.carrier=COMMON
ro.bootloader=1.49.0000
ro.hardware=desirec
ro.revision=2
ro.cid=VZW__001
init.svc.recovery=running
init.svc.adbd=running
adb.connected=
I:Set boot command ""
I:Set boot command ""
I:Set boot command ""
I:Set boot command ""
Restore BDS-20110109-1844 ?
Press Trackball to confirm,
any other key to abort.
Restoring : .
nandroid-mobile v2.2.1
Searching for backup directories, matching BDS-20110109-1844, to delete or restore
or compress
Looking for the latest backup, will display other choices!
Default backup is the latest: /sdcard/nandroid/HT9CLHG11370/BDS-20110109-1844
Other available backups are:
Using G1 keyboard, enter a unique name substring to change it and <CR>
or just <CR> to accept: Accepting default.
Restore path: /sdcard/nandroid/HT9CLHG11370/BDS-20110109-1844
error: /sdcard/nandroid/HT9CLHG11370/BDS-20110109-1844/nandroid.md5 not found, cannot verify backup data
Error : run 'nandroid-mobile.sh restore' via adb!
I:Set boot command ""
I:Set boot command ""
I:Set boot command ""
Move recovery.log to SD
Press Trackball to confirm,
any other key to abort.
Moving : .unmounting /system
unmounting /sdcard
unmounting /data
So, what now? I can flash a new ROM, but I'd greatly prefer to have my nandroid restored, as it contains all the texts from my gf, and I want to keep them.
Well... as predicted, the log contains the source of your error:
Code:
...
Restore path: /sdcard/nandroid/HT9aaaannnnn/BDS-20110109-1844
error: /sdcard/nandroid/HT9aaaannnn/BDS-20110109-1844/nandroid.md5 not found, cannot verify backup data
...
Now, it is a mystery to me why the "nandroid.md5" file would not be found. It is always, always, always, created when a nandroid backup has been performed. If you didn't screw around with contents of your SD card, the only thing I can presume is that you filled up your SD card during the nandroid restore. That is to say - you had an error that occurred during the nandroid backup and you failed to take notice of it.
The "nandroid.md5" file contains the MD5 checksums of each of the backup images in the backup folder, so clearly it must be the last thing created... and so, if you filled up your SD card... it would fail to be created.
This is bad news on several fronts; let me explain why. First, though, here is an example of a file listing of one of my recent nandroid backups:
Code:
$ adb shell ls -l /sdcard/nandroid/HT*/BDS-CELBFroyo_3.9-20110109-1756/
----rwxr-x 1 system sdcard_r 2621440 Jan 9 17:56 boot.img
----rwxr-x 1 system sdcard_r 125323968 Jan 9 17:57 data.img
----rwxr-x 1 system sdcard_r 131 Jan 9 17:57 nandroid.md5
----rwxr-x 1 system sdcard_r 105811200 Jan 9 17:56 system.img
You will note a couple things about the above: first (from the file dates) the "data.img" and the "nandroid.md5" files are the last two files created during the backup on an Eris, and second - that "data.img" is a BIG file (125 MB in the above example).
That means that if you filled up the SD card writing a big file, the big file in question was probably "data.img". That's the file that contains all your user data and application settings - including your GF-related data. It is stored in a "yaffs2" archive format, and when it is unpacked during a nandroid restore operation, the /sbin/unyaffs command is used.
If you were to clean up your SD card, you could manually recreate a "nandroid.md5" file by hand, and then attempt a nandroid recovery.
Here is what a "nandroid.md5" file looks like:
Code:
$ adb shell cat /sdcard/nandroid/HT*/BDS-CELBFroyo_3.9-20110109-1756/nandroid.md5
b94da50ce57174e4a1583da1bf07071c boot.img
db9f1fc53f86a8186da448d0347d09d8 data.img
dc989fe4d74bdee8e9be0ff8cfc2075b system.img
Pretty simple, really. Just the MD5 checksum of each of the three files "boot.img", "data.img", and "system.img". There is a "md5sum" command available under Amon_RA, so it would be trivial for you to hack together a "nandroid.md5" file to place in your backup folder BDS-20110109-1844.
Now, you would be performing an "unyaffs" operation on a presumably corrupted "data.img" file - you might be able to get your data out of this operation, or maybe not. The resulting partially-restored system might go into a boot loop, as there are important files stored in /data/system (for instance).
good luck.
bftb0
To anybody else reading this thread, it is worthwhile to re-iterate two things about using Amon_RA's recovery:
[SIZE=+2]1) Amon_RA's original instructions in his announcement thread, to wit:[/SIZE]
"[SIZE=+1]Always check recovery.log before posting your issues![/SIZE]"
[SIZE=+2]2) Error conditions in Amon_RA [/SIZE]
[SIZE=+1]If an error occurs, you will see an "(E)" on your screen[/SIZE]
No blinking lights, no different text colors or bold fonts - you need to inspect the output of every command action that the Amon_RA recovery performs, and watch for the appearance of ANY line that contains an "(E)". Sometimes the associated error message is very brief - pay attention!
[SIZE=+1](E) means ERROR![/SIZE]
Don't ignore any (E) you see - (E) means ERROR!
Hi,
adb root prompt me that it is unable on product builds. But I gave a try this way after Googling. Though adb deamon is not in root mode I have rooted my device with the help of saferoot. (Thanks saferoot)
adb shell su (now with root)
I mount rootfs / in read write mode.
I notice default.prop file and open it using vi. Value of ro.secure=1 and ro.debuggable=0.
I change those value as follow: ro.secure=0 and ro.debuggable=1
exit from shell and execute adb kill-server and adb start-server
But still adb root tells that it is unable on product builds.
Can I get adbd run as root in this way? what has I missed.
Many thanks,
iua
Hi, I'd like to ask a general question (I suppose) about device boot process. I've made some changes in init.rc and I packed again boot.img. Then I flashed it. So, phone shows logo screen. I've changed boot.img again to enable adb by making changes to default.prop.
So, I've packed boot.img and flashed it again. So, phone shows logo screen and I can use adb during boot process, but I don't know how to use adb to get info about android failed boot (adb has not root permissions, though).
What methods could I follow in these cases? Any ideas?
P.S.
My changes at boot.img: I've moved /system, /usrdata and /cache mount commands into an .sh script in ramdisk root directory.
P.P.S.
I've tried also adb pull last_kmsg and I don't see error messages in the little log (~87 kb). When I look at last_kmsg, I see some lines about phone charging (connected to pc), so I think these messages could be related at the moment which phone is connected to pc but turned off (I'm not sure, though) because last_kmsg is related to previous boot process (charging mode with phone turned off?) and the current one (I think). I'd like to read kmsg and not last_kmsg, however, but kmsg can be read only by root (and my current adb has not root permissions, as I said before).
P.P.P.S.
During the boot process, I can pull directories and files from ramdisk root directory (related to boot partition) into my pc by using adb pull command. I've found that 'dev', 'proc' and 'sys' are very well populated of files and sub-directories. Instead, 'data' and 'system' directories are sadly empty. So, I suppose /usrdata and /system related partitions are not mounted at that moment and such thing prevents to load android system.
Solved
I've found a way to get dmesg without using adb shell. It's possible to use busybox dmesg command inside a shell script (placing busybox binary and shell script into ramdisk root directory of boot.img) and run the script by busybox ash command from init.rc, redirecting the output to a logfile. The command inside shell script should look like as the following:
Code:
/busybox dmesg >> /path/to/my/logfile.txt 2>&1
(That way, stderr and stdout will be redirected to a log file, that can be pulled down by adb pull command)
Hi,
Im trying to block my adb in a way that I cant activated it in the Developer Settings.
I tried edit build.prop and default.prop with:
Code:
persist.sys.usb.config none
ro.debuggable=0
persist.service.adb.enable=0
but as soon as I go in the options and enable it, I can see the device once again with: adb devices
There is someway to remove the adb funcionality ?
Hi all,
I bought a chinese tablet Elink with mediatek mt8163 running Android 6. I tried Kingroot, oneclickroot, kingoroot, iroot... with no success. There is no custom recovery/ROM for this tablet.
This is what I have done so far:
-I backup the boot image with sp flash tool
-Unlock bootloader
-Unpacked boot.img and made the following changes: ro.secure=0, ro.adb.secure=0, security.perf_harden=0, ro.debuggable=1
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.mtk_key_manager_kb_path=1
ro.adb.secure=0
persist.service.acm.enable=0
ro.secure=0
security.perf_harden=0
ro.allow.mock.location=0
ro.debuggable=1
ro.zygote=zygote64_32
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=512m
ro.dalvik.vm.native.bridge=0
debug.atrace.tags.enableflags=0
persist.sys.usb.config=mtp
ro.mount.fs=EXT4
camera.disable_zsl_mode=1
#
# BOOTIMAGE_BUILD_PROPERTIES
#
ro.bootimage.build.date=2017年 09月 14日 星期四 15:31:41 CST
ro.bootimage.build.date.utc=1505374301
ro.bootimage.build.fingerprint=alps/full_elink8163_tb_m/elink8163_tb_m:6.0/MRA58K/1505374020:user/test-keys
-Disabled dm-verity and forceencrypt in fstab
-Replaced adbd \sbin with Chainfire's insecure adbd https://forum.xda-developers.com/showthread.php?t=2593581
-Repacked boot.img and then fastboot boot boot.img
Once I boot into android, I run from cmd: adb shell and it shows # but I get mount: Permission denied with mount -o rw, remount /system
I also tried adb root, adb remount but keep getting Permission denied
I would like to push/copy su binary and install supersu. Please, could anyone give some ideas for what to do next?
andres81f said:
-Disabled dm-verity and forceencrypt in fstab
-Replaced adbd \sbin with Chainfire's insecure adbd https://forum.xda-developers.com/showthread.php?t=2593581
-Repacked boot.img and then fastboot boot boot.img
Click to expand...
Click to collapse
In my boot fstab, I also changed the /system line from "ro" to "rw". That gave me access to /system, I just wanted to remove some apps. You could manually install what you want then. I chose the systemless root method using TWRP, cleaner install and uninstall IMO. Fastboot never worked for me, I have to use SPF Tools to make the changes persistent.
You got most of what you need in those files from unpacking to build TWRP3 yourself. The TWRP building thread will fill you in on the rest.