Yes, /efs is /factory and it's mounted on different device but I don't see while they suggest to recreate whole partition from scratch. You can just do renaming in place. Have you checked that your /factory directory is really corrupted (ie. files there have wierd sizes, dates, or it doesn't even mount)?

Another interesting thing to do is look at messages in /data/radio/log/nv.log (# cat /data/radio/log/nv.log as root). It may contain some clue as to what's happening...

I'm having the same issue with a customer's phone.

http://forum.xda-developers.com/show....php?t=1643015

From what I can see, /factory is intact. Same as with OP, the phone was completely stock and the customer denies rooting it or even unlocking the bootloader. He said it occurred when swapping SIM cards internationally, then returning to the states. Unlike OP, I haven't been able to get the IMEI to come back at all.

At this point, I'm not even sure if JTAG will be able to save it.

Does anyone think it could be hardware related?

Originally Posted by jup007

Yes, /efs is /factory and it's mounted on different device but I don't see while they suggest to recreate whole partition from scratch. You can just do renaming in place. Have you checked that your /factory directory is really corrupted (ie. files there have wierd sizes, dates, or it doesn't even mount)?

Another interesting thing to do is look at messages in /data/radio/log/nv.log (# cat /data/radio/log/nv.log as root). It may contain some clue as to what's happening...

yes, i also think that is too much work to just rename two files, but since i have tried many things and nothing seems to work and this fix looks to solve the problem to many people in gsII, i decided give it a try...

and to be honest, files look just fine, same date and size as its relative .bak!

Originally Posted by Naezor

I'm having the same issue with a customer's phone.

http://forum.xda-developers.com/show....php?t=1643015

From what I can see, /factory is intact. Same as with OP, the phone was completely stock and the customer denies rooting it or even unlocking the bootloader. He said it occurred when swapping SIM cards internationally, then returning to the states. Unlike OP, I haven't been able to get the IMEI to come back at all.

At this point, I'm not even sure if JTAG will be able to save it.

Does anyone think it could be hardware related?

have you tried to remove the battery for like 5 minutes? the problem looks exactly the same as your customer... it's really weird. I was all stock (only unlocked bootloader).

in my case, i can't believe it's a hardware fault, since i can make "imei, phone number, baseband, etc." come back...

the strangest thing is when imei, baseband, etc... are okay i have to set "2g only", because if i try to use 3g, network signal drops and only come back after i remove the battery for the usual 5 minutes!!

if a let 3g on and don't try to actually use the internet it stays okay, but if i open the browser and star loading a page, i.e, that's it, no signal at all...

Well, what does

# cat /data/radio/log/nv.log

say? This is log file where normally radio daemong logs unusual things...

EDIT: Btw, I've seen unknown IMEI when nv_data.bin has broken access rights (it's not accessible by radio).

"no such file or directory"...

how could i know if my nv_data.bin has broken access rights?

Try following 2 commands:

shell@android:/ # ls -la /data/radio
drwxrwxr-x radio    radio             2012-04-20 16:02 log
-rwx------ radio    radio     2097152 2012-05-07 14:49 nv_data.bin
-rwx------ radio    radio          32 2012-05-07 14:49 nv_data.bin.md5

shell@android:/ # ls -la /factory/                                             
-rwx------ radio    radio     1048576 2012-04-20 03:13 .nv_core.bak
-rwx------ radio    radio          32 2012-04-20 03:13 .nv_core.bak.md5
-rwx------ radio    radio     2097152 2012-04-20 03:13 .nv_data.bak
-rwx------ radio    radio          32 2012-04-20 03:13 .nv_data.bak.md5
-rwx------ radio    radio           1 2012-04-20 03:13 .nv_state
drwxr-xr-x radio    radio             2011-01-03 15:26 bluetooth
-rw------- radio    radio         640 2011-01-03 15:26 hdcp.keys
drwxrwxr-x radio    radio             1999-12-31 16:02 imei
drwx------ root     root              1969-12-31 16:00 lost+found
-rw------- radio    radio        4674 2012-04-20 03:13 nv.log
-rwx------ radio    radio     2097152 2012-04-20 03:13 nv_data.bin
-rwx------ radio    radio          32 2012-04-20 03:13 nv_data.bin.md5
drwxrwx--- system   radio             1999-12-31 16:00 wifi
-rw-r--r-- radio    radio         144 2011-01-03 15:26 wv.keys

And see how much results differ. Times will be different, sizes and owners should probably be same. Although in your case, you may not have /data/radio at all, since you don't have log file.

well, i noticed that /factory was totally messed up due my attempt to fix it. I retore and fix permssions to looks just like yours but for a strange reason i can't restore .nv_data.bak and .nv_data.bak.md5 through root explorer...



in any case, even with /factory without almost all files inside the issue was exactly the same and i was able to make radio works with the "battery remove" workaround...

edit: exactly same problem, but now with a generic imei! =o)

i'm gonna restore my backup when get in home...

Originally Posted by thiagodark

well, i noticed that /factory was totally messed up due my attempt to fix it. I retore and fix permssions to looks just like yours but for a strange reason i can't restore .nv_data.bak and .nv_data.bak.md5 through root explorer...



in any case, even with /factory without almost all files inside the issue was exactly the same and i was able to make radio works with the "battery remove" workaround...

edit: exactly same problem, but now with a generic imei! =o)

i'm gonna restore my backup when get in home...

Your /factory still as wierd permissions. Most of the files are owned by root and are not readable by radio, which will cause problem. This is probably result of restore. You made nv_data.bin owned by radio, but without accompanying nv_data.bin.md5 system will just ignore it and probably give you generic IMEI, which is what we were seeing here when md5 files didn't match bin files.

Anyway, generic IMEI looks promising. We know how to fix generic IMEI if you have backup of /factory - so please don't loose it.

So yes, restore /factory, fix the permissions

# cd /factory
# chown radio.radio .*

and try checking the log file in /data/radio/log again. Since you have the directory, I still think there must be something in there.

done, restored factory from backup, what was strange is that even after all files restored. with right permisions and with right owner, the generic imei remained and i had to install f*ckdocomo.apk to get it back...

now i just have the original problem =o)

i really didn't have any file inside /data/radio path before, but now it has a log and i believe is due the /factory problem and not related with the original problem

anyway, that's log in /data/radio/log

9 09:44:21 2012: MD5 is turned on.

Wed May 9 09:44:21 2012: truncate 10276 -> 5156 bytes
Wed May 9 09:44:33 2012: __refresh_md5_file: Can't open /factory/nv_data.bin.md5. Permission denied.
Wed May 9 09:44:33 2012: MD5 is turned on.
Wed May 9 09:44:44 2012: __refresh_md5_file: Can't open /factory/nv_data.bin.md5. Permission denied.
Wed May 9 09:44:44 2012: MD5 is turned on.

REPEAT FOR A LONG LONG TIME AND THEN I RESTORE FILES IN /RECOVERY copying files from sdcard

Wed May 9 09:53:20 2012: __refresh_md5_file: Can't open /factory/nv_data.bin.md5. Read-only file system.
Wed May 9 09:53:20 2012: MD5 is turned on.
Wed May 9 09:53:31 2012: __refresh_md5_file: Can't open /factory/nv_data.bin.md5. Read-only file system.
Wed May 9 09:53:31 2012: MD5 is turned on.
Wed May 9 09:53:43 2012: __refresh_md5_file: Can't open /factory/nv_data.bin.md5. Read-only file system.

REPEAT FOR LOOOONG TIME AND THEN I RESTORE MY .IMG BACKUP AND USE F*UCKDOCOMO.APK

Wed May 9 14:24:50 2012: /data/radio/nv_data.bin does not exist.
Wed May 9 14:24:50 2012: MD5 fail. orignal md5 'f6afbceb74ee4290c4563e046f24' computed md5 '6ec535b7b029665813c18d6283c7' (rild)
Wed May 9 14:24:50 2012: MD5 fail. orignal md5 '861f9436276afbcbdc44f58d473a' computed md5 'de37d01ec798841e4944ee69cf5f' (rild)
Wed May 9 14:24:51 2012: default NV restored.
Wed May 9 14:26:07 2012: /data/radio/nv_data.bin does not exist.
Wed May 9 14:26:07 2012: /data/radio/nv_data.bin does not exist.

oh, and i think all files is just fine in /factory path, but no fix at all.

i start to think it should be a hardware fault...

This is after fdocomo v3, right? So your files get rebuild from what's in the factory and you still get what, unknown IMEI? This may also be that files in factory are simply broken and were broken before backup. They contain IMEI, so if something happened to them, this would show as such problem. However, if /factory is lost, I don't know how to fix it. There are things worth trying though - you may try restoring nv_data files from nv_core files, which is actually pretty simple if you have busybox. With rw mounted factory and airplane mode on, do:

shell@android:/factory # cd /factory
shell@android:/factory # rm nv_data.bin*
shell@android:/factory # rm .nv_data.bak*
shell@android:/factory # rm /data/radio/nv_data.bin.*
shell@android:/factory # ls -la
-rwx------ radio    radio     1048576 2012-04-20 03:13 .nv_core.bak
-rwx------ radio    radio          32 2012-04-20 03:13 .nv_core.bak.md5
-rwx------ radio    radio           1 2012-04-20 03:13 .nv_state
drwxr-xr-x radio    radio             2011-01-03 15:26 bluetooth
-rw------- radio    radio         640 2011-01-03 15:26 hdcp.keys
drwxrwxr-x radio    radio             1999-12-31 16:02 imei
drwx------ root     root              1969-12-31 16:00 lost+found
-rw------- radio    radio        4674 2012-04-20 03:13 nv.log
drwxrwx--- system   radio             1999-12-31 16:00 wifi
-rw-r--r-- radio    radio         144 2011-01-03 15:26 wv.keys
# busybox killall rild

wait lets say 30 secs

shell@android:/factory # ls -la
-rwx------ radio    radio     1048576 2012-04-20 03:13 .nv_core.bak
-rwx------ radio    radio          32 2012-04-20 03:13 .nv_core.bak.md5
-rwx------ radio    radio     2097152 2012-05-10 00:34 .nv_data.bak
-rwx------ radio    radio          32 2012-05-10 00:34 .nv_data.bak.md5
-rwx------ radio    radio           1 2012-04-20 03:13 .nv_state
drwxr-xr-x radio    radio             2011-01-03 15:26 bluetooth
-rw------- radio    radio         640 2011-01-03 15:26 hdcp.keys
drwxrwxr-x radio    radio             1999-12-31 16:02 imei
drwx------ root     root              1969-12-31 16:00 lost+found
-rw------- radio    radio        4847 2012-05-10 00:34 nv.log
-rwx------ radio    radio     2097152 2012-05-10 00:34 nv_data.bin
-rwx------ radio    radio          32 2012-05-10 00:34 nv_data.bin.md5
drwxrwx--- system   radio             1999-12-31 16:00 wifi
-rw-r--r-- radio    radio         144 2011-01-03 15:26 wv.keys
shell@android:/factory # cat nv.log
(...)
Thu May 10 00:34:19 2012: NV backup has been rebuilt.
Thu May 10 00:34:19 2012: backup NV restored from Secondary bak.
Thu May 10 00:34:23 2012: MD5 open fail. (No MD5 file) : /data/radio/nv_data.bin.md5
Thu May 10 00:34:23 2012: NV restored.(GED)

What this does is gives rild (radio interface Samsung daemon) chance to rebuid /factory from .nv_core backup. It knows how to do it, but normally can't do it on startup, since /factory is ro mounted. By mounting it rw, deleting files that are broken and killing daemon (which is service, so it gets restarted by android magicaly almost immediatelly), it gets chance. So try this. If you don't have busybox, just do ps, find rild there and PID number and do kill <PID>.

If this doesn't help, your secondary backup .nv_core.bak is also broken or it's really HW issue. In either case, this would require special tools to fix. But this is worth trying as last resort. I did it on my phone just to test this theory again.

EDIT: And I don't believe it's HW issue. If it was, generic IMEI wouldn't work. But it does for you and generic IMEI is nothing else then nv_data.bin that is hardcoded somewhere in the system to be used if factory doesn't exist. But if your /factory is broken and you don't have backup, you'd still need SPTBox or something similar to generate new files from scratch. So send it to somebody or find some Samsung repair place...