Want to preface this by saying I just had a HUGE thread ready to go with detailed step by step of what I did and it just got deleted while I was hitting submit somehow. After wasting many hours this evening, I'll start over, again, lol.
So I wanted to Partition my SD card back to 0, 0 so I could flash KF V32. I backed up my SD to my laptop, wiped Partition, changed to double zero and moved everything back over. I factory/davelk wipe and after about an hour, I finally am ready to flash V32. I go to flash from my SD card and it says "F: File is Empty"
I quickly realized what I had done wrong. I dragged the entire folder I created from my laptop onto my SD instead of dragging individually. Rookie mistake. Another hour passes and I'm so ready to flash my 1st Froyo ROM and 2nd ROM ever!!!
I select KF V32 from my SD, click trackball to confirm and "File is Bad" pops up 2 seconds later
I decide to restore my newest Nand that I had made last night because I knew I'd be flashing this evening. I select it, its runs and I reboot. 20 minutes later, xtrCUSTOM pops up on the homescreen and I realize that this is the stock xtrSENSE 4.0.6.1, not the Nand I restored.
I immedietly D/L'd Astro to see what was on my SD card and EVERYTHING was there. My nands, D/L's, settings, etc. My Titanium Backup I just D/L'd last night in preparitions for flashing V32 was there.
My question to all the brilliant minds around this forum. WTF happened here? Did I do something wrong? I made sure I did everything slowly and took my time so I'm perplexed. Has this happened to anyone else? I love xtrSENSE and I have every intention of it being my everday ROM. I want to give FroYo a fair shot though and check it out but now, after tonight, I'm kinda gun shy. I don't want to have to set up V32 from scratch then if I go back to xtr have to do it all over. Any advice, comments and questions are more than welcomed.
Thanks everyone
The Following User Says Thank You to WormDoes For This Useful Post:
From your post it appears you missed one or more wipe procedures.
1. Wipe data/factory reset
2. Wipe Dalvik-cache
3. Wipe SD: ext partition Even though you've supposedly removed it.
Also, Instead of making the partition 0;0 I would suggest a format instead with 32k clusters. I would then load the zip and only restore the other stuff later
My guess is that the Kaos Froyo ROM file was not fully copied over. A similar thing happened to me when trying to flash V34. I have been using Dropbox to copy ROMs over to my SD card because I hate mounting my phone to my computer, plus having it on Dropbox gives me the reassurance that the files will be available to me, say, if I travel and something happens to my phone.
Anyway, I had donwloaded V34, but it was obviously not fully copied down, but I did not find out until I was in Recovery and had already wiped data and saw the error message when I tried to flash. Rather than nand restore and do it all again, I connected the phone to my computer while still in recovery, started Terminal on my Mac, changed to the tools directory of my SDK files, and ran the following adb command:
Code:
./adb push kaosfroyo-v34.zip /sdcard/
After that command finished, I was able to flash the ROM successfully.
I use dropbox for the same reason. However sometimes it will disconnect from the Dropbox server in the middle of a download. If you happen to be looking at the screen when it happens there is a pop-up that notifies you, but it doesn't stay on the screen very long. So if you've wandered away from your phone you won't know that you only got part of the file unless you compare file sizes and/or the MD5 sum - or until something about the file doesn't work correctly.
I'm not as concerned with V32 not taking but why my Nand didn't restore correctly?
Does anyone know why It restored the ROM instead of my backup?
So, was it xtrSense 4.0.6.1 that was loaded before you tried to flash KF v32 and before you tried the Nand restore? I'm a little unclear about the exact sequence of events...
If so, I'm thinking that the KF v32 flash obviously didn't work (duh) and the Nandroid restore didn't actually restore...
Does the Nandroid backup directory contain a nandroid.md5 file in it? When I've had Nandroid backups fail, they usually do not create this file.
Perhaps the Nandroid didn't actually restore anything if this (key) file was not present...would this account for what you saw?
So, was it xtrSense 4.0.6.1 that was loaded before you tried to flash KF v32 and before you tried the Nand restore? I'm a little unclear about the exact sequence of events...
If so, I'm thinking that the KF v32 flash obviously didn't work (duh) and the Nandroid restore didn't actually restore...
Does the Nandroid backup directory contain a nandroid.md5 file in it? When I've had Nandroid backups fail, they usually do not create this file.
Perhaps the Nandroid didn't actually restore anything if this (key) file was not present...would this account for what you saw?
Yes, xtrSENSE was the ROM loaded before I flashed V32. I just checked all my Nands and NONE of them have MD5. Why did this happen? I could see it happening to one but all 4 of my backups? Should I just delete the older Nands and make a new one? How can I ensure that the MD5 will be on the new Nand?
I'm not as concerned with V32 not taking but why my Nand didn't restore correctly?
Does anyone know why It restored the ROM instead of my backup?
My guess, since you mention that you had a partitioned SD card, is that you did not repartition the card, so your apps could not be reinstalled to the ext partition on your SD card. Also, did you do Nandroid backup or Nand+ext? If you did not do Nand+ext, then none of your installed apps would have been backed up.
The proper procedure for flashing a new ROM is:
- Restart in recovery.
- Nandroid backup (do a Nand+ext if you have a partitioned SD card with apps installed)
- Wipe data, dalvik, and sd:ext, if you have a partition with apps
- repartition, if you need to, and copy files back to your SD card (hopefully, you have a card reader.)
- flash the new ROM
And, for restoring a Nandroid backup:
- restart in recovery
- (I usually wipe data, dalvik, and ext, just to be sure)
- if you are restoring a Nand+ext and you removed the partition, you need to repartition the card, copy your files back to SD.
- Nandroid restore
- do not wipe! - just reboot.
The Following User Says Thank You to doogald For This Useful Post:
Yes, xtrSENSE was the ROM loaded before I flashed V32. I just checked all my Nands and NONE of them have MD5. Why did this happen? I could see it happening to one but all 4 of my backups? Should I just delete the older Nands and make a new one? How can I ensure that the MD5 will be on the new Nand?
lol, not 100% sure...when I've done my Nandroid backups, I've always had a full (100%) charge on my phone and been plugged-in (via my USB cable to my laptop). Also, I've never even removed the /sdcard from the phone (its the original) and have ever partitioned or USD a2sd, so the card is still "lightly used" .
Just make sure you do have a full charge, are plugged-in, and watch for any messages that the Nandroid backup might report (i.e., something about "nandroid-mobile.sh..."...I can't recall at the moment). Then, after it finishes, you can check the BDS directory to see if (make sure that) the nandroid.md5 file was created. That would be my threshold for knowing that the backup was completed succcessfully or not.
I also think eu1 has posted info about what Amon_RA's custom recovery might have a log file...not sure if it necessarily pertains to the Nandroid backups... I'll try to dig that up when I get home...
Hope this helps! Cheers!
edit: I should add that I don't know that not having the nandroid.md5 file will cause the Nandroid restore to fail...I can check on this too (I've think I got the script on my laptop at home). I guess I didn't fully answer your question about whether or not to delete the old Nandroid backups: I don't know at this point...i.e., if they are still "good" or not...more research needed...
Last edited by scary alien; September 9th, 2010 at 01:15 PM.
The Following User Says Thank You to scary alien For This Useful Post:
I'm going to try and make a new nand when I'm fully charged and I'll post back in here and we'll go from there. If my nands don't take it looks like I'm stuck with xtrSENSE...not a bad thing, IMO
I'm going to try and make a new nand when I'm fully charged and I'll post back in here and we'll go from there. If my nands don't take it looks like I'm stuck with xtrSENSE...not a bad thing, IMO
Remember, do a Nand+ext if you have apps2sd in xtrSENSE.
And, just to state the obvious in case you are not getting it, if you do a Nandroid backup while your phone is running xtrSENSE, and then do a Nandroid restore of that backup, when you are done your phone will be running xtrSENSE, even if you have switched to a different ROM since then. You can think of Nandroid backup as a snapshot of your phone at the time that you run the backup, and Nandroid restore as a way to get back to that snapshot and start running again from there.
Just my $.02 I think of NANDROID restore like the restore in Windows which takes your system back to a certain point in time.
Which brings me to a question: Is there a way to set up a NANDROID to do backups on a scheduled basis.
Well, you have to boot into recovery to start/do a Nandroid backup. The custom recoveries actually invoke a script (nandroid-mobile.sh) to do the "dirty" work, but the O/S is only partially booted when this occurs--you want a quiescent system when the backup is being made so that things are not changing).
Technically, I believe this might be possible...things that you normally wouldn't have to change/tweak might require alteration... I'm not sure I'd want my phone taking off and booting itself into recovery...
So I just did a nand backup with my phone at 100% and plugged in via wall outlet and I just checked my BDS directory in Astro and once again the MD5 file is missing? I clicked on the HT9xxxxxxxxx folder, then on my newest backup. Theres 4 files in there, boot, data, nandroid and system. If I click on nandroid it says "file type md5 not found." What's going on here? Why can't I make a secure backup? I'm starting to get very worried not being able to have a backup available
Last edited by WormDoes; September 11th, 2010 at 01:19 PM.
So I just did a nand backup with my phone at 100% and plugged in via wall outlet and I just checked my BDS directory in Astro and once again the MD5 file is missing? I clicked on the HT9xxxxxxxxx folder, then on my newest backup. Theres 4 files in there, boot, data, nandroid and system. If I click on nandroid it says "file type md5 not found." What's going on here? Why can't I make a secure backup? I'm starting to get very worried not being able to have a backup available
I've got the source pulled-up now and am looking at it...got no answers for you yet...
1. The nandroid-mobile.sh script (at least the version I found (#!/sbin/sh echo $* ## # - Nandroid-mobile.sh - Y11YaYyb - Pastebin.com) ), has lots and lots of references to the string "MD5". This may not be the same script that we are using for the Eris...I'm still trying to find "our" version. However, I'm fairly confident that this is representative.
edit: the Eris-specific version can be found below in this post: I Messed Up..???
2. The Nandroid backup command that Amon_RA's recovery uses is as follows: /sbin/nandroid-mobile.sh -b --norecovery --nocache --nomisc --nosplash1 --nosplash2 --defaultinput 1>&2 By the way, Amon_RA's custom recovery just invokes the script to do the Nandroid backup. All of the logic and error handling and report for the backup is done in the script--not by custom recovery.
3. One restore-related reference implies that a missing "nandroid.md5" file will generate a "error: $RESTOREPATH/nandroid.md5 not found, cannot verify backup data" message (i.e., the nandroid.md5 file needs to be present for a restore).
4. There is code section that will output "Verifying backup images..." and proceed to do an 'md5sum -c nandroid.md5' which causes him to check on each entry listed in the nandroid.md5 file. It the md5sum utility returns a status of "1", it will report "Error: md5sum mismatch, aborting" and cause the scirpt to exit. This is interesting because of what I just tested on my phone. See below:
Code:
# pwd
pwd
/sdcard/nandroid/xxxxxxxxxxx/BDS-20100903-0113
# ls -l -a
ls -l -a
----rwxr-x system sdcard_rw 2621440 2010-09-03 01:13 boot.img
----rwxr-x system sdcard_rw 175395264 2010-09-03 01:14 system.img
----rwxr-x system sdcard_rw 94231104 2010-09-03 01:14 data.img
----rwxr-x system sdcard_rw 131 2010-09-03 01:15 nandroid.md5
----rwxr-x system sdcard_rw 16 2010-09-11 14:54 fake.md5
# cat nandroid.md5
cat nandroid.md5
4268f10529fe277714099544efeb41e7 boot.img
0f51ef7468afcf21ccc6e1d6d5ef4754 data.img
6a65c1b23979e3e6746dc5a8941d6358 system.img
# md5sum -c nandroid.md5
md5sum -c nandroid.md5
boot.img: OKdata.img: OKsystem.img: OK
# echo $?
echo $?
0
#
# cat fake.md5
cat fake.md5
abc123 boot.img
# md5sum -c fake.md5
md5sum -c fake.md5
md5sum: WARNING: 1 of 1 computed checksums did NOT match
# echo $?
echo $?
1
# cat /dev/null > fake.md5
cat /dev/null > fake.md5
# md5sum -c fake.md5
md5sum -c fake.md5
# echo $?
echo $?
0
#
I started an 'adb shell' session and did the following:
a. cd'd to a Nandroid backup folder in my /sdcard/nandroid directory
b. displayed the current contents of the nandroid.md5 file
c. issued the 'md5sum -c nandroid.md5' command and go the expected output (": OK" messages) and a non-error status of "0"
d. displayed a fake nandroid.md5 file I created called "fake.md5" and purposely put an invalid MD5 sum for the boot.img file
e. issued the 'md5sum -c fake.md5' and got the expected warning and non-zero error status
f. I then cleared the fake.md5 file
g. I re-issued the 'md5sum -c fake.md5' command on the empty fake.md5 file and got no warnings and a non-error status of "0". This means that an empty nandroid.md5 file will be considered just as valid as a proper one! It does not check for an empty nandroid.md5 file, which I consider an oversight.
5. On a side-note, there is a logic in the nandroid-mobile.sh script that checks to see that you've got at least 30% charge on your battery. This is enforced unilaterally for a Nandroid restore, but is not enforced for a backup unless the -c (compress) option is used (which is not via Amon_RA).
6. The script also enforces a free-space requirement of 130MB on your /sdcard in order to do a backup.
7. There is a log file that the script writes to that you should be able to check after you do the backup. The log file is /cache/recovery/log. While you are still in recovery and just after you've done the backup, issue an "adb pull /cache/recovery/log recoverylog.txt" command from the Android SDK's tools directory to save it off for later review (I'll try it on my phone and see what kind of stuff is in it).
8. There is an explicit verification of the MD5 sum of the boot partition (and recovery and misc partitions too if they were being backed-up) when they are being backed-up. This check is omitted for when the system, data, and cache partitions are backed-up.
9. Finally, at the end of the backup sequence, the MD5 checksums of the partitions that were selected to be backed-up, are written to the nandroid.md5 file. There is no verification that the source data files (i.e., the boot.img, system.img, or data.img files) are non-zero in size.
So, bottom line: it looks like if you want to know what is going on with your backup, you are going to have to check-out the /cache/recovery/log file or run the nandroid-mobile.sh script manually. I don't think that running it with the --verbose switch will gain you too much since it is not referenced in the backup except for causing the tar command to use its verbose flag to output what files are being backed-up.
I can point you to a post where I've already done this: Flashing Rom, Trackball not working! for reference purposes, of course (i.e., don't do the wipes, flashes, etc.). This thread/post had to do with someone who had trackball problems and eu1 wrote-up a method for flashing a new ROM using adb (pretty cool).
That's all I got (for now). I didn't find a smoking gun or anything, but it was interesting to check out.
Cheers!
Last edited by scary alien; September 17th, 2010 at 05:43 PM.
The Following User Says Thank You to scary alien For This Useful Post:
So I just did a nand backup with my phone at 100% and plugged in via wall outlet and I just checked my BDS directory in Astro and once again the MD5 file is missing? I clicked on the HT9xxxxxxxxx folder, then on my newest backup. Theres 4 files in there, boot, data, nandroid and system. If I click on nandroid it says "file type md5 not found." What's going on here? Why can't I make a secure backup? I'm starting to get very worried not being able to have a backup available
I think that you are all set. The error message is Astro telling you that there is no app on the phone that can run .MD5 files. My phone does the same thing; my Nandroids are all ok. My nandroid.md5 files are all listed as 131 bytes long. If you see that, I'll bet you are ok.
The Following 2 Users Say Thank You to doogald For This Useful Post:
I think that you are all set. The error message is Astro telling you that there is no app on the phone that can run .MD5 files. My phone does the same thing; my Nandroids are all ok. My nandroid.md5 files are all listed as 131 bytes long. If you see that, I'll bet you are ok.
Interesting. After clicking on details it says the file is 131. I'm wondering if the trouble I had with my last backup was because when I renamed the nandroid I left a space in the new filename?? I'm starting to feel a little better now
Wow, I leave for a few minutes to finish updating my overly-long post and doogald figures it all out! w00t!
Anyway, I do have plans to create a quick app that will check-out a Nandroid backup directly and verify that all of the files are non-zero in length and that the MD5 sums all match-up. Its on my to-do list.
Haha, Dooglad to save the day. I greatly appreciate both of your help. The real test will be when I flash xtrSENSE 4.1 when it comes out of beta, set it up, then go back to my newest Nandroid backup. Fingers will def be crossed on that restore
I'm wondering if the trouble I had with my last backup was because when I renamed the nandroid I left a space in the new filename??
That sounds right; it is true that Nandroid restore does not like it when the files have spaces in the names, probably because they are just calling scripts that misinterpret the space as separating the file name from a parameter.
Device(s): Incredible 2, stock 2.3.4
Eris, rooted, with XtrSense
Thanks: 62
Thanked 17 Times in 9 Posts
So, perhaps my following Q has been answered, in that case I apologize.
Now I am XtrSense 4.06.1 with apps2sd and cache2sd.
So I have an EXT3 partiton on the SD card.
I want to move to the new version and not to use the apps2sd and cache2sd BUT using the new cache2cache option.
So my plan is, please correct me if I am doing it wrong:
1. nand backup everything with the EXT partition (where my apps are)
2. Make all Ti backup of apps, settings and system settings.
3. Save all to PC.
4. Download the new ROM to PC.
5. Boot to recovery and remove the EXT partiton (HOW DO I DO THAT so I dont loose that space and it appendec back to the SD card space. ? Do I set its size to zero and or reformat to FAT32?, DO I REFORMAT THE WHOLE CARD?)
6. Wipe all factory reset.
7 Reboot, Copy from PC to the card the saved content of the SD card.
8 Copy the new ROM to the card.
9 Reflash the ROM.
10 Go through the setup step (gmail and sync, etc).
11 Use the Ti backup to restore the apps. (when I saved them there were on the EXT partition. Now I do not have that partition any more. Will they be restored nevertheless?)
So please correct my scheme, I am a bit worried to screw up.
Peter
When *I* made this particular ROM move I didn't remove my ext partition at first, in case I wanted to go back. Unlike a 2.2 ROM this ROM will work with the ext partition there, it just doesn't use it when set up the way you are planning to. That way if you feel the need to go back to the old ROM your partition is still there.
To remove the ext partition you do exactly the same steps you did to set it up, but set both values to zero. You do not need to reformat that fat32 portion of the card. All data on the card will be deleted, but it looks like you've taken that into account.
Yes, TI will restore your apps even though they no longer 'belong' on the ext partition.
Device(s): Incredible 2, stock 2.3.4
Eris, rooted, with XtrSense
Thanks: 62
Thanked 17 Times in 9 Posts
Quote:
Originally Posted by mhotovec
Peter
When *I* made this particular ROM move I didn't remove my ext partition at first, in case I wanted to go back. Unlike a 2.2 ROM this ROM will work with the ext partition there, it just doesn't use it when set up the way you are planning to. That way if you feel the need to go back to the old ROM your partition is still there.
To remove the ext partition you do exactly the same steps you did to set it up, but set both values to zero. You do not need to reformat that fat32 portion of the card. All data on the card will be deleted, but it looks like you've taken that into account.
Yes, TI will restore your apps even though they no longer 'belong' on the ext partition.
mhotovec, thanks for the fast reply.
Perhaps it is prudent to leave the ext partion in place just in case, as you suggested.
Now in this case when I restore the apps with the Ti backup, will they go automatically to this ext partition (where they were saved from)?
Peter
Just to put a cap on the nandroid-mobile.sh script from before...
I booted my Eris into custom recovery and pulled the /sbin/nandroid-mobile.sh script: nandroid-mobile.zip
Interestingly enough, this file is not present while the phone is booted normally...(I'm assuming that the act of booting into custom recovery must place this file in /sbin temporarily, but I couldn't find such a reference in Amon_RA's recovery source code).
Anyway, this version is different (but very similar) to the pastebin version I posted earlier.
It just nice to have this for future reference. Cheers!
The Following User Says Thank You to scary alien For This Useful Post:
Perhaps it is prudent to leave the ext partion in place just in case, as you suggested.
Now in this case when I restore the apps with the Ti backup, will they go automatically to this ext partition (where they were saved from)?
Peter
Peter
I can't say for SURE, but I'd bet a fair amount of money (50 cents) that the apps will be saved in the phone rather than on the card. While TI remembers your apps and their data, I believe it's the phone setting that will control where the apps are actually restored to.
The Following User Says Thank You to mhotovec For This Useful Post:
Interestingly enough, this file is not present while the phone is booted normally...(I'm assuming that the act of booting into custom recovery must place this file in /sbin temporarily, but I couldn't find such a reference in Amon_RA's recovery source code).
There are two bootable linux/android "images" on the phone: boot.img, and recovery.img (held in raw format in the boot and recovery flash memory (MTD) partitions). Never the twain shall they meet - by design.
For stock releases, the compressed kernel is identical between the "boot" and "recovery" images, but is duplicated between the two partitions for rather obvious reasons - you don't want corruption of the OS boot to kill off the recovery boot as well.
Think of it this way: the kernel creates a "virtual" file system in system RAM that starts at "/", and has a bunch of folders and files which are also virtual (in the sense that they reside only in RAM); these files and folders get populated by the kernel from the contents of the ramdisk. When the regular OS starts up, it creates this virtual file system, and then "mounts" a bunch of file systems on top of it - some of which are "real", (as in "backed up by non-volatile flash memory") such as /system, /data, and /cache, and some of which are also virtual, but use different memory-based storage formats, such as /proc, /sys, /tmp, et cetera. Note that one of the folders, namely: /sbin is not a mount point, so everything that you find in /sbin in either the recovery boot or the regular OS boot comes with the ramdisk that is part of the (respective) bootable image file.
When Amon_RA starts up, it is more or less self-contained - the only "real" file system that it mounts by default is /cache, and the reason that it does so is for compatibility with the stock Android recovery boot (the OS or the bootloader can place commands that the recovery binary /sbin/recovery interprets that are stored in /cache/recovery/command - that is one way that the different boots can "communicate" with each other across a reboot cycle).
Hope that explanation helps,
eu1
PS There is one other thing about Amon_RA which is a little bit interesting. You will note that you can use commands such as "ls" and "grep" from within the (adb) shell with Amon_RA recovery booted - but if you examine the "PATH" variable, you will find that
PATH = /sbin
and while you will find things in there such as "nandroid-mobile.sh", you won't find "ls" or "grep"... they are all "built-in" to the adb shell. Sort of like a combination of "sh" and "busybox", where "sh" understands a bunch of "built-in" commands which are not usually part of a bash, (ash, or bourne) shell.
__________________
Please don't send me PMs - post your questions so others may benefit from any answers given.
The Following User Says Thank You to erisuser1 For This Useful Post:
I tried finding the nandroid-mobile.sh referencs in init.rc and other various places since I didn't know about the compressed mini-kernel. This must also explain why you would want to do it this way--i.e., you don't want a "live" filesystem mounted that Nandroid would backup due to wanting to preserve the integrity of the files and filesystems being saved.
I didn't look at the PATH variable or explore too deeply ...this was really only my second time exploring via adb while booted into recovery (thanks for that, too!).
Thanks again and we missed your presence around here for the past couple of days...hope all is okay.
I posted this Help please, can't nandroid restore :( earlier this evening and wanted to re-post here so that this additional Nandroid backup and restore information was all linked together in one thread. The post had to do with listing most all of the exit status values from the Eris' nandroid-mobile.sh script.
Anyway, I could copy/paste that information again here if anyone thinks it would be helpful. Let me know.
The HTC Droid Eris launched for Verizon Wireless on November 6th in part as the carrier's first Android Phone. However it was overshadowed by the other member of the inaugural Verizon Droid duo - the Motorola Droid. The Droid Eris might look fa... Read More
I Messed Up..???
.
), has lots and lots of references to the string "MD5". This may not be the same script that we are using for the Eris...I'm still trying to find "our" version. However, I'm fairly confident that this is representative.
I'm starting to feel a little better now
w00t! 
...this was really only my second time exploring via adb while booted into recovery (thanks for that, too!).
