Related
This is a general CWM question but I could not find any place better to post on XDA, so excuse this if incorrect location.
I have flashed all the Skyrocket ICS roms in the past few days to see which I liked best. Before I flashed a new one, I would make a CWM backup of the current one. Wanting to easily be able to identify the files, I appended the rom name to the end of the CWM filenames after deleting all the characters after the date, which appeared to be a GMT time stamp. Now, when I try to restore any of those files, I get an MD5 checksum error. I am only assuming that this is due to changing the filename and not some other problem. Anyone have any ideas on how to fix this? TIA.
phoneturf said:
This is a general CWM question but I could not find any place better to post on XDA, so excuse this if incorrect location.
I have flashed all the Skyrocket ICS roms in the past few days to see which I liked best. Before I flashed a new one, I would make a CWM backup of the current one. Wanting to easily be able to identify the files, I appended the rom name to the end of the CWM filenames after deleting all the characters after the date, which appeared to be a GMT time stamp. Now, when I try to restore any of those files, I get an MD5 checksum error. I am only assuming that this is due to changing the filename and not some other problem. Anyone have any ideas on how to fix this? TIA.
Click to expand...
Click to collapse
Are you talking about the folder name? Because that shouldnt affect it. Inside the folder that is created for each backup, there are backup files which dont have any dates/times in the filename itself.
I vaguely remember reading about this, but I can't recall how it was resolved. Try updating your can to 5.5.0.4 Touch or 5.8.1.3 (?? something along those lines) and seeing if that resolves it. Outside if that I must ask the obvious, did u Google "md5 checksum error cwm"?
Are you using the same CWM version as you did when you backed up? If you didnt, then thats one reason. You have to stay on the same CWM version, many of these CWM versions floating around have different fixes in there.
One way around this is to go to Advanced Restore and restore all the IMG files from there.
Dixit
ihtfp69 said:
I figured I would post this fix here in case anyone else ran into this problem. This is assuming you did not change the folder names and let Clockworkmod create them. I haven't had it happen until today, but it's not a nice message to see when you are trying to do a restore.
Code:
Checking MD5 sums...
MD5 mismatch!
Do this to fix:
To fix this problem use the code below. Substitute the final folder name for the backup you need to fix.
Code:
adb shell
# cd /sdcard/clockworkmod/backup/2010-06-29.20.22.53
# rm nandroid.md5
# md5sum *img > nandroid.md5
When that finishes, re-run the restore and everything should be fine.
NOTE: As rpearl stated, there could be something really wrong with your nandroid, so use this tutorial as a learning experience and not a fix-all. In my case, everything was fine after restoring. However, that may not always be the case. Do this with caution.
Click to expand...
Click to collapse
Use this method to potentially fix.
dixit said:
Are you using the same CWM version as you did when you backed up?
Dixit
Click to expand...
Click to collapse
That is correct on most of them. I updated to CWM Touch for the last one, but it did not restore either. To check this out, I just did a backup and without changing the name did a restore and it worked fine. The thing that was odd in the backups that would not restore was that it immediately bombed out of the checksum each time as if it was checking the name itself first.
That is brilliant. I did not realize you could generate the MD5 from ADB and stick it right into the folder. Thanks!
The few times this md5 mis-match has happened to me was because (a) the backup was actually messed up (check folder size) probably due to corruption or (b) my SD card was out of space. I've always renamed my backup set similar to yours (I append the ROM name) and it never affects the restore.
bdbx18 said:
The few times this md5 mis-match has happened to me was because (a) the backup was actually messed up (check folder size) probably due to corruption or (b) my SD card was out of space. I've always renamed my backup set similar to yours (I append the ROM name) and it never affects the restore.
Click to expand...
Click to collapse
Are you using touch or standard CWM? I wonder if this only happens in touch version. I will try this in the next few days.
I changed the name of one of the backups I created with CWM touch and it restored fine using touch. I suppose my earlier problem may have been trying to restore a backup created with old CWM using touch version.
well since you are on the subject cwm touch im making a nanadroid backup of my current ics rom right now as i speak. i started about an hour ago and its still on the backing up data part. when i used the older version to make backups i dont remember it taking this long. have any of you had cwm touch take well its been a little over an hour now? i do have more apps on my phone now than i did the last time i made a backup would that matter? should i just jerk the battery out and go back to the older version of cwm i was using? thanks ahead of time for any advice / help you may give i would appreciate it. im trying to backup this rom cause i want to flash a different modem cause the ics modem form the leak is crap and need a backup in case it dont work..
garydv2002 said:
well since you are on the subject cwm touch im making a nanadroid backup of my current ics rom right now as i speak. i started about an hour ago and its still on the backing up data part. when i used the older version to make backups i dont remember it taking this long. have any of you had cwm touch take well its been a little over an hour now? i do have more apps on my phone now than i did the last time i made a backup would that matter? should i just jerk the battery out and go back to the older version of cwm i was using? thanks ahead of time for any advice / help you may give i would appreciate it. im trying to backup this rom cause i want to flash a different modem cause the ics modem form the leak is crap and need a backup in case it dont work..
Click to expand...
Click to collapse
If you are using sk8erwitskil version of the CWM touch (ClockworkMod TOUCH 5.5.0.4 v3.5) then most likely you didnt follow one of the directions on the front page. This is a known issue. Here it is again. You need to create that file on the location you backing upto.
For CWM to recognize the .hidenandroidprogress file you need to boot into CWM and go to mounts and storage>>mount /sdcard then go back to backup & restore and make a restore and it should work everytime (as long as you do the steps in that order and you have the .hidenandroidprogress file in /sdcard/clockworkmod & /sdcard/external_sd/clockworkmod folders)
There is a known bug in ClockworkMod 5.5.0.4 that long file names can POSSIBLY cause backups to hang. There is a solution/workaround:
•boot into recovery
•try to make a backup (no matter if it passes or fails proceed to next step)
•either through terminal emulator or through adb run the following command EXACTLY:
Code:
touch /sdcard/clockworkmod/.hidenandroidprogress
•if you are backing up to external sdcard then run the following:
Code:
touch /sdcard/external_sd/clockworkmod/.hidenandroidprogress
im using 5.8.1.3 hercules that i got from the dev section. is this a known issue with it to?
garydv2002 said:
im using 5.8.1.3 hercules that i got from the dev section. is this a known issue with it to?
Click to expand...
Click to collapse
Not sure, I used that for awhile but then went back to the other touch and Ive had those two files still in my directories.
I would go ahead and create those two files (one for internal SD and one for external SD if you got one you are using that is) and try it again. Make sure you call that file exactly the way it is, or copy/paste the code identically if you do it through ADB.
Dixit
garydv2002 said:
im using 5.8.1.3 hercules that i got from the dev section. is this a known issue with it to?
Click to expand...
Click to collapse
I use that one, takes less than 5 minutes on my class 10 sd.
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
Well the crazy thing is after sitting there over an hour waiting I finally took out the battery and even though it never said complete all the files are there but I still don't trust that it made a good backup so I deleted those files tried putting in the code above and it still would not work so I flashed back to version 5.0.2.0 thats not touch and it made a perfect backup in under 2 minutes. Might be one of those it just ain't gonna work right on this specific phone thing or it could be the little green gremlins at it again lol... who knows.. I'll just wait for new version of touch to come along and try it. It won't be long till a newer greater version comes along as fast as technology is going today.. thanks for the help. I'm learning more and more each day from you guys on xda.....
Sent from my SAMSUNG-SGH-I727 using XDA
Not sure if this is the cause of the issue but for nandroid backups you can't make a folder name with spaces otherwise you will get an md5 sum error. Try renaming the folder with underscores instead of spaces
Initial phone stats: DS Mod 1.55.531.3, hboot 1.45.0013, s-on/unlocked via HTC unlocker.
I'm trying to update my own phone to 1.63.531.2 via the PG59IMG.zip file found here, http://forum.xda-developers.com/showpost.php?p=17424340&postcount=24 , but I'm running into problems applying this update and keeping it after restoring a Nandroid backup. It would be a huge amount of work to set up my phone from square one, and I'd like to avoid the process if at all possible.
The steps I've followed (twice, now, with no joy) are the following:
* apply the update through the PG59IMG.zip
* flash CWM 5.0.2.7
* flash Superuser
* restore most recent Nandroid backup
* flash 1.63.531.2 boot image (for wi-fi fix)
And this puts me back at my starting point, with the 1.63.531.2 update not applied.
I know I'm going about this the wrong way, but I can't figure out the correct method to make this work. The fact that I flashed the DS Mod 1.55.531.3 ROM back after unlocking might have something to do with this, however, I just can't nail down why. Really could some help to make this work.
TIA for any suggestions --
--
KingCheetah
hey, real quick, after flashing the 1.63.531.2 update, instead of restoring your full nandoid of 1.55.531.3, go to 'advanced restore', choose that nandroid, and choose only 'restore data'. that will put all your apps and data onto the new update, rather than flashing you all the way back to what you had before.
you could also backup and restore your data with an app called Mybackup Root, or some people use Titanium Backup. I personally like using the advanced data restore in CWM, or else Mybackup.
Yogi, I thought your suggestion would be a smoking gun. However, I'm having the same problem as described in this thread: http://forum.xda-developers.com/showthread.php?p=25431819#post25431819
Might you have any suggestions for addressing the md5 problem? I'm coming up empty...
Thanks for your help --
--
KingChetah
yeah, come to think of it, I've had that problem before as well. did you try what xmc suggested? also, perhaps try the Modaco 4.0.0.9 version of CWM to do the advanced data restore... if my memory serves me, I have had more success overall with that version. unfortunately that's about all I got!
the other sugestion would be to flash your full nandroid, then use Mybackup Root to back everything up. then after updating, DL the app again and restore.
good luck and keep us posted!
yogi2010 said:
yeah, come to think of it, I've had that problem before as well. did you try what xmc suggested?
Click to expand...
Click to collapse
Yes, and for the backup I want to restore, all the md5s are the same between the files and what is listed in the nandroid.md5 file. So, the method XMC suggested really doesn't do anything.
yogi2010 said:
also, perhaps try the Modaco 4.0.0.9 version of CWM to do the advanced data restore... if my memory serves me, I have had more success overall with that version. unfortunately that's about all I got!
Click to expand...
Click to collapse
Hmm, okay, I'll give that a try. Weird that CWM 5.0.2.7 has this problem. Also frustrating.
yogi2010 said:
the other sugestion would be to flash your full nandroid, then use Mybackup Root to back everything up. then after updating, DL the app again and restore.
Click to expand...
Click to collapse
I'll keep this as the last resort, because I'd rather not have to download an app for just this purpose. Nandroid backups have served me fine so far. Call me a minimalist.
I'll try Modaco and see what happens. Thanks much for the idea to try.
--
King Cheetah
Sadness
Using Modaco didn't work. Although the Advanced Restore sees the file and appears to run successfully, it says it can't find a data.img file and an Android.img file, so it doesn't restore the info.
So, I guess it's down to trying Mybackup Root and see what happens. Getting tired of redoing this process over and over.
Why can't things "just work" in these situations?
--
KingCheetah
check the other thread....problems with restoring backup
---------- Post added at 05:11 PM ---------- Previous post was at 05:08 PM ----------
or actually...just flash the data.img through fastboot....its ten times easier
but the data.img in the same directory as adb and fastboot....then run the two commands with your phone in the bootloader
fastboot erase data
fastboot flash data data.img
xmc wildchild22 said:
or actually...just flash the data.img through fastboot....its ten times easier
but the data.img in the same directory as adb and fastboot....then run the two commands with your phone in the bootloader
fastboot erase data
fastboot flash data data.img
Click to expand...
Click to collapse
The problem with this is the file "data.img" doesn't exist in a Nandroid backup. As I stated in my previous message, the Advanced Restore process tossed up a message that the file didn't exist (which is correct).
The files within a given Nandroid backup folder are the following:
.android_secure.vfat.tar
boot.img
cache.ext4.tar
data.ext4.tar
nandroid.md5
recovery.img
system.ext4.tar
From the Advanced Restore problem thread (http://forum.xda-developers.com/showthread.php?t=1624319):
xmc wildchild22 said:
then take the system.img from the 1.63 update and put in replace of the nandroids one....then redo the md5 checksum for the system.img like i had showed before
Click to expand...
Click to collapse
I would love to try this, but since the 1.63 update is a PM59IMG.zip, I can't open it with a zip file manager--it throws up a "central directory not found" error. Unless there's another program besides 7zip that's needed to handle this type of zip file...
Edit: I just realized that, as you can see from the file list above, a Nandroid backup also doesn't have a "system.img" file--it has a "system.ext4.tar," but not "system.img." So being able to pull anything from a PM59IMG.zip file is a moot point at this juncture.
Banging one's head against the keyboard does little constructive good, but it's really tempting at this point --
--
KingCheetah
just try opening it with a plain windows explorer
xmc wildchild22 said:
just try opening it with a plain windows explorer
Click to expand...
Click to collapse
Using the "Explore" option from the right-click context menu in Windows Explorer gives the following error: "The Compressed (zipped) Folder is invalid or corrupted." (Since archive files on my laptop are associated with 7zip, this is the only method by which I can access Win XP's native archive file handling.)
This has been the case with all PM59IMG.zip files--they don't register as normal zip files.
Thanks for the suggestion, though --
--
KingCheetah
hmm...maybe tht zip is corrupted because it works for me....DL this --> http://tinyw.in/Mzg2
Nope, not corrupted because it works just fine to update my phone to 1.63 (as stated before, I've done this twice now). Also, that's the exact same source from whence I downloaded my copy of the file. The PM59MG.zip for 1.55.531.3 gives exactly the same error, and I used that without difficulty as well.
KingCheetah said:
Nope, not corrupted because it works just fine to update my phone to 1.63 (as stated before, I've done this twice now). Also, that's the exact same source from whence I downloaded my copy of the file. The PM59MG.zip for 1.55.531.3 gives exactly the same error, and I used that without difficulty as well.
Click to expand...
Click to collapse
Use winrar to open the PG59IMG.zip files - that's what I used to make all the custom ones with, and also what I used to open the leaked ones we started from.
You won't be able to edit existing leaked ones, because they are locked and have an HTC signature.
Sent from a digital distance.
Thanks for the pointer, Blue, and I'll keep this in mind. But as I added to my previous post (#8), I realized that a Nandroid backup doesn't have a "system.img" file--it has a "system.ext4.tar," but not "system.img." So being able to pull anything from a PM59IMG.zip file is a moot point at this juncture.
I think I'm going to have to wait for a 1.63 ROM that can be installed through CWM rather than the PM59IMG.zip method. The DS Mod 1.55.531.3 worked well for me, and all apps/data were just there after I flashed it. Maybe I just got lucky with the process I followed previously, who knows? (http://forum.xda-developers.com/showthread.php?t=1508406&page=4 post #39)
At any rate, I've got a truly mean headache from working on this all day. Time for a break with a bit of ice on ye old cervical vertebrae.
Thanks again for chiming in --
--
KingCheetah
No prob, didn't read through and shot from the hip on the last post I saw, out at dinner and skimming the forums on smoke breaks
Sent from a digital distance.
does anyone know the deal with the implementation of tar backups? I think that came into play at some point, and I wonder if that has anything to do with anything.
I just checked a backup I made with the Modaco CWM, and the files in it are all .img files, including data. and I know for a fact I have done backups and advanced data restores with that recovery. it would be a hassle, but if you get re-energized you might make the backup and do the restore with Modaco. definitely would be a hassle if it didn't work, but you could also make a backup with Mybackup, and have that ready too, as well as probably have a data.img to try and flash thru fastboot like xmc suggested.
anyway, hopefully we'll get this all sorted out. take it easy!
well .tar are used ever since cwm started working with ext4....maybe imgs are only ext3 or lower or its just inefficient
On that note, I did use the modaco 4.0.0.9 recovery to make the nandroids I pulled the system images from to get the bases from which I de-odexed, and when finished I uploaded to my host and they are the de-odexed bases I posted in dev.
I am pretty sure I went with modaco recovery for that because cwm 5.0.2.7 output tar files and it just saved a step in the process.
If you are working with the .tar files then jump on linux to unarchive them if that's what you are trying to do.
I just ran the deodex process using windows, because the first working deodex tool I found was a windows tool.
Generally I use modaco .9 for nandroids I want to work with in windows, and cwm 5 for nandroids I want to work with in linux.
We're probably leaving the restaurant soon, if we split up I'll actually read back through the thread when I get home and see if I have anything else to add.
Sent from a digital distance.
Yogi, you're brilliant!
yogi2010 said:
I just checked a backup I made with the Modaco CWM, and the files in it are all .img files, including data. and I know for a fact I have done backups and advanced data restores with that recovery.
Click to expand...
Click to collapse
[facepalm] Of course! This is why my Advanced Restore attempt with Modaco failed--because I used the CWM 5.0.2.7 backup, which did not have the files Modaco would have referenced. Duh! I wasn't even thinking along the lines of a file type mismatch between the two recoveries. Baka baka baka...
yogi2010 said:
it would be a hassle, but if you get re-energized you might make the backup and do the restore with Modaco. definitely would be a hassle if it didn't work, but you could also make a backup with Mybackup, and have that ready too, as well as probably have a data.img to try and flash thru fastboot like xmc suggested.
Click to expand...
Click to collapse
At this point, not a hassle, but the best chance to accomplish this thing with a minimum of fuss and bother. I'll give this a shot right after a bit 'o java. Thank you, Yogi, for highlighting something that should have been obvious to me when Modaco gave the error message that "data.img" didn't exist. Oy!
However, this still leaves unanswered the question of why CWM 5.0.2.7 is tossing up the md5 mismatch error when one tries to use Advance Restore, and that files aren't seen by CWM via Advance Restore until one accesses regular Restore. Paperskye is having the exact same problem in this thread: http://forum.xda-developers.com/showthread.php?t=1624319 . Should this be brought to the attention of the CWM devs? It really seems like a rather show-stopping error for CWM...unless Advanced Restore isn't really used with 5.0.2.7 and the MT4GS. There just doesn't seem to be a good reason for the observed behavior.
Many thanks for your encouragement. I'll report back with results on the next try with Modaco --
--
KingCheetah
It's a beautiful thing!
Using Modaco for my backup prior to the update, then Advanced Restore of data afterward = perfect restore of my phone environment with 1.63 on board. Done with as little fuss as I was hoping to encounter. Yogi, you get the prize. The only thing I had to manually put back was my custom boot animation, but that's trivial.
I think I'll just leave Modaco on as my recovery for now, since AR is functional with it and CWM 5.0.2.7 is not. Makes me wonder, from just an everyday backup standpoint, is there any real advantage of CWM over Modaco? I wish there was more information on how the recovery module functions on the CWM website--I'd like to read up on it for educational purposes. Guess I'll do a Google to find more.
So ridiculously happy right now. In a stew of things going wrong, at least something went right.
Big rumbling purr of gratitude --
--
KingCheetah
What is it? Because I want to download the mokeeOS, but the installation is confusing me, so I wanna know if the efs matters
Sent from my SGH-T959V using XDA
1. Yes efs matters a lot
2. I don't know a whole lot but it holds the network info, imei number, and alot of other really important things
Sent from my SGH-T959V using xda premium
Although there is a way to make sure you have a backup, flash this file in cwm
sourceforge.net/projects/teamacid/files/fb/cwm/cm7-efs-backup.zip/download
And there will be two files in the root of your sd card
Efs-backup.tar and efs-backup.tar.md5 ( I suggest save it to your computer, it saved my ass )
And you can restore this backup at anytime by flashing this
sourceforge.net/projects/teamacid/files/fb/cwm/cm7-efs-restore.zip/download
Good luck
Sent from my SGH-T959V using xda premium
Efs is the files system that holds the unique identifiers for your device. Without it, your phone is basically useless. You won't be able to connect to any network properly do things like phone calls, internet, texting, are all degraded, if they even work at all... Make sure you know what you are doing before messing with it. Fb created a vet good guide on the wiki. Follow it to a T!
Sent from my SGH-T959V using XDA
I would suggest using a root browser to copy the EFS folder to somewhere safe on your PC and copy a 2nd back-up to your SD card. I lost IMEI going from CM7 to moKeeOS but was able to easliy restore it with a back-up and a root browser.
The flashable EFS back-up/restore from FB should still be used, but with EFS/IMEI I don't think you can be too careful and backing it up manually as previously stated is a good idea.
Yeah, I keep multiple copies of it on my PC. The reason being is that I copy it whenever I do a backup before a flash. So I have a directory with the date with 3 folders: efs, nandroid, and sdcard. I used adb to copy them:
Code:
cd efs
adb pull /efs/
Probably overkill, but better to be safe than sorry, eh?
Ok, but once you lose IMEI and don't have a backup (I received this phone for repair), then what can I do?
serialteg said:
Ok, but once you lose IMEI and don't have a backup (I received this phone for repair), then what can I do?
Click to expand...
Click to collapse
It's pretty much screwed without the OEM Samsung/Tmo software. You would have to send it to Samsung for repair, or you might get lucky and get an engineer to hook you up, but that is unlikely...
thomas.raines said:
It's pretty much screwed without the OEM Samsung/Tmo software. You would have to send it to Samsung for repair, or you might get lucky and get an engineer to hook you up, but that is unlikely...
Click to expand...
Click to collapse
thanks for the answer. that OEM software isn't available in the forums or anywhere else for us? because I swear I flashed something OEM'ish without root with heimdall.
also, the imei is on the battery part of the phone, can't i fix it?
i read somewhere that you could use a phone just fine without imei on the about phone.
you can use the phone without imei, but it doesn't function as well as it would with it. Also, i was using titanium backup and it said my device's id was changed, and it showed my actual imei. If i were to restore it, would that fix the imei?
EFS help on the SGH-T959V
Basically, I've had a hell of a time with some EFS drama this weekend, made a total noob mistake, but in a stroke of luck I was able to "recover" so to speak my EFS even after it was supposedly "wiped."
After some thorough research and READING and bit of thought, I realized that the PIT mapping layouts between BML and MTD are indeed different, and that in theory if one remaps to BML (in layman's terms a stock partition map) then the EFS data originally on the phone gets correctly remapped (at least in my case it did).
To reiterate:
1. I did a nandroid backup. Basic ****. I hope to god you at least did this step too.
2. I used the cm7-efs-backup.zip script to backup my EFS. This was my first mistake. In my case, I don't know why I'm still researching, this script failed to make a backup .tar on my sdcard or anywhere else for that matter. It didn't throw any error messages either on the screen in the process. Not trying to attack the authors of that script, I'm just saying it didn't work for me this time.
3. I pushed the TWRP boot.img with Heimdall
4. I used the cm7-efs-restore.zip script which also "succeeded" but did nothing to restore any sort of EFS obviously because there was no backup to begin with.
5. I flashed R11 unofficial cm7 and booted up. Everything was fine but the IMEI was corrupted and I confirmed that the new MTD EFS partition was empty. On T-Mobile I could place no calls and only got sporadic and intermittent data access.
It was at this point I was sure I had ruined my phone.
After some more careful reading I realized that the original EFS was still present on the firmware, however the new MTD layout I flashed (wisely) stores its EFS partition in a different physical location. In theory, I thought if I reverted to BML and a stock ROM then I would recover the original EFS. In my case, this was successful.
1. I accessed the most recent "boot.img" file from my most recent nandroid and pushed that back to the device with Heimdall
2. At this point you have to flip your USB drivers back to USB Composite Device.
3. I then used a Heimdall one click to return to a rooted stock KJ6 "Gremlin Remover"
4. Upon restart, everything was fine (sigh of relief)
At this point, I'm still trying to determine why my EFS cannot be backed up with a few automatic tools. I made a backup of the file structure, but even lyriquidperfection's EFS Pro 1.4.7 can't make a backup of the EFS. It can access the ADB Server, but the backup 'fails'.
I'll check back in after I figure out why.
Hopefully this info will help anyone else who has switched to MTD and has a missing EFS.
nick.tansy said:
At this point, I'm still trying to determine why my EFS cannot be backed up with a few automatic tools. I made a backup of the file structure, but even lyriquidperfection's EFS Pro 1.4.7 can't make a backup of the EFS. It can access the ADB Server, but the backup 'fails'.
I'll check back in after I figure out why.
Hopefully this info will help anyone else who has switched to MTD and has a missing EFS.
Click to expand...
Click to collapse
I had similar issues yesterday. If your trying to install the twrp and then downgrade to the version with wifi dont flash the boot.img with heimdall. Follow the instructions for installing via cwm.
Just install the zip that has twrp in it. But follow the directions for normal cwm installation.
Also when trying to make a backup of your efs, make sure system is mounted. I initially did not have any problem but I was on antonx's kernel and when you flash with that recovery it would mount properly. What is happening is system isnt getting mounted. So its making a null backup.
The most important thing to do is when you are trying to make a backup of your efs is mount system!
Hi have you tried the updated EFS Pro v1.7.13? It can now automatically detect the mount point of the '/efs' folder for back up and restore. Also many many bug fixes and new code to communicate with adb.exe alot more quickly and efficiently.
Head over to the forum and check it out.
I already solved this problem, but this would seem useful other people with the same problem. But what forums are you exactly referring to?
Sent from my SGH-T959V using XDA
mierkat09 said:
I already solved this problem, but this would seem useful other people with the same problem. But what forums are you exactly referring to?
Sent from my SGH-T959V using XDA
Click to expand...
Click to collapse
This one.
http://forum.xda-developers.com/showthread.php?p=18524176
Update 9/1/2012: A user has successfully restored with this method! Continue to "Testimonials" for more info!
Update 9/2/2012: TrevE has now come up with a way to leverage Samsung's built-in restore to your advantage! Read below for more!
Update 9/3/2012: Changed adb commands to reduce Operation not permitted problems.
Thanks to the efforts of some great developers, there is now *possibly* a more comprehensive method to backup your IMEI. While I have not personally tested a restore using this method, a user in IRC has done a manual NVRAM wipe and restored it using this method, without the roaming issues caused by a occasionally-bungled QPST restore or manual IMEI injection. In addition, posts in this thread indicate a successful restore from an actual occurrence of the problem, all without the use of QPST and also without any roaming issues!
Before I go any further, the same old disclaimer still applies; you accept all responsibility for what you do to your own device!
Theory:
The theory is that the S3 has, in the boot process, a routine which is "tripped" when it detects an error condition. This routine is designed to "save" your IMEI by restoring images from two built-in backup blocks. The problem is, it actually does the opposite; for whatever boneheaded reason, the default backup blocks contain dummy images with an IMEI of 0 and no carrier identification. This is why your phone forgets what carrier it's on and what its IMEI number is; the restore routine actually overwrites the phone's only copy of the IMEI data with a dummy. Because much more data is lost than just the IMEI, this is also why a QPST injection (not a QCN restore) persistently leaves you on roaming.
In an initial attempt to solve this problem, users have attempted to "dd", or create an image of, a single block supposedly containing the IMEI when the phone is still in a good state. This is the efs.sbn method that you may have seen. However, upon further inspection, it turns out the IMEI data is actually spread across five different block devices, hence why the efs.sbn method is either ineffective or leaves you on roaming! After the block devices were identified, a SynergyROM team member created an easy-to-use recovery zip that allows you to image these five blocks, allowing you to reflash them should the Samsung boot process overwrite your IMEI! Re-flashing these blocks after they've been crapped up virtually ensures your phone has been fully restored to its pre-IMEI-loss condition, thereby preventing roaming or data issues seen consistently with a manual injection, or intermittenly with a QPST restore. You do not need SynergyROM to use this tool; I've done it from full stock.
But wait: there's more. About a week after the development of this tool, several unused boot entry points were discovered that revealed a way to control Samsung's built-in "safety" feature and actually make it work properly! Two backup blocks were put in by Samsung themselves; "fsg" and "backup". The great news is that, although these images may contain dummies by default, you can instruct the bootloader to write your good NVRAM data to them so that the good data is what's written to NVRAM in the event of an error. That is, instead of restoring a dummy image over your good IMEI...it restores a good backup instead and you don't lose a thing! How awesome is that?
Developers are now recommending a new IMEI backup regimen, leveraging Samsung's built-in IMEI backup and SynergyROM's manual backup, together with an optional QCN backup you can do for good measure. Of course I can't make any guarantees, but doing this backup should leave you in such a good spot that almost nothing can total your IMEI or leave you in a roaming state. Here are the new instructions on how to backup your IMEI, iron-clad. Do Parts A and B, in order, C is optional but will give you added peace of mind.
Backup:
Part A (Samsung's built-in backup):
1. If your phone does not have Terminal Emulator installed, you will need to use ADB. Download and install the Android SDK platform-tools for your platform. This is a bit non-trivial as it requires the installation of the Android SDK, however, you can find a guide for installing adb here. After installing, open a command prompt and navigate to the "platform-tools" folder within the SDK, where adb is stored. If you need additional help on this, simply ask in this thread.
If your phone is rooted and has Terminal Emulator installed, you don't need to do any of this. Simply open up the Terminal Emulator and go to step 2.
2. For ADB: Connect your phone to the computer and ensure it is in "Debug Mode" (Settings->Developer Options->USB debugging). Then. in the command prompt, type the following:
Code:
adb reboot nvbackup
For Terminal Emulator: The actual "beef" of the command is the "reboot nvbackup" line. Therefore, if you have Terminal Emulator installed, you can just run the command straight off your phone. Enter these two commands from the app:
Code:
su
reboot nvbackup
3. Your phone will reboot and copy the contents of two IMEI partitions to the two built-in backup blocks. You may see tiny blue text on the bootloader screen indicating that it is copying.
4. Allow it to finish and then reboot back into Android. The "fsg" and "backup" block devices now contain your IMEI information as they should have in the first place.
Part B (SynergyROM's "Plan B" manual backup):
1. Download the attachment at the bottom of this post. This is an update ZIP you can run right from recovery.
2. Reboot into recovery. On stock this can be done by turning off the phone and then turning it back on while holding UP and HOME.
3. CWM: Use VOL UP and VOL DOWN together with HOME to select "install zip from sdcard" then "choose zip from sdcard". Navigate to the folder you downloaded it to (most likely Download/). Select the zip you just downloaded to "flash".
TWRP: Touch "install" and navigate to the folder you downloaded the zip to (most likely Download/). Swipe to confirm flash.
4. Allow the backup to complete successfully. "Flash" is a bit of a misnomer; this is actually just a script that will safely backup your EFS and radio information to /sdcard/synergyrom/backup without touching your ROM at this point. When the script completes, reboot.
Part C: Backup with QPST:
Once the gold standard of IMEI backup, this method (in my opinion) should now be done only in the event of an unlikely complete catastrophe where neither Samsung's built-in restore nor SynergyROM's restore works. Simply follow the instructions here for extreme peace of mind; you don't need to do this if you don't want to, but I personally did.
Restore:
Do not do this unless your IMEI has been lost!
Performing Part A of the backup should ensure that you never lose your IMEI in the first place; the theory being that the Samsung built-in backup now has a good image to restore itself, as opposed to a dummy image. However, things may still happen. If you've still lost your IMEI, perform each of these methods in order of priority, "A" being the first.
Restore Plan A:
Run the following command from adb, just like when you backed up (have Android SDK installed, connect phone, and ensure USB debugging is enabled):
Code:
adb reboot nvrestore
This method triggers Samsung's built-in IMEI restore; except this time, you got good images on your side. Simply allow the phone to restore and reboot itself when completed. NEVER PERFORM THIS COMMAND WITHOUT DOING PART A OF "BACKUP" FIRST; THIS WOULD RESTORE THE DUMMY IMAGES INSTEAD AND WIPE YOUR IMEI!
Restore Plan B:
Sometimes a fluke happens and the nvrestore does not work. That's why this one is Plan B and not Plan A. Good thing you did Part B of "Backup"! Rather than instructing Samsung's bootloader to restore your NVRAM, this method will do so manually from recovery using a manually done backup.
It's just like when you backed up, except now you want to flash the zip containing your NVRAM info that the other zip built for you. This zip is located in /sdcard/synergyrom/backup. Simply navigate to this path and flash the zip beginning with "keybackup"; this will write images to 5 block devices from a time when your IMEI was all good. Reboot the phone; if all went well, you now have your IMEI back with no roaming!
Restore Plan C:
Both methods above may fail you in extremely unlikely circumstances. At this point, you'll need to try using QPST to get your IMEI back. If you did Part C in "Backup", you can follow instructions in that same thread to get you back up and running. In most QPST restores, you shouldn't have any issues with data or roaming.
Restore Plan D:
The planets have lined up, the Cubs have won the World Series, and all three above methods have failed you in what is surely a sign of the apocalypse. Far more likely, though, is that you didn't have a backup of anything and your IMEI is gone for good. The good news is that you can still get your phone working; the bad news is that you'll be stuck on roaming and may have problems with data. You'll need to perform an "IMEI injection" which is a kludgy last-resort restore method that manually writes the IMEI to NVRAM; the link I provided in Part C of "Backup" will tell you how to do it.
Testimonials:
This method has been tested good by the following users in this thread!
amaury48 said:
Just flashed CM10 09-01 nightly and lost data, confirmed I lost my IMEI. I had used the process in the OP a while ago to backup my IMEI. Just would like to confirm that I just flashed the backup it created and happy to report all is well again. Thanks for the post of this tool........saved my butt......
Click to expand...
Click to collapse
alee said:
I'll join the club. Lost my IMEI while doing the latest CM10 nightly. Restored and was back in action in no time.
Click to expand...
Click to collapse
Nght12 said:
Hey, used your backup method and ended up having to use it later in the day. It works. I'd reply but I can't yet due to being a new member here
Click to expand...
Click to collapse
Please continue to let everyone know if this restore has worked for you after an IMEI loss!
Happy flashing!
TrevE said:
The other trickery we ran into is partitions do not like to be written to for whatever reason outside of package_extract_file right outa the zip. dd'ing directly back failed over and over, I have no clue why, poor esc must have flashed 100 zips before I gave up looking into it. So the updater zip restore uses only package_extract_file, actually writing partitions out properly. I have high hopes that it will actually work, but until tested otherwise do as many types of backups as you can
Click to expand...
Click to collapse
Your restore dd commands won't work.
con247 said:
Your restore dd commands won't work.
Click to expand...
Click to collapse
Good catch. I'll revise the guide appropriately.
So will this work on any ROM?
Sent from my SCH-I535 using xda app-developers app
Yeah I'm on stock rom just rooted an cwm. Can I flash this zip an since I don't have synergy, where will the backup be stored?
Sent from my SCH-I535 using xda app-developers app
Worked on CM10.
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Travisimo said:
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Click to expand...
Click to collapse
You nailed it!
Nice, I'm assuming this is similar to what the Synergy ROM team is now including?
nyjumpman said:
Nice, I'm assuming this is similar to what the Synergy ROM team is now including?
Click to expand...
Click to collapse
Its the same. Just a standalone version.
Sent from my SCH-I535 using Tapatalk 2
Confirmed successful backup using CWM.
I can confirm this backup method works using CWM.
I first tried it with TWRP via Goo Manager and the script didn't execute properly.
I tried flashing the file while still in TWRP and I couldn't even find the zip file anywhere, user error I'm guessing.. lol.
So I flashed CWM over TWRP via ROM Manager PRO and flashed the zip file with CWM via ROM Manager PRO and the zip script executed nicely. I found the backed up zip file where the OP said it would be.
Here's to hoping I never have to use the backed up file, but it's good to know I have it there if needed.
Thanks again OP!
xCHPx said:
So will this work on any ROM?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
This should work regardless of ROM as it is a recovery zip. I've tested it with CWM: I've never used TWRP so I don't know how well it would work in TWRP.
tu3218 said:
Yeah I'm on stock rom just rooted an cwm. Can I flash this zip an since I don't have synergy, where will the backup be stored?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
I've tested a backup successfully on full stock, rooted. The backup will be stored in a folder called "synergyrom" but this just the name the tool gives to the directory (as the tool was created by the Synergy team) and has no impact on function or dependency on SynergyROM.
Travisimo said:
I'm all for redundancy of backups, so here's hoping this method fully works when restoring. I have not experience a loss of IMEI myself, but I definitely want to be safe. I know the original efs backup method was proven to be an incomplete backup, but I thought the QPST NV backup method was proven to work? Are you saying that restoring with tthe QPST method (where you have an NV backup before you lose IMEO) does not work and will still having roaming issues?
Click to expand...
Click to collapse
QPST method is not perfect; it is better than a simple IMEI injection, but the boot bug writes crap over much more than just the IMEI. This is why either method may leave you on roaming (althogh a QPST restore only sporadically causes roaming). In addition, various DRM keys may be erased as well, leaving you potentially unable to play back HDCP/PlayReady titles; QPST does not restore these.
At any rate, it will be interesting to see if this is the "one true backup" to rule them all for IMEI. So basically, you flash the zip in recovery and it creates another zip with the backed up contents. And in the event of an IMEI loss, you just flash the new zip and should be good to go? At least, that's the theory, right?
Click to expand...
Click to collapse
That's correct. When you "flash" the backup zip, nothing actually is written to the ROM as far as I can tell; it runs just like a script/batch file and saves your backup zip to /sdcard/synergyrom. The tool itself creates a new flashable zip in this directory, one that does modify your unit, which you can then use only in the event that the bootloader craps up the NVRAM.
Just did this on cm10. Backed up without issue and I see the folder it created. Thank you. I've done qpst as well so now I feel very safe
Sent from my SCH-I535 using Tapatalk 2
hopesrequiem said:
Just did this on cm10. Backed up without issue and I see the folder it created. Thank you. I've doneSame. Thanks for the info.ll so now I feel very safe
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Same
Sent from my SCH-I535 using Xparent Blue Tapatalk 2
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Just did this, thanks!
I now have 3 different types of backups. I feel safe now if I ever lose it.
Safe-r, I should clarify.
Sent from my SCH-I535 using Tapatalk 2
Made my back up on unofficial cm10 0816. Thanks.
Sent from my SCH-I535 using xda premium
tu3218 said:
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
There is no excuse to not be unlocked at this point.
Sent from my SCH-I535 using Tapatalk 2
tu3218 said:
So this requires an unlocked bootloader? I just did this but it skipped because my bootloader is still locked. Is that correct in that it needs to be unlocked for this backup process to work?
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
lol ur still locked???
here. http://forum.xda-developers.com/showthread.php?t=1839791
enjoy bro. now you got no excuces
Stryker1297 said:
lol ur still locked???
here. http://forum.xda-developers.com/showthread.php?t=1839791
enjoy bro. now you got no excuces
Click to expand...
Click to collapse
i know i know lol I've been hesitant because of the IMEI issue and the phone is pretty damn good as is. But I'm slowly leaning towards flashing custom roms to get rid of the bloat, and since there are more ways now to hopefully restore the IMEI in case its deleted.
Currently running beans 13. I have 5 different back ups on my phone and I would like to get rid of a few of them. However, out of the 5, 2 of them I have no idea what rom or setup they are. One, I know is stock rooted and I would like to keep that one. Can I just go into recovery and flash each one to see what it is? I don't want to screw anything up. I just want to know which backups are which
Thanks in advance
Yes, you can do that. Or you could connect your phone to your computer and browse the files with a program like 7zip to see if you can tell what each is without having to flash each one.
putney1477 said:
Currently running beans 13. I have 5 different back ups on my phone and I would like to get rid of a few of them. However, out of the 5, 2 of them I have no idea what rom or setup they are. One, I know is stock rooted and I would like to keep that one. Can I just go into recovery and flash each one to see what it is? I don't want to screw anything up. I just want to know which backups are which
Thanks in advance
Click to expand...
Click to collapse
I am also running Beans b13 and loving it. Im not really sure but might be some way to look and get the details on the nandroid. Im thinking you can find it in my files and long click then select details. Hope this helps
No issues with switching back and forth between saved files.
I think you can also rename your files.
Also if you save your backups as beans13_date, it should be easy to know which files you can remove or keep.
soohyunk83 said:
No issues with switching back and forth between saved files.
I think you can also rename your files.
Also if you save your backups as beans13_date, it should be easy to know which files you can remove or keep.
Click to expand...
Click to collapse
Don't rename the nandroid. It will change the md5 and you will not be able to restore to it. I just save a simple text file on my phone with the last 4 digits of the nandroid and what ROM it was.
Sent from my SCH-I535 using Tapatalk 2
Eric021 said:
Don't rename the nandroid. It will change the md5 and you will not be able to restore to it.
Click to expand...
Click to collapse
I've always renamed mine (especially since there's a bug that gives it a name with a 1970 date), and never had a problem with md5 or restoring.
Same here. I just add the name of the rom at the end.
Sent from my SCH-I535 using xda app-developers app