Replicant

h1. RestoreEfsNvDataBackupFile

{{TOC}}

h2. Introduction

Many devices supported by Replicant have a partition with the modem data (IMEI, etc) which is called EFS.

That partition is used by Replicant to enable the modem to store data, by making files inside that partition available to the modem through a network protocol between Replicant and the modem.

The advantage of that architecture is that Replicant has more control, and the modem (which runs nonfree software) has less control over the data it uses.

However as with every other computer system, files can get corrupted, especially if the power goes away suddenly, while data is being written in some of the files.

That can happen with batteries that are in very bad conditions: very old batteries can still last several hours, but if the smartphones tries to consume too much power (mA / miliampers) at once, the battery can be unable to provide that much power at the same time, which results in the voltage dropping and the smartphone or tablets being turned off suddenly, without having the time to properly save any data it may be writing.

In addition to the issue described above, the modem data partition contains data that is crucial (like the IMEI) and we don't know (yet) how to reconstruct the files that are in that partition. And without them, the modem will not work. This is why doing a backup of the data that is in this partition is crucial.

So if you didn't do that backup yet, you can follow the instructions in the [[BackupTheEFS]] wiki page.

The [[BackupTheEFS]] page has information on which devices have a modem data partition (some devices supported by Replicant don't have a modem for instance).

h2. Warning

If you don't want your device to break, really make sure you have a backup of the modem data partition. The backup can be done with the instruction that are in the [[BackupTheEFS]] wiki page.

If all the files in the modem data partition are destroyed for a reason or another, you won't be able to receive SMS, make calls, get 3G data connections, etc.

We don't know how to repair that (yet).

h2. Restoring nv_data.bin

If only the nv_data.bin file is corrupted , you can easily restore it, without having to restore a full backup.

h3. Making a new backup

Before starting, it's a good idea to make a new backup of the modem data partition, and name it in a way that is self-explanatory. For instance you could put it in a directory named 'backup-with-corrupted-nvdata-bin' not to confuse it with other backups that do not contain any corrupted files. As repeated before, you can use the [[BackupTheEFS]] instructions to do a backup.

Making a new backup has several advantages:

* If you lost your old backups you have a new one

* If you have your old backups somewhere else (like on another computer), you don't risk erasing them by mistake

Make sure not to erase the old backups while making a new one.

At the time of writing, the [[BackupTheEFS]] contain the following command:

<pre>

REPLICANT_EFS_BACKUP_DIR=~/replicant_devices/0123456789abcdef/backup_efs

mkdir -p $REPLICANT_EFS_BACKUP_DIR && cd $REPLICANT_EFS_BACKUP_DIR

</pre>

This creates a directory named replicant_devices in your home, with inside a directory named 0123456789abcdef, with inside a directory named backup_efs.

Then it makes you go in that directory from the command line. This way the next commands will save the backups in that directory.

We can easily substitute that command with another one:

<pre>

REPLICANT_EFS_BACKUP_DIR=~/replicant_devices/backup-with-corrupted-nvdata-bin-of-fourth-jully-2020/backup_efs

mkdir -p $REPLICANT_EFS_BACKUP_DIR && cd $REPLICANT_EFS_BACKUP_DIR

</pre>

Here instead of creating the 0123456789abcdef directory, it will create one named backup-with-corrupted-nvdata-bin-of-fourth-jully-2020. We can change that as we need to make sure that the directory has a name that is self explanatory, not to confuse the half-corrupted backups with ones that are not corrupted at all.

Alternatively if the replicant_devices, 0123456789abcdef or backup_efs directories don't exist, you can also follow the [[BackupTheEFS]] and rename the directories as you wish once the backup is done. 

Or if you have an old backup, you could rename its directories to make sure you don't accidentally overwrite it.

h3. Setup ADB

The [[BackupTheEFS]] page has instructions to setup ADB. So if you just did a backup you should be good.

However if you already had an old backup somewhere and didn't do a new one, you will need to make sure that ADB is setup.

To do that, you can follow the [[ADB|setting up ADB on your computer]] instructions, so that you can access a root shell on your device.

*NOTE*: when prompted on your Replicant device, make sure that you check the box that says *Always allow from this computer* when you grant your computer USB debugging permissions. Otherwise, you will be unable to obtain root shell access on your Replicant device when you reboot it into the recovery OS to actually perform the EFS backup.

*NOTE*: for security reasons, you may want to [[BackupTheEFS#Revoke-USB-debugging-permissions|revoke these non-expiring permissions]] once the EFS backup is complete.

h3. Reboot into the recovery

You can reboot your device into the recovery by one of the following methods:

h4. Using ADB

Run the following on your computer:

<pre>

adb reboot recovery

</pre>

h4. Using your Replicant device's user interface

Do the following:

# Make sure that your device is booted under Replicant.

# Press the power button until a menu appears.

# Press *Reboot*.

# Select *Recovery* and then press *ok*.

h3. Ensure that your device's system partition is mounted

In order to get a root shell in the recovery, your devices system partition must be mounted.

On certain devices, "the system partition is already mounted":https://redmine.replicant.us/issues/1934, so you might already be able to get a root shell without mounting the system partition again.

In any case, it's still best to do the following to make sure that the system partition is mounted:

# Select *Advanced*.

# Select *Mount /system*.

# Press the back key to get back to the general menu.

h3. Copy and pasting commands

The next sections will have commands that you can copy and paste. To ensure that they work correctly it's best to:

* Type them in the same terminal window

* Copy/paste one line at the same time. For instance if you copy 10 lines and just paste then, in some cases you could have some issues.

Also to make sure that they are really executed, you can press the 'enter' key after having pasted them. 

Pressing 'enter' twice will not hurt as the command will still be executed only once.

h3. Restore the hidden nv_data.bin

The nv_data.bin file seem to be the file that is corrupted the most, probably because it is more often written to than the other files.

On most devices it can be found at several locations:

* /efs/nv_data.bin

* /efs/.nv_data.bak

The second one is a backup file. Note the '.' in front of the nv_data.bak. That dot ('.') is part of the file name. So that file name is '.nv_data.bak'.

When a file name starts with a dot, many tools (like file managers, command line utilities like 'ls', etc) will not list that file by default.

This convention enables to 'hide' some files. In GNU/Linux, this is typically used to 'hide' the configuration files used by graphical programs. Without that, it wound't be very convenient as you would see hundreds of extra files in your home. And in GNU/Linux the graphical programs still need to store their configuration somewhere.

For instance if you want to list all the files in your home in GNU/Linux, including the hidden ones you can use the following command:

<pre>

ls -a ~

</pre>

The '~' is a shortcut/alias for your home, and the '-a' switch tells ls to list all files (including the hidden ones).

So here we need to replace 'nv_data.bin' with '.nv_data.bak'. And as '.nv_data.bak' is a hidden file, we will use the concept of hidden files later on.

To do that we first need to mount the modem data partition (named efs) to a directory (here we will use /efs).

Your device should already be in the recovery, ready to accept commands through adb.

Not all the devices have their modem data partition at the same place. 

Because of that you need to follow the instructions that are specific to your device.

h4. Galaxy S 2 (I9100), Galaxy S 3 (I9300), Galaxy S 3 4G (I9305), Galaxy Note (N7000), or Galaxy Note 2 (N7100)

<pre>

adb shell "mkdir /efs"

adb shell "mount /dev/block/platform/*/by-name/EFS /efs"

</pre>

h4. Galaxy Nexus (I9250)

<pre>

adb shell "mkdir /efs"

adb shell "mount /dev/block/platform/*/*/by-name/efs /efs"

</pre>

h4. Galaxy Tab 2 7.0 (P3100)

<pre>

adb shell "mkdir /efs"

adb shell "mount /dev/block/platform/*/*/by-name/EFS /efs"

</pre>

h4. TODO: move EFS

{{stub}}

TODO

<pre>

ls -a /efs/

</pre>

TODO

We will then proceed to replace /efs/nv_data.bin by /efs/.nv_data.bak.

TODO: /efs/.nv_data.bak.md5 and /efs/nv_data.bin.md5

TODO:

<pre>

adb shell "umount /efs" 

adb shell "rmdir /efs" 

</pre>

h2. Reboot your device

Once the backup is done, you can reboot your device into Replicant by one of two ways.

You can reboot by running the following command on your computer:

<pre>

adb reboot

</pre>

Or alternatively you can use the Replicant recovery graphical user interface to reboot by selecting *Reboot system now*.

h2. Revoke USB debugging permissions

If you are concerned about security, you may want to revoke the non-expiring USB debugging permissions that you granted to your computer earlier (which you may of course grant again at any time, as desired). This control is located at *Settings* > *Developer options* > *Revoke USB debugging authorizations*.

That's it! Your device's EFS partition is now backed up. Your device should be running Replicant normally again.