[Verizon] MD5 Mismatch Error

[quickmustang]

Solved! Delete .android_secure from your internal memory if you are having the same problem!




With every back up I make with Rom Manager, when I attempt to restore it, I get an error message. It says:

Checking MD5 sums...
MD5 mismatch.


When I go to show log, it says:

Checking MD5 sums...
md5sum: nandroid.md5: No such file or directory
MD5 mismatch.

Any idea what could be happening? If I rebuild the MD5 sum through ADB with this code:

adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5


Then everything works again. Any ideas on why it won't build the MD5 sum correctly to begin with? How can I fix this?

 

[jbdan]

With every back up I make with Rom Manager, when I attempt to restore it, I get an error message. It says:

Checking MD5 sums...
MD5 mismatch.


When I go to show log, it says:

Checking MD5 sums...
md5sum: nandroid.md5: No such file or directory
MD5 mismatch.

Any idea what could be happening? If I rebuild the MD5 sum through ADB with this code:

adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5


Then everything works again. Any ideas on why it won't build the MD5 sum correctly to begin with? How can I fix this?

Have you tried creating the backup without the aid of Rom Manager? Reboot into recovery and make a backup through CWM.

Or, by chance, have you renamed the backup/s that are not working?

 

[quickmustang]

I get the same error if I create the backup in recovery mode. I am not renaming the files. I also noticed when I run the backup, I get this message:

Backup boot image...
backing up recovery image...
backing up system...
backing up data...
backing up .android_secure...
Unable to find volume.
Error finding an appropriate backup handler.

 

[jbdan]

I get the same error if I create the backup in recovery mode. I am not renaming the files. I also noticed when I run the backup, I get this message:

Backup boot image...
backing up recovery image...
backing up system...
backing up data...
backing up .android_secure...
Unable to find volume.
Error finding an appropriate backup handler.

So your on CWM 5.5.0.4? Or are you using a modded version of CWM like the ones floating around (larger font and touch enabled)?

 

[scary alien]

Its not really a good idea to re-generate your nandroid.md5 and restore the associated backup...you are pretty-much subverting the safety check that the MD5 checksums are providing (in the nandroid.md5 file).

Usually you get an MD5 mismatch error when a custom recovery like ClockworkMod cannot find your nandroid.md5 file (usually because of renaming issues, which you've already ruled-out).

The bigger question would be why CWM isn't or isn't able to generate your nandroid.md5 file when your backup is being made...

CWM pretty-much generates the nandroid.md5 file in exactly the way you did...he is just supposed to do it immediately after the backups are taken.

You could try taking a new backup, note any messages on the screen, and pull the recovery.log file from the phone. I know I've seen the recovery.log in a few places when I've done an adb shell while CWM is running, but one of these should work:

/cache/recovery/log
/cache/recovery/last_log

(i.e., do an "adb pull /cache/recovery/log cwm-recovery-log.txt", etc.).

You can also look in /tmp for similarly named files.

There might be more information in there that can tell us what is going on.

Good luck!

 

[ska.t73]

As well as what Scary said you might also want to bring this to Koush's attention, he is the developer of CWM and Rom Manager. (if you are using an unmodded version of CWM).

 

[quickmustang]

Yes, I am using 5.5.0.4.

I never would have remade the MD5, but I couldn't get my phone to boot up without restoring a backup. I tried to install a custom kernel and my phone wouldn't boot up (I'm not sure why for that either, but one issue at a time). My only internet access is tethering through my phone, so I couldn't get another kernel either, so I had to find a way to get the boot section off of my backups and that was all I could find to do.

 

[nkk]

My first question would be is CWM miscalculating md5s somehow or are they not being written/read correctly, or what?

I would create a nandroid, and immediately make a copy of nandroid.md5. Then md5 all of the files by yourself and compare. If they are the same, there is an interpretation error when restoring. If they are different, either they were miscalculated or your files are being corrupted almost instantly.

At least then you will know where in the process something is going wrong (something I am sure Koush would appreciate if/when you contact him).

-Nkk

EDIT: Reread. for some reason I thought you had an MD5 mismatch, not a missing nandroid.md5. I do not know how to help you with that, except for saying reflash CWM and see if that does anything.

Also, (and Scary or a real dev could confirm this), there may be (do not know if it was kept from the main kernel and even if it was if it would be written by recovery) a log file for fs read/writes, so you can see if the nandroid.md5 is ever actually written, or if it is written then deleted, or what.

 

[scary alien]

Also, (and Scary or a real dev could confirm this), there may be (do not know if it was kept from the main kernel and even if it was if it would be written by recovery) a log file for fs read/writes, so you can see if the nandroid.md5 is ever actually written, or if it is written then deleted, or what.

Well, I can't see anything special in the code itself (although I'm not looking at the current code for the GNex--doesn't look like Koush has released that yet or I just can't find it) regarding a separate log file for the writes (other than what is displayed on the screen while its running).

Here's a snippet of a recent recovery log file for a backup I did:

I:Checking for extendedcommand...
I:Skipping execution of extendedcommand, file not found...
I:using /data/media, no /sdcard found.
Backing up boot image...
Backing up recovery image...
Backing up system...
:
<snip--this is where all the .apk files are listed, etc.>
:
No /sdcard/.android_secure found. Skipping backup of applications on external storage.
Backing up cache...
loglast_loglast_installNo sd-ext found. Skipping backup of sd-ext.
Generating md5 sum...

Backup complete!

I can see the code releated to the "Generating md5 sum..." line in the nandroid.c file and it simply invokes the nandroid-md5.sh script which does pretty-much what the OP did in the first post when he recreated the nandroid.md5 file:

md5sum *img > nandroid.md5

You know, it occurred to me that there is a way that the nandroid.md5 file would no longer be present would be if it couldn't be written in the first place. I could see this happening if the md5sum utility in the ramdisk that's packed with CWM failed (aborted) without producing output, or if the "SD card" was full and it had no space for this very small file (237 bytes) to be written (hardly seems likely given the size of the internal storage). The other possibility is just as unlikely is that the file was deleted after the backup was made.

Dunno--if it were me, I would do a CWM backup and have an adb shell session running and watching it while it was being created and immediately afterwards. You'd be able to examine the recovery log file and the content and creation of the nandroid.md5 file, too.

Cheers!

 

[nkk]

Well, I can't see anything special in the code itself (although I'm not looking at the current code for the GNex--doesn't look like Koush has released that yet or I just can't find it) regarding a separate log file for the writes (other than what is displayed on the screen while its running).

<snip>

The log I am referring to is written by a part the main linux kernel I believe. Hence my questioning whether the android team kept it (or any derivative of it), and if it would even be used in recovery.

Anyway, I do doubt it was kept (seems relatively useless on a mobile/embedded system, where a more catch all thing like the logcat works better), but I thought it was worth asking someone with more knowledge if they knew anything about it.

-Nkk

 

[scary alien]

The log I am referring to is written by a part the main linux kernel I believe. Hence my questioning whether the android team kept it (or any derivative of it), and if it would even be used in recovery.

Anyway, I do doubt it was kept (seems relatively useless on a mobile/embedded system, where a more catch all thing like the logcat works better), but I thought it was worth asking someone with more knowledge if they knew anything about it.

-Nkk

Ah, my bad...I misunderstood what you were asking.

Did you mean something like dmesg or cat'ing the /proc/kmsg? (How to get kernel messages from Android? - BootLoader)

I booted into CWM and the /proc/kmsg file is empty (and stays empty while navigating the menus). There is a /proc/last_kmsg file that is non-zero, but is clearly from the tail-end of the last part of Android before shutting down to recovery.

The dmesg utility does produce output, but monitoring it while a Nandroid backup is running doesn't reveal that many lines of output (mostly what looks like battery status info).

Cheers!

edit: I re-checked a "cat /proc/kmsg" while the CWM Nandroid backup was running and it looks just like the dmsg output

 

[nkk]

Ah, my bad...I misunderstood what you were asking.

Did you mean something like dmesg or cat'ing the /proc/kmsg? (How to get kernel messages from Android? - BootLoader)

I booted into CWM and the /proc/kmsg file is empty (and stays empty while navigating the menus). There is a /proc/last_kmsg file that is non-zero, but is clearly from the tail-end of the last part of Android before shutting down to recovery.

The dmesg utility does produce output, but monitoring it while a Nandroid backup is running doesn't reveal that many lines of output (mostly what looks like battery status info).

Cheers!

edit: I re-checked a "cat /proc/kmsg" while the CWM Nandroid backup was running and it looks just like the dmsg output

Well...there goes my solution.

Thanks for checking.

Nkk

 

[quickmustang]

Dunno--if it were me, I would do a CWM backup and have an adb shell session running and watching it while it was being created and immediately afterwards. You'd be able to examine the recovery log file and the content and creation of the nandroid.md5 file, too.

Cheers!

Sorry, I was too busy to mess with it this weekend. Back to playing a little bit now.


I can't get ADB to connect when I am in recovery mode. Is it supposed to?

 

[nkk]

Sorry, I was too busy to mess with it this weekend. Back to playing a little bit now.


I can't get ADB to connect when I am in recovery mode. Is it supposed to?

Yes. Which OS is the computer using?

Nkk

 

[quickmustang]

Yes. Which OS is the computer using?

Nkk

OK, well it connects to my laptop at home in recovery mode. I have windows 7 and it doesn't connect there for some reason.

Dunno--if it were me, I would do a CWM backup and have an adb shell session running and watching it while it was being created and immediately afterwards. You'd be able to examine the recovery log file and the content and creation of the nandroid.md5 file, too.

So how do I do this? I ran adb shell, but I don't know what else to do to examine the recovery log file.

When I browse through the backup files on the phone, the nandroid.md5 file isn't there on any of the backups other than the ones I created manually.

 

[quickmustang]

Anything? Anyone? Kind of frustrated because I can't make safe backups of my phone, so I don't feel comfortable installing custom kernels and roms. So if I can't play with this phone very much, I'm really starting to miss the Rezound.

 

[nkk]

On the machine it does not work on...the drivers are correct, no? Have you tried different drivers (The naked ones posted on xda, pdanet, etc)? The fact that it works somewhere else means the problem is not the phone.

As for the md5:

So I do not know that this will do anything, but the engineer in me wants to isolate variables.

I suggest that you make a nandroid (sans md5 of course), trust that it is good and transfer it to your computer. Then, completely unroot. Reflash all original radios, recovery, boot.img, etc. Use the official packages from google code servers. Then, 'fastboot oem lock'.

Now, reroot with no custome ROM. Just CWM and su.apk/su binaries.

Do md5sums work now?

I know it sounds painful, but it actually only takes 30 or so minutes (I have done it a couple of times already).

Nkk

PS: I am in pittsburgh, If you were just a bit closer (and by a bit I mean more than half ) I would offer to come and help in person (not that that would necessary achieve much). Hope you solve this...it would be a shame to switch phones for such a stupid problem.

EDIT: Again with isolating vars, but have you flashed CWM through fastboot and not rom manager? That might be another thing to try. Not sure it will do much, but isolating vars is one way to find the problem and this just gets rid of one more thing that could potentially cause a problem.

 

[scary alien]

quickmustang,

Sorry for the delay in the reply...

I can't give you details here and now (being at work and all), but I'd be happy to, when I get home this evening, run through and document/record where I see the files that I was mentioning above.

I'll post back here exactly what I find and see when I run a ClockworkMod back (i.e., exactly where the recovery log gets saved and copied to, "watching" the nandroid.md5 file, monitoring for free space on your internal SD card, etc.) to see if we can tell what might be going on with your device.

It would be good to collect / capture all of this stuff before making any changes like nkk suggested (I hate mysteries, LOL--I want to know what caused / fixed a particular problem, otherwise I just lie awake at night, wondering ).

After that, then resetting things to a known/good state like nkk suggested would be an excellent thing to do.

Let me know how that sounds...if necessary, we could do a Gtalk session if that would help, but let me post what I can document this evening if that's okay.

Cheers!

 

[scary alien]

Okay, here's what I did:

By the way, the location of the ClockworkMod recovery log is at: /cache/recovery/log

There's also the previous log kept at: /cache/recovery/last_log

1. Start-up a Windows Command Prompt (DOS Window) where my adb utility is located (you can optionally create a "cwm" folder if you are able to access adb from anywhere (you'll have to put the adb utility location in your PATH environment variable)):

C:\gnex\sdk-tools>mkdir cwm
C:\gnex\sdk-tools>cd cwm
C:\gnex\sdk-tools\cwm>

2. Connect phone to PC via USB cable

3. Reboot into ClockworkMod recovery

4. Started-up a Nandroid backup

5. Monitor the backup during and after it runs:

# first, find / see what the new directory name is being used (yours will be different, of course)
#
C:\gnex\sdk-tools\cwm>adb shell ls -a -l /data/media/clockworkmod/backup
drwxrwxrwx root root 2012-01-11 19:01 2012-01-11.23.53.58

# start watching the Nandroid's backup files as they are being made:
#
C:\gnex\sdk-tools\cwm>adb shell ls -a -l /data/media/clockworkmod/backup/2012-01-11.23.53.58
drwxrwxrwx 2 root root 4096 Jan 11 23:54 .
drwxrwxr-x 7 media_rw media_rw 4096 Jan 11 23:54 ..
-rw-rw-rw- 1 root root 8388608 Jan 11 23:54 boot.img
-rw-rw-rw- 1 root root 12517376 Jan 11 23:54 recovery.img
-rw-rw-rw- 1 root root 296216064 Jan 11 23:54 system.ext4.tar

# time passes, more files are being created:
#
C:\gnex\sdk-tools\cwm>adb shell ls -a -l /data/media/clockworkmod/backup/2012-01-11.23.53.58
drwxrwxrwx 2 root root 4096 Jan 12 00:01 .
drwxrwxr-x 7 media_rw media_rw 4096 Jan 11 23:54 ..
-rw-rw-rw- 1 root root 8388608 Jan 11 23:54 boot.img
-rw-rw-rw- 1 root root 16896 Jan 12 00:01 cache.ext4.tar
-rw-rw-rw- 1 root root 287029760 Jan 11 23:59 data.ext4.tar
-rw-rw-rw- 1 root root 12517376 Jan 11 23:54 recovery.img
-rw-rw-rw- 1 root root 321760768 Jan 11 23:54 system.ext4.tar

# backup is complete (you can see the nandroid.md5 file in the list):
#
C:\gnex\sdk-tools\cwm>adb shell ls -a -l /data/media/clockworkmod/backup/2012-01-11.23.53.58
drwxrwxrwx 2 root root 4096 Jan 12 00:01 .
drwxrwxr-x 7 media_rw media_rw 4096 Jan 11 23:54 ..
-rw-rw-rw- 1 root root 8388608 Jan 11 23:54 boot.img
-rw-rw-rw- 1 root root 16896 Jan 12 00:01 cache.ext4.tar
-rw-rw-rw- 1 root root 287029760 Jan 11 23:59 data.ext4.tar
-rw-rw-rw- 1 root root 237 Jan 12 00:01 nandroid.md5
-rw-rw-rw- 1 root root 12517376 Jan 11 23:54 recovery.img
-rw-rw-rw- 1 root root 321760768 Jan 11 23:54 system.ext4.tar

# see how much space is used in the /data/media (SD card mount):
#
C:\gnex\sdk-tools\cwm>adb shell df /data/media
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
29501504 3586428 25915076 12% /data

# display all of the mounts:
#
C:\gnex\sdk-tools\cwm>adb shell df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 323048 32 323016 0% /dev
/dev/block/platform/omap/omap_hsmmc.0/by-name/cache
435400 7308 428092 2% /cache
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
29501504 3586428 25915076 12% /data

# dump the contents of the nandroid.md5 file:
#
C:\gnex\sdk-tools\cwm>adb shell cat /data/media/clockworkmod/backup/2012-01-11.23.53.58/nandroid.md5
3d88f1a56b64c15ea95237bd08690eaa boot.img
b1f2b4dfe3c0e3fe7e9c1e887fe9663a cache.ext4.tar
863150f807e8980cf66574bdb79c6932 data.ext4.tar
b0e63ab99bc04fd0c7c41a598b8a3442 recovery.img
35ffb942bce3a2f46d50645ad48a2ce3 system.ext4.tar

# CWM also copies/creates files in the ramdisk's temporary /tmp directory:
#
C:\gnex\sdk-tools\cwm>adb shell ls -a -l /tmp/*
-rw-rw-rw- 1 root root 2 Jan 12 00:01 /tmp/dircount
-rw-rw-rw- 1 root root 237 Jan 12 00:01 /tmp/nandroid.md5
-rw-rw-rw- 1 root root 54700 Jan 12 00:01 /tmp/recovery.log

# let's grab the main CWM log file:
#
C:\gnex\sdk-tools\cwm>adb pull /cache/recovery/log cwm-log.txt
1618 KB/s (54700 bytes in 0.033s)

# also grab the prior log:
#
C:\gnex\sdk-tools\cwm>adb pull /cache/recovery/last_log cwm-last_log.txt
2811 KB/s (54700 bytes in 0.019s)

# grab the other files that CWM created in /tmp:
#
C:\gnex\sdk-tools\cwm>adb pull /tmp/recovery.log cwm-tmp-recovery.log
2811 KB/s (54700 bytes in 0.019s)

# he even copies the nandroid.md5 file to the temporary /tmp directory:
#
C:\gnex\sdk-tools\cwm>adb pull /tmp/nandroid.md5 cwm-tmp-nandroid.md5
57 KB/s (237 bytes in 0.004s)

# grab this file, too (what the heck)
#
C:\gnex\sdk-tools\cwm>adb pull /tmp/dircount cwm-tmp-dircount.txt
0 KB/s (2 bytes in 0.003s)

# finally, display what we've grabbed
#
C:\gnex\sdk-tools\cwm>dir
Volume in drive C has no label.
Volume Serial Number is 843C-52A5

Directory of C:\gnex\sdk-tools\cwm

01/11/2012 07:10 PM <DIR> .
01/11/2012 07:10 PM <DIR> ..
01/11/2012 07:08 PM 54,700 cwm-last_log.txt
01/11/2012 07:08 PM 54,700 cwm-log.txt
01/11/2012 07:10 PM 2 cwm-tmp-dircount.txt
01/11/2012 07:09 PM 237 cwm-tmp-nandroid.md5
01/11/2012 07:09 PM 54,700 cwm-tmp-recovery.log
5 File(s) 164,339 bytes
2 Dir(s) 395,629,531,136 bytes free

That's about it... I'll be interesting to see if you see a nandroid.md5 file being created while its running, etc.

Look at the contents of your /cache/recovery/log (pulled-over as cwm-log.txt) and see if there's anything interesting in there.

Let me know.

Cheers!

 

[quickmustang]

Here is my log from the adb session. It doesn't look like the MD5 was ever created. I've attached all the log files because it's way over my head.



D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>fastboot flash recovery r
ecovery-clockwork-5.5.0.4-toro.img
sending 'recovery' (5140 KB)...
OKAY [ 0.609s]
writing 'recovery'...
OKAY [ 1.139s]
finished. total time: 1.749s

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb reboot recovery


D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /clock
workmod/backup
ls: /clockworkmod/backup: No such file or directory

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls - a -l /sdca
rd/clockworkmod/backup
ls: -: No such file or directory
ls: a: No such file or directory
/sdcard/clockworkmod/backup:
drwxrwxrwx 2 root root 4096 Dec 21 17:17 2011-12-21-12.15.14
drwxrwxrwx 2 root root 4096 Dec 31 16:33 2011-12-31-11.30.29
drwxrwxrwx 2 root root 4096 Jan 1 2000 2012-01-05-08.58.22
drwxrwxrwx 2 root root 4096 Jan 6 18:13 2012-01-06.18.10.53
drwxrwxrwx 2 root root 4096 Jan 9 17:35 2012-01-09.17.33.35
drwxrwxrwx 2 root root 4096 Jan 12 04:04 2012-01-12.04.02.16
drwxrwxrwx 2 root root 4096 Jan 12 04:22 2012-01-12.04.21.58
drwxrwxrwx 2 root root 4096 Dec 19 05:37 first_backup_

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /sdcar
d/clockworkmod/backup/2012-01-12.04.21.58
drwxrwxrwx 2 root root 4096 Jan 12 04:24 .
drwxrwxrwx 10 root root 4096 Jan 12 04:22 ..
-rw-rw-rw- 1 root root 8388608 Jan 12 04:22 boot.img
-rw-rw-rw- 1 root root 120214528 Jan 12 04:24 data.ext4.tar
-rw-rw-rw- 1 root root 12517376 Jan 12 04:22 recovery.img
-rw-rw-rw- 1 root root 321396736 Jan 12 04:22 system.ext4.tar

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /sdcar
d/clockworkmod/backup/2012-01.-12.04.21.58
ls: /sdcard/clockworkmod/backup/2012-01.-12.04.21.58: No such file or directory

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /sdcar
d/clockworkmod/backup/2012-01-12.04.21.58
drwxrwxrwx 2 root root 4096 Jan 12 04:24 .
drwxrwxrwx 10 root root 4096 Jan 12 04:22 ..
-rw-rw-rw- 1 root root 8388608 Jan 12 04:22 boot.img
-rw-rw-rw- 1 root root 235512320 Jan 12 04:26 data.ext4.tar
-rw-rw-rw- 1 root root 12517376 Jan 12 04:22 recovery.img
-rw-rw-rw- 1 root root 321396736 Jan 12 04:22 system.ext4.tar

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /sdcar
d/clockworkmod/backup/2012-01-12.04.21.58
drwxrwxrwx 2 root root 4096 Jan 12 04:24 .
drwxrwxrwx 10 root root 4096 Jan 12 04:22 ..
-rw-rw-rw- 1 root root 8388608 Jan 12 04:22 boot.img
-rw-rw-rw- 1 root root 914598912 Jan 12 04:28 data.ext4.tar
-rw-rw-rw- 1 root root 12517376 Jan 12 04:22 recovery.img
-rw-rw-rw- 1 root root 321396736 Jan 12 04:22 system.ext4.tar

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell df /sdcard/cloc
kworkmod
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
29501504 23573496 5928008 80% /data

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 323168 32 323136 0% /dev
/dev/block/platform/omap/omap_hsmmc.0/by-name/cache
435400 7408 427992 2% /cache
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata
29501504 23573496 5928008 80% /data

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /sdcar
d/clockworkmod/backup/2012-01-12.04.21.58
drwxrwxrwx 2 root root 4096 Jan 12 04:24 .
drwxrwxrwx 10 root root 4096 Jan 12 04:22 ..
-rw-rw-rw- 1 root root 8388608 Jan 12 04:22 boot.img
-rw-rw-rw- 1 root root 914598912 Jan 12 04:28 data.ext4.tar
-rw-rw-rw- 1 root root 12517376 Jan 12 04:22 recovery.img
-rw-rw-rw- 1 root root 321396736 Jan 12 04:22 system.ext4.tar

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell ls -a -l /tmp/*

-rw-rw-rw- 1 root root 3 Jan 12 04:28 /tmp/dircount
-rw-rw-rw- 1 root root 49413 Jan 12 04:28 /tmp/recovery.log

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb pull /cache/recovery/
log cwm-log.txt
846 KB/s (49413 bytes in 0.057s)

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb pull /cache/recovery/
last_log cwm-last_log.txt
8042 KB/s (49413 bytes in 0.006s)

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb pull /tmp/recovery.lo
g cwm-tmp-recovery.log
2539 KB/s (49413 bytes in 0.019s)

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb pull /tmp/nandroid.md
5 cwm-tmp-nandroid.md5
remote object '/tmp/nandroid.md5' does not exist

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb pull /tmp/dircount cw
m-tmp-dircount.txt
0 KB/s (3 bytes in 0.004s)

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>

 

[scary alien]

quickmustang,

I think I know what's going on here...your /data partition is really big (full), and therefore, so is the resulting data.ext4.tar file:

yours: -rw-rw-rw- 1 root root 914,598,912 Jan 12 04:28 data.ext4.tar

mine: -rw-rw-rw- 1 root root 287,029,760 Jan 11 23:59 data.ext4.tar

My total Nandroid backup size was 629MBs...and my /data partition is only 12% full.

So, I think its because you simply don't have enough space on you "SD card" to make your Nandroid backup.

The df you did on /data shows it 80% full, so I'm guessing that you have a lot of stuff on your /sdcard, is that right?

That all meshes with why you don't have a nandroid.md5 file (and your backup surely didn't even finish backing-up your /data partition, either)...

I don't know what the ratio of free space for /data needs to be, but I do see that you have several other Nandroid backups that you could delete and retry the backup again to see if it works this time (or make sure you've got "plenty"--a relative term, apparently) space on /data to make your backups.

If you do an adb shell df while Android is booted-up normally, what does that show you? Here's my output:

C:\gnex\sdk-tools\cwm>[COLOR="Blue"][B]adb shell df[/B][/COLOR]
Filesystem             Size   Used   Free   Blksize
/dev                   347M    32K   347M   4096
/mnt/asec              347M     0K   347M   4096
/mnt/obb               347M     0K   347M   4096
/system                643M   319M   324M   4096
[COLOR="red"]/data                   28G     3G    24G   4096[/COLOR]
/cache                 425M     7M   418M   4096
/factory                19M     4M    15M   4096
/mnt/sdcard             28G     3G    24G   4096

Hope this helps!

Cheers!

 

[quickmustang]

quickmustang,

I think I know what's going on here...your /data partition is really big (full), and therefore, so is the resulting data.ext4.tar file:

yours: -rw-rw-rw- 1 root root 914,598,912 Jan 12 04:28 data.ext4.tar

mine: -rw-rw-rw- 1 root root 287,029,760 Jan 11 23:59 data.ext4.tar

My total Nandroid backup size was 629MBs...and my /data partition is only 12% full.

So, I think its because you simply don't have enough space on you "SD card" to make your Nandroid backup.

The df you did on /data shows it 80% full, so I'm guessing that you have a lot of stuff on your /sdcard, is that right?

That all meshes with why you don't have a nandroid.md5 file (and your backup surely didn't even finish backing-up your /data partition, either)...

I don't know what the ratio of free space for /data needs to be, but I do see that you have several other Nandroid backups that you could delete and retry the backup again to see if it works this time (or make sure you've got "plenty"--a relative term, apparently) space on /data to make your backups.

If you do an adb shell df while Android is booted-up normally, what does that show you? Here's my output:

C:\gnex\sdk-tools\cwm>[COLOR="Blue"][B]adb shell df[/B][/COLOR]
Filesystem             Size   Used   Free   Blksize
/dev                   347M    32K   347M   4096
/mnt/asec              347M     0K   347M   4096
/mnt/obb               347M     0K   347M   4096
/system                643M   319M   324M   4096
[COLOR="red"]/data                   28G     3G    24G   4096[/COLOR]
/cache                 425M     7M   418M   4096
/factory                19M     4M    15M   4096
/mnt/sdcard             28G     3G    24G   4096

Hope this helps!

Cheers!

I have 5gigs free. Isn't that enough for a backup? I checked my first backup after I had just unlocked and rooted and there wasn't an MD5 in that either. My data should have been pretty much empty then. Does the backup on the Nexus backup the entire "SD Card"? It never did that on my OG.

Why would I get the message that says "Error finding an appropriate backup handler" at the end of my backup. It seems like something is just missing from my phone for creating the MD5.

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell df
Filesystem Size Used Free Blksize
/dev 347M 32K 347M 4096
/mnt/asec 347M 0K 347M 4096
/mnt/obb 347M 0K 347M 4096
/system 643M 318M 324M 4096
/data 28G 22G 5G 4096
/cache 425M 7M 418M 4096
/factory 19M 4M 15M 4096
/mnt/sdcard 28G 22G 5G 4096

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>

 

[scary alien]

I have 5gigs free. Isn't that enough for a backup? I checked my first backup after I had just unlocked and rooted and there wasn't an MD5 in that either. My data should have been pretty much empty then. Does the backup on the Nexus backup the entire "SD Card"? It never did that on my OG.

Why would I get the message that says "Error finding an appropriate backup handler" at the end of my backup. It seems like something is just missing from my phone for creating the MD5.

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>adb shell df
Filesystem Size Used Free Blksize
/dev 347M 32K 347M 4096
/mnt/asec 347M 0K 347M 4096
/mnt/obb 347M 0K 347M 4096
/system 643M 318M 324M 4096
/data 28G 22G 5G 4096
/cache 425M 7M 418M 4096
/factory 19M 4M 15M 4096
/mnt/sdcard 28G 22G 5G 4096

D:\Nexus\Root Stuff\android-sdk-windows\platform-tools>

I too would think 5GB would be enough free...

Since the SD card (/sdcard) is mounted from a point inside the /data partition at /data/media, perhaps there's a "min-free" type of limit that Android (ICS) wants for /data that it won't let you exceed.

I've checked (but its been a week or so) for updates to Koush's source code for CWM and haven't seen that he's published anything that would have to be specific to the GNex version that he made. I say this because the Nandroid backup for the /data partition would have to be coded to exclude the contents of the /data/media hierarchy, and the current code does not appear to discriminate in that manner.

I don't know the answer to your question about the "Error finding an appropriate backup handler".

If I were you, I would:

1. Move and cleanup any old CWM backups to you have to your PC to get back a lot of free space

2. Move (save to your PC) / cleanup any other large filesets you've got if necessary to make free space (you can always move this stuff back if needed)

3. Try another Nandroid backup and see if that works (depending on how much free space you now have)

4. Failing the above, I would follow what nkk said previously and return to stock (clean slate) to see if there's something else going on and debug things from there.

 

[nkk]

I do not know about hunting through source, but my backups most certainly do not contain /data/media. I took the data.ext4.tar, transferred it to my desktop and extracted.

ls -la ./data yields:

total 168
drwxrwx--x  20 myName myName  4096 2012-01-10 07:24 .
drwxr-xr-x   4 myName myName  4096 2012-01-12 11:46 ..
drwxrwxr-x   2 myName myName  4096 2012-01-07 02:03 anr
drwxrwx--x   2 myName myName 12288 2012-01-09 23:05 app
drwxrwx--x   2 myName myName  4096 2012-01-07 02:21 app-private
drwx------   5 myName myName  4096 2012-01-10 07:23 backup
drwxrwx--x   2 myName myName 24576 2012-01-09 23:05 dalvik-cache
drwxrwx--x 247 myName myName 16384 2012-01-10 16:21 data
drwxr-x---   2 myName myName  4096 2012-01-07 01:43 dontpanic
drwxrwxr--   4 myName myName  4096 2012-01-07 01:44 drm
drwxrwx--x   3 myName myName  4096 2012-01-07 01:43 local
drwxrwx---   2 myName myName  4096 2012-01-07 01:43 lost+found
drwxrwx--t  11 myName myName  4096 2012-01-07 01:43 misc
-rw-------   1 myName myName  4096 2012-01-10 10:48 NVM0
-rw-------   1 myName myName     0 2012-01-10 07:23 NVM1
-rw-------   1 myName myName     0 2012-01-10 07:23 NVM10
-rw-------   1 myName myName   608 2012-01-10 07:24 NVM11
-rw-------   1 myName myName  2832 2012-01-10 10:47 NVM13
-rw-------   1 myName myName     0 2012-01-10 07:23 NVM2
-rw-------   1 myName myName     4 2012-01-10 07:24 NVM20
-rw-------   1 myName myName 31000 2012-01-10 07:24 NVM7
-rw-------   1 myName myName     0 2012-01-10 07:23 NVM9
drwx------   2 myName myName  4096 2012-01-10 08:49 property
drwxrwxr-x   3 myName myName  4096 2012-01-07 01:43 radio
drwxrwx--x   2 myName myName  4096 2012-01-07 01:43 resource-cache
drwxrwx---   2 myName myName  4096 2012-01-07 01:43 smc
drwxrwxr-x  10 myName myName  4096 2012-01-10 16:34 system
drwxr-xr-x   2 myName myName  4096 2012-01-08 23:31 tombstones
drwxr-xr-x   2 myName myName  4096 2012-01-07 01:43 user

OP, if you could get a data.ext4.tar file from an old backup, extract it (7zip is free and opensource and will do the extraction in windows) and see if there is a ./media file. That would be a quick way to test it /data/media is being backed up by CWM

Nkk

EDIT: Replaced the ls output with the slightly more helpful ls -la output. Also, took my name out of the listings.

EDIT2: Scary, do you know what on Earth that dontpanic directory is? There is nothing in it...

 

[scary alien]

I do not know about hunting through source, but my backups most certainly do not contain /data/media. I took the data.ext4.tar, transferred it to my desktop and extracted.

ls -la ./data yields:

<snip>

OP, if you could get a data.ext4.tar file from an old backup, extract it (7zip is free and opensource and will do the extraction in windows) and see if there is a ./media file. That would be a quick way to test it /data/media is being backed up by CWM

Nkk

EDIT: Replaced the ls output with the slightly more helpful ls -la output. Also, took my name out of the listings.

EDIT2: Scary, do you know what on Earth that dontpanic directory is? There is nothing in it...

Oh, yeah, I hope I didn't mean to imply that I thought the /data/media folder (hierarchy) was being backed-up... Its just that in the currently published source, /data is backed-up as an entire partition and that wouldn't work for the GNex since there's the /data/media stuff inside it (it would clearly have to redact / omit that folder (I believe)).

I'm guessing that the dontpanic folder might be an inside joke (Phrases from The Hitchhiker's Guide to the Galaxy - Wikipedia, the free encyclopedia)...dunno for sure.

I didn't get a chance to review my data.ext4.tar file, but it would be interesting to find the what large files are in the OP's /data directory (outside of /data/media, of course).

I'll examine my file tonight...(can't do it here at work...).