[Q] ClockworkMod wipe blocking encryption? - Android Q&A, Help & Troubleshooting

Hi guys and gals,
I've been investigating why I can't enable encryption on either of my phones running CM9. I'm getting this error in logcat when I go to enable:
E/Cryptfs ( 1454): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
What I've discovered is that the dmcrypt layer requires 16kb of space at the end of the /data partition to store its volume keys. In the case of my HOX, stock recovery is smart enough to reserve those last blocks. But from what I can tell, CWM when it formats /data (to perform a wipe) formats the entire partition.
By passing an option for number of blocks (n where n is the total number of blocks - (16/blocksize)) to mke2fs at wipe time it should reserve enough space for encryption.
Looking at the cwm recovery source, I found this code for formatting ext4 volumes such as /data:
Code:
if (strcmp(fs_type, "ext4") == 0) {
int length = 0;
if (strcmp(v->fs_type, "ext4") == 0) {
// Our desired filesystem matches the one in fstab, respect v->length
length = v->length;
}
reset_ext4fs_info();
int result = make_ext4fs(device, length);
if (result != 0) {
LOGE("format_volume: make_extf4fs failed on %s\n", device);
return -1;
}
return 0;
}
So there is already a provision for a length option. The v variable is an array built from this code:
Code:
Volume* volume_for_path(const char* path) {
int i;
for (i = 0; i < num_volumes; ++i) {
Volume* v = device_volumes+i;
int len = strlen(v->mount_point);
if (strncmp(path, v->mount_point, len) == 0 &&
(path[len] == '\0' || path[len] == '/')) {
return v;
}
}
return NULL;
}
device_volumes appears to be populated from fstab, and from what i can see length will always be 0 (??) which i assume tells mkfs to always format the entire volume.
Perhaps someone more familiar with CWM's code paths (I'm a little lost) could explain how to get CWM to format the volume reserving the last 16kb?

---

Close, but the actual code in question is the following in bootable/recovery/roots.c:
Code:
static int parse_options(char* options, Volume* volume) {
char* option;
while (option = strtok(options, ",")) {
options = NULL;
if (strncmp(option, "length=", 7) == 0) {
volume->length = strtoll(option+7, NULL, 10);
...
That's reading the options from /etc/recovery.fstab (using roots.c:load_volume_table()). So all you need to do is make sure your device's recovery.fstab specifies the correct length. This is easiest done using a negative offset length of 16384. So, for a One X, update device/htc/endeavoru/recovery.fstab to add "length=-16384" to the end of the line for /data. For an example, see https://github.com/CyanogenMod/android_device_htc_pyramid/blob/ics/recovery.fstab.

---

While it would be better if indeed CWM was made smart enough to deal with this, I did make in the mean time a patch you can apply after a wipe to shrink the partition

---

cybermaus said:
While it would be better if indeed CWM was made smart enough to deal with this, I did make in the mean time a patch you can apply after a wipe to shrink the partition
Click to expand...
Click to collapse
Just played a bit with CM10.2 on my SGS3. To be honest I don't get this issue with partition size. Could you please help me to understand the following: why do we need to resize the partition if the stock ROM does not do it, neither in runtime (when encrypting) nor in flashing new ROM? How does it work on the stock ROM in comparison to CM? What's different? I'm afraid to resize the partition before I understand why I must do it (I read about this 16kb, I fully understand it, but I don't get why it's not needed by the stock ROM).
Thanks!
Maciej