Replicant

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.

• 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.

Status¶

¹ 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 device-common.mk, which is included by device.mk in the espresso3g directory.

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 "fix-permissions.sh"? 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.

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

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.

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.