[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] kalisjr:
Hey bro,

As crazy as it sounds there is more than one way to skin a cat when it comes to technology, the information relative to what I posted applies to only those who have a backup of their factory efs which would come from a person's nandroid backup/restore, that was not stated clear in my original post "that's 100% my bad" and that insight will keep me on my toes to ensure more detail is given so as to avert the perception it's not misleading or mis-guided or over even un-sourced or under researched.

As I did research on this I found the link to which you are referring along with a ton of other links from other sites which use various different methods and tools to accomplish successful resolution to this problem and it's many causes

prior

to even posting this potential resolution.

I decided like many people who do this for a living to take the "low hanging fruit first" approach meaning to try the easier methods to test before delving into the more complex ones, sometimes people don't need brain surgery for headache if you can see where I'm going.

I chose what appeared to be the best method offered by our internet community considering the skillset of a minority out here who have less experience; as a first attempt to resolve this.

I planned to take the next method and so on and so on until the issues were resolved using the most complicated means as last resort. Before recklessly posting anything I obviously needed to test what I had found on other forums they guaranteed was a solution.

So in doing do I deleted the files in my efs folder/partition after taking a backup and performed a flash using the standard build ROM published in the OP

again with an empty efs folder/partition

to reproduce the error knowing I had so many other means of recovery at my disposal.

I did the method a little different just because I was curious to see what would happen when I attempted restore/recovery so after this I reinstalled root explorer and browsed to my efs backup folder/partition and copied the whole folder back and rebooted and GUESS WHAT? It worked!!

Then I tried to do it another way because I wanted to simulate a corruption so I opened the critical file nv_data.bin and wrote bogus data to the file and saved it leaving all of the other restored files from my test backup which was nothing more than a copy alone and rebooted.

I found what I expected to and that was effectively a hosing up file to the level of FOOBAR and creating the exact same situation as my first test situation successfully producing the no IMEI condition. I then proceeded to browse once again to my backup and overwrote the corrupted files and rebooted and once again GUESS WHAT? It worked again!!!

The next test was with a format of internal sd and as many know the install of the ROM recreates the efs but in my case I did the test again and again it worked.

Now so everyone understands where I am coming from and I calculated the facts. For starters people have a backup with a means to restore their no IMEI condition from both nandroid and the manual backups I instructed people to do. And second as I have read from many of the affected members posts about their phones as they report; when they run their backup from nandroid to restore the previous ROM the IMEI issues do not exist or goes away.

This tidbit of information was the initial inspiration for seeking a simpler method of resolution therefore trying to provide a quick and easy way which worked for me on 5 different test iterations based of the steps I have provided above.

The only one trump card I could think of in my mind is that I am using a different model of SGS3 (SGH-I747) not the M variety most of those affected here own. So if it turned out not to work for them as it did for me I would have defaulted to more the aggressive means of resolution finding a solution which might produce a result for them.

But during my contemplation I thought but what if it did work, let me find out because I had to know if it could really be that simple? Many others sites which claim to resolve this issue have fully respected the impressive methods outlined in the link you suggested.

But again experience has always taught me what knowledge can't and that is there are more ways to get a problem solved then what text books teach and it's been the pinnacle of success in my career as technical professional. For the status quo say knowledge is power, but reality says knowledge is powerless without application things must be tested to see if they be true or false. And reality also teaches technical professionals there are two kinds of truth absolute truth or relative truth where the later kind mostly distorted by the perception of a thing not the reality of it.

The perception of the affected users would naturally develop a mental bias when presented multiple technical options for not using a more complicated method and could deceive them into thinking since the proposed solution didn't require much effort it must not a really legit fix and therefore it can't be trusted.

Now when you use the many testing methods and tools available to verify which I assume all would do after execution of any chosen steps from the forum exactly as recommended all would have achieved just as much confidence with a simple outcome producing a valid and passing test as much as a complex series of steps would. So to me it's a matter of how much effort you are willing to take, but on the other hand if the simple steps first all end in failure you have now spend 10 times as much time as you would have if you had of started with the most complicated option, not saying the link below has that level of burden on folks but it's really a gamble and the only positive which comes from it is that we all learn what is really possible and what is not to a certain degree.

Many of the problems with MMS out here I have never had when doing the installations yet others do?? What gives??

To me it does not matter but when others wonder why did he tell me to delete the feature.xml file seems kind of shady one would have to know the architecture of android and the options, because when porting to reduce conflict I chose to define the settings in the others.xml and if you have the feature.xml defining the same settings you get conflicts and this will cause force closing as they are seeing.

Once I realized that file made it into this build I had figured out what was causing the issues everyone was complaining about.

So if others now choose to not do the steps which I have managed to have success with that's fine, I support that 100% and make no mistake about it I am for what solves the problem with the least amount of grief.

The link below would have been the next steps suggested if the affected users found no real resolution with the steps I tested to work.

http://xdaforums.com/showthread.php?t=1801997

This link is the one which caused me to try the series of steps that I did and ulitmatly lead to the proposal.

http://forum.samdroid.net/f60/tutorial-remounting-restoring-backup-efs-partition-3600/

It takes a greater degree of faith to even engage in what we all do out here, and I fully respect proven methods and those would not be proven by me but rather by the greater group amongst us.

Thanks,

Jk

In the future I’ll make sure to offer the most popular option in addition to what I propose as potential fixes and sincerely appreciate that people out here care enough about others that they would advise against something for the sake of their own good, and that’s awesome, I strive to do no less for them.