[Q] NANDROID Restore problems. - Droid Eris Q&A, Help & Troubleshooting

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!