Issue #2028

Make a script and/or a howto that explains how to rebuild an EFS.img from the files

Added by Denis 'GNUtoo' Carikli 6 months ago. Updated 5 months ago.

Telephony and mobile data
Target version:
Start date:
Due date:
% Done:


Estimated time:
Galaxy Nexus (I9250), Galaxy Note (N7000), Galaxy Note 2 (N7100), Galaxy Note 8.0 (N51xx), Galaxy S (I9000), Galaxy S 2 (I9100), Galaxy S 3 (I9300), Galaxy S 3 4G (I9305), Galaxy Tab 2 10.1 (P51xx), Galaxy Tab 2 7.0 (P31xx), Nexus S (I902x)


tutorial (1.88 KB) tutorial Ama Agne, 05/20/2020 12:00 PM (1.13 KB) Ama Agne, 05/20/2020 12:01 PM
tutorial.txt (1.89 KB) tutorial.txt added .txt to file name Ama Agne, 05/20/2020 12:09 PM

Updated by Denis 'GNUtoo' Carikli 5 months ago

We had a bug with the previous backup instructions as described in the BackupsResearch wiki page.

So some people are stuck with the individual files in /efs having been backed up but without a valid backup of raw EFS partition.

We might need to enable people in this case to recreate a valid EFS partition from the files.

To obtain the necessary information:
  • We can find out which filesystem is used in the EFS by looking at what is used on existing devices. Devices pages sometimes have detailed partition information like here: GalaxySIIIGTI9300 with the filesystem.
  • For the file paths and permissions we can create pages like GT-I9300EFSContent that have the information.

We will then need to create a script and/or instructions on how to recreate such EFS images from the files.

The Replicant 6.0 recoveries also have mkfs.ext4 and similar tools that can help simplifying the process.


Updated by Denis 'GNUtoo' Carikli 5 months ago


Device Partitions and filesystem file permissions
Galaxy S II (GT-I9100) ext4: GalaxySIIGTI9100 GT-I9100EFSContent
Galaxy S III (GT-I9300) ext4: GalaxySIIIGTI9300 GT-I9300EFSContent
Galaxy Note (GT-N7000) ext4: GalaxyNoteGTN7000 GT-N7000EFSContent
Galaxy Note II (GT-N7100) ext4: GalaxyNote2N7100 GT-N7100EFSContent
Galaxy Nexus (GT-I9250) ext4: GalaxyNexusGTI9250 GT-I9250EFSContent
Galaxy Tab 2 7.0 GSM (GT-P3100) ext4: GalaxyTab270GTP31xx GT-P3100EFSContent
Galaxy Tab 2 10.1 GSM (GT-P5100) ext41
Galaxy Note 8.0 GSM (GT-N5100) ext4: GalaxyNote80GTN51xx

1 As I don't have a GT-P5100, instead of looking with "mount", I looked instead at the fstab.espresso. While it's in the espressowifi directory, it's included by, which is included by in the espresso3g directory.


Updated by Ama Agne 5 months ago


Updated by Ama Agne 5 months ago

My I9300's Modem broke and I tried restoring the EFS partition with
a faulty backup image a had from the deprecated procedure mentioned
in BackupsResearch.
I managed to restore my EFS using the files (not the EFS.img) that I had.
Here is a How To and a script that tries to set the file permissions
according to GT-I9300EFSContent which I didn't try restoring the EFS
without fixing them.

Can someone take a look at ""? Maybe someone wants to
improve it. Also after doing the procedure in the How To, I had to
"adb sideload" replicant again, because my phone only booted into the
Recovery anymore. I don't know if that would be a problem, if somebody
didn't have a fresh replicant installation before anyway.


Updated by Ama Agne 5 months ago


Updated by Denis 'GNUtoo' Carikli 5 months ago

The fact that it refuses to boot is really strange.

It typically happens when Replicant cannot mount some "crucial" partitions (we need to improve that at some point, for instance for Replicant >=9 it would be a good idea to be more resilient in that reguard).

So, if we take the Galaxy Tab 2 7.0 GSM under Replicant 6.0 as an example, the /fstab.espresso file has the following:

/dev/block/platform/omap/omap_hsmmc.1/by-name/EFS               /efs                ext4        nosuid,nodev,barrier=1                                                           wait,check

So in practice the device will not boot if /efs cannot be mounted as an ext4 filesystem.

I've read the tutorial.txt procedure and mkfs.ext4 alone should normally make sure that the device boot if the filesystem was ext4 before.


Updated by Denis 'GNUtoo' Carikli 5 months ago

It's also possible to get adb during very early boot with AddingADBRootToAnImage, which potentially enable to debug boot issues like that.

Someone probably needs to reproduce all that and debug it to not have to reinstall Replicant.

Anyway since you didn't need to wipe any data, it's not the end of the world as long as people reinstall the exact corresponding version.

That can be found with ImagesIdentification. If another version is reinstalled, in some case it can make your data extremely hard to recover: if there is mismatch between the data and the OS installation between Replicant 6.0 0003 and Replicant 6.0 0004 RC1, the data partition content is then extremely hard to recover: I spent days to recover only part of the data of that partition. While the data is very easily accessible, putting it back on an incompatible version of the /data partition is complicated. And as soon as there is a missmatch and that the OS booted, you end up in this situation without any easy way to revert the effect of the boot.

Also available in: Atom PDF